Faktura ma kilkanaście pozycji. Klient sumuje kwoty brutto z pozycji i wychodzi mu o grosz więcej niż kwota do zapłaty na dole. Dzwoni z pytaniem, która liczba jest prawdziwa. Księgowa wystawia korektę, a w następnym miesiącu robi to samo przy innym kliencie.

Przecież to tylko grosz

Tak, ale za tym groszem idzie praca. Co miesiąc ktoś wystawia korektę i tłumaczy ją klientowi. Po kilku takich miesiącach nikt w firmie nie ufa liczbom z systemu, więc wszystko sprawdza się jeszcze raz w arkuszu. Firma płaci wtedy za system i za ręczne pilnowanie go.

Skąd się bierze różnica?

Najczęściej z tego, jak program przechowuje ułamki. Wiele programów domyślnie zapisuje nawet 10 groszy jako liczbę bardzo bliską 0,10, ale nie dokładnie jej równą. Przy pojedynczym działaniu tego nie widać, ale przy zaokrąglaniu kwot końcówka czasem wypada o grosz w złą stronę.

Programy, które liczą pieniądze, powinny zapisywać kwoty dokładnie, co do grosza, tak jak liczy człowiek na kartce. Wykonawca, który wcześniej nie robił programów do faktur albo rozliczeń, łatwo to przeoczy, bo w testach na kilku pozycjach wszystko się zgadza.

Zaokrąglać każdą pozycję czy dopiero sumę?

Oba sposoby są spotykane i oba mogą dać inną kwotę końcową. Gorzej, gdy w jednym systemie działają oba naraz, bo formularz zaokrągla pozycje, a wydruk dopiero sumę.

Sposób zaokrąglania powinien być ustalony raz i zapisany w jednym miejscu systemu, tak żeby obowiązywał w formularzu, w zapisanym dokumencie, na wydruku i w eksporcie. Powinno też być jasne, gdzie dokładnie kwota jest zaokrąglana. To, ile cyfr po przecinku pokazuje ekran, nie może po cichu zmieniać samej kwoty.

O tym, który sposób jest właściwy, decyduje firma razem ze swoją księgową. Programista nie powinien zgadywać, bo zgadnięta reguła zwykle wychodzi na jaw dopiero przy pierwszej korekcie.

W aplikacjach, które budujemy, kwoty liczymy dokładnie, co do grosza. Mamy do tego autorskie biblioteki: obliczenia zapisuje się w nich formułami jak w arkuszu, a ta sama formuła liczy w formularzu i przy zapisie. Sposób zaokrąglania ustalamy z firmą i jej księgową, zanim powstanie pierwsze obliczenie.

Dlaczego oferta liczy inaczej niż faktura?

Zwykle dlatego, że każda część systemu liczy po swojemu. Przeglądarka pokazuje sumę w trakcie wpisywania, serwer liczy ją jeszcze raz przy zapisie, a potem osobno liczą wydruk i eksport. Jeśli każde z tych miejsc ma własny sposób liczenia, rozjadą się przy pierwszej poprawce, którą ktoś zrobi tylko w jednym z nich.

Dobrze zbudowany system ma jeden zapis obliczenia, z którego korzystają wszystkie miejsca. Ta sama zasada dotyczy sprawdzania pól, o czym piszemy w artykule Formularz, który odstrasza klienta. Warto też, żeby dokument zapamiętywał wyliczone sumy. Faktura, która poszła do klienta, pokazuje wtedy te same kwoty także po latach, nawet jeśli w międzyczasie zmieniły się reguły liczenia.

Czy księgowa może sprawdzić, jak liczy program?

Może, jeśli obliczenia są zapisane formułami podobnymi do tych z arkusza kalkulacyjnego. Osoba, która na co dzień pracuje w arkuszach, przeczyta wtedy, co liczy program, i porówna to ze swoimi wyliczeniami. Gdy obliczenia są schowane w kodzie, zostaje tylko zaufanie do programisty.

Jeśli firma ma już arkusz, któremu ufa, to jest najlepszy punkt wyjścia. Jego zasady przenosi się do programu, a potem porównuje wyniki na tych samych danych. Różnice wychodzą wtedy przed wdrożeniem, zanim trafią na fakturę dla klienta.

Co jeszcze potrafi się nie zgadzać?

Dwa drobiazgi, o których mało kto myśli. Dzielenie przez zero powinno pokazać w polu wyraźny błąd, tak jak robi to arkusz. Jeśli program po cichu wstawi zero, trafi ono do sumy i nikt nie będzie wiedział, skąd się wzięło. Podobnie z pustą datą. Termin płatności liczony od niewpisanej daty wystawienia powinien zostać pusty, bo inaczej na dokumencie pojawi się data sprzed stu lat.