Exchange valt buiten deze API/CLI-release. Eventuele historische Exchange-voorbeelden in deze gids zijn niet beschikbaar; dit zegt niets over bestaande portaalfuncties. Zie het [actuele releasebereik](/developers/guides/release-scope?lang=nl).

# Bedrijfscontacten aanmaken en het oorspronkelijke verzoek herstellen

Portal, API en Rust-CLI gebruiken de bestaande WeFact-verbinding van het portal en hetzelfde bedrijfsjournaal. De CLI verbindt niet rechtstreeks met WeFact. Het moderne bedrijf heeft één oorspronkelijke contactreservering; een verloren antwoord mag geen tweede `debtor.add` veroorzaken. Deze implementatie activeert geen productieomgeving of CLI-download. Controleer de beschikbare API-capabilities van je omgeving.

## Vooraf

Gebruik een persoonlijke verbinding van een menselijke interne beheerder met recente passkeyverificatie. Service-integraties en verbindingen met beperkte resource-regels kunnen dit globale beheer niet uitvoeren. De administratiecontext (`--account`) is afzonderlijk van het moderne doelbedrijf. Behoud beide nummers.

`admin:read` is nodig voor overzicht, review en SQL-status. Aanmaken en hervatten vereisen `admin:write`, actieve API-schrijf-, beheer- en gevoelige-actie-instellingen en een werkende, ongewijzigde accountingverbinding. Uitsluitend-lezen leveranciersherstel vereist actuele `admin:read` én de huidige `admin:write`-bevoegdheid van de persoonlijke verbinding, recente sterke verificatie en dezelfde oorspronkelijke mens/securitygeneratie. Dat herstel kan ook wanneer nieuwe API-writes of leverancierswrites tijdelijk zijn uitgeschakeld. Een uitgeschakelde of gewijzigde leveranciersverbinding wordt niet omzeild.

## In het portal

Open **Beheer → WeFact → Bedrijfscontact aanmaken**. Vul het moderne bedrijf-ID in en kies **Bedrijfscontact controleren**. Controleer de actuele bedrijfsnaam, factuurgegevens en klantcode. De review vervalt na tien minuten. Bij een bestaande ondertekende incassomachtiging meldt de pagina dat de huidige machtiging wordt meegestuurd; bank- en machtigingswaarden worden niet op de reviewpagina afgedrukt. De volledige oorspronkelijke payload, inclusief zulke verborgen waarden, is wel aan de goedkeuring gebonden.

Bevestig de selectie en kies **Contact aanmaken of bevestigen**. Er wordt geen factuur, betaling of e-mail gemaakt. Het bestaande canonieke bedrijfscontact kan worden gelezen; een nieuw contact vereist één originele add en volledige exacte teruglezing voordat de lokale bedrijfskoppeling zichtbaar wordt. De lokale bankrekening en machtiging worden niet gewijzigd.

Bij onzekerheid vergrendelt de pagina de aanmaakactie. Kies **Oorspronkelijke poging controleren**. Herstel nooit door opnieuw op aanmaken te drukken, een andere sleutel te kiezen of een vergelijkbaar contact te koppelen. De status en oorspronkelijke UUID blijven opnieuw opvraagbaar met het bedrijf-ID, ook na het opnieuw openen van de pagina.

## API-contract

Alle onderstaande paden staan onder `/api/v1/accounts/{administratiecontext}`. `company` is het moderne doelbedrijf; `resolution` is de oorspronkelijke UUID. JSON-antwoorden staan in `data` en gebruiken `Cache-Control: no-store`.

| Methode | Pad | Gedrag |
|---|---|---|
| GET | `admin/wefact` | Lokale aantallen en beschikbaarheid; geen leverancier |
| POST | `admin/wefact/contact-review` | Exacte lokale review; geen leverancier of reservering |
| POST | `admin/wefact/contact-ensure` | Eén beoordeeld oorspronkelijk contact; `Idempotency-Key` en `If-Match` verplicht |
| GET | `admin/wefact/companies/{company}/contact-resolution` | Vind de oorspronkelijke reservering na een verloren antwoord |
| GET | `admin/wefact/companies/{company}/contact-resolutions/{resolution}` | SQL-status van de exacte oorspronkelijke UUID |
| POST | `admin/wefact/companies/{company}/contact-resolutions/{resolution}/actions/reconcile` | Alleen exact leverancierscontact lezen en oorspronkelijke lokale koppeling afronden |
| POST | `admin/wefact/companies/{company}/contact-resolutions/{resolution}/actions/resume` | Expliciet de oorspronkelijke eerste verzending hervatten, uitsluitend bewezen nooit verstuurd |

Vraag een review met `{"company_id":42}`. De server retourneert `company.id`, `company.name`, `company.version`, veilige `contact`-velden, `existing_mandate_included`, `reviewed_at`, `expires_at` en `review_token`. Bewaar de review in een beschermd bestand, niet in logs of een gedeelde map. De token bindt de huidige menselijke identiteit, securitygeneratie, persoonlijke verbinding, administratiecontext, bedrijfsversie, volledige payload en leveranciersbron.

Stuur voor ensure exact dit contract, met `If-Match` gelijk aan `company_version`:

```json
{
  "company_id": 42,
  "company_version": "<64 hextekens uit de review>",
  "reviewed_at": 1793250000,
  "review_token": "<64 hextekens uit de review>",
  "confirm_company_id": 42
}
```

De tijd en tokens hierboven zijn vormvoorbeelden; gebruik altijd de actuele serverreview. `dry_run:true` of `X-Binadit-Dry-Run:true` valideert de ensure zonder contactjournaal, API-operatie of leverancierseffect. Een echte ensure retourneert onder meer `company_id`, `remote_identifier`, `debtor_code`, `resolution_id`, `linked`, `local_bank_details_changed:false` en `invoice_created:false`. Bij een al bestaand legacycontact zonder dit administratiejournaal kan `resolution_id` null zijn. De nieuwe bedrijfskoppeling en de oorspronkelijke API-operatie worden in dezelfde lokale transactie bevestigd.

## Status na onzekerheid

`contact-resolution` en de exacte statusroute lezen uitsluitend SQL. Zij tonen de oorspronkelijke resolution/intent/company-ID's, `state`, `provider_attempted`, `prepared_without_dispatch`, `original_add_acknowledged`, `verified_remote_identifier`, `reply_origin` en `requires_reconciliation`. Zij geven geen oorspronkelijke payload, bankwaarden, sleutel of privé-ontvangstbewijsreferentie terug. Hun `supplier_reads:false` en `supplier_mutations:false` beschrijven deze statusaanvraag.

Een nieuwe persoonlijke verbinding of het portal van **dezelfde huidige mens, securitygeneratie en administratiecontext** mag dit oorspronkelijke bewijs lezen en expliciet herstellen, ook als de oorspronkelijke poging via het andere kanaal begon. De actuele adapter controleert zijn eigen volledige rol-, scope- en passkeybeleid. De opgeslagen oorspronkelijke principal, goedkeuring en API-operatie worden niet vervangen. Een andere mens/securitygeneratie of een gewijzigd bedrijf, leveranciersbron of bewijs wordt geweigerd.

| Status | Betekenis en volgende stap |
|---|---|
| `prepared` / `blocked`, `prepared_without_dispatch:true` | Bewijs bevestigt dat de oorspronkelijke verzending nog niet is begonnen. Een expliciete nieuwe review en **resume** kunnen uitsluitend die eerste verzending uitvoeren. |
| `dispatching` / `uncertain` | De leverancier kan de add hebben geaccepteerd. Gebruik uitsluitend **reconcile**; nooit resume of een nieuwe add. |
| `confirmed` | De oorspronkelijke exacte koppeling is lokaal bevestigd. Dit zegt niets over factuurbetaling of een nieuw contract. |

Een ontbrekende reservering kan nog behoren bij een lopend oorspronkelijk verzoek. Gebruik afwezigheid niet als reden om automatisch een nieuwe aanmaak te starten. Een oud journaal zonder verifieerbaar administratiebewijs wordt niet automatisch als nieuwe goedkeuring overgenomen.

## Uitsluitend-lezen leveranciersherstel

Lees eerst de oorspronkelijke SQL-status en de actuele bedrijfsversie via een nieuwe lokale review. Bevestig de exacte oorspronkelijke UUID, het bedrijf en de huidige versie. `If-Match` moet dezelfde actuele bedrijfsversie bevatten.

```json
{
  "confirm_resolution_id": "<oorspronkelijke resolution-UUID>",
  "confirm_company_id": 42,
  "company_version": "<actuele 64 hextekens>",
  "confirm_no_supplier_mutation": true
}
```

Als een positieve oorspronkelijke add-ID bewaard is, leest de server uitsluitend dat exacte contact. Als het oorspronkelijke antwoord geen ID bevatte, zijn aanvullend `verified_remote_identifier` (positief geheel getal) en `supplier_receipt_reference` (privéreferentie van maximaal 1000 tekens) verplicht. Selecteer dat ID alleen uit de **gecontroleerde oorspronkelijke leveranciersbevestiging**. Een naam, factuuradres, klantcode of zoekmatch is onvoldoende eigendomsbewijs.

De referentie is de verklaring van de actuele bevoegde beheerder. De server authenticeert geen extern ontvangstbewijsdocument cryptografisch. Zij controleert het expliciete ID wel via `debtor.show`, de exacte oorspronkelijke serverklantcode, volledige oorspronkelijke payload en unieke huidige/gearchiveerde bedrijfseigendom. Onjuist, ontbrekend of tegenstrijdig bewijs behoudt de oorspronkelijke hold. Er wordt niet gezocht en nooit opnieuw toegevoegd.

Herstel retourneert dezelfde oorspronkelijke status met `supplier_reads:true` en `supplier_mutations:false`. `reply_origin:operator_readback` wordt onderscheiden van `original_add`; een handmatige teruglezing wordt niet als ontvangst van de oorspronkelijke add-ACK voorgesteld. Een succesvol herstel bevestigt de oorspronkelijke lokale koppeling en oorspronkelijke ouderoperatie. Het maakt geen nieuwe API-operatie, factuur, e-mail of leverancierseffect aan.

## Expliciet hervatten van een nooit verstuurde reservering

**Resume is een schrijfactie en kan de oorspronkelijke eerste add uitvoeren.** Het is geen reconcile. Gebruik het uitsluitend bij `prepared_without_dispatch:true`, met een nieuwe actuele review, `If-Match`, `confirm_resolution_id` en `confirm_no_previous_dispatch:true`, naast de normale ensure-reviewvelden. Nieuwe writes moeten beschikbaar zijn. Stuur geen nieuwe `Idempotency-Key` en geen dry-run; de exacte oorspronkelijke UUID is de duurzame reservering.

Binnen de canonieke vergrendelde voorbereiding moet de oorspronkelijke reservering nog steeds geen dispatchgetuige, ACK-ID of herstelkandidaat hebben. Een race, gewijzigde bron/payload, onzekere/uitgevoerde add of bestaande koppeling wordt geweigerd. De oorspronkelijke context, principal en ouderoperatie blijven behouden. Succes rapporteert `supplier_reads:true` en `supplier_mutations:true`; opnieuw hervatten wordt geweigerd. Een onzeker resume-resultaat gaat vervolgens uitsluitend via oorspronkelijke status/reconcile verder.

## Rust-CLI

De zeven onderstaande Rust-opdrachten zijn aanvullingen op de bevroren 355 referentieopdrachten. Gebruik een actuele beschikbare Rust-build en persoonlijke beheerdersverbinding. Bescherm bestanden met `umask 077`; de CLI weigert onveilige invoerbestanden. `--input -` leest beschermd aangeleverde JSON van stdin. Privéreferenties horen nooit als shell-argument in de proceslijst.

```sh
binadit admin wefact overview --account 1
umask 077
binadit admin wefact review-contact 42 --account 1 --output json > contact-review.json
binadit admin wefact ensure-contact --account 1 --confirm-company 42 --input contact-review.json --yes
binadit admin wefact contact-status 42 --account 1
binadit admin wefact contact-resolution 42 ORIGINAL_RESOLUTION_UUID --account 1
```

Maak voor reconcile een beschermd `contact-recovery.json` met de JSON uit de herstelsectie; voeg uitsluitend indien nodig het gecontroleerde oorspronkelijke ID en de privéreferentie toe:

```sh
binadit admin wefact reconcile-contact 42 ORIGINAL_RESOLUTION_UUID --account 1 \
  --confirm-company 42 --confirm-resolution ORIGINAL_RESOLUTION_UUID \
  --input contact-recovery.json --yes
```

Voor het afzonderlijke nooit-verstuurd-geval haalt u eerst een verse review op:

```sh
binadit admin wefact review-contact 42 --account 1 --output json > contact-review.json
binadit admin wefact resume-contact 42 ORIGINAL_RESOLUTION_UUID --account 1 \
  --confirm-company 42 --confirm-resolution ORIGINAL_RESOLUTION_UUID \
  --input contact-review.json --yes
```

Reconcile en resume vereisen hun eigen expliciete oorspronkelijke UUID. Zij gebruiken geen nieuwe automatische HTTP-intent en proberen een mislukte POST niet automatisch opnieuw. Resume controleert daarnaast de actuele schrijf-capability. De normale ensure blijft aan haar oorspronkelijke lokale sleutel en persoonlijke verbinding gebonden.

Na succesvol leveranciersherstel kan een oude automatische ensure-intent lokaal nog vaststaan. Gebruik daarvoor uitsluitend de [oorspronkelijke-operatiehandleiding](/developers/guides/original-operations?lang=nl), met de exacte oude principal, sleutel, methode, pad en oorspronkelijke beschermde body en expliciet `api --confirm-original-operation ORIGINAL_OPERATION_UUID`. Die bevestiging leest SQL, wist alleen de passende geslaagde lokale pending-aanvraag en stopt; zij verstuurt de ensure niet nogmaals. De operation-UUID en resolution-UUID zijn verschillende referenties.

## Beveiliging en agentregels

Elke lokale afronding controleert de werkelijk opgeslagen bedrijfskoppeling, journaalvelden, oorspronkelijke operatie en auditregel; een door modelhooks geannuleerde of gewijzigde save is geen succes. Ongevraagde bedrijfsvelden moeten ongewijzigd blijven. Positieve originele leveranciers-ACK-evidence wordt apart onder rijvergrendeling vastgelegd, ook als zakelijke modelhooks of latere autorisatie de lokale publicatie weigeren. Het oorspronkelijke API-envelope en provenance worden met de bestaande oorspronkelijke-operatie-MAC geverifieerd vóór herstel en publicatie; oude of gewijzigde ontbrekende bewijsvelden blijven geblokkeerd.

De bestaande brongebonden bedrijfsreservering blijft canoniek. Encryptie beschermt privécontext en herstelreferenties; afzonderlijke keyed bindingen beschermen oorspronkelijke context, dispatchgetuige, ACK/herstel-ID en afronding. Een statusreset wist die onafhankelijke getuige niet. Elke fase controleert actuele identiteit, rol, bedrijf, bron en de definitieve pure tijdsgrens; leveranciersverkeer loopt buiten lokale transacties. De SDK controleert direct vóór verzending de werkelijke methode, HTTPS-URL, Host, TLS/redirectinstellingen en volledige JSON tegen het bedoelde verzoek. Sleutels worden niet afgedrukt. Adds worden niet automatisch herhaald.

Bewaar als gebruiker of agent het oorspronkelijke bedrijf, de context, review, request key, principal, operation-UUID en resolution-UUID. Maak geen nieuwe sleutel of leverancier-ID om een onzekere uitkomst te omzeilen. Verwijder of wijzig geen journalen om verder te gaan. Rapporteer contactkoppeling, originele ACK, handmatige teruglezing en betaling afzonderlijk. Een bevestigde contactkoppeling is geen betalingsbewijs en staat geen wijziging van een externe overeenkomst of machtiging toe.