Dwie spółki, wspólny magazyn i jedno pytanie handlowca
Czy możemy zrealizować zamówienie klienta, skoro w naszej spółce brakuje towaru, ale być może ma go druga firma?
Właśnie z takim problemem mierzył się klient ProcesON. Prowadził działalność przez dwie spółki korzystające z wFirma. Spółki współpracowały ze sobą, sprzedawały sobie towary i operacyjnie korzystały ze wspólnego zaplecza magazynowego. Każda zachowywała jednak własną ewidencję produktów i stanów.
Dla handlowca ten podział nie kończył sprawy. Potrzebował wiedzieć nie tylko, ile produktu znajduje się w jego spółce, lecz także, czy odpowiedni towar jest dostępny w drugiej.
Informacje istniały. Problem polegał na tym, że były rozdzielone pomiędzy dwa źródła.
Na pierwszy rzut oka rozwiązanie wydawało się proste: pobrać obie listy produktów i zsumować ilości. Dopiero po przyjrzeniu się kartotekom okazało się, że najtrudniejsze nie będzie dodawanie liczb, ale ustalenie, które liczby rzeczywiście można do siebie dodać.
Połączyć informacje, a nie przebudować całą firmę
Nie zaczynaliśmy od propozycji wymiany programu magazynowego.
Obie spółki miały już swoje kartoteki, nazwy produktów i sposób pracy. Potrzebowały dodatkowego narzędzia, które połączy informacje przydatne handlowcom, a nie kolejnego miejsca do ręcznego prowadzenia magazynu.
Przyjęliśmy więc prosty podział odpowiedzialności: wFirma pozostaje źródłem danych, a przygotowana przez nas aplikacja pobiera je, kojarzy odpowiadające sobie produkty i przedstawia wspólny widok.
Katalog głównej spółki został punktem odniesienia. Do jej produktów dołączyliśmy dane o odpowiednikach znajdujących się w drugiej firmie.
Dzięki takiemu podejściu rozwiązaliśmy konkretny problem informacyjny bez przebudowywania wszystkiego, co w firmie już działało.
Co robi API w takiej integracji?
API można potraktować jako uzgodniony sposób rozmowy pomiędzy programami. Zamiast prosić pracownika o otwarcie wFirma i przepisanie danych, aplikacja wysyła odpowiednie zapytanie i odbiera informacje w formie nadającej się do dalszego przetwarzania. wFirma udostępnia taki interfejs do tworzenia zewnętrznych integracji. [2]
W oficjalnej dokumentacji znajdują się między innymi operacje pobierania listy produktów — goods/find — i szczegółów produktu — goods/get. Parametr company_id pozwala wskazać firmę, której dotyczy zapytanie. To istotne właśnie wtedy, gdy integracja obsługuje więcej niż jedną spółkę. [1]
W tym wdrożeniu wykorzystaliśmy API do odczytywania danych z obu firm. Następnie aplikacja łączyła informacje o odpowiadających sobie towarach.
Tyle że najpierw trzeba było wiarygodnie ustalić, co oznacza „odpowiadający sobie towar”.
Ten sam produkt, ale dwie różne nazwy
W jednej firmie produkt był zapisany pod jedną nazwą, w drugiej — pod inną. Fizycznie był to ten sam towar, ale kartoteki nie wyglądały identycznie.
Oparcie integracji wyłącznie na nazwach byłoby ryzykowne. Drobna zmiana opisu mogłaby zerwać powiązanie, a podobieństwo nazw nie dawałoby pewności, że chodzi o ten sam wariant produktu.
Nie mogliśmy również wykorzystać pola SKU. U klienta miało ono już inne zastosowanie. Zmienianie istniejących oznaczeń tylko po to, żeby ułatwić nową integrację, ingerowałoby w dotychczasowy sposób pracy.
Potrzebny był osobny, wspólny identyfikator produktu, niezależny od jego nazwy i używanych już oznaczeń.
Dodatkowe pole zamiast zmiany dotychczasowych oznaczeń
wFirma umożliwia dodawanie własnych pól tekstowych do produktów. Takie pole może być również wyświetlane jako dodatkowa kolumna na liście produktów. Potwierdza to dokumentacja dotycząca edycji okna produktu. [3]
W opisywanym wdrożeniu wykorzystaliśmy dodatkowe pole nazwane „QR kod”. Na potrzeby integracji jego wartość pełniła funkcję wspólnego identyfikatora. Nie chodziło o rozpoznawanie obrazka ani konieczność skanowania kodu — aplikacja porównywała tekst zapisany przy produktach.
Jeżeli dwie kartoteki opisywały ten sam towar, otrzymywały tę samą wartość.
Przykład poglądowy — nazwy, kod i ilości poniżej nie są danymi klienta:
| Źródło | Nazwa produktu w danej firmie | Wspólny kod | Dostępna ilość |
|---|---|---|---|
| Spółka A | Kebab drobiowy 10 kg | QR000123 | 12 szt. |
| Spółka B | Mięso kebab kurczak — 10 kg | QR000123 | 28 szt. |
Dzięki wspólnemu kodowi aplikacja może rozpoznać powiązanie i pokazać 40 sztuk łącznej dostępności, zachowując informację, ile przypada na każdą spółkę.
Warunkiem jest oczywiście to, że pracownicy potwierdzili zgodność produktów i że ilości wyrażono w tej samej jednostce.
Nie musieliśmy więc ujednolicać nazw. Musieliśmy uporządkować relacje pomiędzy kartotekami.
Około 700 produktów w jednej firmie i 800 w drugiej
Przy kilku pozycjach można porównać listy ręcznie. Tutaj do przejrzenia było około 700 kartotek w jednej firmie i około 800 w drugiej.
To około 1500 wpisów do uporządkowania — nie 1500 różnych produktów ani 1500 gotowych par. Część kartotek miała odpowiedniki, a część mogła występować tylko po jednej stronie.
Samo dodanie pustego pola nie rozwiązywało więc problemu. Pracownik nadal musiałby znaleźć właściwy odpowiednik, zapamiętać powiązanie i zadbać o zgodne oznaczenie w obu firmach.
Dlatego przygotowaliśmy również osobne narzędzie ułatwiające kojarzenie produktów.
Pracownik wybiera produkt z jednej firmy.
Wyszukuje jego rzeczywisty odpowiednik w drugiej.
Potwierdza powiązanie albo pozostawia produkt bez skojarzenia.
Zatwierdzone pary trafiają do etapu zapisania wspólnych kodów.
Decyzję, czy dwa produkty są faktycznie tym samym towarem, pozostawiliśmy osobom znającym asortyment. Narzędzie miało ułatwić im pracę, a nie zastępować wiedzę o różnicach pomiędzy produktami zgadywaniem na podstawie podobnych nazw.
Po zatwierdzeniu powiązania dalsza integracja nie musiała już ponownie interpretować nazwy. Korzystała z jednoznacznego kodu.
Pole było dostępne w panelu, ale jego zapis przez API okazał się problemem
W tym miejscu pojawiła się kolejna trudność.
Dodatkowe pole można było uzupełnić w przeglądarce. Potrzebną wartość mogliśmy też odczytać na potrzeby integracji. Jednak w używanym podczas wdrożenia API próby aktualizacji tego pola nie dawały oczekiwanego efektu.
To ważne rozróżnienie: możliwość odczytania informacji nie oznacza automatycznie możliwości jej zapisania tą samą drogą.
Samo istnienie operacji goods/edit, opisanej w dokumentacji wFirma, nie rozstrzyga jeszcze, czy można nią zmienić każde pole widoczne w formularzu produktu. [1]
W tym obszarze dokumentacja nie wystarczała do przygotowania rozwiązania bez dodatkowych testów. Trzeba było sprawdzać rzeczywiste odpowiedzi API, sposób udostępniania pola i rezultat prób zapisu. Należało również prawidłowo rozpoznać pole w każdej spółce — jednakowa nazwa widoczna dla pracownika nie oznaczała identycznego identyfikatora technicznego po obu stronach.
Nie był to zatem tylko projekt „pobierz dwie tabelki”. Część pracy polegała na ustaleniu, które operacje system rzeczywiście udostępnia i jak zachowują się w konkretnym przypadku.
Opisujemy tu ograniczenie napotkane w tym wdrożeniu, a nie zasadę dotyczącą wszystkich dodatkowych pól i wszystkich przyszłych wersji API.
Jak wykorzystaliśmy automatyzację przeglądarki
Skoro odpowiednią wartość dało się zapisać przez panel wFirma, wykorzystaliśmy tę drogę.
Przygotowaliśmy narzędzie obsługujące przeglądarkę, które wykonywało powtarzalne czynności potrzebne do aktualizacji dodatkowego pola. Punktem wyjścia były wcześniej zatwierdzone skojarzenia produktów.
Zamiast ręcznie otwierać kolejne kartoteki i przepisywać kody, można było przeprowadzić tę operację w uporządkowany sposób.
Taki mechanizm działa przez interfejs dostępny uprawnionemu użytkownikowi. Narzędzia do automatyzacji przeglądarki, takie jak Playwright, pozwalają między innymi wypełniać pola formularzy i uruchamiać przyciski. [6]
W naszym rozwiązaniu role były wyraźnie rozdzielone:
Pracownik rozpoznawał właściwe pary produktów. Narzędzie przeglądarkowe pomagało zapisać ich oznaczenia. API służyło do bieżącego pobierania danych.
Nie oparliśmy więc całej integracji na automatycznym klikaniu po panelu. Przeglądarka uzupełniała konkretną brakującą możliwość.
To istotna decyzja projektowa. Mechanizm korzystający z formularzy trzeba ponownie sprawdzić po zmianach ich wyglądu lub działania. Dlatego w takim rozwiązaniu warto ograniczyć go do niezbędnego zakresu i kontrolować, czy zapis rzeczywiście się powiódł.
Aktualne stany, a nie zestawienie, które starzeje się po eksporcie
Jednorazowe połączenie kartotek byłoby niewystarczające. Handlowcy potrzebowali informacji przydatnej podczas codziennej pracy, a nie kolejnego zestawienia aktualnego tylko w chwili jego przygotowania.
Dlatego drugą częścią rozwiązania była aktualizacja danych.
wFirma udostępnia webhooki, czyli powiadomienia wysyłane do zewnętrznej aplikacji po określonym zdarzeniu. W oficjalnym opisie znajdują się między innymi zdarzenia dodania produktu i zmiany ilości na magazynie. [4]
Można to wyjaśnić prosto: zamiast nieustannie pytać o wszystkie produkty, aplikacja dostaje sygnał, że konkretny produkt wymaga ponownego sprawdzenia.
W przygotowanym mechanizmie informacja o zmianie wskazuje pozycję do odświeżenia. Aplikacja pobiera jej dane z właściwej firmy przez API, aktualizuje lokalny zapis i uwzględnia nową wartość we wspólnym widoku. Przy wejściu lub odświeżaniu widoku handlowiec korzysta z aktualizowanych danych, zamiast samodzielnie porównywać dwa konta.
Pobranie nowego stanu i pokazanie go użytkownikowi to jednak dwa odrębne etapy. Dlatego „prawie na żywo” nie oznacza obietnicy zerowego opóźnienia. Aktualność zależy od przekazania zdarzenia, odpowiedzi API i odświeżenia widoku.
Jest też szczegół wymagający sprawdzenia przy takiej integracji: powiadomienia o zmianie ilości magazynowej nie należy automatycznie uznawać za potwierdzenie obsługi każdej zmiany rezerwacji. Dokumentacja webhooków wymienia konkretne zdarzenia, a ich wpływ na dostępność trzeba zweryfikować w testach. [4]
Stan magazynowy to nie zawsze dostępność do sprzedaży
Przy łączeniu danych nie wystarczy zadbać o prawidłowe nazwy i kody. Trzeba jeszcze wiedzieć, co dokładnie oznacza prezentowana liczba.
W wFirma zapisanie rezerwacji zmniejsza ilość produktów dostępnych i zwiększa ilość zarezerwowaną. Samo wydanie towaru jest kolejnym etapem. Oznacza to, że fizyczny stan magazynu i dostępność dla następnego klienta mogą się różnić. [5]
Dlatego w tej integracji rozdzieliliśmy stan produktu od jego dostępności. Zachowaliśmy również ujemne wartości dostępności zwracane w tym wdrożeniu, zamiast sztucznie zamieniać je na zero i ukrywać informację o niedoborze względem rezerwacji.
Istotne były też jednostki. Nie można po prostu dodać dziesięciu kartonów do dwudziestu kilogramów. Zanim powstanie suma, dane muszą być porównywalne.
Podobnie ostrożnie potraktowaliśmy powiązania. Bez wspólnego kodu aplikacja nie dołączała produktu z drugiej spółki tylko dlatego, że jego nazwa wyglądała podobnie. Jeżeli do kodu pasowało więcej kartotek, model uwzględniał ich sumę i oznaczał taki przypadek, zamiast wybierać przypadkowy rekord.
To szczegóły mało widowiskowe, ale od nich zależy, czy wspólnemu widokowi można ufać.
Co zmieniło się dla handlowców?
Efektem wdrożenia jest narzędzie, które zbiera informacje z obu spółek i pokazuje dostępność powiązanych produktów w jednym miejscu.
Handlowiec nie musi znać technicznych identyfikatorów, rozumieć API ani pamiętać, pod jaką nazwą ten sam towar występuje w drugiej firmie. Widzi produkt oraz informacje potrzebne do dalszej rozmowy z klientem.
| Wyzwanie | Jak zostało rozwiązane |
|---|---|
| Dane magazynowe rozdzielone pomiędzy dwie spółki | Jeden widok pobierający informacje z obu źródeł |
| Różne nazwy tego samego produktu | Powiązanie przez wspólny identyfikator |
| SKU zajęte innym zastosowaniem | Osobne pole, bez zmiany dotychczasowych oznaczeń |
| Setki kartotek wymagających porównania | Narzędzie pomagające pracownikom zatwierdzać odpowiedniki |
| Problem z zapisem dodatkowego pola przez API | Automatyzacja przeglądarki do uzupełnienia kodów |
| Zmieniające się ilości i dostępność | Mechanizm aktualizacji danych zamiast ręcznego zestawienia |
Najważniejsza zmiana nie polega na tym, że powstała kolejna tabela. Polega na tym, że informacja potrzebna do obsługi klienta przestała być rozdzielona pomiędzy dwa osobne miejsca.
Podobny problem z perspektywy codziennej pracy przedstawiciela opisujemy w artykule o stanach magazynowych i cenach klienta dostępnych na telefonie.
Gdzie jeszcze można wykorzystać podobne rozwiązanie?
Ten przypadek dotyczył dwóch spółek korzystających z wFirma, ale sam pomysł można rozważyć również w innych układach organizacyjnych.
Przykładem jest producent współpracujący ze spółką dystrybucyjną. Innym — grupa firm, w której handlowiec powinien widzieć dostępność towaru w kilku podmiotach, mimo że każdy zachowuje własne kartoteki i dokumenty.
Nie oznacza to, że każdą kolejną firmę wystarczy podłączyć jednym przyciskiem. Nadal trzeba ustalić sposób identyfikacji produktów, znaczenie pokazywanych ilości, zasady udostępniania danych oraz możliwości integracyjne poszczególnych systemów.
Można też pójść krok dalej i połączyć widok dostępności z obsługą zamówień. To jednak odrębny zakres: czym innym jest wiedzieć, gdzie znajduje się towar, a czym innym prawidłowo zarezerwować go i przekazać zamówienie do realizacji.
Ten drugi problem opisujemy w materiale o przekazywaniu zamówień handlowców do ERP bez przepisywania.
Dobra integracja zaczyna się od zrozumienia procesu
W tym projekcie samo połączenie z API było tylko częścią pracy.
Trzeba było zrozumieć współpracę dwóch spółek, znaleźć sposób identyfikacji produktów, ułatwić pracownikom ich kojarzenie, rozwiązać problem aktualizacji dodatkowego pola i zadbać o sens prezentowanych stanów.
Dopiero te elementy razem stworzyły narzędzie przydatne handlowcom.
Nie wymieniliśmy wFirma. Nie narzuciliśmy nowych nazw wszystkich produktów. Nie zabraliśmy pola SKU z procesu, w którym było już potrzebne. Dodaliśmy brakujące połączenie pomiędzy danymi, które firma już posiadała.
Twoja firma również korzysta z kilku kont, spółek albo systemów, a pracownicy nadal ręcznie szukają informacji o towarze?
Opisz nam, jak wygląda ten proces w Twojej firmie. W ProcesON sprawdzimy, które dane warto połączyć i czy problem rozwiąże integracja API, niewielka aplikacja, czy zmiana sposobu wykorzystania obecnych narzędzi.
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 pochodzi z doświadczeń ProcesON. Dokumentacja producentów potwierdza opisane możliwości narzędzi, nie stanowi niezależnego potwierdzenia przebiegu projektu.
