Microsoft Dynamics, Odoo i Sage z AI

Scenariusz krok po kroku

1. 01

   Najpierw ustalamy produkt i miejsce zapisu

   W jednej firmie „Dynamics” oznacza Business Central, w innej rozmowa dotyczy innego produktu z tej rodziny. Podobnie informacja „mamy Sage” wymaga doprecyzowania programu i wydania. Pierwszym materiałem do wyceny jest nazwa używanego systemu, jego sposób utrzymania oraz dokument, który ma powstać po przeglądzie.

   Sprawdzamy z administratorem dostępne importy i interfejsy. Potrzebne są także informacje o dodatkowych polach, modyfikacjach i osobie odpowiedzialnej za zatwierdzenie dokumentu. Jeśli obecna funkcja importu obsługuje poprawnie Wasz plik, może wystarczyć jej konfiguracja. Osobny projekt ma uzasadnienie do oceny, gdy pracownik regularnie odczytuje swobodne opisy, szuka indeksów lub przenosi dane między kilkoma miejscami.

   Przykład produktu	Co potwierdza dokumentacja	Co sprawdzamy w firmie
   Dynamics 365 Business Central	Microsoft opisuje interfejsy do odczytu i zapisu oraz zaleca REST API dla integracji	Dostępny obiekt dokumentu, dodatkowe pola, uprawnienia i środowisko testowe
   Odoo, dokumentacja SaaS 19.3	Zewnętrzne API jest wskazane dla planu Custom; modele i pola zależą od bazy	Wersję, plan, sposób hostowania oraz wymagane operacje w tej bazie
   Sage Intacct	Sage opisuje API usług księgowych i uprawnienia użytkownika firmy	Czy firma używa właśnie Intacct i jakie operacje są dostępne w jej środowisku

   Źródła: Microsoft Business Central, Odoo JSON-2 API, Sage Intacct Web Services. Sprawdzone 10 października 2026. Możliwości tych produktów nie potwierdzają połączenia Syntalith ani obsługi innych wydań, na przykład Sage 50.

2. 02

   Szkic zamówienia zachowuje jednostkę i źródło

   Rozważmy fikcyjne zamówienie na cztery opakowania produktu. Katalog określa sześć sztuk w opakowaniu, więc szkic powinien pokazać zarówno cztery opakowania ze źródła, jak i 24 sztuki po przeliczeniu. Jeśli system docelowy przyjmuje opakowania, wpisanie do tego pola liczby 24 zmieniłoby wielkość zamówienia.

   Pracownik potrzebuje widoku nazwy klienta, wybranego indeksu, jednostki i przeliczenia. Nieznane opakowanie lub dwa pasujące indeksy trafiają do wyjaśnienia. Zmiana kartoteki po przygotowaniu szkicu wymaga ponownego sprawdzenia zależnych pozycji. AI może zaproponować odczyt opisu, natomiast obliczenie ilości wykonuje ustalona reguła.

   Do szkicu zapisujemy odwołanie do wiadomości lub pliku. Korekta przesłana później powinna być powiązana z istniejącą sprawą, aby pracownik mógł ustalić, czy zastępuje poprzednią wersję. Przy ponownym imporcie tego samego materiału system musi rozpoznać wcześniejszą operację. Kolejne zamówienie nie może wtedy powstać.

3. 03

   Faktura potrzebuje własnego zakresu

   Przy fakturze ustalamy, czy chodzi o roboczy dokument sprzedaży, przyjęcie dokumentu zakupowego czy przygotowanie danych do kontroli. Każdy z tych obiegów ma inny moment zatwierdzenia i inne pola wymagane przez firmę. Odczyt kwoty oraz nazwy kontrahenta nie potwierdza poprawności całego dokumentu.

   Proponowany zakres może zestawić odczytane pozycje ze źródłem oraz wskazać brak identyfikatora, jednostki lub powiązania z zamówieniem. Pracownik rozstrzyga rozbieżności przed przekazaniem danych. Reguły księgowe i podatkowe dostarcza zespół odpowiedzialny po stronie firmy; model nie dobiera ich sam na podstawie podobnej faktury.

   Uzgodnienie szkicu w ERP nie zamyka zakresu KSeF. Osobno sprawdzamy, co obsługuje używany moduł, kto zatwierdza dalsze działania i jak wracają statusy oraz błędy. Ta oferta nie potwierdza gotowego połączenia KSeF dla każdego z wymienionych produktów. Szerszy obieg opisuje automatyzacja KSeF.

4. 04

   Co się dzieje po częściowym zapisie

   Załóżmy, że integracja zapisuje nagłówek, lecz połączenie przerywa się przed potwierdzeniem wszystkich pozycji. Pracownik musi zobaczyć, jaki dokument powstał i które kroki pozostają niepewne. Bez tej informacji ponowienie całego zadania może utworzyć drugi szkic albo pozostawić niekompletny pierwszy.

   Dokumentacja Odoo JSON-2 wskazuje, że każde wywołanie ma własną transakcję. Nie można zakładać, że kilka osobnych wywołań zapisze się wspólnie albo wspólnie wycofa. Sposób przekazania pełnego dokumentu i odzyskania stanu po błędzie sprawdzamy dla wybranego interfejsu. Ta właściwość Odoo nie jest opisem zachowania wszystkich ERP.

   W próbie potrzebne są także odmowa uprawnień, zmiana kartoteki podczas przeglądu i ponowienie tego samego wejścia. Oczekiwanym wynikiem jest możliwy do odtworzenia stan dokumentu oraz informacja dla operatora. Zamknięcie zadania w integracji nie może samo oznaczać zaksięgowania ani zatwierdzenia faktury.

5. 05

   Jaki dowód jest dostępny

   Lokalny demonstrator przyjęcia zamówień pokazuje decyzje dotyczące katalogu i jednostek, zapis przeglądu oraz eksport CSV. Nie łączy się z rzeczywistym ERP ani skrzynką klienta. Jego sprawdzenie nie dowodzi odczytu faktur, działania KSeF ani skuteczności integracji z trzema opisanymi rodzinami produktów.

   Opis reguł i ograniczeń demonstratora pomaga ocenić część pracy przed zapisem. Dla projektu trzeba przygotować osobną próbę na dozwolonych materiałach i środowisku testowym ERP. Mierzymy poprawność pozycji oraz czas sprawdzenia i naprawy błędów. Nie przedstawiamy takiej próby jako wykonanej.

6. 06

   Co można zamówić

   Pierwszy zakres może objąć jeden kanał wejścia i jeden rodzaj dokumentu. Firma dostarcza katalog, reguły sprawdzania oraz administratora środowiska. Syntalith może przygotować odczyt, kolejkę wyjątków i zapis szkicu przez uzgodniony interfejs. Aplikacje lub agenci zaczynają się od 12 500 zł netto, jeśli potrzebny jest osobny widok pracy zespołu. Licencje ERP, dostęp API, użycie modeli i utrzymanie wyceniamy oddzielnie; ceny kategorii usług są w cenniku.

   Opisz produkt, wersję i dokument, który dziś przepisujecie. Na pierwszą rozmowę wystarczy opis obiegu bez haseł i danych kontrahentów. Porównamy konfigurację obecnej funkcji z dodatkową automatyzacją i wskażemy, czego brakuje do sprawdzenia połączenia.