Konfiguracja integracji BaseLinker z systemem księgowym

Kilka formatów, jeden system docelowy

Zamówienia spływające z różnych platform mają różną strukturę danych: inaczej opisanego kupującego, inaczej podane koszty wysyłki, inaczej oznaczone rabaty. Integracja z systemem księgowym musi to ujednolicić, zanim powstanie dokument.

Co ustalamy przy konfiguracji

• Moment wystawienia dokumentu: po opłaceniu, po wysyłce czy po zamknięciu zamówienia.
• Rozróżnienie sprzedaży dla firm i dla osób prywatnych.
• Sposób ujęcia kosztów wysyłki i rabatów platformowych.
• Stawki podatku przypisane do właściwych pozycji.
• Numerację dokumentów spójną z resztą sprzedaży firmy.
• Obsługę zwrotów i korekt.

Rabaty i kupony platform

To najczęstsze źródło rozbieżności między kwotą zamówienia a kwotą dokumentu. Każda platforma ujmuje je inaczej — część jako obniżkę ceny, część jako osobną pozycję. Ustawiamy przeliczanie tak, żeby dokument zgadzał się z rzeczywistą wpłatą.

Sprzedaż dla firm

Numer identyfikacji podatkowej podawany przez kupującego decyduje o rodzaju dokumentu. Na platformach bywa przekazywany w różnych polach — konfigurujemy odczyt każdego z nich, żeby obsługa nie musiała tego rozstrzygać ręcznie.

Zwroty

Muszą trafiać do systemu księgowego jako korekty. Zwrot obsłużony wyłącznie w systemie zamówień oznacza dokument bez pokrycia i rozjazd rozrachunków przy zamknięciu okresu.

Uzgodnienie z księgowym

Sposób wystawiania dokumentów ustalamy z osobą prowadzącą księgowość — to jej wymagania decydują o konfiguracji.

Zakres danych przekazywanych między systemami

Integracja nie sprowadza się do przesłania końcowej wartości zamówienia. Dokument księgowy wymaga prawidłowego przypisania nabywcy, pozycji towarowych, ilości, cen, rabatów, kosztów dostawy, metod płatności oraz właściwych oznaczeń podatkowych. Trzeba również ustalić, które dane są nadrzędne. Może to być informacja zapisana w BaseLinkerze, sklepie, systemie magazynowym albo programie księgowym.

Przed uruchomieniem automatyzacji porównujemy pola dostępne po obu stronach integracji. Mapowanie pól, czyli przypisanie jednej informacji do odpowiadającego jej miejsca w drugim systemie, obejmuje między innymi symbole produktów, dane kontrahentów i rodzaje dokumentów. Jeżeli dwa systemy inaczej nazywają tę samą wartość, konieczna jest reguła tłumacząca ją podczas przesyłania.

Osobnego ustalenia wymagają dane, których system docelowy nie może przyjąć bezpośrednio. Nie powinny być przypadkowo pomijane ani wpisywane do pola o innym znaczeniu. W takim przypadku dobieramy bezpieczny sposób ich obsługi, na przykład zapis w uwagach, przekształcenie zgodne z wymaganiami księgowości albo zatrzymanie dokumentu do weryfikacji.

Różne warianty przebiegu integracji

Najprostszy wariant polega na przekazywaniu gotowych zamówień z BaseLinkera do systemu księgowego. Sprawdza się wtedy, gdy dane towarowe są uporządkowane, a zasady wystawiania dokumentów są jednakowe dla wszystkich kanałów. Nawet w takim układzie należy rozstrzygnąć, czy dokument powstaje automatycznie, czy dopiero po zatwierdzeniu przez pracownika.

Bardziej rozbudowany wariant obejmuje równoczesną współpracę z systemem magazynowym. Symbol produktu musi wtedy wskazywać tę samą kartotekę, czyli zapis produktu w bazie, niezależnie od miejsca złożenia zamówienia. Różne symbole tego samego towaru mogą prowadzić do utworzenia dodatkowych kartotek, błędnego rozchodu magazynowego albo dokumentu zawierającego pozycję nierozpoznaną przez system.

Jeszcze innego podejścia wymaga sprzedaż prowadzona w kilku krajach lub walutach. Znaczenie mają wtedy dane źródłowe dotyczące waluty, sposobu płatności i rodzaju transakcji. Reguł nie należy opierać wyłącznie na nazwie platformy, ponieważ jeden kanał sprzedaży może obsługiwać kilka odmiennych przypadków. Każdy rzeczywiście używany wariant trzeba uwzględnić w scenariuszach testowych.

Produkty, usługi i koszty dostawy

Pozycje z zamówienia mogą być rozpoznawane na podstawie symbolu, numeru katalogowego albo innego jednoznacznego identyfikatora. Samo podobieństwo nazwy produktu nie wystarcza. Nazwy bywają skracane przez platformy, rozszerzane o wariant albo zmieniane na potrzeby oferty. Stabilny identyfikator ogranicza ryzyko przypisania sprzedaży do niewłaściwej kartoteki.

Koszt dostawy może zostać przekazany jako osobna usługa lub rozliczony w inny sposób wymagany przez księgowość. Ważne, aby ta sama opłata nie została jednocześnie dodana do wartości produktów i ponownie zapisana jako osobna pozycja. Podobnej kontroli wymagają opłaty dodatkowe, dopłaty do wybranej formy dostawy oraz zamówienia, w których dostawa jest bezpłatna dla kupującego.

Produkty w wariantach, na przykład różniące się rozmiarem lub kolorem, powinny prowadzić do właściwych pozycji w systemie docelowym. Jeżeli BaseLinker rozpoznaje wariant dokładniej niż program księgowy, trzeba ustalić poziom szczegółowości potrzebny na dokumencie i w ewidencji magazynowej.

Płatności częściowe, pobrania i kilka metod zapłaty

Status zamówienia nie zawsze oznacza pełne rozliczenie. Może wystąpić płatność częściowa, przedpłata, pobranie albo połączenie kilku metod zapłaty. Automatyczne wystawienie dokumentu na podstawie samego przejścia do określonego statusu może być wtedy zbyt wczesne. Konfiguracja powinna odróżniać status operacyjny, czyli etap realizacji, od rzeczywistej informacji o rozliczeniu.

W przypadku pobrania wysyłka może nastąpić przed otrzymaniem środków. Przy płatności internetowej informacja o opłaceniu może z kolei pojawić się wcześniej niż gotowość zamówienia do wysyłki. Wybór momentu utworzenia dokumentu zależy więc od procesu stosowanego w firmie, a nie od uniwersalnej reguły dla wszystkich wdrożeń.

Trzeba również ustalić sposób postępowania z nieudaną płatnością, anulowaniem oraz ponownym opłaceniem tego samego zamówienia. Reguła powinna zapobiegać tworzeniu kolejnego dokumentu tylko dlatego, że kanał płatności przesłał zaktualizowany komunikat.

Jak zapobiegamy duplikatom dokumentów

Duplikaty mogą powstać po ręcznym ponowieniu eksportu, zmianie statusu w obie strony albo czasowej przerwie w komunikacji między systemami. System wysyłający może uznać, że dokument nie został utworzony, mimo że system docelowy zdążył go już zapisać. Dlatego konfiguracja powinna korzystać z jednoznacznego powiązania zamówienia z dokumentem.

Sprawdzamy zachowanie integracji po ponowieniu operacji oraz po ręcznej korekcie danych. Sam komunikat o poprawnym przesłaniu nie wystarcza. Potwierdzeniem jest właściwy dokument w systemie księgowym, zachowane powiązanie z zamówieniem i brak drugiego zapisu po ponownym uruchomieniu tej samej czynności.

Jeżeli dokument został wystawiony ręcznie, należy określić, jak integracja ma rozpoznać taki przypadek. Bez tej reguły automatyzacja może potraktować zamówienie jako nieobsłużone. Proces ręczny i automatyczny powinny mieć wspólną zasadę oznaczania zakończonych operacji.

Błędy przy samodzielnej konfiguracji

Częstym błędem jest włączenie automatycznego wystawiania dokumentów przed sprawdzeniem mapowania produktów i stawek. Pojedyncze zamówienie testowe może przejść prawidłowo, ale nie obejmuje zwrotu, rabatu, przesyłki bezpłatnej, sprzedaży dla firmy ani produktu w wariancie. Test powinien odzwierciedlać różne rodzaje zamówień rzeczywiście występujące w sklepie.

Problemy powoduje także tworzenie reguł wyłącznie na podstawie nazwy statusu. Status „wysłane” może mieć inne znaczenie w zależności od procesu, a ręczne cofnięcie zamówienia może ponownie uruchomić eksport. Konieczne jest sprawdzenie nie tylko docelowego statusu, lecz także historii wykonanej operacji i istniejącego powiązania z dokumentem.

Nie należy usuwać błędnego dokumentu i ponawiać eksportu bez ustalenia przyczyny. Jeżeli źródłem problemu jest niewłaściwa reguła, kolejna próba odtworzy ten sam błąd. Najpierw sprawdzamy dane zamówienia, dziennik zdarzeń, czyli zapis wykonanych operacji, oraz odpowiedź systemu księgowego. Dopiero potem dobieramy sposób korekty.

Ryzykowne jest również ręczne zmienianie symboli produktów tylko po jednej stronie. Taka zmiana może naprawić jedno zamówienie, ale zerwać powiązanie przy następnych. Symbole i reguły mapowania powinny być aktualizowane według ustalonego planu, z uwzględnieniem już istniejących dokumentów i kartotek.

Kiedy problem nie wynika z samej integracji

Brak dokumentu w systemie księgowym nie zawsze oznacza awarię połączenia. Przyczyną może być nieosiągnięty status zamówienia, brak wymaganego identyfikatora produktu, niepełne dane kupującego albo odrzucenie dokumentu przez reguły systemu docelowego. Integracja może działać, lecz celowo zatrzymać zapis niekompletnych danych.

Rozbieżność wartości nie musi również wynikać z błędnego przeliczania. Niekiedy platforma prezentuje kupującemu kwotę po rabacie finansowanym według zasad danego kanału, a do sprzedawcy przekazuje kilka osobnych wartości. Trzeba wtedy porównać składniki zamówienia, płatność i sposób ujęcia rabatu, zamiast zestawiać wyłącznie dwie kwoty końcowe.

Jeżeli dokument powstaje poprawnie, ale zawiera niewłaściwy opis lub symbol, problem zwykle dotyczy mapowania kartotek. Gdy dokument nie powstaje wcale, sprawdzamy warunek uruchamiający, kompletność danych i komunikat zwrotny. Takie rozróżnienie skraca diagnostykę i ogranicza przypadkowe zmiany ustawień.

Testy przed uruchomieniem automatycznego obiegu

Konfigurację sprawdzamy na kontrolowanym zestawie zamówień. Powinny znaleźć się w nim przypadki sprzedaży dla osoby prywatnej i firmy, zamówienie z kosztem dostawy, rabatem, kilkoma produktami oraz zwrotem. Jeżeli firma korzysta z pobrania, płatności częściowych lub różnych walut, te warianty również wymagają osobnego sprawdzenia.

Dla każdego przypadku porównujemy dane źródłowe z dokumentem zapisanym w systemie księgowym. Kontrola obejmuje nabywcę, pozycje, ilości, wartości, sposób ujęcia dostawy, rodzaj dokumentu i jego numerację. Następnie sprawdzamy, czy ponowienie operacji nie tworzy duplikatu i czy korekta zachowuje powiązanie z pierwotnym dokumentem.

Po zakończeniu testów automatyzację można uruchamiać etapami. Pozwala to obserwować rzeczywiste zamówienia bez jednoczesnej zmiany całego obiegu. Zakres kontroli ustalamy z osobą odpowiedzialną za księgowość i obsługę zamówień, ponieważ obie strony oceniają inne elementy procesu.

Dodatkowe pytania dotyczące integracji BaseLinkera z księgowością

Czy każde zamówienie musi automatycznie tworzyć dokument?

Nie. Dokument może powstawać automatycznie po spełnieniu ustalonych warunków albo czekać na ręczne zatwierdzenie. Drugi wariant bywa potrzebny przy nietypowych zamówieniach, brakujących danych lub procesach wymagających kontroli księgowej. Można też rozdzielić reguły dla różnych kanałów sprzedaży.

Co zrobić, gdy produkt ma inny symbol w BaseLinkerze i programie księgowym?

Należy utworzyć jednoznaczne mapowanie między symbolami albo uporządkować identyfikatory w systemach źródłowych. Nie powinno się opierać dopasowania wyłącznie na nazwie produktu. Przed zmianą trzeba sprawdzić, czy dany symbol jest używany także przez magazyn, sklep lub wcześniejsze dokumenty.

Czy korekta może powstać automatycznie po zwrocie?

Może, jeżeli integracja otrzymuje kompletne dane o zwrocie, potrafi wskazać dokument pierwotny i obsługuje wymagany przebieg korekty. Samo oznaczenie zamówienia jako zwróconego nie zawsze zawiera informację o zwracanych pozycjach i kwotach. Zasady automatyzacji trzeba uzgodnić z księgowością.

Dlaczego dokument nie powstał mimo zmiany statusu zamówienia?

Sprawdzamy, czy status rzeczywiście uruchamia eksport, czy zamówienie zawiera wymagane dane i czy wcześniej nie zostało już powiązane z dokumentem. Następnie analizujemy komunikat systemu docelowego. Przyczyną może być odrzucona kartoteka, nieprawidłowe pole nabywcy lub chwilowy brak komunikacji.

Czy można zmienić zasady integracji po jej uruchomieniu?

Tak, ale zmiana powinna objąć wyłącznie nowe operacje albo zostać poprzedzona planem obsługi istniejących zamówień. Inna numeracja, nowe mapowanie produktów lub zmieniony moment wystawiania dokumentu mogą wpłynąć na trwające realizacje. Najpierw wykonujemy test, a potem wdrażamy regułę w uzgodnionym momencie.

Spójny obieg od zamówienia do korekty

Dobrze skonfigurowana integracja nie polega na przesyłaniu jak największej liczby danych, lecz na przekazywaniu właściwych informacji we właściwym momencie. Kluczowe są jednoznaczne kartoteki, sprawdzone reguły dokumentów, kontrola duplikatów i obsługa wyjątków. Dzięki temu BaseLinker oraz system księgowy tworzą jeden uporządkowany obieg, który pozostaje czytelny także wtedy, gdy zamówienie zostanie zmienione, anulowane lub zwrócone.