BaseLinker + Comarch Optima u dystrybutora
Scenariusz modelowy: zamówienia ze sklepu i marketplace trafiają do Comarch Optima jako dokumenty, stany wracają w drugą stronę, a o stanie magazynowym decyduje jeden, ustalony system.
Zastrzeżenie
To scenariusz modelowy. Nie opisuje wdrożenia u konkretnego klienta, tylko architekturę i decyzje, które wracają w tego typu projektach. Nie zawiera nazw firm ani wyników przypisanych komukolwiek.
Punkt wyjścia
- zamówienia ze sklepu i z Allegro przepisywane ręcznie do ERP
- faktury wystawiane z opóźnieniem, bo powstają dopiero po przepisaniu zamówienia
- stany w Optimie i w kanałach sprzedaży rozjeżdżają się w ciągu dnia
- brak jednoznacznej odpowiedzi, który system jest źródłem prawdy dla stanu
Model docelowy
- zamówienia z kanałów trafiają do BaseLinkera, a stamtąd do Optimy jako dokumenty
- faktura powstaje w momencie ustalonym regułą, bez ręcznej decyzji operatora
- stany magazynowe synchronizowane w jednym, ustalonym kierunku
- kartoteka ERP powiązana z SKU używanymi w sprzedaży
Punkt wyjścia
Sprzedaż idzie przez własny sklep i Allegro, magazyn i księgowość stoją w Comarch Optima, a między jednym a drugim ktoś przepisuje zamówienia. Przy kilkunastu zamówieniach dziennie to działa. Przy pięćdziesięciu kosztuje: faktury wystawiane z opóźnieniem, nadsprzedaż z rozjechanych stanów, korekty.
To opis typowej architektury. Nie dotyczy wdrożenia u konkretnego klienta.
Cztery rozstrzygnięcia
Wynik integracji BaseLinker ↔ Optima zależy od czterech decyzji, które trzeba podjąć przed pierwszą linijką konfiguracji.
Źródło prawdy dla stanu. Optima albo BaseLinker, na stałe. Przy synchronizacji w obie strony bez ustalonego kierunku oba systemy nadpisują się nawzajem i stan zmienia wartość co cykl.
Moment powstania faktury. Przy złożeniu zamówienia, przy opłaceniu albo przy wysyłce. To decyzja księgowa, ale od niej zależy reszta konfiguracji: przy wystawianiu z góry każde anulowanie zostawia korektę do dokumentu, który nie powinien był powstać.
Rozpoznawanie kontrahenta. Po NIP, po adresie e-mail albo nowy przy każdym zamówieniu. Reguła po e-mailu przy sprzedaży B2B rozmnaża kartoteki tego samego klienta; nowy przy każdym zamówieniu zaśmieca bazę w tempie liczby zamówień.
Powiązanie kartoteki z SKU. Jeśli indeksy w Optimie i w kanałach sprzedaży nie są spójne, potrzebna jest osobna pozycja na dopięcie i wyczyszczenie duplikatów. Bez tego integracja powiela te same błędy automatycznie, przy każdym zamówieniu.
Czego integracja nie rozwiąże
Niespójnych danych produktowych i procesu, którego nikt nie opisał. Jeśli dwa działy podają różne ceny dla tego samego towaru, narzędzie tego nie rozstrzygnie - opisujemy to w tekście Kiedy BaseLinker przestaje wystarczać.
Podobny problem u Ciebie?
Opisz, jak dziś przepływają dane między Twoimi systemami. Odpowiemy, czy wystarczy konfiguracja, gotowa wtyczka, czy potrzebna jest dedykowana integracja.