Součet účetních dokladů není peněžní plnění — dvojí započtení přes zálohový řetěz

import { Aside } from ‘@astrojs/starlight/components’;

Peněžní základ odvozuj výhradně z ledgeru přijatých plateb; účetní doklady jsou reprezentace, ne peníze — daňový doklad k platbě nikdy nenese vlastní platbu a nesmí se sčítat.

Symptom

Výpočet odvozený od „zaplacených dokladů” (provizní základ, obratové statistiky) vychází výrazně vyšší než skutečně přijaté peníze. V našem případě by naivní součet dokladů dal 160 % reálného plnění.

Root cause

Český zálohový flow vytváří k JEDNÉ platbě víc dokladů:

ZF (zálohová faktura)  → přijde platba  → Payment řádek NA ZF
DD (daňový doklad)     → generuje se K TÉŽE platbě — vlastní platbu NEMÁ NIKDY
VF (vyúčtování)        → odpočet zálohy + vlastní platba jen za DOPLATEK

Kdo sčítá SUM(doklad.total WHERE status='PAID'), započítá zálohu dvakrát (ZF i DD) a při vyúčtování potřetí. V produkci: 125 ze 125 daňových dokladů nemělo jediný Payment řádek — peníze nesly výhradně ZF/VF.

Druhá vrstva téhož: stav PAID lze nastavit ručně bez záznamu platby, takže ani status='PAID' není důkaz peněz.

Fix

unikátní plnění = Σ Payment řádků (ZF + VF + koncové faktury)
                  − skutečné ekonomické dobropisy
DD se nezapočítává NIKDY (daňový stín platby).

Fallbacky jen s provenancí a autoritou:

1. payment_ledger — existují-li Payment řádky, platí výhradně jejich součet (cap na hodnotu dokladu); ruční PAID je nepovyšuje.
2. audited_manual_paid — PAID bez ledgeru, ale s auditovanou mark-paid operací (aktér + čas) → počítá se, s labelem.
3. legacy_unverified — PAID bez ledgeru i auditu → základ 0 + anomálie k ručnímu ověření; nikdy automatický dopočet.

Pozor na dokladové opravy: dobropis + náhradní daňový doklad ke stejné platbě nemění ani nárok, ani peníze — klasifikace výhradně explicitní vazbou (parent doklad + correction operation id), nikdy heuristikou „stejný den a částka”. Model drž ve dvou hodnotách: účetní netto nárok (doklady − ekonomické dobropisy) vs. peněžní vypořádání (platby − vratky).

Jak se tomu vyvarovat v jiných systémech

• Detection: spočítej Σ dokladů PAID vs. Σ payment ledger per zakázka — poměr nad 100 % = dvojí započtení; doklady typu „daňový doklad k platbě” s vlastními platbami = podezřelé.
• Anti-pattern: hasPaidDocument = status === 'PAID'; párování dobropisu podle částky/dne; ruční mark-paid, který nezapíše platbu.
• Lepší přístup: každá „zaplaceno” mutace vytváří settlement záznam s provenancí; dobropis má povinnou vazbu na konkrétní původní doklad.