Jak przekazywać zamówienia od handlowców do ERP bez ręcznego przepisywania?

Klient zamówił. Dlaczego biuro musi wpisywać wszystko jeszcze raz?

Handlowiec kończy rozmowę z wykonawcą i wysyła do biura wiadomość: „Te same materiały co ostatnio, tylko trzy palety. Na drugą budowę, w czwartek rano. Cena uzgodniona”. Pracownik biura szuka poprzedniego dokumentu, wybiera produkty i ustala, który adres jest właściwy. Potem oddzwania, bo nie wie, czy trzy palety dotyczą całego zamówienia, czy jednej pozycji.

To przykładowa sytuacja. Problemem nie jest sam e-mail, lecz to, że zamówienie trzeba odtworzyć z wiadomości, zamiast przekazać gotowe dane do realizacji.

Zamówienia od handlowców można wprowadzać przez aplikację mobilną współpracującą z ERP, połączony z nim CRM albo niewielki formularz. Gotowe rozwiązania tej klasy oferują m.in. Symfonia i Comarch. Nie trzeba więc z góry zakładać budowy nowego systemu. ^[1][2]

Najważniejszy warunek brzmi: po przekazaniu danych ma powstać właściwy dokument w programie firmy, a handlowiec powinien otrzymać informację o wyniku. Sam komunikat „wysłano” to za mało, jeśli nie wiadomo, czy zamówienie zostało zapisane i co dalej się z nim dzieje.

Szerszy podział odpowiedzialności opisuje poradnik CRM dla hurtowni budowlanej. Tutaj przyjrzymy się jednemu przejściu: od ustaleń z klientem do zamówienia, które biuro i magazyn mogą obsłużyć bez ponownego wpisywania pozycji.

Czym zastąpić przepisywanie zamówień do ERP?

Aplikacja mobilna obecnego systemu

Najpierw sprawdź, czy używane oprogramowanie ma odpowiedni moduł mobilny lub sprawdzone rozwiązanie partnerskie. Symfonia Mobilny Handel umożliwia składanie zamówień ze smartfona lub tabletu i współpracuje z systemem handlowym producenta. ^[1]

Nie oceniaj jednak wyłącznie koszyka. W tabeli funkcjonalności Comarch Mobile osobno wymieniono wystawianie zamówień lub rezerwacji oraz pobieranie stanu realizacji. Dostępność tej drugiej funkcji różni się zależnie od współpracującego ERP. Obsługa wysyłki nie dowodzi więc, że handlowiec zobaczy również dalszy przebieg realizacji. ^[2]

Poproś o pokazanie całej drogi na używanej wersji programu, z uwzględnieniem konfiguracji i licencji. Jeżeli gotowy moduł ją obsługuje, budowanie własnego odpowiednika nie musi mieć uzasadnienia.

Połączenie CRM-u, którego handlowcy już używają

Gdy zamówienie jest już poprawnie zapisane w CRM-ie, warto sprawdzić możliwość przekazania go dalej. Taka integracja CRM z ERP powinna obejmować pozycje i warunki zamówienia oraz powiązanie z dokumentem w systemie realizacji. Samo połączenie baz kontaktów nie usuwa przepisywania produktów. ^[3]

Ustal również, kto odpowiada za poszczególne dane. CRM nie powinien tworzyć drugiej, niezależnie poprawianej wersji cennika czy rezerwacji tylko po to, żeby wysłać zamówienie.

Niewielki formularz zamiast całego CRM-u

Jeżeli brakuje wyłącznie wygodnego miejsca przyjmowania zamówień, rozważ niewielki panel zamówień dla handlowców. Proponowany zakres to wybór klienta, koszyk, dane dostawy, podsumowanie oraz informacja o przekazaniu do programu firmy. Nie trzeba dodawać lejka sprzedaży i rozbudowanego kalendarza. ^[4]

Ważne rozróżnienie: formularz, który tylko wysyła e-mail do biura, porządkuje wiadomość, ale nie usuwa drugiego wpisywania. Aby przejść dalej, potrzebne jest połączenie z ERP albo obsługiwany przez niego import.

Gdy system pozwala importować zamówienia z ustalonego formatu pliku, taki wariant również warto sprawdzić. Wymagaj potwierdzenia, które zamówienia przyjęto, a które odrzucono. Nie zakładaj, że możliwość importu kartoteki produktów oznacza możliwość importu dokumentów sprzedażowych. ^[3]

A co z zamówieniami do Subiekta?

Trzeba ustalić dokładny produkt i edycję. InsERT opisuje Sferę dla Subiekta GT jako dodatek do tworzenia rozszerzeń korzystających z mechanizmów programu. W Subiekcie nexo możliwość tworzenia rozwiązań przez Sferę jest wymieniona wśród funkcji wersji PRO. To różne środowiska, a nie jeden uniwersalny konektor. ^[5][6]

Przed wyborem integratora sprawdź na przykładzie, jaki dokument zapisuje, czy obsługuje potrzebne jednostki i warunki oraz jak pokazuje błąd. Odczyt stanów lub faktur nie jest jeszcze potwierdzeniem możliwości poprawnego tworzenia zamówień.

Jakie dane musi zawierać zamówienie od handlowca?

Nie chodzi o formularz z trzydziestoma obowiązkowymi polami. Większość informacji warto podpowiadać z kartoteki klienta, produktu lub zaakceptowanej oferty. Handlowiec powinien doprecyzować to, co zmienia się w tej konkretnej transakcji.

Poniższa tabela jest propozycją zakresu do sprawdzenia w firmie, nie listą obowiązkowych pól każdego ERP.

Źródło: opracowanie ProcesON. Propozycja zakresu do sprawdzenia w firmie, nie obowiązkowe pola każdego ERP.

Przy kilku kartotekach z tym samym NIP-em nie wybieraj automatycznie pierwszego wyniku. Zaplanuj świadome przypisanie właściwego rekordu, a miejsce dostawy przechowuj osobno. NIP może pomóc wyszukać firmę, ale nie rozstrzyga, na którą budowę ma pojechać towar.

Podobnie produkty warto powiązać z konkretnymi kartotekami, zamiast za każdym razem zgadywać po nazwie. Brak jednoznacznego dopasowania powinien zatrzymać pozycję do wyjaśnienia, nie powodować automatycznego założenia kolejnego „kleju” w magazynie.

Zamiast uwagi „druga budowa, rano, zadzwonić” zaproponuj adres dostawy, oczekiwany przedział godzinowy i kontakt do odbiorcy. Pole uwag zostaw na rzeczy nietypowe. Nie każ handlowcowi wpisywać od nowa danych, które firma już zna.

Warunki cenowe i dostępność trzeba przygotować przed zatwierdzeniem. Szczegółowo opisuje to artykuł jak handlowiec może sprawdzić stan magazynowy i cenę klienta na telefonie. Tutaj ważne jest, aby te ustalenia nie zgubiły się podczas przekazywania zamówienia.

Jaki dokument ma powstać w ERP — i kiedy rezerwujemy towar?

Przed wdrożeniem nazwij docelowy rezultat: zamówienie od klienta, rezerwacja czy dokument roboczy oczekujący na akceptację. Nie zaczynaj od zasady „po kliknięciu od razu wystawiamy fakturę”, jeśli firma najpierw sprawdza możliwość realizacji.

Przykładowo dokumentacja wFirma dla Biur Rachunkowych opisuje rezerwację, która po zapisaniu otrzymuje status oczekujący i wpływa na ilość dostępną. Na jej podstawie można później wystawić m.in. WZ lub dokument sprzedaży. Opisywana funkcja wymaga pakietu z rozbudowanym magazynem. ^[7]

Nie przenoś jednak tych nazw i skutków automatycznie do innego programu. Ustal, kiedy rezerwacja rzeczywiście powstaje i czy wymaga potwierdzenia. Rozróżnij też zamówienie od klienta od zamówienia do dostawcy — sama nazwa zakładki nie opisuje kierunku operacji.

Przykład z prac ProcesON: formularz i istniejący magazyn

W projekcie dla dystrybucji spożywczej przyjęliśmy, że zamówienie z formularza CRM ma trafiać do wFirma jako rezerwacja, z wykorzystaniem istniejących kartotek produktów i kontrahentów. Punktem wyjścia było więc połączenie konkretnego etapu pracy, a nie odtworzenie magazynu w CRM-ie.

To przykład decyzji projektowej z innej branży, nie opis wdrożenia w hurtowni budowlanej. Podobne pytanie warto jednak postawić również tutaj: jaki istniejący dokument najlepiej przyjmie ustalenia handlowca, żeby biuro nie musiało tworzyć ich ponownie?

Źródło: materiał własny ProcesON — ustalenia projektu dla dystrybucji spożywczej z 10–11 września 2026 r. Opis dotyczy decyzji projektowej.

Jak powinno wyglądać przekazanie zamówienia do realizacji?

Poniżej przykładowy przebieg. Miejsca akceptacji i tworzenia rezerwacji należy dopasować do używanego systemu oraz zasad firmy.

1. Handlowiec zapisuje zamówienie.

   Wybiera klienta i produkty, potwierdza ilości, warunki oraz dane dostawy. Zamówienie otrzymuje własny identyfikator.

2. System sprawdza kompletność i warunki.

   Brakujące dane, niestandardowy rabat lub ograniczenie sprzedaży trafiają do wyjaśnienia, zamiast zostać pominięte.

3. Dane trafiają do ERP.

   Powstaje właściwy dokument. Aplikacja zapisuje jego identyfikator i numer albo pokazuje błąd bądź nieustalony wynik operacji.

4. Następuje potwierdzenie i rezerwacja według ustalonych reguł.

   Jeśli potrzeba decyzji biura lub uzupełnienia towaru, handlowiec widzi, na co zamówienie czeka.

5. Magazyn przygotowuje realizację.

   Otrzymuje dyspozycję i zapisuje przygotowane lub wydane ilości; powstają właściwe dokumenty.

6. Informacja wraca do sprzedaży.

   Handlowiec widzi wykonany zakres, pozostałe pozycje i potwierdzone etapy dostawy, o ile firma je rejestruje.

W dokumentacji Comarch Mobile dla ERP XL opisano konkretny wariant: po synchronizacji zamówienie otrzymuje status potwierdzony, gdy zarezerwowano wszystkie pozycje, a przy częściowej rezerwacji wraca jako niepotwierdzone. Działanie wymaga odpowiedniej konfiguracji. To przykład, dlaczego dotarcie danych i potwierdzenie realizacji nie są tym samym. ^[8]

Oddziel wynik wysyłki od etapu realizacji

Nie próbuj opisać wszystkiego jednym zielonym napisem „OK”. Zaproponuj osobne informacje o przekazaniu danych, decyzji handlowej i realizacji. Poniższe komunikaty są przykładami do zaprojektowania, nie gotowymi statusami każdego produktu.

Źródło: opracowanie ProcesON. Przykładowe komunikaty projektowe, nie nazwy statusów konkretnego produktu.

Warto sprawdzić powrót danych równie dokładnie jak ich wysyłkę. Comarch opisuje eksport informacji o realizacji z ERP XL do aplikacji mobilnej jako funkcję wymagającą włączenia odpowiedniego parametru. Nie należy zakładać, że zadziała tylko dlatego, że zamówienia można już wysyłać. ^[9]

Co zrobić, gdy warunki się zmienią albo integracja napotka problem?

Cena lub dostępność zmieniła się przed przyjęciem

Ustal, które warunki obowiązują: zaakceptowana oferta, uzgodniona cena czy cennik sprawdzany przy przyjęciu zamówienia. Jeśli wynik w ERP różni się od tego, co handlowiec przedstawił klientowi, nie nadpisuj go po cichu. Pokaż różnicę i przekaż ją do odpowiedniej decyzji.

Przy niedoborze również potrzebna jest reguła: odrzucamy całość, przyjmujemy zamówienie oczekujące na towar czy proponujemy częściową realizację? Dostępne warianty trzeba sprawdzić w danym systemie. Nie usuwaj brakującej pozycji bez informacji dla osoby składającej zamówienie.

Brakuje internetu albo ERP chwilowo nie odpowiada

Zapis lokalny lub umieszczenie w kolejce oznacz jako oczekiwanie na przekazanie, nie potwierdzoną rezerwację. Określ, kto zobaczy zamówienie, które czeka zbyt długo, i kto ma zareagować.

Przy błędach rozróżniaj problemy chwilowe od tych, które wymagają poprawy. Przerwa w dostępności może uzasadniać ponowienie po czasie; brak właściwego produktu czy uprawnień wymaga innej reakcji. Dokumentacja Microsoft dotycząca ponowień zaleca dostosowanie działania do typu błędu, zamiast powtarzania każdej nieudanej operacji bez końca. ^[10]

Handlowiec nacisnął „Wyślij” drugi raz

Wyobraźmy sobie, że ERP zapisał zamówienie, ale połączenie przerwało się przed odebraniem odpowiedzi. Aplikacja nie zna wyniku. Ponowne utworzenie dokumentu mogłoby dać dwa zamówienia zamiast jednego — taki mechanizm ryzyka opisuje Microsoft w dokumentacji wzorca ponowień. ^[10]

Dlatego wymagaj rozpoznawania kolejnych prób dotyczących tego samego zamówienia. Jednym z mechanizmów są unikalne identyfikatory żądań; ich wykorzystanie do bezpiecznych ponowień opisuje AWS. Zastosowanie do konkretnego ERP wymaga jednak sprawdzenia jego możliwości. ^[11]

Sam numer w panelu ani wyłączenie przycisku nie gwarantują ochrony. Gdy wynik zapisu jest nieznany, integracja powinna ustalić, czy dokument powstał, a jeśli nie potrafi tego rozstrzygnąć — skierować sprawę do sprawdzenia zamiast tworzyć nowy w ciemno.

Jednocześnie dwa świadomie złożone, identyczne zamówienia klienta muszą pozostać dwoma zamówieniami. Nie blokuj ich tylko na podstawie podobnej listy produktów. ^[11]

Klient zmienia zamówienie po wysłaniu

Ustal moment, do którego handlowiec może samodzielnie edytować dane. Gdy magazyn rozpoczął kompletację, zmiana ilości lub adresu powinna przejść przez uzgodnioną obsługę zmiany, z widocznym wynikiem dla zainteresowanych osób.

Nie zakładaj, że aplikacja pozwala edytować każdy dokument w dowolnym stanie. Comarch opisuje mobilną edycję niepotwierdzonych zamówień sprzedaży z ERP XL, uzależniając zakres zmian od konfiguracji i uprawnień. To nie jest zapewnienie dowolnej edycji dokumentów już realizowanych. ^[12]

Podobnie anulowanie w panelu nie powinno kończyć się wyłącznie ukryciem zamówienia. Trzeba potwierdzić odpowiednią zmianę w ERP, uwzględnić rezerwację i ustalić, co zrobić z towarem już wydanym.

Kilka magazynów i częściowa realizacja: co powinien widzieć handlowiec?

Załóżmy, że klient zamówił dwadzieścia paczek materiału. Dwanaście można wydać teraz, a pozostałe osiem dopiero po uzupełnieniu. To przykład redakcyjny, nie dane konkretnego klienta.

W widoku zamówienia pokaż ilość zamówioną, wydaną i pozostałą. Jeśli część została anulowana, rozróżnij ją od części nadal oczekującej. Nie oznaczaj całego zamówienia jako zakończonego tylko dlatego, że powstał pierwszy dokument.

Taką obsługę warto oprzeć na możliwościach obecnego programu. InsERT opisuje w Subiekcie nexo PRO realizowanie jednego zamówienia wieloma wydaniami oraz indywidualne terminy pozycji. Podgląd handlowca powinien korzystać z tych informacji, jeśli są dostępne w wybranej integracji, zamiast prowadzić odrębną historię. ^[13]

Przy kilku magazynach określ również, czy powstaje jeden dokument, czy kilka powiązanych. Handlowiec może widzieć jedno zamówienie klienta, ale aplikacja musi zachować odniesienia do wszystkich dokumentów potrzebnych do jego obsługi. Zaplanuj też reakcję, gdy pierwszą część zapisano, a druga się nie udała: nie ponawiaj całego zestawu tak, jakby nic wcześniej nie powstało.

Oddziel wydanie magazynowe od dostarczenia. Status „dostarczone” powinien wynikać z rzeczywistego potwierdzenia tego etapu. Jeżeli firma go nie rejestruje, nie dopisuj takiego statusu automatycznie na podstawie faktury albo WZ.

A jeśli klient nadal zamawia telefonicznie lub mailem?

Nie trzeba wymuszać na każdym kliencie nowego sposobu kontaktu. Zamówienie przyjęte przez telefon może wprowadzić pracownik biura bezpośrednio do wspólnego procesu. To nadal pierwsze zapisanie ustaleń, a nie ponowne przepisywanie dokumentu przygotowanego przez handlowca.

Dla zamówień mailowych warto rozważyć ustalony szablon lub import pliku, jeśli używane narzędzia to obsługują. Przy automatycznym odczytywaniu swobodnych wiadomości zacznij od przygotowania szkicu do zatwierdzenia. Wymagaj wyjaśnienia niejednoznacznego produktu, jednostki czy adresu, zamiast pozwalać mechanizmowi je zgadywać.

Zachowaj wiadomość źródłową przy zamówieniu. Doprecyzuj też, czy kolejne „proszę dodać jeszcze pięć” jest zmianą istniejącego zamówienia, czy nowym zakupem. Celem jest wspólna obsługa zamówień z różnych kanałów, nie zamiana każdego e-maila w dokument bez sprawdzenia znaczenia.

Od czego zacząć, żeby nie budować od razu całego systemu?

Wybierz ograniczony pierwszy zakres: zamówienia od wskazanej grupy handlowców, określony typ dokumentu i jasno opisany sposób przyjmowania. Na początku biuro może zatwierdzać każde zamówienie — ważne, żeby otrzymywało gotowe pozycje, a nie musiało wpisywać ich ponownie.

W pilotażu nie pomijaj błędów tylko dlatego, że zakres jest mały. Razem z dostawcą przeprowadź pięć testów na uzgodnionych danych testowych lub kopii bazy:

• Zwykłe zamówienie. Czy w ERP zgadzają się klient, produkty, jednostki, ilości, wartości i adres, a handlowiec widzi numer dokumentu?
• Wyjątek handlowy. Co dzieje się przy braku towaru albo rabacie wymagającym akceptacji? Czy wiadomo, kto podejmuje decyzję?
• Przerwane potwierdzenie. ERP zapisuje dokument, ale aplikacja nie odbiera odpowiedzi. Czy ponowienie nie tworzy duplikatu i czy wynik można ustalić?
• Zmiana lub anulowanie. Czy aktualizacja trafia również do ERP oraz osoby przygotowującej wydanie? Co stanie się, gdy operacja zostanie odrzucona?
• Częściowa realizacja. Czy po pierwszym wydaniu widać pozostałe ilości i powiązania dokumentów, także przy podziale między magazyny?

Ustal osobę odpowiedzialną za zamówienia wymagające wyjaśnienia i sposób pracy podczas dłuższej awarii. Jeżeli biuro wyjątkowo wprowadzi dokument ręcznie, ten fakt musi zostać powiązany ze zgłoszeniem handlowca przed wznowieniem automatycznej wysyłki.

Przed pilotażem zapisz, które dane są przepisywane, ile czasu wymaga ich obsługa i jakie poprawki się pojawiają. Potem porównaj te same czynności. Uwzględnij również licencje, utrzymanie integracji i testy po aktualizacjach, zamiast oceniać rozwiązanie tylko po koszcie uruchomienia.

Dobry pierwszy efekt nie brzmi „mamy nowy CRM”. Brzmi: handlowiec zapisuje zamówienie raz, biuro widzi właściwe dane, a każdy wie, co zostało przyjęte i co wymaga działania.

Podaj nazwę używanego programu i przykład informacji, które biuro musi ponownie wpisywać lub wyjaśniać. W ProcesON zaczynam od poznania tego przebiegu — dopiero później dobieram konfigurację, gotowe narzędzie, integrację albo dodatkową aplikację.

Opisz, jak zamówienie trafia dziś od handlowca do realizacji

Sposób pracy ProcesON: ^[14].

Źródła i dokumentacja

Sprawdzono 16 września 2026 r. Zakres funkcji zależy od wersji, licencji, konfiguracji i współpracującego ERP. Scenariusze zamówień, ilości, tabele i komunikaty są ilustracyjne. Przykład decyzji projektowej pochodzi z materiału własnego ProcesON.

1. Symfonia, „Symfonia Mobilny Handel” — mobilne składanie zamówień, współpraca z systemem handlowym, kontekst aplikacji na urządzenia mobilne. ↩1 ↩2
2. Comarch, „Dostępność funkcjonalności w aplikacjach Comarch Mobile” — osobne pozycje dla wystawiania ZS/RO i pobierania stanu realizacji oraz różnice zależnie od ERP. ↩1 ↩2
3. ProcesON, „Integracje systemów” — przepływ klientów, zamówień, statusów i dokumentów, ustalanie źródeł danych oraz rozważanie kontrolowanych importów i synchronizacji. ↩1 ↩2
4. ProcesON, „Dedykowane aplikacje dla firm” — niewielkie aplikacje rozwiązujące konkretny problem, systemy zamówień i współpraca z istniejącymi programami. Zakres funkcji formularza w artykule jest propozycją, nie specyfikacją gotowego produktu. ↩
5. InsERT, „Sfera dla Subiekta GT — opis” — rozszerzenia oparte na mechanizmach Subiekta GT, integracja posiadanych systemów i wymagania aktywacji. ↩
6. InsERT, „Subiekt nexo PRO — opis” — Sfera dla Subiekta nexo wymieniona w funkcjach wersji PRO. Nie oznacza, że każdy dodatek integracyjny wykorzystuje ten sam mechanizm ani że wszystkie edycje obsługują go identycznie. ↩
7. wFirma, „Rezerwacje w magazynie i ich realizacja” — status oczekujący, wpływ na dostępność, dokumenty powiązane i wymagany pakiet z rozbudowanym magazynem. Źródło opisuje funkcję systemu, nie stanowi specyfikacji API. ↩
8. Comarch, „Synchronizacja zamówień z wykonaniem rezerwacji asortymentu w systemie ERP” — potwierdzenie przy pełnej rezerwacji, niepotwierdzone zamówienie przy rezerwacji częściowej i wymagane ustawienia w opisanym wariancie ERP XL. ↩
9. Comarch, „Eksportowanie realizacji zamówień sprzedaży” — osobna konfiguracja przekazywania informacji o realizacji z ERP XL do aplikacji. ↩
10. Microsoft Learn, „Retry pattern” — rozróżnienie błędów, strategie ponowień oraz ryzyko powtórzenia operacji, która została wykonana, lecz nie zwróciła odpowiedzi. ↩1 ↩2
11. AWS Builders’ Library, „Making retries safe with idempotent APIs” — identyfikatory żądań, niejednoznaczny wynik wywołania i odróżnienie ponowienia od nowego, świadomie identycznego żądania. To źródło zasady technicznej, nie deklaracja jej gotowej obsługi przez ERP-y wymienione w artykule. ↩1 ↩2
12. Comarch, „Modyfikacja niepotwierdzonych zamówień pobranych z centrali” — ograniczenie do niepotwierdzonych dokumentów ZS z ERP XL i zależność zakresu edycji od ustawień oraz uprawnień. ↩
13. InsERT, „Subiekt nexo PRO — szczegółowy opis” — jedno zamówienie realizowane wieloma wydaniami, terminy na poziomie pozycji; dostępność w mobilnym podglądzie zależy od integracji. ↩
14. ProcesON, strona główna — analiza procesu przed doborem rozwiązania, zachowywanie używanych narzędzi, ograniczony pierwszy zakres i dobór gotowego programu, integracji lub aplikacji. ↩