Platforma B2B pokaże klientowi wiarygodną cenę i dostępność tylko wtedy, gdy firma uzgodni reguły ich pobierania z Business Central. Przed wyborem konektora warto określić właścicieli danych, kolejność tworzenia zamówienia i sposób wykrywania rozbieżności.
Krótka odpowiedź
Integrację Microsoft Dynamics 365 Business Central z platformą B2B projektujemy przez wskazanie danych do synchronizacji, źródła prawdy dla każdego pola oraz sposobu uwierzytelniania i obsługi ponowień. Standardowe API Business Central v2.0 udostępnia między innymi klientów i zamówienia sprzedaży, ale wymagania dotyczące cen, wariantów i stanów trzeba potwierdzić dla danego środowiska.
Microsoft dokumentuje limity API oraz konieczność obsługi odpowiedzi 429, 503 i 504.
Usługi KC Mobile
Potrzebujesz pomocy w tym temacie?
Czytasz poradnik „Integracja Microsoft Dynamics 365 Business Central z platformą B2B”. Napisz, co chcesz zrobić i na jakim etapie jesteś. Ustalimy, czy możemy pomóc i jaki zakres prac będzie potrzebny.
Jakie procesy połączyć między Business Central a platformą B2B?
Procesy łączymy według tego, jakie dane klient musi zobaczyć i co ERP musi otrzymać, aby obsłużyć zamówienie. Typowy zakres do oceny obejmuje klientów, produkty, warianty, ceny, dostępność, zamówienia, warunki płatności i statusy realizacji.
Dla każdego obiektu określamy kierunek przepływu, częstotliwość i zdarzenie uruchamiające aktualizację. Dokumenty takie jak faktury lub potwierdzenia wysyłki włączamy do zakresu tylko wtedy, gdy wybrana platforma i API obsługują wymagane pola.
Business Central udostępnia wersjonowane punkty końcowe REST w standardzie OData v4 oraz wbudowane API. Własne API można przygotować jako strony lub zapytania API, zgodnie z dokumentacją Microsoft sprawdzoną w październiku 2026 r. Firmy korzystające z BaseLinkera w obsłudze sprzedaży mogą rozważyć wdrożenie integracji z BaseLinkerem, jeśli zakres połączenia odpowiada ich procesom.
Czytasz poradnik „Integracja Microsoft Dynamics 365 Business Central z platformą B2B”. Napisz, co chcesz zrobić i na jakim etapie jesteś. Ustalimy, czy możemy pomóc i jaki zakres prac będzie potrzebny. Omów temat tego poradnika
Który system powinien być źródłem prawdy dla poszczególnych danych?
System nadrzędny należy ustalić osobno dla każdego pola, tak aby dwa systemy nie aktualizowały go niezależnie. Tabela pokazuje przykładowy podział ról, który firma powinna zatwierdzić przed konfiguracją synchronizacji.
| Encja | Proponowany właściciel | Reguła synchronizacji | Przykładowy konflikt |
|---|---|---|---|
| Produkt i wariant | Business Central | Publikuj zatwierdzone kartoteki | Inny kod wariantu w platformie |
| Cena kontrahenta | Business Central lub uzgodniony silnik cenowy | Pobierz cenę dla klienta i warunków | Inny rabat w koszyku |
| Stan magazynowy | Business Central | Przekazuj stan według lokalizacji | Opóźniona rezerwacja |
| Dane klienta | Business Central lub platforma B2B | Dopasuj po stabilnym identyfikatorze | Dwa konta dla tej samej firmy |
| Zamówienie | Platforma B2B do przyjęcia przez ERP | ERP zwraca numer i status | Ponowne przesłanie zamówienia |
Tabela przedstawia wzorcowy podział właścicieli danych. Najważniejszą regułą jest wskazanie, który system rozstrzyga konflikt i jak zachować odrzuconą zmianę.
Zalecamy osobno zdefiniować klienta firmy i użytkownika składającego zamówienie. Jedno konto kontrahenta może mieć wielu użytkowników, różne uprawnienia zakupowe i indywidualne cenniki.
Jak przebiega synchronizacja produktów, cen i stanów?
Synchronizacja produktów, cen i stanów powinna używać stałych identyfikatorów oraz uzgodnionej reguły aktualizacji pełnej lub przyrostowej. Synchronizacja pełna odczytuje cały wybrany zakres, a przyrostowa pobiera tylko rekordy zmienione od ostatniego poprawnego przebiegu.
Business Central udostępnia filtrowanie oraz webhooki, które mogą ograniczyć potrzebę częstego pobierania całych zbiorów. Webhook wysyła powiadomienie o zmianie, ale integracja nadal powinna potwierdzić aktualny stan zasobu i obsłużyć ponowienia. Microsoft zaleca obsługę limitów API; dokumentację sprawdziliśmy w październiku 2026 r.
Plan synchronizacji powinien określać:
- klucz produktu i wariantu używany w obu systemach;
- jednostkę miary, walutę, precyzję ceny i zasady podatkowe;
- magazyny lub lokalizacje uwzględniane przy dostępności;
- moment, od którego zmiana ceny lub stanu jest widoczna;
- sposób wykrycia pominiętego zdarzenia i wykonania synchronizacji uzupełniającej.
Zalecamy okresowe uzgodnienie kontrolne, które wykrywa różnice po utracie powiadomienia lub przerwie w działaniu.
Jak przekazywać zamówienia B2B do Business Central?
Zamówienie B2B należy przekazać do Business Central po walidacji klienta, produktu, ceny, ilości i warunków handlowych. Standardowe API v2.0 Business Central pozwala utworzyć zamówienie sprzedaży przez żądanie POST do zasobu salesOrders, a udana operacja zwraca odpowiedź 201 Created; dokumentację Microsoft sprawdziliśmy w październiku 2026 r.
Przepływ warto rozpisać w następującej kolejności:
1. Zweryfikuj konto firmy i przypisz użytkownika do kontrahenta.
2. Sprawdź identyfikatory produktów, jednostki miary i warunki cenowe.
3. Nadaj zamówieniu trwały identyfikator źródłowy.
4. Wyślij nagłówek i pozycje do Business Central.
5. Zapisz zwrócony numer ERP i status utworzenia.
6. Przy błędzie odczytaj stan dokumentu przed ponowieniem wysyłki.
Sama odpowiedź HTTP nie zastępuje kontroli dokumentu biznesowego. Test uzgodnieniowy porównuje klienta, pozycje, ilości, ceny i status zamówienia w obu systemach.
Kiedy wystarczy konektor, a kiedy potrzebne jest API?
Konektor wystarczy, gdy obejmuje wymagane procesy, wersję Business Central i obsługę błędów bez nadmiernych przeróbek. API jest potrzebne, gdy przepływ wymaga pól lub reguł niewspieranych przez konektor, niestandardowego obiektu albo szczególnej kontroli nad synchronizacją.
Tabela porównuje warunki, które pomagają wybrać konektor lub API. Ocenę należy przeprowadzić dla używanej wersji systemu i konkretnych reguł sprzedaży.
| Kryterium | Konektor może wystarczyć | API może być potrzebne |
|---|---|---|
| Procesy | Typowe katalogi i zamówienia | Nietypowe zatwierdzenia lub dokumenty |
| Ceny | Standardowe cenniki obsługiwane przez narzędzie | Indywidualne reguły dla grup klientów |
| Magazyny | Jeden uzgodniony sposób publikacji | Wiele lokalizacji z własnymi regułami |
| Błędy | Konektor zapisuje logi i umożliwia ponowienia | Wymagana własna kolejka i deduplikacja |
| Utrzymanie | Dostawca aktualizuje zgodność narzędzia | Firma utrzymuje własny kod i wersje API |
Konektor ogranicza zakres własnego kodu, a API daje kontrolę nad niestandardowymi regułami i obsługą błędów.
W środowiskach objętych tą funkcją administrator może otworzyć wyszukiwarkę w Business Central skrótem Alt+Q, wpisać API Overview i sprawdzić dostępne strony, zapytania oraz codeunits API. Widok prezentuje dostępne interfejsy, ale nie konfiguruje API ani nie nadaje dostępu; dokumentację Microsoft sprawdziliśmy w październiku 2026 r.
Jakie pułapki pojawiają się przy integracji Business Central?
Najczęstsze problemy wynikają z rozbieżnych identyfikatorów, reguł cenowych i uprawnień, a nie z samego transportu danych. Mapowanie powinno jawnie opisywać jednostki miary, warianty, waluty, podatki, lokalizacje magazynowe i statusy dokumentów.
Kontrola jakości danych powinna wykrywać brak produktu, nieaktywną jednostkę, nierozpoznaną walutę, niezgodny identyfikator klienta i cenę niezgodną z warunkami kontrahenta. Uprawnienia API należy ograniczyć do środowiska i operacji wymaganych przez integrację.
Przy równoległej edycji rekordu przydatny jest znacznik wersji. Microsoft dokumentuje użycie nagłówka If-Match z eTag przy aktualizacji zamówień sprzedaży, co pozwala wykryć zmianę obiektu od czasu odczytu; dokumentację sprawdziliśmy w październiku 2026 r.
Jak przetestować integrację przed startem sprzedaży?
Test integracji powinien potwierdzić zgodność danych, brak duplikatów i prawidłowe zachowanie po błędzie. Scenariusze odbiorowe uzgadniają rekordy po stronie platformy B2B i Business Central.
Tabela przedstawia scenariusze, które należy uruchomić przed otwarciem sprzedaży. Odbiór powinien wymagać zapisanych wyników testów oraz potwierdzenia obsługi błędnych rekordów.
| Przypadek testowy | Oczekiwany rezultat | Kryterium akceptacji |
|---|---|---|
| Zmiana ceny | Nowa cena widoczna dla właściwego klienta | Zgodność ceny i waluty |
| Zmiana stanu | Dostępność zgodna z regułą magazynową | Zgodność lokalizacji i ilości |
| Nowy kontrahent | Konto powiązane z właściwą firmą | Brak duplikatu klienta |
| Zamówienie z rabatem | ERP otrzymuje uzgodnione pozycje i warunki | Zgodność sum i danych pozycji |
| Błąd walidacji | Zamówienie pozostaje widoczne do poprawy | Komunikat wskazuje pole i przyczynę |
| Ponowienie transferu | Dokument nie zostaje utworzony drugi raz | Zgodny identyfikator źródłowy |
Scenariusze obejmują zmiany katalogu, dane klienta, reguły cenowe i ponowienie, więc pozwalają sprawdzić najważniejsze ryzyka przed startem.
Zalecamy osobny test zmiany danych w trakcie synchronizacji, aby potwierdzić, czy system wykrywa konflikt i nie nadpisuje nowszej wartości starszą.
Jak monitorować działanie po wdrożeniu?
Monitoring powinien mierzyć opóźnienie synchronizacji, liczbę błędnych rekordów, ponowienia i zgodność zamówień między systemami. Microsoft zaleca obsługę odpowiedzi HTTP 429, 503 i 504; przy 429 i 503 klient powinien ponawiać żądanie po przerwie, a długie żądanie kończące się 504 należy podzielić na mniejsze operacje. Dokumentację sprawdziliśmy w październiku 2026 r.
Tabela łączy typowe objawy z miejscem diagnostyki i pierwszą reakcją techniczną. Logi powinny zachować identyfikator żądania, czas, endpoint i odpowiedź serwera.
| Objaw | Prawdopodobna przyczyna | Gdzie sprawdzić | Reakcja |
|---|---|---|---|
| Zamówienia nie dochodzą | Błąd uwierzytelnienia lub walidacji | Log API i kolejka integracji | Sprawdź token, uprawnienia i treść odpowiedzi |
| HTTP 429 | Przekroczony limit wywołań | Odpowiedź API i metryki kolejki | Odłóż żądanie i ponów po przerwie |
| HTTP 503 | Usługa chwilowo niedostępna | Logi integracji i stan endpointu | Ponów z rosnącym odstępem |
| HTTP 504 | Żądanie trwa zbyt długo | Czas odpowiedzi i zakres zapytania | Podziel pobieranie na mniejsze porcje |
| Rozbieżne statusy | Opóźnione lub nieodebrane powiadomienie | Znacznik czasu i stan obu dokumentów | Wykonaj uzgodnienie i odczyt kontrolny |
Tabela przypisuje objaw do miejsca diagnostyki i wskazuje pierwszą reakcję. Microsoft wymienia odpowiedzi 429, 503 i 504 jako przypadki wymagające obsługi po stronie klienta integracji; dokumentację wydajności sprawdziliśmy w październiku 2026 r.
Jeśli firma potrzebuje wykonawcy do zaprojektowania przepływu między systemami sprzedaży, wdrożenie integracji z BaseLinkerem może być punktem wyjścia do ustalenia zakresu. Dopasowanie oferty wymaga potwierdzenia, że obejmuje używaną platformę B2B i interfejsy Business Central.
Więcej poradników w tym temacie
Wspomniane narzędzia
Najczęściej zadawane pytania
Jak połączyć Microsoft Dynamics 365 Business Central z platformą B2B?
Czy integracja Business Central synchronizuje stany magazynowe na bieżąco?
Jak przesyłać cenniki kontrahentów do sklepu B2B?
Czy zamówienie B2B może automatycznie utworzyć dokument w Business Central?
Kiedy do integracji Business Central potrzebne jest API?
Jak sprawdzić, dlaczego zamówienie nie trafiło do ERP?
Krzysztof Czapnik
Founder & Technical Lead, KC Mobile
Projektuję i rozwijam strony WordPress, sklepy WooCommerce oraz aplikacje internetowe. Łączę projektowanie z programowaniem, integracjami i technicznym SEO. Projekty KC Mobile prowadzę osobiście.
Potrzebujesz pomocy z tym tematem? Napisz - odpowiem osobiście w 24h.
Potrzebujesz pomocy w tym temacie?
Czytasz poradnik „Integracja Microsoft Dynamics 365 Business Central z platformą B2B”. Napisz, co chcesz zrobić i na jakim etapie jesteś. Ustalimy, czy możemy pomóc i jaki zakres prac będzie potrzebny.