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.
Bedrijfseigendom van domeinen en bestaande facturering
Implementatiestatus: beoordeelde lokale bedrijfsoverdracht voor native portaalovereenkomsten, gratis overeenkomsten en expliciet ongefactureerde overeenkomsten is geïmplementeerd in de gedeelde service, API, getypeerde CLI en het bevestigingsscherm in het portaal. Bestaande WeFact-overeenkomsten gebruiken de afzonderlijke, expliciet beoordeelde migratie met één poging en het uitsluitend-lezen herstelproces hieronder. Gewone overdracht weigert deze overeenkomsten nog steeds met domain_ownership_wefact_migration_required. Inspectie-/importcommando's voor de registrar behouden de bestaande eigenaar en staan los van bedrijfsoverdracht.
Een wijziging van het verantwoordelijke portaalbedrijf moet oorspronkelijke facturen en betaalde perioden behouden. Zij mag geen historische factuur hernoemen, de schuld naar het doelbedrijf verplaatsen of stilzwijgend een overlappende jaarovereenkomst starten. Een juridische houderwijziging bij de registrar is een afzonderlijke handeling.
Bevestiging in het portaal
Een beheerder selecteert maximaal 25 domeinen en het doelbedrijf in het bestaande domeinoverzicht en opent Bedrijfsoverdracht beoordelen. Deze selectie gebruikt moderne portaalbedrijfs-ID's. De volgende pagina toont per domein het oorspronkelijke en nieuwe bedrijf, de prijs per volledige periode, de behouden jaarverplichting en de toekomstige factureringsstart. Voer het doelbedrijfsnummer in en bevestig de beoordeling expliciet. Een actuele, gebruikersgebonden passkeygoedkeuring is vereist voordat de server de eigendom beoordeelt of overdraagt.
Elk geselecteerd domein behoudt zijn eigen oorspronkelijke verzoek en duurzame ontvangstbevestiging. Een fout stopt de reeks; voltooide overdrachten blijven voltooid. Gebruik na een onzeker antwoord Het oorspronkelijke verzoek inspecteren. Een geverifieerd voltooid ontvangstbewijs staat doorgaan met het volgende domein toe; expliciet hervatten van een onopgelost verzoek behoudt dezelfde oorspronkelijke body en identificatie. Een mislukte inspectie maakt geen nieuw verzoek. Oude, onbeoordeelde toewijzingsverzoeken worden geweigerd.
Een ondersteunde native overeenkomst beoordelen en overdragen
Gebruik een actuele menselijke beheerdersmachtiging met admin:read, admin:write en recente passkeygoedkeuring. --account is de goedgekeurde beheercontext; --target-account is een afzonderlijk modern bedrijfs-ID. Het domein-ID is het lokale portaal-ID, niet het registrar-ID bij de leverancier.
binadit admin domains ownership plan 42 --target-account 99 --account 1 --output json
Lees het oorspronkelijke bedrijf, doelbedrijf, betalingsbeleid van het doel, prijs per volledige periode, behouden oorspronkelijke verplichtingen en eerste nieuwe factureringsdatum. Kopieer domain_version, plan_version, period_price_excl, reviewed_at en intent_id uit precies deze beoordeling. Voeg --start-billing consequent toe aan zowel beoordeling als overdracht, uitsluitend wanneer het de bedoeling is een bekende bestaande gratis overeenkomst voor toekomstige perioden betaald te maken.
binadit admin domains ownership transfer 42 \
--target-account 99 --confirm-target-account 99 --confirm-domain 42 \
--version "$DOMAIN_VERSION" --plan-version "$PLAN_VERSION" \
--period-price "$PERIOD_PRICE_EXCL" --reviewed-at "$REVIEWED_AT" \
--intent-id "$INTENT_ID" --account 1 --dry-run
De preview controleert dezelfde resource en hetzelfde ondertekende plan zonder een operatie te reserveren of eigendom te wijzigen. Dien dezelfde opdracht zonder --dry-run in nadat je de echte bedrijven en perioden hebt beoordeeld; gebruik de normale interactieve bedrijfsbevestiging of expliciet --yes voor beoordeelde automatisering. Bewaar bij een onbekend resultaat de oorspronkelijke intentie en client-idempotentiesleutel. Dezelfde voltooide eigendoms-UUID kan zijn oorspronkelijke lokale ontvangstbewijs herstellen; hij kan niet aan een ander bedrijf, een andere prijs of beoordeling worden gebonden. Deze native overdracht maakt geen registrarverzoek, factuur, betaling of leverancierstaak aan.
De HTTP-equivalenten zijn GET /api/v1/accounts/{context}/admin/domains/{domain}/ownership-plan met target_account_id en start_billing, gevolgd door POST /api/v1/accounts/{context}/admin/domains/{domain}/actions/transfer-company. De POST vereist de exacte domein-If-Match, duurzame Idempotency-Key en beoordeelde bevestigingsvelden. Oorspronkelijke facturen en eerdere volledige jaarverplichtingen blijven bij het bronbedrijf. Oude private contactverwijzingen worden verwijderd; registrarhouders, DNS-providerconfiguratie en hostingeigendom worden niet gewijzigd. Een private DNS-verbinding/-groep van een ander bedrijf, een wachtende geplande DNS-wijziging of onopgeloste oorspronkelijke aankoop moet eerst expliciet worden opgelost.
Bestaande native jaarovereenkomst
DomainOwnershipPeriods is een uitsluitend-lezen planner met dezelfde addMonths-opbouw als de canonieke maandfactuurplanner. Hij accepteert volledige jaarperioden met een samenhangende betaalcursor en zonder openstaande factuur of opzegging. Elk reeds begonnen jaar en elke ongefactureerde achterstand blijven bij het bronbedrijf; de eerste periode van het doelbedrijf begint op de volgende oorspronkelijke jaargrens. Reeds gefactureerde toekomstige jaren blijven gedekt tot hun exacte oorspronkelijke einddatum.
Een ongefactureerd jaar januari–december 2026 blijft bijvoorbeeld verschuldigd aan het oorspronkelijke bedrijf wanneer de verantwoordelijkheid in oktober verandert. Het eerste jaar van het nieuwe bedrijf begint op 1 januari 2027. Een contract dat reeds tot en met 31 december 2028 is gefactureerd, kan het nieuwe bedrijf niet vóór 1 januari 2029 belasten. Tests voeren de echte native monthLines()-planner uit tegen deze voorgestelde oude/nieuwe grenzen. Dit onderdeel maakt zelf geen vervangende overeenkomst of eigendomswijziging.
Bestaande WeFact-overeenkomst
DomainOwnershipCoverage voert uitsluitend subscription.show en invoice.show uit via de geconfigureerde canonieke boekhoudclient. De service controleert vóór en na leveranciersreads de actuele actor, het bedrijf, de resource, debiteur en lokale contractbindingen. Zij levert een vaste metadataprojectie; zij beëindigt nooit een overeenkomst, voert geen betaling uit en wijzigt geen lokale eigendom.
Het ondersteunde interoperabiliteitsdeel vereist alles hieronder:
- Eén exacte lokale domeinovereenkomst en één exact extern contract/debiteur in EUR.
- Aantal één, overeenkomend product/basisprijs en een factureringsperiode van hele jaren.
- Een expliciete huidige cyclus waarvan de inclusieve einddatum gelijk is aan begin plus contractperiode min één dag en waarvan de volgende factuurdatum de dag daarna is.
- Voor een betaald contract een expliciet geselecteerde, volledig betaalde leveranciersfactuur en precies één regel waarvan
PeriodicID, aantal, product, prijs, korting, periode-eenheid/-aantal en inclusieve datums met dat contract en die cyclus overeenkomen. - Geen bekende lokale intrekking, terugbetaling, opzegging, factuurbinding met een ander bedrijf of dubbele oude bedrijfskoppeling.
Een kosteloze overeenkomst kan zonder verzonnen betaalde factuur worden bewezen. Ontbrekend, dubbelzinnig of tegenstrijdig bewijs geeft domain_billing_coverage_unverified; een ontbrekende geselecteerde factuur voor een betaalde overeenkomst geeft domain_paid_period_review_required.
De primaire abonnementsdocumentatie en factuurdocumentatie beschrijven deze velden. Hun voorbeelden bewijzen niet de volledige relatie of de betekenis van de huidige cyclus voor iedere historische WeFact-installatie. Bovenstaande controles zijn expliciete runtimevoorwaarden, geen bewering dat alle historische overeenkomsten eraan voldoen. Een uitsluitend-lezen productieselectie vond geen actieve lokale domeinovereenkomst, zodat geen echte leveranciersovereenkomst beschikbaar was om deze weergave te verifiëren. Testgegevens demonstreren geaccepteerde en geweigerde protocolvormen; zij zijn geen productiebewijs. Een onverenigbare overeenkomst vereist boekhoudkundige reconciliatie vóór iedere eigendoms- of factureringswijziging.
De private terugleeshelper bindt ook de geconfigureerde boekhoudbron. Hij leest hetzelfde contract en de geselecteerde betaalde factuur opnieuw, vergelijkt alle beoordeelde commerciële velden en de exacte factuurregelidentiteit en vereist dat TerminationDate gelijk is aan de goedgekeurde inclusieve dekkings-einddatum. Een andere bron, ontbrekende of afwijkende opzegdatum, gewijzigde regel of ingetrokken betaling kan de oorspronkelijke overeenkomst niet bevestigen. Deze helper wijzigt lokaal niets.
De afzonderlijke gedeelde migratieservice implementeert een duurzame poging en terugleesgrens. Voorbereiding en de ene verzendingsreservering worden atomair vastgelegd vóór boekhoud-HTTP. Een onzeker antwoord behoudt het oorspronkelijke bedrijf en de intentie; reconciliatie leest het exacte oorspronkelijke betaalde contract voordat atomair een toekomstige portaalovereenkomst wordt gemaakt. De nieuwe overeenkomst begint de dag na de oorspronkelijke inclusieve dekkings-einddatum; het oude contract en de facturen behouden hun oorspronkelijke bedrijf. De oorspronkelijke ondertekende eindgrens kan ook na die datum worden gereconcilieerd; een nieuwe beoordeling vereist nog steeds een huidige cyclus.
Een bestaande WeFact-overeenkomst beoordelen en migreren
Selecteer in het portaal één domein en open zijn WeFact-migratie vanaf de gewone bedrijfsoverdrachtspagina. De domeinkiezer van het bedrijfsaccount opent ook deze beoordeling; het vroegere directe toewijzingseindpunt kan de eigenaar niet veranderen. Voer de exacte externe WeFact-factuur-Identifier in en beoordeel het oorspronkelijke bedrijf, doelbedrijf, betaalde dekking, toekomstige prijs per volledige periode en betalingsbeleid van het doel. Bevestig het doelbedrijfsnummer en de specifieke migratie met een actuele persoonlijke beheerderspasskey. Een kosteloos oorspronkelijk contract vereist expliciete kosteloze beoordeling; ontbrekende facturen gelden nooit als betaalde dekking.
De getypeerde CLI gebruikt dezelfde service en houdt de beheercontext gescheiden van het doelbedrijf:
binadit admin domains ownership plan-wefact 42 \
--target-account 99 --paid-invoice-id 900 --account 1 --output json
Gebruik --zero-cost-contract in plaats van --paid-invoice-id uitsluitend voor een bewezen kosteloze oorspronkelijke overeenkomst. Kopieer de exact geretourneerde velden naar de opdracht:
binadit admin domains ownership migrate-wefact 42 \
--target-account 99 --paid-invoice-id 900 \
--confirm-target-account 99 --confirm-domain 42 \
--version "$DOMAIN_VERSION" --plan-version "$PLAN_VERSION" \
--period-price "$PERIOD_PRICE_EXCL" --reviewed-at "$REVIEWED_AT" \
--intent-id "$INTENT_ID" --account 1 --dry-run
Verwijder --dry-run na beoordeling en bevestig het beheerbedrijf expliciet, of gebruik --yes --no-input voor beoordeelde automatisering. De CLI leest hetzelfde ondertekende plan met zijn oorspronkelijke tijdstempel opnieuw. Preview maakt geen operatie, clientmutatiesleutel, beëindiging of eigendomswijziging. Echte indiening bewaart vóór één POST één stabiele client-idempotentiesleutel; een antwoord wordt pas geaccepteerd als het exacte domein, doel, oorspronkelijke intentie, eindgrens en toekomstige start overeenkomen. De lokale sleutel blijft na een mislukt of tegenstrijdig antwoord behouden.
Bij een onbekende uitkomst eindigt de CLI met code 4 en vermeldt de oorspronkelijke migratie-UUID en aanvraagsleutel. Vraag geen nieuw plan aan om een onzekere beëindiging opnieuw te proberen. Inspecteer eerst het oorspronkelijke ontvangstbewijs; dit verzoek doet geen leveranciersaanroepen:
binadit admin domains ownership migration-status 42 \
--intent-id "$INTENT_ID" --account 1 --output json
Gebruik voor een wachtend ontvangstbewijs de huidige domain_version, het oorspronkelijke doel, prijs en intentie voor uitsluitend-lezen reconciliatie:
binadit admin domains ownership reconcile-wefact 42 \
--intent-id "$INTENT_ID" --confirm-intent "$INTENT_ID" \
--target-account 99 --confirm-target-account 99 --confirm-domain 42 \
--version "$CURRENT_DOMAIN_VERSION" --period-price "$PERIOD_PRICE_EXCL" \
--account 1 --yes --no-input
Nieuwe beëindigingen reserveren het canonieke abonnementsjournaal en het oorspronkelijke eigendoms-/API-ontvangstbewijs in één lokale commit. Dezelfde oorspronkelijke intentie, bron, bedrijf, contract en betaalde eindgrens binden beide journalen. De ene leveranciersverzending begint pas nadat die reservering is gecommit; de bevestiging blijft bij een latere lokale fout behouden. Spiegelbeëindiging, doeleigendom, vervangende overeenkomst en oorspronkelijk API-resultaat worden daarna atomair gepubliceerd na uitsluitend-lezen bevestiging. Eerder uitgerolde eigendomsbewijzen behouden hun oorspronkelijke uitsluitend-lezen herstel; zij reserveren nooit een nieuwe leveranciersmutatie ter vervanging van een onzeker oud verzoek. Een reeds ingeplande exacte leverancierseindgrens vereist evenmin een nieuwe beëindiging.
Na een gestopte worker blijven zijn duurzame bedrijfsclaims vastgehouden. Een Binadit-beheerder moet het herstel van een gestopte uitvoerder op de vastgelegde host gebruiken om te bewijzen dat die uitvoerder is gestopt en uitsluitend zijn exacte claims vrijgeven. Inspecteer en reconcilieer daarna dezelfde oorspronkelijke migratie-UUID. Een claim vrijgeven verzendt of bevestigt geen financiële mutatie.
Reconciliatie controleert het oorspronkelijke betaalde contract en de exacte beëindigingsdatum en rondt uitsluitend de oorspronkelijke lokale overdracht af. Zij kan geen beëindiging versturen. Zij blijft bruikbaar na de oorspronkelijke dekkingsdatum. Een gelijktijdige domeinwijziging kan een nieuwe metadata-inspectie en versie vereisen; dat wijzigt alleen het uitsluitend-lezen reconciliatieverzoek, niet de oorspronkelijke financiële intentie. Een expliciete migrate-wefact --recover --confirm-intent "$INTENT_ID" met de volledige ongewijzigde oorspronkelijke argumenten kan de oorspronkelijke POST/sleutel herhalen nadat het ontvangstbewijs inspecteerbaar is. Dit haalt nooit een nieuwe offerte op en probeert nooit zelfstandig opnieuw; gebruik bij een wachtende beëindiging bij voorkeur de uitsluitend-lezen reconciliatieopdracht.
Het portaal bewaart vóór verzending dezelfde oorspronkelijke intentie en body. Na een dubbelzinnig antwoord is Inspecteren vereist voordat een andere actie beschikbaar wordt. Een wachtend ontvangstbewijs staat alleen uitsluitend-lezen reconciliatie toe. Bewezen afwezigheid staat een expliciete herhaling van hetzelfde verzoek toe; er wordt nooit een vervangende UUID gereserveerd. Verloren browseropslag kan een op de server bekende intentie door inspectie herstellen.
HTTP-equivalenten onder /api/v1/accounts/{context}/admin/domains/{domain}:
GET wefact-ownership-plan?target_account_id=99&paid_invoice_id=900;POST actions/migrate-company-billingmet de beoordeelde bevestigingen,paid_invoice_id,intent_id,reviewed_at,plan_versionen exacteperiod_price_excl, plus de oorspronkelijke domein-If-Matchen idempotentiesleutel;GET ownership-migrations/{originalIntentUUID}voor veilige lokale voortgang;POST ownership-migrations/{originalIntentUUID}/actions/reconcilemetconfirm_domain_id,confirm_intent_iden huidigedomain_version, dezelfde versie inIf-Matchen een eigen stabiele idempotentiesleutel. Dry-run wordt ondersteund.
Actuele actor, context, passkeytermijn, bedrijfsbindingen en betalingsbeleid van het doel worden opnieuw gecontroleerd bij de daadwerkelijke effectgrenzen. Oorspronkelijke facturen, het oude bedrijfscontract en zijn hele betaalde periode behouden het bronbedrijf. De vervangende native overeenkomst begint de volgende dag; migratie maakt geen factuur voor de huidige periode, betaling, registrarwijziging of DNS-providerwijziging. Een oorspronkelijke mislukte API-operatie blijft historisch; volg het oorspronkelijke migratiebewijs en de reconciliatieoperatie voor het opgeloste resultaat.
Tests gebruiken synthetische leveranciersantwoorden en een tijdelijke echte MariaDB-instantie; er is geen productiebeëindiging uitgevoerd. Commercieel runtimebewijs blijft verplicht: een niet-ondersteunde historische datum-/factuurweergave wordt vóór beëindiging geweigerd in plaats van geraden.
Ontvangstbewijzen in de Rust-CLI
De Rust-handlers valideren de echte portaal-DTO's, inclusief exacte bedrijfs- en domein-ID's, ondertekende beoordelingsversies, periodeprijzen met twee decimalen, actuele ETags en oorspronkelijke operatiemetadata. Een native bedrijfsoverdracht reserveert een eigen transfer_id; de overdrachts-ID van een WeFact-migratie is zijn oorspronkelijke zakelijke intentie-UUID. Geen van beide is een API-operatie-ID.
Voor migrate-wefact --recover wordt een geverifieerde voltooide oorspronkelijke migratie na de uitsluitend-lezen status-GET geretourneerd en stopt de opdracht zonder POST. Een onvolledige oorspronkelijke migratie blijft onder de hierboven beschreven regels voor oorspronkelijk verzoek en reconciliatie vallen. Gebruik na opnieuw verbinden de gedocumenteerde uitsluitend-lezen inspectie; de algemene CLI-principal-/herstelvrijgavecontrole moet slagen voordat mutatieherhaling over verbindingen heen wordt ondersteund. Een mislukt of ontbrekend antwoord staat nooit een vervangende beëindiging of intentie toe. --wait volgt alleen een gevalideerde geretourneerde operatie en dient geen andere eigendomsmutatie in.