Znasz tę sytuację? Proces kompletacji jest w toku, wystawiasz Zlecenie Kompletacji (ZK), do niego generujesz Rozchód Wewnętrzny (RW), potem okazuje się, że trzeba to skorygować, więc robisz RWK. Nagle anulujesz RWK, modyfikujesz ZK dodając nowy towar, zamykasz dokument, i w systemie pojawiają się rezerwacje widmo na towary, które przecież dawno zeszły ze stanu.
Chaos na magazynie gotowy. Zastanawiasz się, czy to wina konfiguracji, czy może system sam z siebie generuje podwójne rezerwacje. Jednak gdy zaczynamy badać logikę tego obiegu i działanie API w Comarch ERP XL, szybko okazuje się, że to nie wina samego systemu, a najprawdopodobniej Twojej zewnętrznej integracji.
Jak naturalnie działa obieg ZK i RW w ERP XL?
Podczas standardowego zatwierdzania Zlecenia Kompletacji (ZK), Comarch ERP XL automatycznie generuje rezerwacje na wszystkie potrzebne składniki towaru. Kiedy praca rusza i robimy dokument RW (rozchód składników), system naturalnie ściąga rezerwacje, bo składniki zostały już fizycznie pobrane.
Jeśli na tym etapie pojawia się potrzeba wycofania lub korekty (RWK), teoretycznie (zgodnie ze sztuką) rezerwacje powinny wrócić. Jednak mechanizm rezerwacji w Comarch ERP XL ma w tym miejscu swoje “niedorobienia” i nie odtwarza ich automatycznie po wygenerowaniu RWK. Wielu klientom takie zachowanie wręcz bardzo odpowiada, ale w tym scenariuszu rezerwacje niespodziewanie wracają później – po dodaniu nowej pozycji i zamknięciu zlecenia.
Gdzie leży błąd w Twoim procesie?
Wiele osób uważa, że przy częściowo zrealizowanym ZK (gdy powstaną RW/RWK) system w ogóle nie pozwala na edycję. To nie do końca prawda. Interfejs programu dopuszcza dodanie kolejnej, całkowicie nowej pozycji do takiego dokumentu bez konieczności ponownego zamykania całego zlecenia. Kiedy robi się to z poziomu interfejsu (lub poprawnie w tle), rezerwacja pojawi się tylko na tę nową część. Cała historyczna część dokumentu pozostaje nienaruszona.
Skąd w takim razie rezerwacje widmo na wszystko? Odpowiedzią jest wywoływanie funkcji ZamknijDokumentZlc za pomocą API lub zewnętrznego skryptu.
Wywołanie tej metody to dla systemu sygnał do wykonania procedury zamykania dla całości dokumentu, dokładnie tak jak przy pierwszym zatwierdzaniu. Program wykonuje ślepo to polecenie – przelicza wszystkie pozycje i generuje na nowo rezerwacje dla każdego składnika, nie analizując tego, że powiązane dokumenty zjadły już te stany. Wywoływanie funkcji ponownego zamykania całego zlecenia przy dodaniu zaledwie jednej nowej pozycji to poważny błąd logiczny.
Perspektywa ELTE-S: Niestandardowe operacje wymagają precyzji
Tworzenie własnych rozwiązań opartych na API czy integracjach to świetny sposób na przyspieszenie pracy, ale wymaga głębokiego zrozumienia mechaniki Comarch ERP XL. Powyższe działania to krótka droga do poważnego problemu: stany magazynowe zaczną się rozjeżdżać, system zacznie mnożyć rezerwacje widmo na tysiące sztuk, a to w prostej linii prowadzi do paraliżu procesów magazynowych i wstrzymania wysyłek do innych klientów, bo system zablokuje towar jako rzekomo “zarezerwowany”.
Zamiast walczyć z systemem i zamykać produkcję na czas sprzątania bazy, warto oddać integracje w ręce kogoś, kto zna API Comarcha na wylot. W ELTE-S chętnie sprawdzimy, w jaki sposób Twoja aplikacja odpytuje system, zlokalizujemy luki w logice i zaprojektujemy poprawki, dzięki którym proces przestanie generować fikcyjne blokady towaru.
Nie ryzykuj uszkodzenia bazy i chaosu na magazynie. Zostaw to nam.
