Krátka odpoveď
Účtovník má pred ostrým režimom overiť nielen to, že doklad existuje v účtovnom programe, ale aj to, že prešiel správnym doručovacím tokom, je dostupné pôvodné XML a chybové stavy majú jasného vlastníka.
Finančná správa pri postupe začiatku uvádza testovanie odosielania a prijímania faktúr pred plným spustením. Pre účtovníka to znamená kontrolný scenár, nie iba kliknutie na ukážkovú faktúru.
Kontrolný scenár
| Krok | Čo musí byť jasné |
|---|---|
| Príjem | participant ID a DIČ patria správnemu klientovi; doklad je v pôvodnom XML |
| Odoslanie | je známy CPDS, čas odoslania, identifikátor dokladu a výsledok validácie |
| Doručenie | technické prijatie, nedoručenie a aplikačné odmietnutie sa zobrazujú oddelene |
| Spracovanie | vecné schválenie a zaúčtovanie majú vlastný stav a vlastníka |
| SK TDD | ak ho rieši dané rozhranie, jeho podanie a oprava sú oddelené od doručenia |
| Archív/export | je dostupné pôvodné XML, prílohy a auditná stopa bez závislosti od náhľadu |
| Práva | pracovník vidí iba klientov a úkony, na ktoré má oprávnenie |
Testujte aj chyby
Bez chybového testu neviete, či proces skutočne funguje. Účtovník alebo kancelária by mali vidieť aspoň jeden scenár, v ktorom faktúra neprejde validáciou alebo sa nedoručí podľa očakávania.
Pri chybe treba vedieť:
- či ide o problém v obsahu faktúry,
- či ide o problém v Peppol adresovaní,
- či je zodpovedný účtovný softvér, CPDS alebo obchodný partner,
- či sa chyba prenesie späť používateľovi,
- či zostane auditná stopa.
Negatívny scenár nemá byť iba „neplatné XML“. Otestujte aj nesprávneho príjemcu, neznámy identifikátor, duplicitné odoslanie, nedostupnosť služby a pokus používateľa bez oprávnenia. Pri SK TDD overte opätovné podanie po chybe a zneplatnenie, ak túto vrstvu zabezpečuje používané riešenie.
Čo zapísať do interného postupu
Interný postup nemusí byť dlhý. Musí však pomenovať vlastníka každého kroku. Pri účtovnej kancelárii zapíšte pravidlá zvlášť pre klienta, kanceláriu a prípadného dodávateľa softvéru.
Minimum:
- kto má prístup k CPDS alebo účtovnému rozhraniu,
- kto kontroluje nové doručené doklady,
- kto smie odosielať eFaktúry,
- kto rieši opravy,
- kde sa uchováva XML,
- ako sa postupuje pri zmene klienta alebo účtovníka,
- kto kontroluje SK TDD a kto rieši nesúlad,
- aká je lehota eskalácie pri nedoručení.
Dve kontroly, ktoré sa často vynechajú
Po prvé, samotný výber portálu alebo zaškrtnutie CPDS v softvéri nie je dôkaz aktívnej zmluvy a registrácie na príjem. Skontrolujte zmluvný stav a smerovanie v sieti. Po druhé, pri konkrétnom Peppol identifikátore koordinujte jedného poskytovateľa príjmu; ďalší nástroj môže slúžiť iba na odosielanie alebo spracovanie.
Testy vykonávajte so syntetickými dokladmi v testovacom prostredí. Do protokolu zapíšte dátum, verziu validačných pravidiel, výsledok, vlastníka nápravy a dôkaz o opakovanom úspechu.
Súvisiace čítanie
Pokračujte cez testovanie pred plným spustením, účtovnú kanceláriu a viac klientov a slovník: kontrola eFaktúr účtovníkom.