Model danych faktury GST: minimalne pola dla HSN i zamówień

Co zwykle idzie nie tak z fakturami GST

Większość problemów z fakturami GST to nie „złożona logika podatkowa”, lecz brakujące lub niespójne dane. Audyt kończy się niepowodzeniem, gdy faktury nie da się jednoznacznie powiązać z tym, co sprzedano, komu, gdzie dostarczono i jak policzono podatek.

Częstym wyzwalaczem jest brak HSN, przestarzały kod lub przypisanie HSN na niewłaściwym poziomie. Zespół może przechowywać HSN w produkcie, ale linia faktury jest tworzona z innej nazwy SKU lub wariantu, więc HSN nie trafia na dokument końcowy. Innym częstym problemem jest błędny podział podatku: naliczanie IGST zamiast CGST+SGST (lub odwrotnie), ponieważ „miejsce dostawy” wywnioskowano ze adresu wysyłki bez zapisu kodów stanów użytych do decyzji.

Zespoły finansowe odczuwają to natychmiast. Uzgadnianie staje się codziennym sprzątaniem: sumy faktur nie zgadzają się z zamówieniem, zamówienie nie zgadza się z rozliczeniem bramki płatności, a zwroty wymagają łańcucha ręcznych notatek. Nawet drobne różnice zaokrągleń między pozycjami mogą spowodować niezgodności między PDF faktury, raportami GST i księgą.

Oto wzorce, które powodują najwięcej problemów z niezgodnościami:

• Produkt i linie faktury nie mają tych samych pól HSN, stawki GST i wartości podlegającej opodatkowaniu.
• Podatek jest liczone w kilku miejscach (koszyk vs faktura) i wyniki różnią się.
• Przechowywane są tylko „sumy ogólne” bez rozbicia na wartość opodatkowaną i poszczególne składniki podatku.
• Numeracja faktur jest edytowalna lub zdublowana w różnych seriach.
• Zwroty zapisywane są jako ujemne zamówienia zamiast właściwych not korygujących.

Celem modelu danych faktury GST jest proste: przechowywać minimalny zestaw pól zamówienia, produktu, stron, podatku, faktury i not korygujących, aby każdą liczbę dało się później odtworzyć i wytłumaczyć. Utrzymaj model niewielki, ale nie pomijaj prawnie istotnych pól decydujących o rodzaju podatku, stawce i raportowaniu.

Najmniejszy zestaw rekordów, którego potrzebujesz

Jeśli chcesz, aby faktury GST były łatwe do wygenerowania i późniejszego uzgadniania, zacznij od małego zestawu obiektów i spraw, by każdy z nich robił jedną rzecz. Czysty model danych faktury GST to mniej liczba tabel, a więcej stabilność faktów w czasie.

Oto podstawowe rekordy, których większość zespołów potrzebuje od dnia pierwszego:

• Klient: kto kupił (imię i nazwisko/nazwa, telefon/e-mail, GSTIN jeśli B2B)
• Adres: wysyłka i rozliczenie, plus informacje o stanie i miejscu dostawy
• Produkt (lub usługa): co sprzedano, jednostka, cena bazowa i domyślny HSN/SAC
• Zamówienie: zdarzenie handlowe (koszyk, rabaty, koszty wysyłki, status)
• Płatność: jak przeszły pieniądze (referencja bramki, metoda, kwota zaksięgowana, data)

Faktura powinna być oddzielna od zamówienia. Zamówienia mogą się zmieniać (edytowany adres, anulowane pozycje, częściowa realizacja). Faktury nie powinny. Potrzebują stabilnej numeracji, dat i sum, które nigdy nie „dryfują” z powodu późniejszych zmian zamówienia.

Punktem odniesienia dla dokładności podatku są pozycje (Line Items). Każda pozycja zamówienia (a później każda pozycja faktury) powinna zawierać dokładną ilość, cenę jednostkową, rabat i rozbicie podatku dla tej pozycji. To tam stosuje się HSN/SAC i stawki GST.

Szczegół, który ratuje zespoły finansowe: przechowuj snapshoty. Gdy generujesz fakturę, skopiuj opis produktu, HSN/SAC, stawkę podatku i ceny do pozycji faktury. Nie polegaj na aktualnym katalogu produktów, bo stawki i nazwy się zmieniają.

Opcjonalnie, ale często warto dodać wcześnie: Zwroty, Refundy i Noty korygujące jako oddzielne rekordy. Przykład: jeśli klient zwraca jeden przedmiot z zamówienia dwu-pozycyjnego, chcesz noty korygującej odnoszącej się do oryginalnej linii faktury, podczas gdy zapis zwrotu płatności odnosi się do transakcji bramki. Trzymanie tych obiektów explicite zapobiega ręcznym poprawkom w rejestrach GST na koniec miesiąca.

Jeśli budujesz to w Koder.ai, traktuj każdy obiekt najpierw jako prosty ekran (utwórz, pokaż, edytuj), a generowanie faktury dodaj dopiero po wdrożeniu snapshotów i pól na poziomie linii.

HSN i SAC: gdzie pasują do modelu

HSN (dla towarów) i SAC (dla usług) nie są tylko „szczegółami faktury”. Zaczynają się w definicji produktu/usługi, a następnie są kopiowane na każdą linię faktury w momencie wystawienia. To utrzymuje poprawność koszyków mieszanych i ułatwia audyt, bo każda linia jest samodzielna.

Praktyczny minimalny model danych to:

• Produkt: id, nazwa, SKU, jednostka (UOM), base_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code
• InvoiceLine: id, invoice_id, product_id (opcjonalne dla linii ręcznych), description, unit, qty, unit_price, tax_category_id, hsn_or_sac_type, hsn_or_sac_code

Umieszczenie HSN/SAC w produkcie ułatwia adminowi utrzymanie w jednym miejscu. Skopiowanie go do InvoiceLine to to, co sprawia, że przeszłe faktury są stabilne. Nawet jeśli produkt później się zmieni, faktura pokazuje, co było prawdą w chwili sprzedaży. To sedno modelu danych faktury GST, który nie zawodzi przy uzgadnianiu.

Dla przechowywania HSN trzymaj to proste: kod jest wymagany, opis opcjonalny, a effective_from date opcjonalny jeśli chcesz historię zmian. Większość zespołów nie potrzebuje opisu na każdej pozycji, ale może on pomóc przy wyjątkach sprawdzanych przez finanse.

Mieszane koszyki są normalne: jedna faktura może mieć wiele pozycji i zatem wiele kodów HSN/SAC. Nie próbuj narzucać jednego kodu na fakturę. Sumy agregują się na poziomie nagłówka faktury, klasyfikacja pozostaje na poziomie linii.

Zarządzanie zmianami to miejsce, gdzie ludzie popełniają błędy. Użyj prostego zestawu reguł:

• Nigdy nie nadpisuj HSN/SAC na wystawionych pozycjach faktury.
• Jeśli HSN/SAC produktu się zmieni, zaktualizuj Produkt tylko dla przyszłych zamówień.
• Jeśli śledzisz historię, dodaj nowy rekord effective_from zamiast edytować stary.

W panelu administracyjnym wystarczy jedno miejsce do edycji pól podatkowych Produktu oraz widok tylko do odczytu na linii faktury, by potwierdzić, co zostało zarejestrowane w momencie wystawienia. Jeśli budujesz te ekrany szybko, narzędzia takie jak Koder.ai mogą wygenerować podstawowe strony CRUD i tabele danych z tego modelu przy minimalnym wysiłku.

Dane stron: GSTIN, adresy i miejsce dostawy

Model danych faktury GST najczęściej zawodzi na detalach stron. Jeśli tożsamość nabywcy lub sprzedawcy jest choćby trochę niepoprawna, faktura może być ważna na papierze, ale kłopotliwa w zwrotach i uzgadnianiu.

Zacznij od traktowania „sprzedawcy”, „nabywcy” i „ship-to” jako osobnych stron, nawet jeśli to ta sama osoba. Zapobiega to późniejszym obejściom, gdy klient doda inny adres wysyłki lub gdy sprzedajesz z więcej niż jednej rejestracji GST.

Minimalne pola do przechowania (nabywca i sprzedawca)

Trzymaj pola nudne i jawne. To te, które zwykle trafiają na fakturę i do raportów:

• Nazwa prawna (tak jak ma się pojawić na fakturze)
• Nazwa handlowa (opcjonalna, ale użyteczna)
• GSTIN (sprzedawca wymagany; nabywca dopuszczalny pusty)
• Telefon/e-mail (nie zawsze obowiązkowe, ale pomocne dla obsługi)
• Linie adresu, miasto, stan, kraj, kod pocztowy

Przechowuj stan zarówno jako czytelny tekst, jak i kod stanu, ponieważ raportowanie i zasady miejsca dostawy często opierają się na kodzie.

Rozliczenie vs wysyłka i miejsce dostawy

Zapisz zarówno adres rozliczeniowy, jak i wysyłkowy na zamówieniu, nie tylko w profilu klienta. Profile się zmieniają; faktury nie powinny.

Miejsce dostawy powinno być zapisane jako konkretny kod stanu na fakturze (skopiowany z zamówienia w momencie wystawienia). Nie „przeliczaj” go później. Jeśli twoją regułą jest „stan docelowy wysyłki”, zapisz wynik tej decyzji oraz stan użyty do podjęcia jej. To ułatwia audyty i spory.

B2B vs B2C: kiedy GSTIN jest obowiązkowy

Dla B2B GSTIN nabywcy jest zwykle wymagany i powinien być walidowany pod względem długości i formatu przy wprowadzaniu. Dla B2C GSTIN może zostać pusty, ale nadal potrzebujesz pełnego adresu i stanu, aby określić, czy obowiązuje CGST/SGST czy IGST.

Prosta zasada działająca w większości systemów: jeśli GSTIN nabywcy jest obecny, traktuj jako B2B; jeśli nie, traktuj jako B2C. Jeśli potrzebujesz wyjątków, przechowuj pole customer_type.

Sprzedawcy wielo-oddziałowi (wiele GSTIN)

Jeśli masz oddziały lub jednostki biznesowe z różnymi rejestracjami GST, modeluj „Seller Entity” jako własny rekord z własnym GSTIN i adresem. Każde zamówienie powinno odnosić się dokładnie do jednego podmiotu sprzedawcy, a każda faktura powinna skopiować te dane, aby historyczne faktury pozostały poprawne nawet po zmianie adresu sprzedawcy.

Narzędzia takie jak Koder.ai mogą szybko wygenerować formularze administracyjne dla tych rekordów, ale kluczowa jest struktura: oddzielny podmiot sprzedawcy, snapshoty w czasie zamówienia i jawny kod stanu miejsca dostawy.

Pola obliczeń podatku, które musisz przechowywać

Najczęstszy podział jest prosty: jeśli miejsce dostawy leży w tym samym stanie co dostawca, podatek to CGST + SGST. Jeśli jest inny stan, podatek to IGST. System nie powinien „przeliczać ponownie później z sum”, ponieważ drobne różnice (zaokrąglenia, rabaty, wysyłka) są tym, co powoduje niezgodności.

Przynajmniej przechowuj kwoty podatku na poziomie linii faktury, nie tylko w nagłówku. W ten sposób możesz wyjaśnić każdą złotówkę na fakturze i odnieść ją do produktu, HSN i przychodu.

Praktyczne minimum na poziomie linii faktury wygląda tak:

• taxable_value (po alokacji rabatu do linii)
• gst_rate_percent
• cgst_rate_percent, sgst_rate_percent, igst_rate_percent (przechowuj użyty podział)
• cgst_amount, sgst_amount, igst_amount (przechowuj obliczone kwoty)
• line_total (taxable_value + kwoty podatku)

Rabat to miejsce, gdzie systemy się komplikują. Zdecyduj jedną regułę i przechowuj ją jawnie. Jeśli rabaty obniżają cenę przed podatkiem (typowe dla rabatów pozycyjnych i kuponów), przechowuj oryginalną kwotę brutto, kwotę rabatu i wynikającą wartość opodatkowaną. Jeśli masz kupon na poziomie zamówienia, alokuj go po liniach (zwykle proporcjonalnie do przedrabatowej wartości każdej linii) i przechowuj alokowany rabat na linii, aby rachunki podatkowe były wytłumaczalne.

Zaokrąglanie powinno być spójne i zapisane. Wybierz, czy zaokrąglasz na poziomie linii, czy tylko na poziomie faktury, a następnie zapisuj zaokrąglone wyniki, które wydrukowałeś. Wiele zespołów liczy podatek po linii, zaokrągla do 2 miejsc, sumuje, a potem dodaje pole invoice_rounding_adjustment, by dojść do dokładnej kwoty do zapłaty.

Koszty wysyłki i obsługi nie powinny być ukrytym dodatkiem. Traktuj je jako oddzielną pozycję faktury z własnym kodem HSN/usługi i regułami podatkowymi. Przykładowo, zamówienie z dwoma produktami i opłatą za wysyłkę staje się trzema liniami, każda z przechowywaną wartością opodatkowaną i składnikami podatku, co ułatwia uzgadnianie finansów.

Dane dokumentu faktury: numeracja, daty, sumy, status

Gdy podatek jest policzony, faktura nadal potrzebuje pól „dokumentu”, które czynią ją ważną, audytowalną i łatwą do uzgodnienia później. W modelu danych faktury GST traktuj nagłówek faktury jak zapis prawny: powinien być stabilny, nawet jeśli dane produktu lub klienta zmienią się w przyszłości.

Zacznij od podstaw nagłówka: numer faktury, data wystawienia (data na fakturze), typ faktury (tax invoice, eksport, B2B, B2C itp.) i waluta. Nawet jeśli głównie fakturujesz w INR, przechowywanie waluty unika kłopotliwych przypadków przy eksporcie lub marketplace'ach wielowalutowych.

Numeracja to miejsce, gdzie zespoły się spalają. Trzymaj serię lub przedrostek (np. „FY25-INV-”), przechowuj rok finansowy i egzekwuj unikalność na poziomie bazy danych. Przechowuj też kontrolę „następnego numeru” na serię w panelu admina, aby dwóch administratorów nie mogło wystawić tego samego numeru jednocześnie.

Sumy powinny być przechowane jawnie, a nie tylko wyliczane. Zapisz subtotal (wartość opodatkowaną), całkowity podatek, sumę brutto i oddzielne zaokrąglenie. Jeśli przeliczysz później z pozycji, drobna zmiana reguły może sprawić, że stare faktury przestaną się zgadzać z złożonymi deklaracjami.

Statusy powinny odzwierciedlać rzeczywiste życie dokumentu i blokować rekordy, gdy to potrzebne:

• Draft (edycyjny)
• Issued (numer przypisany, PDF wygenerowane)
• Cancelled (zachowane dla audytu, nie usunięte)
• Refunded (płatność cofnięta, może wymagać noty korygującej)
• Credit noted (wystawiona powiązana nota kredytowa)

Na koniec przechowuj metadane artefaktów: wersję szablonu PDF, znacznik czasu wygenerowania i identyfikator pliku. Hash jest opcjonalny, ale przydatny, jeśli musisz udowodnić, że PDF nie został zmieniony.

Przykład: jeśli agent wsparcia wygeneruje PDF ponownie po aktualizacji szablonu, sumy i numer faktury powinny pozostać identyczne, ale przechowywana wersja szablonu wyjaśnia, dlaczego układ PDF wygląda inaczej.

Ekrany administracyjne dla produktów, podatków i danych klientów

Jeśli chcesz czystych faktur GST, nie zaczynaj od ekranu faktury. Zacznij od stron administracyjnych, które ją zasilają. Dobry model danych faktury GST pozostaje niewielki, gdy wejścia są kontrolowane i spójne.

Katalog produktów (SKU do HSN/SAC)

Katalog produktów to miejsce, gdzie zaczyna się większość przyszłych niezgodności, więc trzymaj go rygorystycznie. Każde SKU powinno mieć dokładnie jeden domyślny HSN (lub SAC dla usług), domyślną stawkę GST i ewentualne wyjątki obowiązujące tylko w określonych datach.

Praktyczny ekran produktu zwykle potrzebuje:

• SKU i nazwa produktu (tak, jak chcesz, by drukowano)
• Kod HSN/SAC, stawka GST i kategoria podatkowa (jeśli używasz)
• Active from/to (żeby zmiany nie nadpisywały starych faktur)
• Nadpisania cen (dla specjalnych MRP lub cen kanałowych)
• Status (aktywny/nieaktywny) z jasnym uzasadnieniem dezaktywacji

Ustawienia podatkowe (stawki i reguły krajowe vs międzystanowe)

Unikaj UI typu „kalkulator”. Zamiast tego przechowuj dane wejściowe, które system może stosować konsekwentnie: tabele stawek, reguły miejsca dostawy, i sposób decydowania o intra-state vs inter-state (zwykle przez porównanie stanu dostawcy i stanu wysyłki).

Utrzymaj ekran podatkowy skoncentrowany na: stawce podatku wg kategorii/grupy HSN, datach obowiązywania i co zrobić, gdy nabywca poda ważny GSTIN vs gdy go nie poda.

Profil klienta i firmy (kto jest na fakturze)

Ekran klienta powinien uchwycić GSTIN i jego status walidacji oraz domyślne adresy rozliczeniowe i wysyłkowe. Nie pozwól użytkownikom wpisywać stanów dowolnym tekstem; używaj kontrolowanej listy, aby „KA” i „Karnataka” nie stały się dwiema różnymi wartościami.

Ekran profilu firmy jest równie ważny: nazwa prawna, GSTIN, adres siedziby i ustawienia serii numerów faktur (prefiks, następny numer i granice roku finansowego). Ogranicz dostęp z uprawnieniami, bo zmiany wpływają na wszystkie przyszłe dokumenty.

Podstawy logów audytu (zaufanie i śledzenie zmian)

Nie potrzebujesz skomplikowanego systemu, ale potrzebujesz śladu. Loguj kto zmienił HSN/SAC, stawki GST, ustawienia serii faktur lub GSTIN firmy, wraz ze starą wartością, nową, znacznikiem czasu i powodem.

Jeśli budujesz te ekrany w narzędziu takim jak Koder.ai, traktuj logi audytu i daty obowiązywania jako pola pierwszej klasy od pierwszego dnia. Kosztują niewiele, a ratują godziny przy przeglądach finansów.

Krok po kroku: od zamówienia do zgodnej faktury

Zgodna faktura to mniej kwestia ozdobnego formatu, a więcej blokowania właściwych faktów we właściwym momencie. Jeśli zaprojektujesz model danych faktury GST wokół tego przepływu, praca finansów stanie się prostym dopasowaniem, a nie cotygodniowym śledztwem.

1) Zamroź to, co klient faktycznie kupił

Zanim policzysz podatek, zablokuj snapshot zamówienia: pozycje, ilości, ceny jednostkowe, rabaty, opłaty za wysyłkę/obsługę, GSTIN klienta (jeśli jest), adresy rozliczeniowe i wysyłkowe oraz sygnały miejsca dostawy. Snapshot nie powinien się zmieniać nawet jeśli cena produktu lub mapowanie HSN zmieni się później.

2) Zamień snapshot na linie faktury (z skopiowanymi atrybutami podatkowymi)

Oblicz podatki i wygeneruj linie faktury ze snapshotu. Każda linia faktury powinna skopiować HSN/SAC, stawkę podatku, wartość opodatkowaną i użyte kwoty podatku w danym momencie, zamiast pobierać je na żywo później.

3) Wystaw fakturę i uczyn ją niezmienną

Przypisz numer faktury i datę wystawienia, a następnie oznacz fakturę jako wystawioną. Od tego momentu zablokuj edycję cen, stawek podatku, kodów HSN i adresów na rekordzie faktury. Jeśli coś trzeba dopuścić, ogranicz to do notatek nie finansowych i wewnętrznych tagów.

4) Wygeneruj dokument końcowy i zapisz sumy

Wygeneruj PDF/widok do druku z wystawionej faktury, a następnie zapisz ostateczne sumy, które będziesz raportować: wartość opodatkowana, sumy CGST/SGST/IGST, zaokrąglenie i sumę brutto. Jeśli chcesz dodatkowego bezpieczeństwa, zapisz wersję dokumentu lub sumę kontrolną, aby udowodnić, że wydruk zgadza się z zapisanymi liczbami.

5) Obsłuż zmiany zgodnie z prawem

Po wystawieniu zmiany powinny następować zgodnie z regułami, a nie przez edycje:

• Korekta ceny: wystaw notę korygującą (debit/credit note) odnoszącą się do oryginalnej faktury.
• Anulowane zamówienie po wystawieniu: anuluj fakturę jeśli prawo pozwala, w przeciwnym razie wydaj notę korygującą.
• Klient zmienia adres po wystawieniu: nie nadpisuj faktury; popraw sprawę odpowiednim dokumentem i zachowaj ślad audytu.
• Częściowy zwrot: nota korygująca tylko na zwrócone linie/kwoty.
• Wymiana przesyłki: nowe zamówienie/faktura, nie cicha edycja.

Jeśli wdrożysz ten przepływ w panelach administracyjnych (tryb planowania Koder.ai pomaga mapować kroki przed budową), zespół może szybko generować faktury bez łamania uzgadniania później.

Uczyń uzgadnianie proste: płatności, refundy i rejestry

Uzgadnianie się komplikuje, gdy płatności są traktowane jako pojedyncza flaga „opłacone/nieopłacone” przy zamówieniu. Trzymaj płatności i refundy jako oddzielne rekordy wskazujące na zamówienie i fakturę, aby finanse mogły dopasować rozliczenia bankowe bez przepisywania historii.

Oddzielne rekordy płatności i refundów (nie edytuj faktury)

Zgodna faktura powinna pozostać stabilna po jej wystawieniu. Jeśli klient płaci w częściach lub zwracasz środki później, zapisz to jako wpis płatności lub zwrotu, a nie jako zmianę sum faktury.

Minimalne pola, które ułatwiają uzgadnianie:

• Payment: payment_id, order_id, invoice_id, method, gateway_name, gateway_payment_id, amount, currency, authorized_at, captured_at, settlement_date, status
• Settlement (opcjonalne): settlement_id, gateway_payout_id, settlement_date, gross_amount, fees, net_amount
• Refund: refund_id, order_id, invoice_id, payment_id, credit_note_id (jeśli wydano), gateway_refund_id, amount, reason, refunded_at, status
• Klucze do uzgadniania, których nigdy nie powinieneś ponownie używać: order_id, invoice_id, payment_id, refund_id, credit_note_id

Jeśli klient zwraca jedną pozycję, nie „zmniejszaj faktury”. Wydaj notę korygującą i powiąż ją z oryginalną fakturą. Rejestr faktur pozostaje czysty, a zwrot powiązuje się z notą korygującą.

Widok dla finansów i eksporty, które oszczędzają godziny

Daj finansom jeden ekran, który odpowiada: co zostało wystawione, co zostało zapłacone, co jest nadal otwarte i co zostało cofnięte. Uwzględnij przedziały zaległości (0-7, 8-30, 31-60, 60+ dni) i możliwość przejścia do powiązanych wpisów płatności oraz zwrotów.

Eksporty, których zespoły potrzebują co miesiąc:

• Rejestr faktur (wystawione, anulowane, skorygowane)
• Podsumowanie podatku według stawki i HSN/SAC (wspiera twój model danych faktury GST)
• Uzgadnianie płatności względem faktur (invoice_id, sumy płatności, saldo)
• Rejestr refundów i not korygujących
• Raport rozliczeń bramki (payout_id do mapowania invoice/payment)

Przykład: zamówienie ma wartość 10 000 Rs, dziś zapłacono 6 000 Rs, a 4 000 Rs następnego tygodnia. Faktura pozostaje na 10 000 Rs. Widok finansów pokazuje saldo 4 000 Rs dopóki nie nadejdzie drugie rozliczenie, potem oznacza jako w pełni zapłacone bez zmiany wystawionego dokumentu.

Powszechne pułapki powodujące problemy z zgodnością i niezgodności

Większość problemów z fakturami GST to nie „logika podatkowa”, lecz prowadzenie rejestrów: liczby na PDF nie zgadzają się z eksportami finansów, albo faktury nie da się wytłumaczyć po miesiącach.

Pierwsza pułapka to liczenie GST tylko w widoku. Jeśli obliczasz CGST/SGST/IGST za każdym razem, gdy ktoś otwiera fakturę, w końcu otrzymasz różne wyniki po zmianie stawki, reguły zaokrągleń lub po naprawie błędu. Przechowuj obliczone rozbicie podatku użyte przy wystawieniu faktury, nawet jeśli zapisujesz też dane wejściowe.

Druga pułapka to pozwalanie na edycje wystawionej faktury. Gdy faktura jest finalna, zmiany powinny następować przez notę korygującą lub przepływ zastępczy z zapisem audytu. W przeciwnym razie zobaczysz spory typu „dlaczego PDF klienta różni się od ksiąg?”.

Oto wzorce niezgodności, które pojawiają się najczęściej w modelu danych faktury GST:

• Brakuje miejsca dostawy lub kod stanu jest błędny, więc naliczono IGST zamiast CGST+SGST (lub odwrotnie).
• HSN/SAC produktu lub stawka podatku zostały zaktualizowane, a stare zamówienia przeliczono z użyciem nowej wartości.
• Podatek jest przechowywany, ale reguły zaokrągleń różnią się między UI, generowaniem PDF i eksportami CSV.
• Rabaty są stosowane po podatku w jednym miejscu i przed podatkiem w innym.
• Zwroty zapisywane są jako ujemne pozycje bez jasnego powiązania z oryginalną fakturą.

Szybki przykład: sprzedajesz klientowi w Karnataka, ale adres wysyłki jest w Maharashtra. Jeśli system wybierze stan rozliczeniowy przypadkowo, możesz pobrać CGST+SGST zamiast IGST. Jeśli dodatkowo przeliczysz podatki na żywo, błąd może się „naprawić” później, pozostawiając finanse z liczbami, które nie pasują do wystawionego dokumentu.

Gdy budujesz ekrany administracyjne (czy to custom, czy przez Koder.ai), dodaj małe zabezpieczenia: blokuj wystawione faktury, pokazuj obok siebie wejścia miejsca dostawy i obliczony typ podatku, oraz przechowuj niemodyfikowalny snapshot HSN, stawki i zaokrągleń użytych przy wystawieniu.

Szybka lista kontrolna i następne kroki

Zanim wyślesz fakturę do klienta lub oznaczysz ją jako „wystawioną”, wykonaj szybki zestaw kontroli. To miejsce, gdzie większość drobnych błędów przeradza się później w duże problemy z uzgadnianiem. Jeśli budujesz model danych faktury GST, warto wbudować te kontrole zarówno w reguły walidacji, jak i w interfejs admina.

Kontrole przed wystawieniem faktury (po jednej fakturze)

• HSN/SAC jest obecny na każdej pozycji i pasuje do sprzedanego produktu/usługi.
• Zasady GSTIN są poprawnie zastosowane (B2B vs B2C), a dane rozliczeniowe i wysyłkowe nie są sprzeczne.
• Miejsce dostawy jest zapisane, a podział podatku ma sens (CGST/SGST vs IGST).
• Sumy się zgadzają: wartość opodatkowana, każdy składnik podatku, zaokrąglenie i suma brutto.
• Po wystawieniu faktura jest zablokowana (brak cichych edycji). Poprawki następują przez notę korygującą lub przepływ anulowania, nie przez przepisywanie historii.

Prosty przykład: klient zmienia adres wysyłki po płatności i zmienia się stan. Jeśli ponownie wystawisz tę samą fakturę z nowym podatkiem, rejestry i zapisy płatności przestaną się zgadzać. Bezpieczniejsze jest zachowanie oryginalnej faktury jako niezmiennej i stworzenie dokumentu korygującego.

Kontrole danych + przepływu (by utrzymać finanse w czystości)

• Numeracja faktur jest unikalna, sekwencyjna zgodnie z polityką i generowana dopiero w momencie „wystawienia”.
• Przechowuj obliczone kwoty podatku, nie tylko stawki, aby raporty pozostały stabilne nawet po zmianie stawek.
• Istnieją jasne kroki statusu: draft -> issued -> cancelled (i oddzielne dokumenty not korygujących).
• Raporty uzgadniają się okresowo: sumy rejestru faktur powinny odpowiadać przechwyconym płatnościom, przetworzonym refundom i należnościom.
• Pola audytu są zawsze obecne: kto utworzył, kiedy wystawiono, oraz powód anulowania lub noty korygującej.

Kolejne kroki: zaimplementuj ekrany i walidacje najpierw, potem iteruj. W Koder.ai zacznij od Planning Mode, aby naszkicować rekordy i ekrany administracyjne (produkty z mapowaniem HSN/SAC, dane klientów/GSTIN, reguły podatkowe i faktury). Wygeneruj aplikację, przetestuj kilka rzeczywistych zamówień end-to-end, a potem użyj snapshotów i rollbacku, aby bezpiecznie dopracować przepływ. Gdy będziesz potrzebować głębszych modyfikacji, eksportuj kod źródłowy i rozwijaj dalej w zwykłym procesie.