Jednosměrný filtr v inkrementálním syncu — storno se nikdy nepropaguje

Situace

Zdrojový systém (CRM/účetnictví) synchronizuje doklady do analytické platformy inkrementálně (updatedAt >= poslední_sync). Dotaz obsahuje zdánlivě rozumný filtr status: { not: "CANCELLED" } — „storna přece neposíláme”.

Past

Filtr funguje jako jednosměrné dveře: zabrání vložení storna, ale zároveň zabrání aktualizaci dokladu, který byl odeslán platný a stornován až poté. Storno změní updatedAt, inkrementální okno by ho zachytilo — ale status filtr ho vyhodí. Cílový systém drží mrtvou kopii navždy: u faktur to znamená falešné pohledávky po splatnosti (v reálném případě přes polovinu vykázané sumy), špatné manažerské priority a ztrátu důvěry v čísla.

Sekundární varianty téže pasti: DRAFT doklady, které projdou (koncept není pohledávka), a dobropisy se zápornou částkou počítané do “dokladů po splatnosti”.

Řešení

1. Kontrakt cílového systému musí umět tombstone: { externalId, cancelled: true } → idempotentní odstranění zrcadlového záznamu podle stabilního source:externalId klíče. POZOR: mazat jen NEZAPLACENÁ zrcadla — zaplacený záznam nese reálný cash pohyb; jeho storno je účetně dobropis a tiché smazání by přepsalo historii (vracet hlasitou chybu).
2. Feed storna ZAHRNUJE (status: { notIn: ["DRAFT"] }) a mapuje je na minimální tombstone item; koncepty vyřadit, dobropisy neposílat jako pohledávku.
3. Obranná vrstva v cílových dotazech: pohledávkové agregace filtrují amount > 0 (záporný doklad není stárnoucí dluh).
4. Jednorázová sanace legacy zrcadel, která nový feed už nikdy nepošle (dřívější drafty/dobropisy) — jinak visí navždy; sanace až PO nasazení opraveného kontraktu, jinak ji další sync vrátí.
5. Verifikace per-doklad proti zdroji pravdy (ne jen sumy!) — rozdíly musí být vysvětlitelné vědomou sémantikou (odpočty záloh, partial payments).

Kategorie

integrations / sync / faktury