Párování dokladů do saldokontních skupin

Účtované doklady lze v účetním deníku párovat do tzv. saldokontních skupin a sledovat pak saldokonto. K tomu je určena agenda Saldokonto - účetní deník souvztažně, což je účetní deník z pohledu párování pohybů do skupin, což znamená, že pohyby v seznamu jsou seskupeny do skupin podle provedeného spárování. Umožňuje sledovat součet obratů uvnitř jednotlivých skupin a jejich "vynulování" a tak u saldokontních účtů zjišťovat saldokontní zůstatek = zůstatek všech nevynulovaných skupin.

Dále jsou účtované záznamy nezávisle na párování do saldokontních skupin řazeny do saldokontních skupin dle párovacích znaků (zadaných uživatelem). Více informací naleznete v popisu agendy Saldokonto - účetní deník souvztažně dle párovacích znaků. Na tento způsob párování nemají mechanismy popsané v této kapitole (SG, SGI) žádný vliv.

V následujícím textu objasníme, jakým způsobem je řešeno párování v agendě Saldokonto - účetní deník souvztažně a kdy program je a kdy není schopen párovat účtované doklady automaticky, zda a jak může párování ovlivnit sám uživatel a co se děje s párováním při změnách v dokladech či v jejich vzájemných vazbách:

Jak bylo řečeno v úvodu kapitoly, zaúčtování dokladů z pohledu jejich spárování do souvztažných saldokontních skupin lze sledovat v agendě Účetního deníku souvztažně.

Toto párování dokladů do skupin si v účetním deníku souvztažně může uživatel provádět sám, nicméně program se samozřejmě snaží tento proces párování maximálně automatizovat a provést jeho automatické spárování do odpovídající saldokontní skupiny, pokud je možné ji určit, a to podle pravidel uvedených dále. Uživatel si takto automaticky vytvořené spárované skupiny může ještě dle potřeby měnit, tj. účetní záznamy osamostatňovat či přesouvat do jiných, příp. spárovat záznamy, jejichž automatické spárování nebylo možné. Kromě tohoto procesu automatického párování, jehož pravidla popíšeme dále v této kapitole, má uživatel rovněž možnost zadat ručně párovací doklady při ukládání dokladu, tedy na úrovni zdrojových dokladů, a tudíž zadat libovolně párování ještě před zaúčtováním.

Tedy spárování dokladu do saldokontní skupiny v účetním deníku může být provedeno:

  • Automaticky bez zásahu uživatele na základě automatického párování - na základě vazeb na tzv. SourceGroup (SG) přidělovaný zdrojovým a účetním dokladům podle daných pravidel a na základě tzv. SourceGroupIdentical (SGI) vznikajících automaticky. Jedná se o případ, kdy program je schopen jednoznačně stanovit párovací doklad a spárování provede zcela automaticky bez nutnosti zásahu uživatele. (V jakých případech tomu tak je, viz Pravidla pro přidělování Source Group dokladům).
  • Automaticky se zásahem uživatele na základě uživatelem ručně zadaných párovacích dokladů - jako předchozí bod s tím rozdílem, že SourceGroupIdentical (SGI) zde vznikají uživatelsky ručním zadáním párovacích dokladů v subzáložce Ruční párování.

    Jedná se o případ, kdy uživatel má možnost si zadat libovolný párovací doklad, na základě kterého mu program poté provede automatické spárování. Využijete v případě, kdy program nemůže provést spárování zcela automaticky (nelze rozhodnout jednoznačně o párovacím dokladu), příp. potřebujete spárovat libovolné doklady přes nějaký párovací symbol, řešit spárování dokladů týkajících se časového rozlišení apod. (Samozřejmě není třeba zadávat ručně párovací doklady v situacích, ve kterých program provádí párování zcela automaticky podle daných pravidel). Příklady využití viz popis SourceGroupIdentical (SGI) a subzáložky Ruční párování.

    Specifické je spárování FV/PP s DL, kdy program automaticky (tj. bez zásahu uživatele) vytvoří párovací vazbu mezi FV/PP a DL, přičemž párovací doklady jsou k dispozici v subzáložce Ruční párování, kde je může uživatel ručně odpojit. Viz Zdrojový expediční skladový doklad (DL), který je importován do příjmového prodejního.

  • Ručně až po zaúčtování, tj. zpětnou úpravou saldoskupin v účetním deníku - automaticky prováděné párování může uživatel ještě dodatečně v deníku měnit, doplnit atd., viz Možnosti dodatečného párování, změny ve spárování v deníku.

Jak bylo objasněno v kap. filozofie vazeb prvotních dokladů do účetnictví, vystavený doklad je vystaven ve zdrojové řadě dokladů a jde o tzv. doklad zdrojový a je-li zdrojový doklad zaúčtován (myšleno vyslán do účetnictví do žádostí nebo do deníku), vznikne jemu odpovídající doklad účetní (v účetní řadě dokladů), tedy odpovídající účetní zápisy v žádostech nebo deníku (zda budou v deníku nebo zatím jen v žádostech a bude třeba je ještě do deníku přeúčtovat, závisí na způsobu účtování nastaveném na dané zdrojové řadě a na úplnosti použitých předkontací).

Každý účetní zápis v účetním deníku si pamatuje číslo saldokontní skupiny, do níž patří (tzv. AccGroup). Toto číslo saldokontní skupiny je po úpravě spočívající ve vypuštění některých znaků (např. nul) zobrazeno v položce Znak. Účetní zápisy se shodným číslem saldokontní skupiny pak tvoří jednu saldokontní skupinu v saldokontu - účetním deníku souvztažně (jednotlivé saldokontní skupiny jsou graficky odděleny a mají stejný údaj v položce Znak):

Účetní zápisy ze tří saldokontních skupin se znaky E9, 79, N9 v účetním deníku souvztažně

Číslo saldokontní skupiny (AccGroup) je každému účetnímu zápisu přiděleno v okamžiku jeho zaúčtování do účetního deníku (pozor, nikoli do žádostí, žádosti nemají AccGroup vyplněno) a to podle jeho vazeb na Source Group a podle existujících záznamů Source Group Identical (tj. identických Source Group). Platí:

  • Pokud je v deníku dohledán záznam, jenž má stejné Source Group jako účtovaný záznam, pak si účtovaný záznam od něj převezme číslo saldokontní skupiny, tedy je k němu připárován do jeho saldokontní skupiny.
  • Pokud je v deníku dohledáno více záznamů se stejným Source Group, připáruje se do saldokontní skupiny k prvnímu z nich (myšleno k prvnímu dohledanému).

    Zde je třeba si uvědomit, že v deníku mohou existovat záznamy, které mají shodné Source group, ale jiné číslo saldokontní skupiny (tedy nejsou v jedné saldokontní skupině). Stane se tak, pokud si uživatel u nich párování ručně měnil.

  • Pokud v deníku není dohledán žádný záznam se stejným Source Group, pak se hledá, zda existuje záznam s identickým Source Group. Termínem "identickým" se rozumí to, že je nějakým způsobem propojen na SourceGroup účtovaného zápisu pomocí záznamů Source Group Identical. Pokud je takový účetní zápis dohledán, převezme se číslo saldokontní skupiny od něj.
  • Pokud v deníku není dohledán žádný záznam se stejným ani identickým Source Group, jako má účtovaný zápis, pak je účtovanému zápisu přiděleno nové číslo saldokontní skupiny (bude tedy tvořit novou samostatnou saldokontní skupinu).

Dále viz příklady uvedené u výkladu Source Group a Source Group Identical a pravidla pro změny v účetních skupinách po vzniku/zániku Source Group Identical.

Číslo saldokontní skupiny přiděluje program automaticky a není uživateli dostupné, nemůže jej nijak měnit, nicméně může vzniklé saldokontní skupiny dodatečně upravovat, viz dále.

Účetní žádosti mají číslo saldokontní skupiny zatím nevyplněné a z hlediska saldokontních skupin tudíž nejsou (ani nemohou být) nijak spárované. Žádosti jsou vizuálně skupinované, ale nejedná se o saldokontní skupiny. Žádosti jsou skupinované pouze pro přehlednost a to podle čísla účetního dokladu (tedy víceřádkové účetní doklady (rozúčtování jednoho dokladu na několik účetních zápisů) jsou v žádostech zobrazeny v jedné skupině graficky zvýrazněné):

Příklad seznamu žádostí barevně graficky oddělených podle čísla dokladu

Je-li záznam vrácen z deníku zpět do žádostí, jeho číslo saldokontní skupiny se vynuluje. Při dalším zaúčtování se znovu vyplní dle pravidel tvorby saldokontních skupin, viz výše.

Každý zdrojový doklad, resp. odpovídající účetní doklad vzniklý při jeho zaúčtování, má pro účely párování do saldokontních skupin přidělen odkaz na jisté číslo, kterému nadále budeme říkat číslo zdrojové skupiny neboli zkráceně Source Group (SG). V systému postupně vznikají jednotlivé zdrojové skupiny průběžně tak, jak je potřeba a vznikající doklady se na ně odkazují. Source Group je interní číslo uživateli nepřístupné, které program generuje a přiděluje sám.

Účetní zápisy, které mají odkaz na stejný Source Group, pak budou automaticky spárovány do téže saldokontní skupiny (dále viz pravidla tvorby saldokontních skupin).

Objasníme na příkladu:

Mějme fakturu vydanou, při jejímž uložení se vytvoří nové číslo Source Group a faktura se na něj bude odkazovat (pro jednoduchost např. SG=A). Po zaúčtování faktury (vyslání do účetnictví, které u faktury nastává automaticky ihned po uložení), vznikne jeden nebo více účetních záznamů (podle údajů na faktuře a podle použité předkontace), přičemž všechny obdrží Source Group stejný jako zdrojová faktura, tj. SG=A. Nechť se jedná zatím o účetní žádosti. (Dále viz pravidla přidělování SG). Účetní žádosti k dané faktuře zaúčtujeme do deníku. Nechť v deníku zatím není žádný jiný záznam s touž Source Group nebo s identickou Source Group (viz dále), tudíž vznikne nová saldokontní skupina (např. pro jednoduchost AccountGoup=1A, tj. znak=1A), v níž budou zatím jen účetní zápisy dané faktury.

Poté zadáme zaplacení dané faktury např. účtenkou a účtenku zaúčtujeme do žádostí. Účtenka při svém vystavení rovněž obdrží odkaz na Source Group a jelikož jde o platbu, dostane stejné SG jako placená faktura, tedy SG=A. (Dále viz pravidla přidělování SG). Její účetní zápisy rovněž budou mít SG=A. Při zaúčtování účetních žádostí k dané účtence do deníku se v deníku najdou záznamy se shodnou SG (zaúčtování placené faktury) a účetní zápisy účtenky se k nim připárují (dostanou shodné číslo saldokontní skupiny AccGroup=1A, tj. znak=1A), tedy účtenka skončí ve stejné saldokontní skupině jako placený doklad. (Jedná se o příklad automatického spárování bez zásahu uživatele).

Vazba na Source Group se nepamatuje přímo ani na zdrojovém dokladu ani na jeho účetním dokladu (na jeho účetních zápisech), ale ve speciální tabulce vazeb. V ní se pamatují jednak vazby zdrojových dokladů na Source Group, dále vazby zdrojových dokladů na jejich účetní zápisy a vazby těchto účetních zápisů dokladů na Source Group.

Kromě čísla zdrojové skupiny - Source Group existují v systému i záznamy čísel zdrojových skupin, které jsou identické, tzv. Source Group Identical. Pojmem identické se zde myslí, že účetní zápisy, které mají odkaz na identické Source Group, pak budou spárovány do téže saldokontní skupiny (dále viz pravidla tvorby saldokontních skupin).

Dále je uvedeno:

Záznamy identických SG vznikají:

  • Automaticky - V případech, kdy se mají automaticky spárovat bez zásahu uživatele doklady, kterým sice není přidělen odkaz na stejný Source Group, ale které mají být spárovány do téže saldokontní skupiny (např. zúčtování ZL s dokladem, do něhož bylo zúčtováno). (Takto spárované doklady nelze uživatelsky odpojit v subzáložce Ruční párování).
  • Uživatelsky - V ostatních případech, kdy uživatel požaduje, aby byly spárovány do téže saldokontní skupiny libovolné jiné doklady s odkazem na různé Source Group, u nichž by automatické spárování bez zásahu uživatele neproběhlo (např. proto, že program sám nemůže určit, kam by se měly připárovat). Pak uživatel na subzáložce Ruční párování editovaného dokladu zadá doklad ke spárování, čímž vznikne záznam o tom, že SourceGroup daného dokladu a párovacího dokladu jsou identické. Po zaúčtování budou všechny účetní zápisy s danou SG a se všemi identickými SG spárovány v jedné saldokontní skupině.

Specifická situace nastává u dodacích listů čerpaných do faktury vydané nebo pokladní příjemky, kde se párovací vazba mezi DL a FV/PP tvoří automaticky při uložení FV/PP, ale uživatel má možnost párovací doklad ručně odpojit v subzáložce Ruční párování. Viz Zdrojový expediční skladový doklad (DL), který je importován do příjmového prodejního.

Objasníme na příkladech:

Příklad 1: Mějme zálohový list, při jehož uložení se vytvoří nové číslo Source Group a zálohový list se na něj bude odkazovat (pro jednoduchost např. SG=A).

Dále vystavíme fakturu vydanou, do níž zúčtujeme zálohový list. Při jejím uložení se opět vytvoří nové číslo Source Group a faktura se na něj bude odkazovat (např. SG=B). Po zaúčtování faktury (vyslání do účetnictví, které u faktury nastává automaticky ihned po uložení), vznikne jeden nebo více účetních záznamů (podle údajů na faktuře a podle použité předkontace), přičemž všechny obdrží Source Group stejný jako zdrojová faktura, tj. SG=B. Vytvořené zúčtování zálohového listu do faktury bude mít SG dle zdrojového dokladu, tj. předpisu zálohového listu, tedy SG=A. (Dále viz pravidla přidělování SG). Jelikož se však požaduje, aby zúčtování zálohy bylo automaticky spárováno v jedné skupině s fakturou, vznikne současně záznam Source Group Identical o tom, že Source Group faktury a Source Group zúčtování jsou identické, tj. A⇔B.

Nechť se při zaúčtování účetních žádostí k předpisu dané faktury do deníku v deníku vytvoří nová saldokontní skupina, v níž budou zatím jen účetní zápisy dané faktury (např. s AccGroup=1A, tj. znak=1A). Při zaúčtování účetní žádosti k zúčtování ZL se v deníku nejdříve hledá záznam s SG=A. Takový tam není. Jelikož však existuje nějaká identická SG (což je SG=B), hledá se v deníku ještě záznam s identickou SG. Takové záznamy se v deníku najdou (zaúčtování předpisu faktury) a účetní zápisy zúčtování ZL se k nim připárují (dostanou shodné číslo saldokontní skupiny AccGroup=1A, tj. znak=1A), tedy zúčtování ZL skončí ve stejné saldokontní skupině jako faktura. (Jedná se o příklad automatického spárování bez zásahu uživatele).

Příklad 2: Mějme fakturu z předchozího příkladu 1 s odkazem na SG=B a se zúčtováním ZL s identickou SG=A a dále interní doklad, který chceme mít v jedné saldokontní skupině s fakturou. Interní doklad nechť má např. odkaz na SG=C. Interní doklady se samozřejmě s prodejními doklady automaticky nespárují, takže mají jiné SG (dále viz pravidla přidělování SG a tvorby SGI). My ale budeme chtít INT s FV spárovat. Proto např. v editaci faktury v subzáložce Ruční párování přidáme párovací doklad (resp. celou skupinu dokladů, která má stejné nebo identické SG jako vybraný párovací doklad), tj. vybereme daný INT jako doklad, k němuž se má párovat. Tím pádem vznikne nový záznam Source Group Identical o tom, že Source Group faktury a Source Group interního dokladu jsou identické, tj. B⇔C. Tedy pak A⇔B⇔C.

Při účtování interního dokladu z účetních žádostí do deníku se nejdříve hledá účetní zápis s SG=C, poté se hledá nějaký účetní zápis s identickou SG (A nebo B) a k prvnímu takovému nalezenému účetnímu zápisu se zaúčtování interního dokladu připáruje (dostane shodné číslo saldokontní skupiny AccGroup=1A, tj. znak=1A), tedy zaúčtování ID skončí ve stejné saldokontní skupině jako faktura a zúčtovaná záloha. (Jedná se o příklad automatického spárování se zásahem uživatele).

Příklad 3: Mějme fakturu z příkladu 1 s odkazem na SG=B a se zúčtováním ZL s identickou SG=A a dále dodací list, který je do dané faktury čerpán. Dodací list nechť má např. odkaz na SG=D. Dodací listy se s prodejními doklady automaticky spárují (dále viz pravidla přidělování SG a tvorby SGI). Tím pádem vznikne nový záznam Source Group Identical o tom, že Source Group faktury a Source Group dodacího listu jsou identické, tj. B⇔D. Tedy pak A⇔B⇔D. V subzáložce Ruční párování se však (na rozdíl od automatického spárování bez zásahu uživatele v případě párování jiných dokladů) zobrazí příslušný párovací doklad a uživatel má možnost párovací doklad odpojit.

Dodací list po ocenění a uzavření skladovou uzávěrkou zaúčtujeme (pozor, pokud chceme, aby se spároval s FV, nesmíme jej zaúčtovat souhrnně), pak jeho účetní zápisy dostanou rovněž SG=D. Po zaúčtování žádostí do deníku se nejdříve hledá účetní zápis s SG=D, poté se hledá nějaký účetní zápis s identickou SG (A nebo B) a k prvnímu takovému nalezenému účetnímu zápisu se zaúčtování dodacího listu připárují (dostanou shodné číslo saldokontní skupiny AccGroup=1A, tj. znak=1A), tedy zaúčtování DL skončí ve stejné saldokontní skupině jako faktura a zúčtovaná záloha. (Jedná se o specifický příklad automatického spárování DL a FV/PP).

POZOR, vznik nového záznamu SGI může způsobit i spojení existujících dosud samostatných saldokontních skupin. Jaké číslo saldokontní skupiny (AccGroup) budou mít záznamy po příp. spojení existujících dosud samostatných saldokontních skupin po vzniku nového záznamu Source Group Identical, (tj. která saldokontní skupina od které číslo převezme, příp. zda dostanou všechny nové) závisí mj. na tom, jaký záznam z párované dvojice změnu vyvolal a o jakou dvojici se jedná. Platí:

  • Při vzniku nového záznamu SGI se kontroluje, zda má dojít ke spojení nějakých účetních zápisů z více saldokontních skupin do jedné společné saldokontní skupiny a pokud ano, jsou automaticky přepsána (opravena) čísla saldokontních skupin tak, aby se provedlo požadované spojení v jednu. Viz příklad 1:

    Příklad 1: Mějme saldokontní skupinu (nechť má číslo AccGroup=1A, tj. znak=1A), v níž jsou účetní zápisy dokladů zúčtování ZL1 (s SG=A), FV1 (s SG=B) a čerpaného DL1 (s SG=C). Jsou v jedné skupině, jelikož existují záznamy SGI, že jejich SG jsou identické, tj.:
    SG=A⇔SG=B⇔SG=C.

    Dále mějme druhou saldokontní skupinu (nechť má číslo AccGroup=2B, tj. znak=2B) a obsahuje účetní zápisy dokladů FV2 (s SG=K) a čerpaného DL2 (s SG=L). Jsou v jedné skupině, jelikož existují záznamy SGI, že
    SG=K⇔SG=L.

    Poté dodatečně provedeme zúčtování ZL1 i do FV2, čímž vznikne další záznam SGI, že
    SG=K⇔SG=A

    Tím ovšem začne platit, že
    SG=A⇔SG=B⇔SG=C⇔SG=K⇔SG=L

    a skupiny se spojí, tj. jedna převezme číslo AccGroup (tj. znak) od druhé. (Která od které závisí mj. na tom, na kterém dokladu konkrétně byla změna vedoucí ke vzniku nového SGI provedena, viz dále).

  • Při opravách AccGroup u již zaúčtovaných záznamů po vzniku SGI postupuje takto:
    • Opravuje AccGroup záznamů dokladu, z jehož strany se párování dělá (k němuž se páruje) a to na hodnotu dohledaného AccGroup dokladu, který je připárován. Viz dále příklad 2.
    • Pokud by se stalo, že připárováváme doklad, který dosud nebyl v deníku (tedy nemá zatím svou saldo skupinu (svůj AccGroup)), tak doklad, k němuž se páruje, zůstane beze změny, tj. saldokontní skupina AccGroup jeho záznamů v deníku se nezmění. Viz též příklad 2 a příklad 4.

      Do v. 9.03 vč. platilo, že pokud se stalo, že připárovávaný záznam dosud nebyl v deníku (tj. nenašel se záznam s jeho SG a nemá zatím svou saldo skupinu AccGroup), pak záznamy dokladu, k němuž je párováno, dostaly nové č. AccGroup. To ovšem v případě velkých saldokontních skupin znamenalo mnoho relativně zbytečných změn v deníku a pomalou odezvu systému. Navíc to mohlo i způsobit, že se spojily skupiny, které si předtím uživatel ručně odpojil. Viz dále příklad 2.

    • Speciálně je ošetřeno zúčtování zálohového listu (ZLV/ZLP) do faktury (FV/FP):
      • Pokud je na zálohovém listu zúčtovaný jen 1 doklad nebo žádný, systém postupuje v souladu s pravidly výše, tedy upraví se saldokontní skupina AccGroup na zálohové straně podle AccGroup fakturační strany. (Tedy pokud k FV připojíte ZL (zúčtujete ZL do FV), záznamy dostanou AccGroup podle FV). Viz příklad 3 a příklad 4.
      • Pokud je zúčtovaný víc jak 1 doklad, systém postup otočí a fakturační strana přebírá saldokontní skupinu AccGroup (údaj z položky Znak) od zálohové strany. Důvodem je optimalizace rychlosti (v tomto případě se předpokládá, že záloha je již v deníku připárovaná k mnoha dalším záznamům, do nichž byla zúčtována, a musela by se měnit AccGroup na mnoha záznamech, což by mělo za následek pomalou odezvu systému při zúčtování do další FV). Viz příklad 5 a příklad 6.

        Do v. 9.03 vč. platilo, že nové AccGroup vzniklo pro skupinu na zálohové straně. Ta ale mohla být díky zúčtováním do více FV velká, což způsobovalo pomalou odezvu systému.

  • Spojení existujících dosud samostatných saldokontních skupin po vzniku nového záznamu Source Group Identical může mít za následek i spojení záznamů, které sice mají shodné nebo identické SG, ale které si předtím uživatel v deníku úmyslně ručně osamostatnil. Viz příklad 7.

Objasníme na příkladech:

Příklad 2: Ruční spárování:

Mějme fakturu (s SG=A), k níž jsme v ručním párování vybrali párovací doklad INT (s SG=B), tudíž existuje záznam SGI, že jejich SG jsou identické, tj. SG=A⇔SG=B a v účetnictví jsou spojeny do jedné saldokontní skupiny (nechť má číslo AccGroup=1A, tj. znak=1A). Dále mějme doklad OSP (s SG=C), který je v druhé saldokontní skupině (s AccGroup=2B, tj. znak=2B). Poté dodatečně provedeme ruční spárování FV s OSP v záložce Ruční párování. Vznikne záznam SGI, že A⇔C a program kontroluje, zda má provést změnu v existujících saldokontních skupinách, což dělá následovně.

a) Pokud ruční spárování provedeme v opravě OSP (zadáme párovací doklad FV), program dohledá, kde se dosud vyskytovaly zápisy s SG=C (nebo s SG dosud identickými s SG=C - takové ale zatím nebyly) a kde by se měly vyskytovat po vzniku nového SGI (A⇔C) a zda se to liší. Jelikož se to liší, je třeba provést změnu v saldo skupinách. Dohledá první účetní záznam s SG=A nebo SG=B a převezme od něj číslo saldo skupiny do záznamu s SG=C (tj. AccGroup celé skupiny bude 1A, tj. znak=1A).

b) Pokud ruční spárování provedeme v opravě FV (zadáme párovací doklad OSP), program dohledá, kde se dosud vyskytovaly zápisy s SG=A (nebo s SG dosud identickými s SG=A, což jsou zápisy s SG=B) a kde by se měly vyskytovat po vzniku nového SGI(A⇔C) a zda se to liší. Jelikož se to liší, je třeba provést změnu v saldo skupinách. Dohledá první účetní záznam s SG=C a převezme od něj číslo saldo skupiny do záznamů s SG=A a SG=B (tj. AccGroup celé skupiny bude 2B, tj. znak=2B).

Pokud by se stalo, že OSP dosud nebyl zaúčtovaný v deníku (tj. nenajde se záznam s SG=C), pak si záznamy s SG=A a SG=B ponechají svou původní AccGroup=1A, tj. znak=1A a OSP se po svém zaúčtování připojí k nim, tj. dostane též AccGroup=1A, tj. znak=1A.

Do v. 9.03 vč. v tomto případě platilo, že pokud OSP dosud nebyl v deníku (tj. nenašel se záznam s SG=C), tak záznamy s SG=A a SG=B dostaly nové č. AccGroup.

Příklad 3: Zúčtování ZL do jedné FV - zúčtování provedené dodatečně:

Mějme zálohový list (s SG=A), k němu platbu PP (rovněž s SG=A). Zálohový list zatím není zaúčtován v deníku, ale jeho platba ano, nechť má AccGroup=1A, tj. znak=1A. Dále mějme FV (s SG=B) zaúčtovanou v deníku, nechť má AccGroup=2B, tj. znak=2B. Poté provedeme zúčtování ZL, tj. do FV v její záložce zálohy připojíme ZL. Záznam zúčtování ZL dostane SG dle svého předpisu, tj. SG=A. Vznikne záznam SGI, že A⇔B a program zkontroluje, zda má provést změnu v existujících saldokontních skupinách a provede ji následovně:

Upraví AccGroup na zálohové straně podle fakturační strany, tj. dohledá první účetní záznam s SG=B a převezme od něj číslo saldo skupiny AccGroup do záznamu s SG=A (tj. AccGroup celé skupiny bude 2B, tj. znak=2B). Až toto dodatečné zúčtování ZL do FV zaúčtujeme do deníku, dostane rovněž AccGroup=2B, tj. znak=2B.

Příklad 4: Zúčtování ZL do jedné FV - zúčtování provedené při vzniku FV:

Mějme zálohový list (s SG=A), k němu platbu PP (rovněž s SG=A). Zálohový list zatím není zaúčtován v deníku, ale jeho platba ano, nechť má AccGroup=1A, tj. znak=1A. Vystavujeme novou FV a při tom rovnou do ní zúčtujeme ZL. Po uložení dostane FV SG=B, záznam zúčtování ZL dostane SG dle svého předpisu, tj. SG=A. Vznikne záznam SGI, že A⇔B a program zkontroluje, zda má provést změnu v existujících saldokontních skupinách. Záznamy fakturované strany však zatím v deníku nejsou, tudíž AccGroup zálohové strany podle nich nijak měnit nebude. Záznamy zálohové strany si tedy ponechají AccGroup=1A, tj. znak=1A. Po zaúčtování FV a provedeného zúčtování ZL tyto rovněž dostanou toto AccGroup (AccGroup celé skupiny v tomto případě bude 1A, tj. znak=1A).

Do v. 9.03 vč. v tomto případě platilo, že pokud FV dosud nebyla v deníku (tj. nenašel se záznam s SG=B), tak záznamy s SG=A dostaly nové č. AccGroup.

Příklad 5: Zúčtování ZL do více FV - zúčtování provedené dodatečně:

Mějme zálohový list (s SG=A), k němu platbu PP (rovněž s SG=A), zúčtovaný do FV1 (s SG=B), vše v deníku, nechť má skupina AccGroup=1A, tj. znak=1A. Dále mějme další FV2 (s SG=C) zaúčtovanou v deníku, nechť má AccGroup=C3, tj. znak=C3. Poté provedeme zúčtování ZL do FV2 (s SG=C). Vznikne záznam SGI, že A⇔C a program zkontroluje, zda má provést změnu v existujících saldokontních skupinách a provede ji následovně:

V tomto případě upraví naopak AccGroup na fakturační straně FV2 podle zálohové strany, tj. dohledá první účetní záznam s SG=A a převezme od něj číslo saldo skupiny AccGroup do záznamu s SG=C (tj. AccGroup celé skupiny bude 1A, tj. znak=1A).

Příklad 6: Zúčtování ZL do jedné FV - zúčtování provedené při vzniku FV:

Mějme zálohový list (s SG=A), k němu platbu PP (rovněž s SG=A), zúčtovaný do FV1 (s SG=B), vše v deníku, nechť má skupina AccGroup=1A, tj. znak=1A. Vystavujeme novou FV2 a při tom rovnou do ní zúčtujeme ZL. Po uložení dostane FV SG=C, záznam zúčtování ZL dostane SG dle svého předpisu, tj. SG=A. Vznikne záznam SGI, že A⇔C a program zkontroluje, zda má provést změnu v existujících saldokontních skupinách:

V tomto případě by měl upravit AccGroup na fakturační straně FV2 podle zálohové strany, tj. dohledat první účetní záznam s SG=A a převzít od něj číslo saldo skupiny AccGroup do záznamu s SG=C (tj. AccGroup celé skupiny bude 1A, tj. znak=1A). Záznamy fakturované strany FV2 však zatím v deníku nejsou, tudíž se nic měnit nebude. Po zaúčtování FV2 a zúčtování ZL tyto tedy rovněž dostanou toto AccGroup (AccGroup celé skupiny v tomto případě bude 1A, tj. znak=1A).

Příklad 7: Spojení předtím ručně rozpojených záznamů:

Mějme fakturu (s SG=A), k níž jsme v ručním párování vybrali párovací doklad INT (s SG=B), tudíž existuje záznam SGI, že jejich SG jsou identické, tj. SG=A⇔SG=B a v účetnictví jsou spojeny do jedné saldokontní skupiny (nechť má číslo AccGroup=1A, tj. znak=1A). Pak v deníku záznam INT osamostatníme (tj. dostaneme např. AccGroup=2B, tj. znak=2B).

Dále mějme doklad OSP (s SG=C) ručně spárovaný s OSV (s SG=D), tudíž existuje záznam SGI, že SG=C⇔SG=D. Poté dodatečně provedeme ruční spárování FV s OSP v záložce Ruční párování. Vznikne záznam SGI, že A⇔C a program kontroluje, zda má provést změnu v existujících saldokontních skupinách, což provede následovně:

a) Pokud ruční spárování provedeme v opravě OSP (zadáme párovací doklad FV), program dohledá, kde se dosud vyskytovaly zápisy s SG=C (nebo s dosud identickými SG=D) a kde by se měly vyskytovat po vzniku nového SGI(A⇔C) a zda se to liší. Jelikož se to liší, je třeba provést změnu v saldo skupinách v deníku. Dohledá první účetní záznam s SG=A nebo SG=B a převezme od něj číslo saldo skupiny do všech záznamů s SG=C a identickým SG=D. Zda se OSP a OSV připárují k FV nebo k INT závisí na tom, který z nich se dohledá jako první, tedy dostanou AccGroup=1A, tj. znak=1A nebo 2B, tj. znak=2B, a ke spojení předtím ručně rozpojeného FV a INT vznikem nového SGI v tomto případě nedojde!

b) Pokud ale ruční spárování provedeme v opravě FV (zadáme párovací doklad OSP), program dohledá, kde se dosud vyskytovaly zápisy s SG=A (nebo s dosud identickými SG=B) a kde by se měly vyskytovat po vzniku nového SGI(A⇔C) a zda se to liší. Jelikož se to liší, je třeba provést změnu v saldo skupinách. Dohledá první účetní záznam s SG=C nebo SG=D a převezme od něj číslo saldo skupiny (nechť je to např. AccGroup=C3, tj. znak=C3) do všech záznamů s SG=A a identickým SG=B. Tj. FV A INT se připárují k OSP a OSV. Ke spojení předtím ručně rozpojeného FV a INT vznikem nového SGI v tomto případě dojde!

- Pokud by se stalo, že záznamy OSP/OSV dosud nejsou v deníku (tj. nenajde se záznam s SG=C ani SG=D), pak si záznamy s SG=A a SG=B ponechají svou původní AccgGroup (tedy FV AccGrooup=1A, tj. znak=1A a INT AccGroup=2B, tj. znak=2B). Ke spojení předtím ručně rozpojeného FV a INT vznikem nového SGI v tomto případě také nedojde a OSP/OSV se po svém zaúčtování připojí k jednomu z nich, tj. dostane AccGroup=1A, tj. znak=1A nebo 2B, tj. znak=2B (podle toho, který se dohledá jako první).

Do v. 9.03 vč. v tomto případě platilo, že pokud záznamy OSP/OSV dosud nebyly v deníku (tj. nenašel se záznam s SG=C ani SG=D), tak záznamy s SG=A a SG=B dostaly nové č. AccGroup. Ke spojení předtím ručně rozpojeného FV a INT vznikem nového SGI v tomto případě tedy rovněž došlo!

K příp. auditacím účetních zápisů se nepřihlíží.

Záznamy identických SG zanikají:

  • Uživatelsky - V případě, kdy uživatel na subzáložce Ruční párování editovaného dokladu odebere párovací doklad(y), tj. odebere připárovanou skupinu, čímž zanikne záznam o tom, že SourceGroup daného dokladu a odebraného párovacího dokladu jsou identické.
  • Automaticky
    • V případě zrušení akce, na jejímž základě vznikly, tj. např. při zrušení zúčtování zálohového listu do faktury.

      Výjimku tvoří párovací vazba mezi DL a FV/PP vytvořená automaticky při uložení FV/PP, do níž byl čerpán DL, která se při odpojení importovaného DL automaticky nezruší. Nicméně připárovaný DL lze odpojit ručně v subzáložce Ruční párování. Viz Zdrojový expediční skladový doklad (DL), který je importován do příjmového prodejního.

    • Zánik vazby SGI v případě mazání dokladů a změně vlastní Source Group

      K mazání případných vazeb Source Group Identical na Source group mazaného nebo opravovaného dokladu nedochází:

      • Pokud je smazán doklad, který má odkaz na Source Group, na níž se přímo odkazuje ještě jiný doklad.
      • Pokud je opravován doklad a dojde při jeho opravě ke změně Source Group a na původní Source Group se přímo odkazuje ještě jiný doklad, pak k mazání případných vazeb Source Group Identical nedochází. Tato situace typicky nastává při mazání nebo odpojování plateb, u nichž byla vazba na jiný doklad a tudíž i na doklad placený nebo při mazání či změně v připojování JSD na FP.

        Mějme fakturu FV s odkazem na SG=A. Její platba účtenkou PP má rovněž odkaz na SG=A. Z dokladu PP ručně zadáme párovací vazbu na ostatní příjem OSP (s odkazem na SG=B), tj. vznikne záznam identických SG: SG=A⇔SG=B.

        - Pokud poté doklad PP smažeme, vazba SG=A⇔SG=B zůstane zachována, tj. OSP bude připárován k FV.

        - Pokud odpojíme doklad PP jakožto platbu od FV, PP získá novou SG=C. Jelikož však nelze rozhodnout, zda vazba na OSP měla být z FV či PP, zůstane SG=A⇔SG=B zachována a vznikne druhá vazba SG=C⇔SG=B, tj. OSP bude připárován k FV i PP. Pokud bychom poté vazbu mezi FP a OSP zrušili, zanikl by záznam SG=A⇔SG=B a zaúčtování FV a OSP by se rozpojilo. Nicméně zaúčtování OSP by zůstalo spojené s PP, jelikož vazba SG=C⇔SG=B stále platí.

        Mějme fakturu přijatou FP s odkazem na SG=A. Dále mějme JSD připojené na danou fakturu FP, tedy rovněž s SG=A. Z dokladu JSD ručně zadáme párovací vazbu na ostatní výdaj OSV (s odkazem na SG=B), tj. vznikne záznam identických SG: SG=A⇔SG=B.

        - Pokud poté doklad JSD smažeme, vazba SG=A⇔SG=B zůstane zachována, tj. OSV bude připárován k FP.

        - Pokud odpojíme doklad JSD od FP, získá JSD novou SG=C. Jelikož však nelze rozhodnout, zda vazba na OSV měla být z FP či JSD, zůstane vazba SG=A⇔SG=B zachována a vznikne druhá vazba SG=C⇔SG=B, tj. OSV bude připárován k FP i JSD.

Při zániku vazby SGI se vždy kontroluje, zda dochází ke spojení/rozpojení nějakých dokladů na úrovni účetnictví, a pokud ano jsou automaticky předělány AccGroupy (účetní skupiny).

Zánik záznamu identických SG nemusí nutně vést k rozpojení spárovaných dokladů. A to tehdy, pokud jsou tyto spárovány ještě na základě něčeho jiného (buď přímo shodných SG, nebo jiného záznamu identických SG).

Zánik záznamu SGI může způsobit i rozpojení jedné dosud společné saldokontní skupiny. Při zániku záznamu SGI se kontroluje, zda má dojít k rozpojení nějakých účetních zápisů do více saldokontních skupin a pokud ano, jsou automaticky přepsána čísla saldokontních skupin tak, aby se požadované rozpojení provedlo. Pro osamostatnění se vybere skupina, která má méně SG spojených přes SGI (aby se AccGroup upravovalo na menším počtu záznamů).

Mějme saldokontní skupinu, která nechť má číslo AccGroup=1A, tj. znak=1A a obsahuje účetní zápisy dokladů FV1 (s SG=A), čerpaného DL1 (s SG=B), zúčtování ZL1 (s SG=C), FV2 (s SG=K) a čerpaného DL2 (s SG=L). ZL1 je zúčtován i do FV2. Jsou v jedné skupině, jelikož existují záznamy SGI, že
SG=A⇔SG=B⇔SG=C⇔SG=K⇔SG=L.

Poté provedeme zrušení zúčtování ZL1 i do FV2, čímž se smaže záznam SGI, že
SG=K⇔SG=C.

Tím ovšem začne platit, že
SG=A⇔SG=B⇔SG=C
SG=K⇔SG=L, ale navzájem identické nejsou a skupiny se rozpojí (odpojená dostane nové číslo saldokontní skupiny, např. AccGroup=XX, tj. znak=XX).

Provedení dané akce spojené se zánikem záznamu identických SG, na jehož základě by došlo k rozpojení saldokontních skupin v deníku, program nepovolí, pokud takové rozpojení nemůže provést.

K příp. auditacím účetních zápisů se nepřihlíží.

Saldokontní skupiny tvořené v deníku automaticky programem (ať už zcela automaticky nebo se zásahem uživatele prostřednictvím zadání párovacích dokladů v subzáložce Ruční párování), si může uživatel ještě libovolně ručně upravovat a měnit. K tomu slouží funkce Přesuň a Osamostatni v účetním deníku souvztažně. Platí:

  • Je-li záznam přesunut do jiné saldokontní skupiny, znamená to, že své původní číslo saldokontní skupiny "zapomene" a převezme si jiné od skupiny, do níž byl přesunut.
  • Je-li záznam osamostatněn, znamená to, že své původní číslo saldokontní skupiny "zapomene" a dostane číslo skupiny nově vzniklé.

Dodatečné ruční spárování využijete např. v případě, kdy spárování nebylo možné provést automaticky bez zásahu uživatele a na úrovni zdrojového dokladu nebyl uživatelem zadán žádný párovací doklad anebo bylo párování provedeno chybně.

Pozor, jak bylo řečeno výše, změna v párování do saldokontních skupin provedená dodatečně v deníku nijak nemění údaje o Source Group, ani záznamy Source Group Identical, týkající se daného účetního zápisu, pouze na přesouvaných účetních zápisech mění číslo saldokontní skupiny (AccGroup, které je zobrazeno v položce Znak).

Pokud tedy ručně přepárovaný doklad přeúčtujete nebo jej jen vrátíte do žádostí z deníku ručně, znamená to, že se jeho číslo saldokontní skupiny vynuluje a při novém zaúčtování do deníku mu bude opět přiděleno dle hledaných záznamů se stejným nebo identickým Source Group, viz Pravidla tvorby saldokontních skupin. Tedy o případné předchozí ruční změny v párování takového záznamu přijdete!

Obdobně, pokud provedete takové změny, na základě nichž se mění záznamy v Source Group Identical (tj. např. ručně jste zadali párovací doklad), může na odpovídajících záznamech v deníku, které mají shodnou nebo identickou Source Group s opravovaným dokladem dojít ke změně saldokontní skupiny (AccGroup), pak o ruční změny v párování těchto záznamů přijdete! Viz příklady v části Vznik SGI.

Z výše uvedeného naopak plyne, jak lze vyvolat znovu automatické spárování účetních záznamů dle pravidel popsaných výše:

  • Vrácením účetního záznamu z deníku zpět do žádostí a novým zaúčtováním.
  • Vyvoláním přeúčtování.

    Při přeúčtování může dokonce dojít i ke změně Source Group (podle toho, čím bylo vyvoláno) a tím samozřejmě poté i ke změně čísla saldokontní skupiny, do níž bude doklad zařazen - jelikož při přeúčtování zdrojového dokladu se účetní doklad vytváří celý znovu, tedy může obdržet i jiný Source Group (např. účtenka připojená jako platba, nesouhrnně účtovaný doklad přeúčtován souhrnně apod.).

Nejdříve je třeba připomenout, že každý účtovaný doklad v ABRA Gen existuje ve dvou podobách: jednak jako zdrojový doklad vystavený ve zdrojové řadě dokladů a dále jako odpovídající účetní doklad v odpovídající účetní řadě dokladů. Podle typu dokladu zdrojový doklad a jeho účetní doklad vznikají buď automaticky najednou nebo mohou účetní doklady vzniknout později až ručním vyvoláním akce zaúčtování zdrojového dokladu do účetnictví, přičemž zdrojový doklad a odpovídající účetní doklad mohou ale nemusí mít shodnou zkratku a číslo dokladu (shodná bude typicky u nesouhrnně účtovaných dokladů, různá bude typicky u souhrnně účtovaných dokladů). Podrobně viz kap. Způsoby účtování - Zdrojové a účetní řady souhrnné/nesouhrnné.

Dále je uvedeno:

  • Účetní doklad souhrnný při svém vzniku obdrží vždy nové číslo zdrojové skupiny a nijak nepřebírá číslo zdrojové skupiny od některého ze zdrojových dokladů, které jsou jím souhrnně zaúčtovány. Tedy při souhrnném účtování souhrnný účetní doklad nebere ohled na čísla zdrojových skupin souhrnně účtovaných zdrojových dokladů, dostane nový SourceGroup a tedy vytváří samostatnou saldokontní skupinu. Objasníme na příkladu:

    Mějme pokladní příjmy PP-1/2002 a PP-2/2002 vystavené v řadě se souhrnným účtováním se zkratkou účetní řady PPS. Po uložení zdrojové doklady obdrží Source Group (např. zdrojový doklad PP-1/2002 obdrží nový samostatný Source Group např. SG=A, zdrojový doklad PP-2/2002 SG=B). Poté je souhrnně zaúčtujeme, nechť vznikne souhrnný doklad PPS-1/02. Účetní doklad obdrží také nový samostatný Source Group, např. SG=C. Po zaúčtování bude tvořit samostatnou saldokontní skupinu.

    Je tomu tak i v případě, že by uživatel v záložce Ruční párování zadal souhrnně účtovaný doklad resp. k souhrnně účtovanému dokladu zadal doklad párovací (tj. vznikl by nový záznam Source Group Identical).

    Mějme dodací list DL-1/2002 vystavený v řadě se souhrnným účtováním se zkratkou účetní řady DLS. Po uložení zdrojový DL má např. SG=A. DL naimportujeme do FV (s SG=B) a v záložce Ruční párování vznikne automaticky párovací vazba (viz Zdrojový expediční skladový doklad (DL), který je importován do příjmového prodejního), tj. vznikne záznam SGI, že SG=A⇔SG=B. Po uzavření uzávěrkou DL souhrnně zaúčtujeme, nechť vznikne souhrnný doklad DLS-1/02, který obdrží samostatný Source Group, např. SG=C. Po zaúčtování bude tvořit samostatnou saldokontní skupinu (neexistuje záznam SGI, že by SG=A bylo identické s SG=C.)

  • Účetní doklad nesouhrnný při svém vzniku přebírá číslo zdrojové skupiny od svého zdrojového dokladu (jak jej získá zdrojový doklad, viz dále Přidělování SourceGroup zdrojovým dokladům).

Zdrojový doklad obdrží odkaz na Source Group ihned při svém vystavení, pokud je pro něj přidělování Source Group smysluplné, tj. platí:

  • Neúčtované doklady:
    • Zdrojový doklad, o němž se z principu vůbec neúčtuje, a současně přidělení Source Group u nich nemá žádné další využití, žádný odkaz na Source Group neobdrží. Např. objednávky, platební příkazy apod.
    • Zdrojový doklad, o němž se z principu sice vůbec neúčtuje, ale přidělené číslo Source Group má další využití (např. pro následné související doklady a jejich spárování), odkaz na Source Group obdrží. Jedná se např. o předpis zálohového listu. (U zálohových listů se účtuje až o vzniklých zúčtováních záloh, nikoliv o předpisu samotném. Nicméně Source Group přidělený předpisu zálohového listu má svůj význam pro párování následných s ním souvisejících dokladů, např. jeho plateb, provedených zúčtování apod. (viz dále)).
    • Zdrojový doklad, o němž se sice defaultně neúčtuje, ale z principu o něm účtovat lze, odkaz na Source Group obdrží. Např. sankční faktura, o níž obecně účtovat lze, ale uživatel se rozhodl o ní neúčtovat a u zdrojové řady dokladů si tedy nastavil "neúčtovat". Pokud takový doklad uživatel skutečně nezaúčtuje, pak Source Group nebude mít další význam. Nicméně měl by význam, pokud by se uživatel nakonec rozhodl takový doklad zaúčtovat nesouhrnně, přestože byl vystaven v řadě s nastavením "neúčtovat" (což lze jen v agendách, kde mohou účetní doklady ke zdrojovým vznikat dodatečně až spuštěním funkce Zaúčtovat uživatelem (např. pokladní doklady, skladové doklady aj.) a současně k dané zdrojové řadě již existuje účetní řada pro nesouhrnné účtování).
  • Doklady účtované souhrnně:
    • Zdrojový doklad, o němž se účtuje a je vystaven v řadě s nastavením "účtovat souhrnně", odkaz na Source Group vždy obdrží. Pokud takový doklad uživatel skutečně zaúčtuje souhrnně, pak Source Group na zdrojovém dokladu nebude mít další význam (viz výše přidělování čísla Source Group účetním dokladům). Nicméně měl by význam, pokud by se uživatel nakonec rozhodl takový doklad zaúčtovat nesouhrnně, přestože byl vystaven v řadě s nastavením "účtovat souhrnně" (což lze jen v agendách, kde mohou účetní doklady ke zdrojovým vznikat dodatečně až spuštěním funkce Zaúčtovat uživatelem (např. pokladní doklady, skladové doklady aj.) a současně k dané zdrojové řadě již existuje účetní řada pro nesouhrnné účtování).
  • Doklady účtované nesouhrnně:
    • Zdrojový doklad, o němž se účtuje a je vystaven v řadě s nastavením "účtovat nesouhrnně", odkaz na Source Group vždy obdrží. Pokud takový doklad uživatel skutečně zaúčtuje nesouhrnně, pak Source Group na zdrojovém dokladu bude mít další význam pro následný účetní doklad (viz výše přidělování čísla Source Group účetním dokladům). Nicméně neměl by další význam, pokud by se uživatel nakonec rozhodl takový doklad nezaúčtovat anebo zaúčtovat souhrnně, přestože byl vystaven v řadě s nastavením "účtovat nesouhrnně" (což lze jen v agendách, kde mohou účetní doklady ke zdrojovým vznikat dodatečně až spuštěním funkce Zaúčtovat uživatelem (např. pokladní doklady, skladové doklady aj.) a současně k dané zdrojové řadě již existuje účetní řada pro souhrnné účtování).

Zdrojovému dokladu může být přidělen Source Group nově vytvořený nebo může být použit existující převzatý od jiného dokladu, viz dále:

Zdrojový doklad nově vzniklý bez vazby na žádný jiný doklad obdrží vždy nové číslo Source Group. Tzn., že vznikne další nová zdrojová skupina.

Tedy nově vzniklý doklad bez vazby na jiný doklad bude po svém nesouhrnném zaúčtování tvořit novou samostatnou saldokontní skupinu (pokud by byl zaúčtován souhrnně, pak by tvořil vždy novou skupinu, jelikož souhrnný účetní doklad dostane nový SourceGroup, viz výše Přidělování SourceGroup účetním dokladům). Objasníme na příkladu:

Mějme pokladní příjem PP-1/2002 vystavený v řadě s nesouhrnným účtováním a vystavený jako samostatný doklad (tedy nejedná se o platbu nějakého předpisu). Po uložení obdrží zdrojový doklad nový Source Group, např. SG=AA1000101. Jedná se o nesouhrnně účtovaný doklad, tudíž při uložení vzniká automaticky odpovídající účetní zápis v dané účetní řadě (nechť má tutéž zkratku PP). Tento účetní doklad přebere číslo Source Group od zdrojového, tedy bude také mít odkaz na SG=AA1000101. Po zaúčtování bude tvořit novou samostatnou saldokontní skupinu.

Zdrojový doklad nově vzniklý, který je inverzním prodejním dokladem - přebírá číslo Source Group (zdrojové skupiny) od dobropisovaného/ vraceného dokladu:

  • Dobropis přijatý/vydaný ⇒ automaticky se spáruje s fakturou přijatou/vydanou

    Mějme fakturu vydanou. Nechť je jí přidělen odkaz na novou zdrojovou skupinu, např. SG=YY000101. Jedná se o nesouhrnně účtovaný doklad, tudíž její účetní doklad, resp. účetní zápisy přeberou číslo SourceGroup od zdrojové faktury, tedy také budou mít odkaz na SG=YY000101. Tedy faktura bude po zaúčtování do deníku tvořit samostatnou saldokontní skupinu. Poté k faktuře vystavíme dobropis vydaný. Vzniklý zdrojový doklad dobropisu jakožto inverzní doklad přebere SourceGroup od zdrojové faktury, tedy jeho SG=YY000101. Jedná se o nesouhrnně účtovaný doklad, tudíž jeho účetní doklad, resp. účetní zápisy přeberou číslo SourceGroup od zdrojového dobropisu, tedy také budou mít odkaz na SG=YY000101. Tj. dobropis bude po zaúčtování do deníku v saldokontní skupině spolu s fakturou.

  • Dobropis daňového zálohového listu přijatého/vydaného ⇒ automaticky se spáruje s příslušným daň. zálohovým listem přijatým/vydaným.
  • Vrácení příjmu/výdaje ⇒ je-li účtováno nesouhrnně, pak se automaticky spáruje s pokladním příjmem/výdejem

    Je-li účtováno souhrnně, pak se automaticky nespáruje s pokladním příjmem/výdejem, jelikož souhrnný účetní doklad vždy obdrží samostatný svůj vlastní Source Group, pak vrácení po zaúčtování do deníku nebude v jedné saldokontní skupině s vraceným dokladem a případné spárování je třeba provést ručně dodatečně v deníku.

    Objasníme na příkladech:

    Příklad 1: Mějme pokladní příjem PP-1/2002 vystavený samostatně v agendě pokladních příjmů jako nový PP doklad v nesouhrnné řadě a nechť zdrojový PP obdrží Source Group např. SG=AA000101. Jeho účetní doklad, resp. účetní zápisy, přebere Source Group od zdrojového, tedy také SG=AA000101. Dále k němu vystavíme vrácení příjmu VP-1/2002 také v nesouhrnné řadě. Jde o inverzní doklad, tedy zdrojový doklad VP přebere Source Group od vraceného zdrojového dokladu, tedy bude mít též SG=AA000101. Jeho účetní doklad, resp. účetní zápisy, přebere Source Group zdrojového VP, tedy bude mít rovněž SG=AA000101. Tedy vrácení příjmu VP bude po zaúčtování do deníku v jedné saldokontní skupině spolu s pokladní příjemkou.

    Příklad 2: Mějme pokladní příjem PP-1/2002 vystavený samostatně v agendě pokladních příjmů jako nový PP doklad v souhrnné řadě a nechť zdrojový PP obdrží Source Group např. SG=AA000101. Jeho účetní souhrnný doklad dostane vlastní Source Group, tedy např. SG=BB000101. Dále k němu vystavíme vrácení příjmu VP-1/2002 také v souhrnné řadě. Jde o inverzní doklad, tedy zdrojový doklad VP přebere Source Group od vraceného zdrojového dokladu, tedy bude mít též SG=AA000101. Ale jeho účetní souhrnný doklad dostane vlastní Source Group, tedy např. SG=CC000101. Tedy vrácení příjmu po zaúčtování do deníku v tomto případě nebude v jedné saldokontní skupině s pokladní příjemkou.

  • Zdrojový doklad nově vzniklý, který je inverzním skladovým dokladem, pokud mezi zdrojovým a inverzním dokladem je vazba 1:1:

    V takovém případě je jednoznačná vazba mezi oběma doklady a lze tudíž přesně stanovit, k čemu se má párovat. Takový zdrojový doklad nově vzniklý, který je inverzním skladovým dokladem - přebírá číslo Source Group (zdrojové skupiny) od vraceného dokladu:

    • Vratka ⇒ je-li účtováno nesouhrnně, pak se automaticky spáruje s dodacím listem

      Je-li účtováno souhrnně, pak se automaticky nespáruje s dodacím listem, jelikož souhrnný účetní doklad vždy obdrží samostatný svůj vlastní Source Group, pak vratka po zaúčtování do deníku nebude v jedné saldokontní skupině s vraceným dokladem a případné spárování je třeba provést ručně dodatečně v deníku.

      Objasníme na příkladech:

      Příklad 1: Mějme dodací list DL-1/2002 vystavený v nesouhrnné řadě a nechť zdrojový DL obdrží Source Group např. SG=AA000101. Poté povedeme uzávěrku skladu a DL zaúčtujeme, jeho účetní doklad, resp. účetní zápisy, přebere Source Group od zdrojového, tedy také SG=AA000101. Dále k němu vystavíme vratku VR-1/2002 také v nesouhrnné řadě. Jde o inverzní doklad, tedy zdrojový doklad VR přebere Source Group od vraceného zdrojového dokladu, tedy bude mít též SG=AA000101. Jeho účetní doklad, resp. účetní zápisy, přebere Source Group zdrojové VR, tedy bude mít rovněž SG=AA000101. Tedy vratka VR bude po zaúčtování do deníku v jedné saldokontní skupině spolu s dodacím listem.

      Příklad 2: Mějme dodací list DL-1/2002 vystavený v souhrnné řadě a nechť zdrojový DL obdrží Source Group např. SG=AA000101. Poté povedeme skladovou uzávěrku a DL zaúčtujeme, jeho účetní souhrnný doklad, resp. účetní zápisy, dostane vlastní Source Group, tedy např. SG=BB000101. Dále k němu vystavíme vratku VR-1/2002 také v souhrnné řadě. Jde o inverzní doklad, tedy zdrojový doklad VR přebere Source Group od vraceného zdrojového dokladu, tedy bude mít též SG=AA000101. Ale jeho účetní souhrnný doklad po sklad. uzávěrce a zaúčtování dostane vlastní Source Group, tedy např. SG=CC000101. Tedy vrátka po zaúčtování do deníku v tomto případě nebude v jedné saldokontní skupině se zaúčtováním dodacím listem.

  • Zdrojový doklad nově vzniklý, který je inverzním skladovým dokladem, pokud mezi zdrojovým a inverzním dokladem je vazba m:n:
    • Vratka příjemek - Jedná se o vazbu m:n (jedna vratka příjemek může být vystavena k více příjemkám a naopak), proto program nemůže jednoznačně rozhodnout, k jakému zdrojovému dokladu by měl párovaní provést. Proto se tyto doklady automaticky bez zásahu uživatele nijak nepárují.

      Uživatel však má možnost zadat si u VPR nebo PR odpovídající párovací doklad v subzáložce Ruční párování, tj. půjde o automatické párování se zásahem uživatele, příp. si párování provést až dodatečně v deníku.

      Párovat Vratky příjemek s příslušnými Příjemkami a hlavně se souvisejícími doklady (Dobropis faktury přijaté, atd.) je žádoucí, protože pak je možné správně rozpouštět oceňovací rozdíly, viz funkce Podle vzorce.

Zdrojový doklad, který není inverzním dokladem, ale má jednoznačnou vazbu 1:n resp. 1:1 k jinému dokladu, přebírá v naprosté většině případů číslo Source Group (zdrojové skupiny) od daného dokladu, tedy páruje se se svým protějškem. Např.:

  • Potvrzení dobropisu - po vystavení přebere SG dobropisu ⇒ automaticky se spáruje s dobropisem

  • Převodka příjem - po vystavení přebere SG převodky výdej ⇒ je-li účtováno nesouhrnně, pak se automaticky spáruje s převodkou výdej

    Mezi převodkami výdej a převodkami příjem sice může existovat vazba m:n (mezi celými doklady, resp. jejich hlavičkami), nicméně vždy existují jednoznačné vazby mezi řádky zdrojových a následných dokladů, které k přebírání Source Group postačují.

    Je-li účtováno souhrnně, pak se automaticky nespáruje s převodkou výdej, jelikož souhrnný účetní doklad vždy obdrží samostatný svůj vlastní Source Group, pak vratka po zaúčtování do deníku nebude v jedné saldokontní skupině s vraceným dokladem a případné spárování je třeba provést ručně dodatečně v deníku.

    Stejný princip (příjmový doklad přebírá SG ze zdrojového výdejového dokladu) platí i pro skladové záměny a přeměny.

  • JSD ⇒ po zadání připojené FP z hlavičky JSD, JSD přebere SG od faktury ⇒ automaticky se spáruje s připojenou fakturou přijatou. Po zrušení vazby na FP obdrží odkaz na novou SG. Pozor, zde se jedná o situaci, kdy se na existujícím dokladu může změnit SG, což může vyvolat přeúčtování dokladu. Pokud je připojení na FP opravováno nebo rušeno, pak může dojít k zániku původní SG pro JSD, proto dále viz Zánik vazby SGI v případě mazání dokladů a změně vlastní Source Group a důsledky pro existující párování.
  • Ostatní příjem resp. Ostatní výdaj vystavený v režimu "Oprava daně u dlužníků v insolvenčním řízení", viz DPH v případě insolvenčního řízení - po vystavení přebere SG faktury vydané resp. přijaté ⇒ automaticky se spáruje s fakturou.
  • Ostatní příjem resp. Ostatní výdaj vystavený v režimu "Zaplacení po opravě daně u dlužníků v insolvenčním řízení", viz DPH v případě insolvenčního řízení - po vystavení přebere SG zdrojového OSP resp. OSV ⇒ automaticky se spáruje se zdrojovým OSP resp. OSV.

Zdrojový doklad, který je platbou jiného dokladu, přebírá číslo Source Group (zdrojové skupiny) od svého předpisu platby.

Toto platí pro všechny typy placených dokladů, tedy i je-li placeným dokladem zálohový list nebo daňový zálohový list. Avšak neplatí to pro platbu zálohou - tj. při zúčtování zálohy platí speciální mechanismus založený na tvorbě SGI, viz dále .

  • Nově vystavený platící doklad
    • Platba bankovním výpisem - řádek bankovního výpisu přebere SG od předpisu platby ⇒ řádek bankovního výpisu se automaticky spáruje s předpisem platby.
    • Platba vzájemným zápočtem - řádek vzájemného zápočtu přebere SG od předpisu platby ⇒ řádek vzájemného zápočtu se automaticky spáruje s předpisem platby.
    • Platba dokladem ostatní příjem/výdej - přebere SG od předpisu platby ⇒ doklad ostatní příjem/výdej se automaticky spáruje s předpisem platby.
    • Platba pokladnou - přebere SG od předpisu platby ⇒ je-li účtováno nesouhrnně, pak se automaticky spáruje s předpisem platby

      Je-li účtováno souhrnně, pak se automaticky nespáruje s předpisem platby, jelikož souhrnný účetní doklad obdrží samostatný svůj vlastní Source Group, pak platba po zaúčtování do deníku nebude v jedné saldokontní skupině s předpisem platby a případné spárování je třeba provést ručně dodatečně v deníku.

      Pokud tedy chcete platby hotově automaticky párovat s předpisem, nevystavujte je v řadách souhrnně účtovaných, což lze i vyloženě zakázat pomocí parametru Povolit zaúčtovat PP/PV souhrnně, pokud se jedná o doklady, které jsou platbou ve Firemních nastaveních.

    • Platba kurzovým rozdílem ⇒ doklad kurzového rozdílu se spáruje s předpisem platby.

  • Doklad připojený jako platba předpisu dodatečně:

    Byl-li platící doklad vytvořen samostatně (tj. má své vlastní číslo zdrojové skupiny, viz výše), ale později byl připojen jako platba k předpisu platby, přebere si od předpisu číslo Source Group. Tedy po zaúčtování je-li účtováno nesouhrnně, budou platba s předpisem v jedné saldokontní skupině. Naopak po odpojení platícího dokladu od předpisu platby, obdrží platící doklad nové samostatné číslo Source Group a po zaúčtování budou oba doklady v samostatných skupinách. Připojení platby dodatečně objasníme na příkladu:

    Mějme pokladní příjem vystavený samostatně v agendě pokladních příjmů jako nový PP doklad bez DPH v nesouhrnné řadě. Nechť je mu přidělen odkaz na nový Source Group, např. SG=YY000101. Jeho účetní doklad, přebere Source Group od zdrojového, tedy také SG=YY000101 a bude tvořit samostatnou saldokontní skupinu. Poté danou účtenku v záložce Platby faktury připojíme jakožto platbu faktury FV-1/2002, která má odkaz na zdrojovou skupinu např. SG=XX000101. Po připojení dojde k přeúčtování pokladní příjemky, její původní Source Group se zapomene a účtenka přebere Source Group od faktury, tedy bude mít SG=XX000101. Její účetní doklad přebere Source Group od zdrojového, tedy také SG=XX000101, tedy pokladní účtenka připojená jako platba k faktuře se spáruje s danou fakturou.

    Pozor, zde se jedná o situaci, kdy se na existujícím dokladu může změnit SG, což může vyvolat přeúčtování dokladu. Pokud je připojení dokladu jakožto platby opravováno nebo rušeno, pak může dojít k zániku původní SG pro daný doklad, proto dále viz Zánik vazby SGI v případě mazání dokladů a změně vlastní Source Group a důsledky pro existující párování.

Pro zúčtování zálohy platí speciální mechanismus. Při zúčtování zálohy (ze zálohového listu (ZL) nebo z daňového zálohového listu (DZL)), vzniká interně doklad o provedeném zúčtování zálohy do cílového dokladu, který není viditelný uživateli jako běžný doklad, ale jen jako záznam o provedeném zúčtování v záložkách Zúčtování ZL resp. DZL. Tento interní doklad o provedeném zúčtování přebere číslo Source Group od svého předpisu zálohy (tj. od ZL nebo DZL). Současně ale vznikne záznam Source Group Identical o tom, že Source Group daného "záznamu zúčtování" a Source Group dokladu, do něhož bylo zúčtováno, jsou identické. Na základě těchto vazeb identických SG pak bude zúčtování spárováno s dokladem, do něhož bylo zúčtováno.

Současně může dojít ke změně v existujícím párování, jelikož dochází ke vzniku nového záznamu identických SG, dále viz Vznik vazby SGI a důsledky pro existující párování.

Čerpání zálohového listu do faktury či jiného předpisu platby, tj. jeho zúčtování, je vlastně platbou této faktury či daného dokladu předpisu platby. Jeden zálohový list může být čerpán do více faktur, pak platí, že tento zálohový list má v deníku (žádostech) minimálně tolik záznamů, do kolika faktur byl zúčtován (čerpán) v odpovídajících částkách. Díky záznamům identických SG pak budou taková zúčtování jednoho ZL a všechny doklady, do nichž bylo zúčtováno (a příp. všechny s nimi spojené) v jedné společné saldokontní skupině. Vystavení daňového zál. listu (DZL) dle ZL je rovněž zúčtováním ZL do koncového dokladu a pro spárování platí totéž.

Zúčtování daňového zálohového listu do faktury není její platbou, ale pro jeho spárování s doklady, do nichž bylo zúčtováno, platí totéž.

Některé doklady umožňují zadávat čerpání částky dokladu z různých nákupních dokladů. Jedná se např. o Příjemky, Kooperace, Změna ceny majetku, Vratky příjemek apod., dále viz Záložka Výdaje pořízení/změny ceny resp. Související doklady - obecně.

Zvláštní případ tvoří doklady Pořízení majetku, viz Zařazení majetku do evidence s vazbou na nákupní doklad (s čerpáním výdajů z nákupního dokladu).

Při čerpání dokladů výdajů pořízení do uvedených dokladů se tyto doklady automaticky bez zásahu uživatele nijak nepárují. Jedná se o vazbu typu m:n (tj. např. skladová příjemka může čerpat z více nákupních dokladů a nákupní doklad může naopak být čerpán do více příjemek či i jiných dokladů), proto program nemůže jednoznačně rozhodnout, k jakému prodejnímu dokladu by měl párovaní provést (načerpání částky z nákupního dokladu do daného dokladu nijak Source Group daného dokladu ani nákupního dokladu neovlivní).

Uživatel však má možnost zadat si u daného dokladu nebo nákupních dokladů odpovídající párovací doklad v subzáložce Ruční párování, tj. půjde o automatické párování se zásahem uživatele. Pro urychlení procesu zadání ručních vazeb pro párování se uživateli vytvoření vazby při čerpání nabízí:

  • Pokud se do daného dokladu (Příjemka, Kooperace, Pořízení majetku, Změna ceny majetku, Vratka příjemky) zadá čerpání z nákupních dokladů, pak po vybrání konkrétního dokladu je uživatel dotázán, zda si přeje provést i ruční spárování a pokud ano, vytvoří záznam vazby mezi daným dokladem a nákupních dokladem v subzáložce Ruční párování. Systém se neptá, pokud párovací vazba mezi SG daného dokladu a SG čerpaného dokladu již existuje.
  • Pokud se odstraňuje čerpání, pak je uživatel dotázán, zda si přeje odstranit i ruční párování.

Je-li vytvořen záznam ručního párování mezi daným dokladem a čerpaným dokladem, pak se daný doklad automaticky spáruje s nákupním dokladem, u příjemek jen, je-li účtována nesouhrnně.

Příjemky totiž umožňují i souhrnné účtování a jak bylo uvedeno výše, je-li účtováno souhrnně, pak se doklad příjemky automaticky nespáruje s nákupním dokladem, ani kdyby splňoval podmínky pro spárování PR, jelikož souhrnný účetní doklad obdrží samostatný svůj vlastní Source Group, pak příjemka po zaúčtování do deníku nebude v jedné saldokontní skupině s nákupním dokladem a případné spárování je třeba provést ručně dodatečně v deníku.

Párovat skladové doklady s nákupními není vyloženě nutné, k doložení přehledu skladových dokladů, na základě kterých byl uskutečněn příslušný nákupní doklad, je možno si zavést a využít nějaký tiskový report věcné a časové souvislosti fakturačních a příjmových skladových dokladů.

Doklady Pořízení majetku se neúčtují a nemají ani subzáložku Ruční párování, tudíž je případná párovací vazba vidět pouze v subzáložce Ruční párování nákupního dokladu, z něhož je čerpáno. Jelikož se doklad Pořízení majetku neúčtuje, slouží párovací vazba jako údaj, přes který se k sobě případně spárují jím čerpané nákupní doklady.

Doklady Pořízení majetku obsahují subzáložku Výdaje pořízení, tj. patří do skupiny dokladů účelů výdaje, a umožňují tedy stejně jako doklady uvedené v části Zdrojový doklad s vazbou na nákupní doklad (s čerpáním výdajů z nákupního dokladu) zadávat čerpání částky dokladu z různých nákupních dokladů.

Doklady Pořízení majetku se neúčtují a nemají ani subzáložku Ruční párování, tudíž je případná uživatelem ručně zadaná párovací vazba vidět pouze v subzáložce Ruční párování nákupního dokladu, z něhož je čerpáno.

Vzhledem k tomu, že se doklady Pořízení majetku neúčtují, využívá se párovací vazby mezi dokladem Pořízení majetku a nákupními doklady až při zařazení příslušné karty majetku do evidence, při němž vznikne doklad Zařazení do evidence (ZM), který se automaticky spáruje s nákupními doklady zadanými v subzáložce Výdaje pořízení dokladu Pořízení majetku patřícího k zařazované kartě majetku, a to bez ohledu na to, zda uživatel ručně vytvořil párovací vazbu mezi dokladem Výdaje pořízení a nákupními doklady, nebo ne. Je-li karta majetku nejdříve zařazena do evidence a teprve potom jsou do subzáložky Výdaje pořízení dokladu Pořízení majetku čerpány nákupní doklady, rovněž se automaticky vytvoří párovací vazba mezi dokladem Zařazení do evidence a příslušnými nákupními doklady.

Jedná se o specifický případ párování, kdy program automaticky (tj. bez zásahu uživatele) vytvoří párovací vazbu mezi FV/PP a DL, přičemž párovací doklady jsou k dispozici v subzáložce Ruční párování, kde je může uživatel prohlížet a ručně odpojit. Viz možnosti párování.

Při importování (čerpání) DL do FV/PP resp. při vystavování nového DL spolu s FV/PP program při uložení FV/PP zkontroluje, zda existuje párovací doklad v subzáložce Ruční párování mezi FV/PP a všemi importovanými DL. Pokud párovací doklad v subzáložce Ruční párování neexistuje, pak se po uložení FV/PP automaticky přidá.

Vzhledem k tomu, že se jedná o vazbu m:n (jeden dodací list může být čerpán do více FV/PP a naopak), program nemůže jednoznačně rozhodnout při smazání řádku FV/PP, k jakému dodacímu listu smazaný řádek patřil, a tudíž nedojde ke zrušení párovací vazby mezi FV/PP a DL. Nicméně tuto vazbu může uživatel odstranit ručně v subzáložce Ruční párování.

Dále má uživatel možnost zadat si u DL nebo FV/PP ručně odpovídající párovací doklad v subzáložce Ruční párování, tj. využít automatické párování se zásahem uživatele, příp. si párování provést až dodatečně v deníku.

Párovat skladové doklady s prodejními není vyloženě nutné, k doložení přehledu skladových dokladů, na základě kterých byl uskutečněn příslušný prodejní (tržbový) doklad, je možno využít tiskový report věcné a časové souvislosti fakturačních a expedičních dokladů Věcná souvislost - výstup.

Při vystavování nové PR spolu s FV/PP v rámci vracení zboží (typicky obalů) na prodejních dokladech se tyto doklady mohou rovnou automaticky spárovat. Zde se jedná o jednoznačnou vazbu 1:1, proto PR přebírá číslo Source Group (zdrojové skupiny) od daného prodejního dokladu, tedy páruje se svým protějškem ⇒ je-li účtováno nesouhrnně, pak se automaticky spáruje s FV/PP. Pozor!!! Podmínka nesouhrnného účtování musí být splněna jak pro skladovou příjemku (PR), tak pro pokladní příjemku (PP).

Pokud by bylo účtováno souhrnně, pak by se PR automaticky nespárovala s FV/PP, jelikož souhrnný účetní doklad vždy obdrží samostatný svůj vlastní Source Group.

POZOR! Ke spárování zmíněných dokladů dojde jen tehdy, je-li PR vystavena rovnou s FV/PP. Automatické spárování se neřeší, pokud je PR do FV/PP naimportována až dodatečně. (Tj. pokud PR nevznikla rovnou s FV/PP, má samostatný Source Group. Obdobně se neřeší rušení párovacích vazeb, pokud PR byla vystavena s FV/PP, ale následně byla odpojena. (Tj. pokud PR vznikne s FV, má s FV shodný Source Group). V takových případech si párovací skupiny upravte až dodatečně v deníku.

Tj. pokud PR nevznikla rovnou s FV/PP, má samostatný Source Group a tento se dodatečným naimportováním do FV/PP nezmění (není řešeno). Tzn., že pokud byste takovou PR přeúčtovali, do saldokontní skupiny k FV/PP se automaticky nedostane. Obdobně, pokud PR vznikla s FV/PP, dostala Source Group od FV/PP a tento se dodatečným odpojením od FV/PP nezmění (není řešeno). Tzn., že pokud byste takovou PR přeúčtovali, dostane se opět do saldokontní skupiny k FV/PP.

  • Z hlediska vazeb na Source Group je jedno, zda účetní zápis je zatím pouze v žádostech nebo zda již je v deníku. Je-li účetní zápis zatím pouze v žádostech, má odkazy na Source Group, které jsou platné a nijak se zaúčtováním do účetního deníku nezmění.
  • Případná změna čísla zdrojové skupiny na zdrojovém a potažmo na účetním dokladu může vyvolat přeúčtování.

    Příklad 1: Mějme doklad JSD bez odkazu na fakturu přijatou. JSD doklad je zaúčtován v samostatné saldokontní skupině. Pokud pak JSD doklad opravíme a zadáme odkaz na fakturu přijatou, změní se Source Group JSD dokladu a provede se přeúčtování. Poté bude JSD doklad spárován s danou fakturou do jedné saldokontní skupiny.

  • Pokud v deníku provedete ruční změnu párování účetního záznamu, Source Group se nijak nemění. To proto, aby bylo možno doklad přeúčtovat s původním párováním. To ale také znamená, že jeho přeúčtováním o případné ručně provedené změny v párování přijdete, viz dále možnosti dodatečného párování, změny v párování.

Řádky téhož dokladu - Všechny řádky téhož účetního dokladu mají shodný Source Group. Tj. např. účtování základu a DPH téhož dokladu, nebo víceřádkové souhrnné doklady apod.

Řádky téhož účetního dokladu jsou v účetních žádostech zobrazeny graficky v jedné skupině.

Z výše uvedeného plyne i to, že je-li opraven jeden ze zdrojových dokladů, který byl zaúčtován pod jedním souhrnným, pak jemu odpovídající účetní zápis (řádek daného souhrnného dokladu) bude po opravě opět automaticky spárován se zbytkem souhrnného dokladu, podrobněji viz Přeúčtování souhrnně zaúčtovaných dokladů.

Toto neplatí pro bankovní výpisy a doklady vzájemných zápočtů, které jsou koncipovány tak, že každý jejich řádek vystupuje v podstatě jako samostatný doklad a účtuje a páruje se zvlášť (např. s odpovídajícím placeným dokladem), tedy každý řádek má vlastní Source Group. Řádky těchto dokladů buď obdrží odkazy na nově vzniklé Source Group, pokud nejsou spojeny s nějakým předpisem platby, nebo v opačném případě obdrží odkaz na Source Group placeného dokladu, viz dále.