Bevar informasjon om slettede kildeobjekter
Et objekt som mangler i neste fil, er ikke automatisk slettet fra kilden.
Et kildeobjekt kan slettes, deaktiveres eller falle utenfor et nytt filter. Alle tre tilfeller kan se ut som fravær i neste eksport. Mottakeren trenger en dokumentert regel for hva fraværet betyr. Ikke slett lokale objekter bare fordi de ikke finnes i en ufullstendig fil.
Skill aktivt register fra historisk dokumentasjon. En kunde kan være inaktiv for nye salg, men fortsatt ha fakturaer og åpne poster som må kunne gjenfinnes. En registerendring skal ikke bryte disse forbindelsene.
En kunde som forsvinner fra neste uttrekk
Syntetisk eksempel med lokal kundenøkkel K-41.
| Leveranse | Opplysning | Mulig forklaring |
|---|---|---|
| Første komplette uttrekk | K-41 finnes | Aktiv eller inkludert kunde |
| Neste deluttrekk | K-41 mangler | Filteret omfatter ikke kunden |
| Eksplisitt endringspost | K-41 deaktivert | Ny tilstand kan behandles |
| Feil lokal sletting | K-41 fjernes med dokumentkoblinger | Historiske fakturaer mister referansen |
Den andre raden beviser ingen sletting. Den tredje gir mer informasjon, men krever fortsatt avtalt betydning for deaktivering.
Beskriv endringstypen i kontrakten
Hvis kilden leverer en slette- eller deaktiveringshendelse, må den ha stabil identitet og et forståelig tidspunkt. En lokal slettemarkør er en kontraktsdel, ikke et nytt offentlig standardfelt som dere kan anta at alle systemer støtter.
Ved komplette øyeblikksbilder må dere bekrefte at leveransen faktisk er komplett før fravær tolkes. En mislykket del av eksporten kan ellers utløse massesletting i mottaket.
- Test sletting og deaktivering som forskjellige scenarioer.
- Bevar identitet og relevant historikk.
- Kontroller åpne poster før aktiv status endres.
- Undersøk om manglende objekt skyldes leveransefeil.
- Dokumenter hvordan gjenopprettet objekt behandles.
Teknisk støtte er ikke samme som dokumentregel
PostgreSQLs logiske replikering beskriver blant annet at oppdatering og sletting trenger egnet radidentitet. Det illustrerer behovet for en stabil nøkkel i endringsflyt. En vanlig CSV-eksport får ikke denne egenskapen automatisk.
Denne veiledningen bestemmer ikke hva virksomheten lovlig kan eller må slette fra bokføringsdokumentasjon. Det er et eget spørsmål som må vurderes etter dokumenttype og gjeldende regler. Den tekniske kontrollen skal bevare nødvendige forbindelser frem til avklaringen er gjort.
Godkjenn når mottakeren kan skille manglende levering fra faktisk endring, og historiske dokumenter fortsatt kan forklares.
Se referanseintegritet og sen kildeendring.
Prøv også at kunden reaktiveres med samme stabile nøkkel. Historiske fakturakoblinger skal fortsatt være tilgjengelige, og mottaket skal ikke opprette en ny juridisk part bare fordi aktiv status endres. Hvis kilden faktisk oppretter et nytt objekt, må den forskjellen dokumenteres i identitetsmodellen.