Problem: zamówienie było w systemie, ale jego wagę trzeba było policzyć
To case study pokazuje, jak wykorzystaliśmy dane produktów, API wFirma i cyklicznie uruchamianą aplikację, aby usprawnić przygotowanie dostaw — bez wymiany systemu magazynowego i bez dokładania handlowcom kolejnych obowiązków przy każdym zamówieniu.
Klient prowadzi działalność dystrybucyjną i dostarcza produkty odbiorcom biznesowym. Handlowcy wprowadzają zamówienia jako rezerwacje w wFirma. Sam etap przekazania danych ze sprzedaży opisuję również w artykule o zamówieniach handlowców do ERP bez przepisywania. Następnie dział odpowiedzialny za realizację kompletuje towar, przypisuje dostawy do samochodów i przygotowuje trasy.
W tym procesie sama lista produktów nie wystarczała. Towary są ciężkie, a każdy samochód ma ograniczoną ładowność. Osoba organizująca dostawy potrzebowała więc informacji o łącznej wadze poszczególnych zamówień.
Dotychczas oznaczało to sprawdzanie pozycji, mnożenie ilości przez wagę produktu i sumowanie wyników. Przy zmianie zamówienia obliczenia trzeba było zweryfikować ponownie. Praca powtarzała się przy kolejnych klientach i kolejnych wyjazdach.
Nie brakowało danych o zamówieniu. Brakowało automatycznego przekształcenia tych danych w informację potrzebną logistyce.
Jak działają rezerwacje w wFirma?
Rezerwacja pozwala zapisać zapotrzebowanie klienta na konkretne towary przed realizacją sprzedaży. Zgodnie z instrukcją producenta dodaje się ją przez MAGAZYN → REZERWACJE → DODAJ, wskazując kontrahenta i pozycje. Funkcja wymaga pakietu z rozbudowanym magazynem. Przywołana instrukcja producenta dotyczy wFirma dla Biur Rachunkowych; dostępność funkcji należy sprawdzić w używanym pakiecie. [1]
Zapisanie rezerwacji zwiększa ilość zarezerwowaną i zmniejsza ilość dostępną. Nie należy utożsamiać tego z fizycznym wydaniem towaru. Różnice między stanem a dostępnością omawiam w artykule o stanach magazynowych i cenach dla handlowca. Na podstawie rezerwacji można później wystawić między innymi dokument WZ lub fakturę. [1]
W opisywanej firmie rezerwacja była zatem naturalnym miejscem przekazania informacji między sprzedażą a realizacją dostaw. Zamiast tworzyć osobny obieg danych o wadze, rozszerzyliśmy dokument, z którego pracownicy już korzystali.
Zobacz ekran dodawania rezerwacji w oficjalnej instrukcji wFirma.
Podstawa obliczeń: waga jednostki produktu
W kartotece produktu wFirma udostępnia pole Waga (kg). Znajduje się ono w zakładce JEDNOSTKI, razem z długością, szerokością i wysokością. Nie musieliśmy więc tworzyć osobnej bazy wag ani zastępować standardowych danych magazynowych własnym słownikiem. [2]
W tym wdrożeniu uzupełniamy właśnie to pole. Aplikacja korzysta z zapisanej wagi i ilości produktu występującej na rezerwacji.
Ważne jest jednak, aby obie wartości odnosiły się do tej samej jednostki. Jeżeli zamówienie zawiera 10 kartonów, a wpisana waga dotyczy pojedynczej sztuki, zwykłe mnożenie da błędny wynik. Trzeba przyjąć spójny sposób opisywania produktów lub uwzględnić odpowiedni przelicznik.
Producent rozróżnia jednostki produktu i jednostki gabarytów: waga jest podawana w kilogramach, a wymiary w centymetrach. Zmiana jednostki handlowej nie zmienia jednostek tych pól. [2]
Przykład obliczenia
Poniższe dane są ilustracyjne — nie pochodzą z zamówień klienta.
| Pozycja | Ilość | Waga jednej jednostki | Waga pozycji |
|---|---|---|---|
| Produkt A | 20 szt. | 12,5 kg | 250 kg |
| Produkt B | 40 szt. | 2 kg | 80 kg |
| Produkt C | 10 szt. | 5 kg | 50 kg |
| Razem | 380 kg |
Zasada jest prosta:
Waga rezerwacji = suma iloczynów ilości produktu i wagi jego jednostki.
Największą wartością nie jest jednak sam wzór. Jest nią to, że pracownik nie musi wykonywać obliczeń osobno dla każdego zamówienia, a wynik trafia tam, gdzie będzie potrzebny.
Zobacz pola wagi i wymiarów produktu w oficjalnej instrukcji wFirma.
Co robi integracja z wFirma?
Przygotowaliśmy aplikację, która uruchamia się automatycznie kilka razy dziennie. Odpowiada za to cron, czyli harmonogram zadań na serwerze. Pracownik nie musi otwierać aplikacji ani uruchamiać obliczeń przyciskiem.
Podczas cyklu system odczytuje rezerwacje i ich pozycje, pobiera potrzebne dane o wagach produktów, wylicza sumy i aktualizuje odpowiedni fragment opisu rezerwacji.
Rezerwacja w wFirma
Handlowiec zapisuje produkty i ilości.
Odczyt danych
Integracja pobiera pozycje rezerwacji i wagi produktów.
Obliczenie łącznej wagi
Aplikacja sumuje iloczyny ilości i mas jednostkowych.
Aktualizacja opisu
Wynik trafia do oznaczonego fragmentu opisu rezerwacji.
Informacja dla logistyki
Pracownik planuje dostawy i przydziela je do samochodów.
Jeżeli handlowiec zmieni ilość produktu, podczas kolejnego cyklu system może przeliczyć zamówienie na podstawie nowych danych. Nie opieramy się więc wyłącznie na wyniku zapisanym przy pierwszym utworzeniu rezerwacji.
To aktualizacja cykliczna, a nie działanie w czasie rzeczywistym. Pomiędzy zmianą rezerwacji a kolejnym uruchomieniem zadania może występować opóźnienie. W tym wdrożeniu przyjęliśmy odświeżanie kilka razy dziennie; harmonogram warto dobierać do godzin przygotowywania dostaw.
API wFirma od strony technicznej
Dokumentacja API obejmuje nie tylko faktury, lecz także produkty i dokumenty magazynowe. Dla tego procesu istotne są następujące zasoby i operacje: [3]
| Element | Przykład operacji | Zastosowanie |
|---|---|---|
| Produkty | goods/find, goods/get/{id} |
Odczyt kartotek produktów |
| Rezerwacje | warehouse_document_r/find |
Wyszukiwanie dokumentów rezerwacji |
| Szczegóły rezerwacji | warehouse_document_r/get/{id} |
Odczyt konkretnego dokumentu |
| Edycja rezerwacji | warehouse_document_r/edit/{id} |
Zapis zmian w dokumencie |
To nazwy operacji, a nie kompletny kod integracji. Trzeba również uwzględnić autoryzację, identyfikator firmy, strukturę danych oraz obsługę błędów. Oficjalna dokumentacja opisuje te mechanizmy i przykłady wywołań. [3]
W naszym rozwiązaniu API łączy dane już obecne w systemie z własną logiką obliczeniową. Nie jest potrzebne ręczne eksportowanie rezerwacji do arkusza i późniejsze przepisywanie wyników.
Dlaczego wynik zapisujemy w opisie, a nie w polu dodatkowym?
Osobne pole „Waga zamówienia” mogłoby wydawać się najbardziej oczywistym miejscem na taki wynik. Przy integracji trzeba jednak sprawdzić nie tylko to, co można wprowadzić ręcznie w panelu, ale również to, co da się aktualizować programowo.
W tym wdrożeniu nie mieliśmy możliwości aktualizowania potrzebnego pola dodatkowego przez API. Dlatego wybraliśmy zapis w opisie rezerwacji. To ograniczenie napotkane w konkretnym rozwiązaniu, a nie stwierdzenie, że wszystkie pola dodatkowe w każdym obszarze wFirma zawsze działają identycznie.
Opis pozwolił przekazać wynik bezpośrednio przy istniejącym dokumencie. Nie oznacza to jednak dopisywania kolejnej linijki przy każdym uruchomieniu zadania.
Informację o wadze zapisujemy w oznaczonym fragmencie, który integracja może rozpoznać i zastąpić aktualną wartością. Dzięki temu automatyczna część opisu jest oddzielona od uwag wpisanych przez pracownika.
Przykładowo taki opis może wyglądać następująco:
To ilustracja zasady działania, nie oryginalny format znacznika użyty u klienta.
Przy kolejnym przeliczeniu system powinien zmienić wartość we własnym bloku, a nie usuwać informację o miejscu dostawy ani pozostawiać obok siebie kilku sprzecznych wyników.
Taki zapis jest ustrukturyzowany, ale nie musi być zaszyfrowany: znaczniki służą rozpoznawaniu danych przez aplikację, a sama waga pozostaje czytelna dla człowieka.
Co zyskała osoba planująca załadunek?
Przed wdrożeniem osoba odpowiedzialna za dostawy musiała najpierw ustalić wagę zamówienia. Dopiero później mogła zestawić ją z pozostałymi dostawami i możliwościami samochodu.
Po wdrożeniu korzysta z wartości automatycznie uzupełnianej przy rezerwacji. Łatwiej porównać kilka zamówień, oszacować ich wspólną masę i zdecydować o przypisaniu do konkretnego pojazdu.
Handlowcy nadal pracują na rezerwacjach. Magazyn nadal korzysta z wFirma. Z procesu znika natomiast powtarzalny etap ręcznego mnożenia i sumowania danych o produktach.
Nie wdrażaliśmy tutaj automatycznego wyznaczania tras ani systemu, który sam przydziela zamówienia do samochodów. Uporządkowaliśmy jeden z elementów potrzebnych do tych decyzji: wagę poszczególnych zamówień.
To ważne rozróżnienie. Nawet niewielka funkcja może realnie usprawnić pracę, jeżeli usuwa konkretny problem w codziennym procesie.
O czym trzeba pamiętać przy takim rozwiązaniu?
Automatycznie obliczony wynik jest użyteczny tylko wtedy, gdy opiera się na właściwych danych. Przy projektowaniu podobnej integracji warto uwzględnić przede wszystkim trzy kwestie.
Brak wagi nie powinien być traktowany jak potwierdzone zero. Jeżeli w kartotece nie ma potrzebnej wartości, bezpieczniej pokazać informację o niepełnym obliczeniu niż przedstawiać zaniżoną sumę jako kompletną.
Waga z kartoteki musi odpowiadać temu, co faktycznie jest liczone. Trzeba rozróżnić masę produktu, opakowania i całego ładunku. Same masy towarów nie muszą obejmować palet, pojemników czy dodatkowych opakowań transportowych. Dlatego wynik wspiera planowanie, ale nie zastępuje kontroli rzeczywistego załadunku.
Aktualizacja nie może niszczyć innych danych. Integracja powinna zachowywać uwagi pracowników, uwzględniać zmiany rezerwacji i obsługiwać nieudane odczyty lub zapisy. Warto też unikać nadpisywania opisu starszą kopią, gdy ktoś równocześnie go edytuje.
To zalecenia projektowe dla podobnych wdrożeń, nie lista dodatkowych funkcji deklarowanych w tym case study.
Podobna zasada może pomóc w liczeniu objętości
W tym projekcie kluczowa była waga. Nie wdrażaliśmy obliczania objętości ani automatycznego układania palet. Warto jednak zauważyć możliwość dalszego rozwoju: kartoteka wFirma zawiera również pola długości, szerokości i wysokości produktu. [2]
Jeżeli opisują one zewnętrzne wymiary jednostki wysyłkowej, można na ich podstawie obliczyć jej objętość. Dla wymiarów zapisanych w centymetrach:
Objętość w m³ = długość × szerokość × wysokość ÷ 1 000 000.
Przykładowy karton o wymiarach 60 × 40 × 30 cm zajmuje 0,072 m³. Dwadzieścia takich kartonów daje łącznie 1,44 m³ ich geometrycznej objętości.
Takie dane mogłyby wspierać wstępne planowanie miejsca w samochodzie lub przygotowanie palet. Nie oznacza to jednak, że suma objętości powie nam, czy wszystkie towary rzeczywiście zmieszczą się w konkretnej przestrzeni. Trzeba jeszcze uwzględnić między innymi kształt, możliwość piętrowania, dopuszczalne ułożenie i wolne przestrzenie pomiędzy produktami.
Liczenie objętości to możliwe rozszerzenie tej integracji. Optymalizacja pakowania na paletach byłaby już osobnym zadaniem.
Integracja z wFirma nie musi oznaczać przebudowy całej firmy
W tym wdrożeniu nie zastępowaliśmy wFirma nowym systemem. Wykorzystaliśmy istniejące rezerwacje, dane produktów i możliwość programowej aktualizacji dokumentu.
Powstała dedykowana aplikacja wykonująca konkretną pracę: cyklicznie oblicza wagę zamówień i udostępnia wynik tam, gdzie pracownicy już podejmują decyzje.
To dobry punkt wyjścia do szukania kolejnych automatyzacji. Nie zawsze trzeba zaczynać od dużego projektu. Czasem warto najpierw przyjrzeć się zadaniu, które ktoś wykonuje codziennie: przelicza, przepisuje lub sprawdza dane, które już są w systemie.
Porozmawiajmy o Twoim procesie
W ProcesON tworzymy dedykowane aplikacje i integracje z wFirma dopasowane do rzeczywistych procesów firmy. Jeżeli Twój zespół ręcznie przelicza zamówienia lub uzupełnia dokumenty, porozmawiajmy o tym procesie. Sprawdzimy, które czynności można przenieść do aplikacji, bez dokładania pracownikom kolejnego obowiązku.
Chcesz poznać szerszy kontekst? Poznaj możliwości API i webhooków wFirma w poradniku głównym tego cyklu.
Źródła i dokumentacja
Opis wdrożenia opiera się na doświadczeniu ProcesON. Poniższe źródła producenta dotyczą funkcji systemu i interfejsu API, nie pomiarów efektów u klienta.
- wFirma: rezerwacje w magazynie i ich realizacja ↩
- wFirma: gabaryty produktów ↩
- Oficjalna dokumentacja API wFirma ↩
Opis ograniczenia pola dodatkowego dotyczy omawianego wdrożenia. Możliwości API i interfejsu należy ponownie zweryfikować przy projektowaniu kolejnej integracji.
