Faktury z zamówień ktoś przepisuje ręcznie do programu księgowego, a potem wysyła ją jeszcze raz, tym razem do systemu skarbówki.
Klient zaznacza „chcę fakturę”, ale NIP albo nazwa firmy nie dochodzą do systemu, który ją wystawia.
Stany i ceny w sklepie różnią się od tych w Subiekcie albo Optimie, bo synchronizacja działa raz dziennie albo wcale.
Szkoła albo urząd potrzebuje faktury z nabywcą i odbiorcą, a checkout ma jedno pole na nazwę firmy.
Ceny hurtowe są w ERP, a sklep pokazuje wszystkim tę samą cenę detaliczną.
Gotowa wtyczka nie obsługuje Twojej wersji ERP albo Twojego procesu zamówień.
W sklepie, który wdrażaliśmy, klient zaznacza w zamówieniu, że chce fakturę, i podaje dane firmy. Faktura powstaje z zamówienia i od razu jest w KSeF. Nikt w firmie nie przepisuje danych ani nie wysyła dokumentu ręcznie.
Większość pracy jest po stronie danych: checkout musi zebrać NIP, pełną nazwę i adres, a przy jednostkach publicznych także odbiorcę. Do tego dochodzą zamówienia z płatności typu InPost Pay, które zapisują dane do faktury we własnych polach. Wszystkie te ścieżki testujemy na prawdziwych zamówieniach, zanim przełączymy sklep.
Terminy, faktury dla konsumentów, paragon z NIP, tryb offline i lista testów: opisaliśmy to w poradniku KSeF w sklepie internetowym.
Klient zaznacza w zamówieniu, że chce fakturę, i podaje dane firmy. Dokument powstaje z zamówienia i sam ląduje w KSeF, a księgowość niczego nie przepisuje.
Klient wpisuje NIP, a nazwa i adres uzupełniają się z GUS. Mniej literówek na fakturach i mniej korekt.
Osobna ścieżka dla szkół, urzędów i JST: nabywca i odbiorca jako dwie różne jednostki, dane wstępnie wypełnione z konta klienta.
Stany, ceny i cenniki hurtowe z Subiekta w sklepie WooCommerce. Subiekt zostaje źródłem prawdy, sklep tylko z niego czyta.
Optimę łączymy przez jej WebAPI, a XL przez OPTisync: dokumenty sprzedaży oraz odczyt faktur i paragonów z ERP w sklepie.
Gdy sklep i marketplace’y już są w BaseLinkerze, łączymy ERP i faktury przez niego, zamiast pisać drugą integrację obok.
Integracja BaseLinker →Sprawdzamy, gdzie powstaje faktura, kto ją dziś wystawia i wysyła, skąd sklep bierze stany i ceny.
Ustalamy, który system odpowiada za stany, ceny, dane klienta i dokumenty. To zapobiega podwójnym fakturom i rozjazdom stanów.
Faktura dla firmy, dla osoby prywatnej, dla JST z innym odbiorcą, korekta, zamówienie z marketplace’u. Każdy przypadek przechodzi przez cały obieg.
Pilnujemy integracji przy aktualizacjach sklepu, ERP i zmianach w KSeF.
Stany, ceny i trzy cenniki dla hurtu płyną z Subiekta do sklepu. Ceny przychodzą netto, sklep liczy z nich brutto. NIP z InPost Pay trafia na fakturę.
Czytaj case study →InPost Pay zapisuje dane do faktury we własnych polach. Zmapowaliśmy je na NIP i „chcę fakturę” w sklepie, żeby faktura dostała właściwe dane.
Czytaj case study →Przeniesienie Płatnika z archiwum na nową maszynę i eksport bazy na starszy SQL Server ze sprawdzeniem liczby wierszy i sum kontrolnych.
Czytaj case study →Integracja z ERP i fakturami dotyka danych osobowych i finansowych, więc projektujemy ją ostrożnie. Przykład: w jednym sklepie odrzuciliśmy pomysł wyszukiwania danych klienta po adresie e-mail, bo publiczny endpoint pozwalałby każdemu pobrać cudze dane. Klient i tak był już zalogowany albo w sesji, więc formularz wypełnia się z niej.
Dostępy do ERP dostajemy tylko w zakresie potrzebnym do integracji, a zmiany w bazach ERP robimy najpierw na kopii.