← Blog / Integracja SAP i Salesforce

Status zamówienia z SAP w Salesforce: co ma widzieć handlowiec

Opublikowano: 23 września 2026 Aktualizacja: 14 października 2026

Klient dzwoni do handlowca w czwartek przed południem i pyta, gdzie jest zamówienie złożone dziesięć dni temu, bo jego produkcja czeka na komponenty. Handlowiec ma w Salesforce wygraną szansę sprzedaży, ofertę i historię rozmów, ale numeru dostawy już nie, więc pisze maila do logistyki, obiecuje oddzwonić i oddzwania po trzech godzinach z informacją, że towar wyjechał we wtorek. Ta sama sytuacja powtarza się przy pytaniu o kopię faktury, o zaległą płatność i o to, czy klient może złożyć kolejne zamówienie, i za każdym razem kończy się mailem do innego działu.

Gdzie kończy się wiedza CRM

W typowym podziale ról Salesforce prowadzi klienta do chwili złożenia zamówienia: szansa sprzedaży, oferta, czasem samo zamówienie przekazane do SAP. Od tej chwili wszystko, co dzieje się z zamówieniem, dzieje się w SAP: potwierdzenie terminu, kompletacja, wydanie towaru, faktura, płatność, a po drodze kontrola kredytowa, która potrafi zatrzymać zamówienie bez wiedzy handlowca. Salesforce zna klienta, SAP zna zamówienie, a handlowiec, który chce odpowiedzieć klientowi, może zalogować się do SAP, jeśli ma tam dostęp i wie, gdzie szukać, albo zapytać kogoś, kto wie.

Ten układ kosztuje przede wszystkim obsługę klienta i handlowców. Dział obsługi zamówień odpowiada na pytania, na które odpowiedź od dawna jest w systemie, a handlowiec przygotowuje nową ofertę dla klienta, któremu kontrola kredytowa od tygodnia wstrzymuje zamówienia, i dowiaduje się o tym dopiero, gdy zamówienie z tej oferty utknie. Dla dyrektora sprzedaży cel projektu da się więc opisać bez słowa o technologii: mniej maili i telefonów do obsługi klienta z pytaniem o status oraz krótsza droga od zapytania klienta do oferty, której nie zatrzyma blokada kredytowa.

Pięć informacji z SAP, które handlowiec ma widzieć

Nazwy API pochodzą z SAP Business Accelerator Hub, który opisuje je jako standardowe interfejsy S/4HANA, więc żaden z tych strumieni nie wymaga programowania po stronie SAP. Wymaga natomiast decyzji, co dokładnie handlowiec ma zobaczyć.

Status zamówienia to zwykle najczęstsze pytanie i zarazem najprostsze do pokazania na żywo. Handlowiec otwiera konto klienta i widzi listę otwartych zamówień, a przy każdym potwierdzony termin, status dostawy i status faktury, odczytane z SAP w chwili otwarcia strony. API zamówień sprzedaży jest dostępne w wersji OData V2 i V4. Kodów statusów z SAP nie należy pokazywać wprost, bo handlowiec ma zobaczyć „częściowo wysłane”, a nie literę z pola statusu, a przełożenie kilkunastu stanów technicznych na cztery albo pięć zrozumiałych dla klienta trzeba uzgodnić z obsługą klienta, która dziś objaśnia je przez telefon.

Dostawy zmieniają się rzadziej i w przewidywalnych momentach: dostawa powstaje, towar zostaje wydany, przewoźnik go odbiera. Tu lepiej sprawdza się kopia w Salesforce aktualizowana w chwili wydania towaru, bo wtedy handlowiec może dostać powiadomienie, zanim klient zadzwoni, a obsługa klienta może zbudować widok „wysłane dziś”. Mechanizm takiej aktualizacji opisujemy we wpisie o integracji zdarzeniowej SAP i Salesforce. Najmniej pewnym elementem tego obrazu jest numer przesyłki u przewoźnika: w części firm trafia do SAP z systemu magazynowego albo od spedytora, w części nie trafia nigdzie, i dopóki nie sprawdzisz, skąd w Twojej firmie bierze się ten numer, nie obiecuj klientom linku do śledzenia.

Faktury i należności to dwa różne obszary SAP i warto je rozdzielić także w Salesforce. Lista faktur pochodzi z dokumentów fakturowania, a API Billing Document według opisu w Business Accelerator Hub pozwala pobrać też PDF faktury, więc handlowiec wyśle klientowi kopię bez angażowania księgowości. Zaległości są w rozrachunkach z odbiorcami i tu handlowcowi wystarczy jedna liczba na koncie klienta: kwota przeterminowana i wiek najstarszej zaległości, odświeżane raz dziennie. Częstsze odświeżanie ma sens tylko wtedy, gdy wpłaty są księgowane w SAP w ciągu dnia.

Limit kredytowy i blokada kredytowa mają największy wpływ na szybkość ofertowania. W SAP Credit Management limit jest przypisany do partnera biznesowego w segmencie kredytowym, a zamówienie, które go przekracza, czeka na decyzję kontrolera kredytowego. Handlowiec potrzebuje tu dwóch informacji: na koncie klienta, ile limitu zostało, zanim przygotuje dużą ofertę, a przy zamówieniu, że stoi ono na blokadzie, zanim klient zapyta, dlaczego nic nie wyjechało. Limit to dane podstawowe i wystarczy replikować go raz dziennie. Zajęcie limitu zmienia się z każdym zamówieniem i fakturą, więc przy tej liczbie trzeba podać godzinę, z której pochodzi. Zablokowane dokumenty SAP udostępnia przez osobne API dokumentów z blokadą kredytową, które służy również do zwolnienia albo odrzucenia blokady. Dla handlowca przeznaczony jest odczyt, decyzja zostaje u kontrolera kredytowego w SAP.

Dostępność jest jedyną z tych informacji, której kopia w Salesforce częściej szkodzi, niż pomaga, bo stan magazynu zmienia się z każdym wydaniem i przyjęciem. Handlowiec, który w rozmowie z klientem sprawdza, czy produkt jest dostępny, powinien dostać odpowiedź z SAP w chwili pytania. Trzeba też ustalić, co dokładnie pokazujemy: stan magazynowy mówi, ile leży na półce, a sprawdzenie dostępności w SAP uwzględnia już przyjęte zamówienia innych klientów i planowane przyjęcia. Dostępność i cena wewnątrz oferty to osobny temat, związany z konfiguratorem i wyceną.

Na żywo czy kopia: co kosztuje każda droga

Podgląd na żywo ma w Salesforce dwie postaci. Pierwsza to Salesforce Connect: dane z SAP pojawiają się jako obiekty zewnętrzne, z listami powiązanymi na koncie klienta i własnymi stronami rekordów, ale nie są w Salesforce przechowywane, tylko pobierane z SAP przy każdym odczycie. Ponieważ API S/4HANA są wystawione w OData, łączy się je przez adapter OData w Salesforce Connect, bez kodu po stronie Salesforce. Salesforce Connect jest dodatkiem płatnym osobno: Salesforce Help podaje, że w edycjach Enterprise, Performance i Unlimited jest dostępny za dodatkową opłatą, a jedna licencja obejmuje jedno połączenie przez jeden typ adaptera w jednej organizacji. Druga postać to własny komponent na stronie konta, który w chwili kliknięcia wywołuje SAP przez platformę integracyjną. Nie wymaga licencji Salesforce Connect, ale ktoś musi go napisać i utrzymywać.

Obie postacie mają wspólny koszt, który rzadko trafia do uzasadnienia projektu: dostępność strony konta w Salesforce zależy od dostępności SAP. W oknie serwisowym SAP zakładka z zamówieniami jest pusta albo pokazuje błąd, a każde otwarcie konta przez każdego handlowca to zapytanie do SAP. S/4HANA działający on-premise trzeba też bezpiecznie wystawić na zewnątrz, zwykle przez bramę API, a nie bezpośrednio z sieci firmowej. Salesforce opisuje w dokumentacji adapterów OData własne limity, między innymi na liczbę obiektów zewnętrznych w organizacji i na liczbę nowych rekordów zewnętrznych w ciągu godziny, więc przy kilkuset handlowcach warto je sprawdzić przed decyzją.

Kopia kosztuje inaczej. Dane zajmują przestrzeń danych Salesforce, ktoś musi pilnować harmonogramu albo zdarzeń, a każda kopia ma świeżość, którą trzeba pokazać wprost, na przykład godziną ostatniej synchronizacji obok liczby. W zamian dane zachowują się jak wszystko inne w CRM: działają w raportach, widokach list, regułach powiadomień i w aplikacji mobilnej, są też dostępne dla agentów AI pracujących na danych z Salesforce, a Agentforce bez danych z SAP odpowiada klientom tylko tym, co zostało w CRM. Dla dostaw, faktur i zaległości to zwykle lepszy wybór, bo dyrektor sprzedaży chce mieć raport „klienci z zaległością i otwartą szansą sprzedaży” bez telefonu do księgowości.

Czego nie pokazywać

Skoro systemy są już połączone, łatwo pokazać za dużo. Kilka rzeczy lepiej zostawić w SAP:

• Pojedynczych pozycji z rozrachunków. Kwota przeterminowana wystarczy, a lista dokumentów księgowych prowokuje rozmowy z klientem o rozliczeniach, które powinna prowadzić księgowość.
• Kosztu własnego i marży, chyba że polityka cenowa firmy wprost tego wymaga.
• Przycisków zmieniających dane w SAP. Adapter OData pozwala na zapis do obiektów zewnętrznych, ale zmiana ilości, terminu albo zwolnienie blokady z poziomu CRM omija kontrolę, która w SAP ma swój powód.
• Surowych kodów statusów.
• Historii zamówień sprzed kilku lat, która przy podglądzie na żywo spowalnia każdą stronę konta, a w kopii zajmuje miejsce.

Od czego zacząć

Zanim ktokolwiek wybierze technologię, warto przez dwa, trzy tygodnie zapisywać, z jakimi pytaniami handlowcy przychodzą do obsługi klienta, logistyki i księgowości. Taka lista zwykle pokazuje, że dwie albo trzy z pięciu informacji odpowiadają za większość zapytań, i od nich warto zacząć. Ten sam pomiar powtórzony po wdrożeniu pokaże, o ile spadła liczba zapytań. Nie da się za to przewidzieć z góry, ile telefonów zniknie, bo część klientów pyta o status zamówienia przy okazji rozmowy o czymś innym i takiej rozmowy żaden widok w Salesforce nie zastąpi.

FAQ

#Salesforce #SAP #Order-to-Cash #CRM #API