Jak AI odpowiada na pytania o koszty i faktury prosto z Dynamics 365 Finance and Supply Chain?

Dynamics 365 Finance and Supply Chain Management ma otwarte OData REST API, przez które AI może pobierać zamówienia, faktury, ruchy magazynowe i salda per wymiar finansowy bez eksportowania plików ręcznie. Nie trzeba czekać na raport z działu IT. Podłączenie wymaga konta serwisowego w Azure Active Directory, odpowiednich ról w systemie i warstwy tłumaczącej surowe dane encji na pytania i odpowiedzi dla kontrolera albo kierownika produkcji.

Jakie dane z Dynamics 365 Finance trafiają do asystenta?

D365 Finance i Supply Chain udostępnia dane przez encje (data entities) pod adresem OData: https://<środowisko>.cloudax.dynamics.com/data/. Do codziennej pracy z asystentem najbardziej przydają się konkretne encje, które firma naprawdę odpytuje.

• PurchaseOrderHeaders i PurchaseOrderLines: zamówienia zakupu z polami StatusOrder, PurchaseOrderNumber, InvoiceAccount, DeliveryDate, CurrencyCode
• VendorInvoiceHeaders i VendorInvoiceLines: faktury od dostawców, status zatwierdzenia, powiązanie z zamówieniem przez pole MatchedPurchaseOrderNumber, kwota netto i VAT
• CustInvoiceJournals: faktury sprzedaży z pozycjami, kodami towarów i cenami jednostkowymi
• InventTransactions: ruchy magazynowe z datą, kodem magazynu, ilością i kosztem jednostkowym
• ProductionOrders: zlecenia produkcyjne ze statusem (Scheduled, Released, Reported as Finished) i powiązanymi komponentami
• GeneralJournalAccountEntries: zapisy w księdze głównej z kombinacjami wymiarów finansowych: CostCenter, Department, Project, BusinessUnit
• BudgetTransactionLines: linie budżetu per wymiar i okres obrachunkowy

Wymiary finansowe to serce raportowania w D365. Każdy zapis w księdze nosi kombinację wymiarów, więc asystent może odpowiedzieć nie tylko "ile wydaliśmy na dostawców w październiku", ale też "ile wydało centrum kosztów CC-010 na projekt P-0045 w Q3 i jak to się ma do zatwierdzonego budżetu". To pytanie, na które bez asystenta trzeba czekać na arkusz z działu finansów przygotowany ręcznie.

Dla polskiej lokalizacji D365 dochodzą encje specyficzne dla naszego rynku: TaxTrans z detalami VAT, dane potrzebne do JPK_VAT i encje rozrachunków z urzędem skarbowym. Warto sprawdzić, czy partner wdrożeniowy D365 nie dołożył własnych encji w ramach lokalizacji, bo te bywają poza standardową dokumentacją.

Jak fizycznie wygląda podłączenie: OData, DMF i konto serwisowe

Dostęp do D365 Finance w środowisku chmurowym Microsoft wymaga kilku konkretnych kroków. Bez tego ugrzęźnie się na etapie konfiguracji z działem IT i w rozmowie z zewnętrznym dostawcą D365.

• App Registration w Azure Active Directory: tworzymy aplikację w AAD, nadajemy jej uprawnienia do środowiska D365 przez External ID konta, wystawiamy Client ID i Client Secret (albo certyfikat). To konto nigdy nie loguje się przez przeglądarkę: jest stricte serwisowe i ma tylko te uprawnienia, których asystent potrzebuje.
• Rola w D365 przypisana do konta serwisowego: najczęściej wystarczy rola Electronic Reporting Reader (odczyt) albo własna rola z dostępem tylko do wybranych encji. Zasada minimalna: konto widzi tylko to, co asystent odpytuje.
• OData aktywny w środowisku: w środowiskach produkcyjnych chmury D365 jest standardowo włączony. W sandbox bywa wyłączony do testów. Przed konfiguracją warto sprawdzić.
• Data Management Framework (DMF, dawniej DIXF): przydatny przy masowych eksportach, na przykład kilkaset tysięcy transakcji magazynowych jednorazowo. Tworzymy job eksportowy w workspace Data management, skrypt go uruchamia i pobiera plik wynikowy bez stronicowania OData.

Czego Microsoft nie udostępnia przez standardowe API: bezpośredniego dostępu do bazy SQL (to Azure SQL pod kontrolą Microsoftu, zablokowany od zewnątrz), tabel frameworkowych z prefiksem Sys*, ani pełnych logów użytkowników w szczegółach (te są osobno przez Azure Monitor i wymagają osobnych uprawnień). Zapis danych z powrotem do D365 odbywa się przez encje z metodami POST i PATCH, co wymaga znajomości struktury encji, ale jest bezpieczniejsze niż pisanie wprost do bazy.

Co AI robi z tymi danymi: trzy konkretne zastosowania

Pierwsze: odpowiedzi na pytania o koszty per wymiar finansowy. Kontroler pisze do asystenta: "Jakie koszty poniosło centrum CC-010 w Q3 i jak to się ma do budżetu tego centrum?" AI pobiera GeneralJournalAccountEntries i BudgetTransactionLines, porównuje po kombinacji wymiarów i odpowiada z konkretami. Bez otwierania raportu w D365, bez Excela.

U jednego klienta z branży produkcyjnej kilku kierowników projektów odpytywało dział finansów dwa razy w tygodniu o stan kosztów swoich projektów. Dział produkował zestawienia w Excelu i wysyłał je we wtorki rano. Po podłączeniu asystenta kierownicy zaczęli pytać na bieżąco, a dział finansów przestał robić te zestawienia w ogóle.

Drugie: zestawienia do zamknięcia miesiąca. Zamknięcie miesiąca w D365 Finance to kilkanaście kroków: uzgodnienie sald kont, weryfikacja rozrachunków z odbiorcami i dostawcami (CustOpenTransactions, VendOpenTransactions), zamknięcie okresu inwentaryzacyjnego przez moduł Inventory close, alokacje przez Cost accounting module, weryfikacja dokumentów wiszących w statusie Draft albo Pending. Asystent może przejść przez każdą z tych warstw i zwrócić listę: co jest gotowe, co wisi i kto ma otwarty dokument blokujący zamknięcie okresu. To nie zastępuje pracy działu finansów, ale skraca czas szukania.

Trzecie: tłumaczenie procesów nowym użytkownikom. D365 Finance to rozbudowany system: sam moduł Accounts payable ma kilkadziesiąt ekranów i typy dokumentów takie jak Vendor invoice journal, Invoice register i Invoice approval journal. Nowy pracownik pyta asystenta: "Jak wprowadzić fakturę kosztową, gdy nie ma zamówienia zakupu?" i dostaje instrukcję dopasowaną do środowiska i roli tej osoby. Nie z ogólnej dokumentacji Microsoft, tylko z kontekstu ich konkretnego portalu D365.

Faktury bez zamówienia i dostawy bez faktury: jak wyłapujemy rozbieżności

W D365 Finance działa mechanizm invoice matching: system weryfikuje, czy faktura od dostawcy pasuje do zamówienia z PurchTable i do dokumentu przyjęcia towaru z ProductReceiptHeader. Matching może być dwustronny (zamówienie i faktura) albo trzystronny (zamówienie, dostawa, faktura). Politykę matchingu ustawia się per dostawca albo per grupa zakupowa.

Problem polega na tym, że nie każda faktura przechodzi przez ten mechanizm. Faktury za usługi, media albo najem są wprowadzane bez Purchase Order i lądują w VendorInvoiceHeaders z pustym polem MatchedPurchaseOrderNumber. Asystent może raz dziennie pobrać nowe rekordy z ostatnich 24 godzin i oznaczyć te bez przypisanego zamówienia: "Faktura FVZ/10/0432 od dostawcy X nie ma przypisanego PO. Status: Pending approval." Trafia to powiadomieniem do osoby zatwierdzającej, zanim faktura zaginie w kolejce.

Odwrotna sytuacja jest równie kosztowna. Dostawa przyszła, ProductReceiptHeader ma datę potwierdzenia, a faktura nie dotarła od trzech tygodni. Asystent przegląda PurchTable i szuka w VendorInvoiceHeaders pary dla każdego przyjęcia towaru. Gdy jej nie ma, generuje listę dla działu AP: numer zamówienia, dostawca, data dostawy, wartość. Dział nie musi szukać tego ręcznie, dostaje gotową listę do działania.

Firmy wciąż na Dynamics AX 2012: co można zrobić przed migracją

Spora część polskich firm produkcyjnych i dystrybucyjnych nadal działa na Dynamics AX 2012 w wersji R2 albo R3. Migracja do D365 Finance to projekt na wiele miesięcy i nie zawsze jest priorytetem w danym roku.

AX 2012 to instalacja on-premise z SQL Server na serwerze firmy. Baza jest dostępna bezpośrednio. Główne tabele to: VendInvoiceJour (faktury dostawców), CustInvoiceJour (faktury sprzedaży), PurchTable (zamówienia zakupu), SalesTable (zamówienia sprzedaży), InventTrans (transakcje magazynowe), ProdTable (zlecenia produkcyjne), LedgerTrans (zapisy w księdze z wymiarami finansowymi przez tabelę Dimensions).

Podłączenie asystenta do AX 2012 polega na zapytaniach SQL z konta tylko do odczytu. Żadnych zmian w konfiguracji AX, żadnych modyfikacji bazy. AX 2012 ma co prawda AIF (Application Integration Framework) z usługami SOAP, ale SQL jest prostszy i wystarczy do czytania danych na potrzeby asystenta.

Co firma dostaje przed migracją: asystent odpowiada na pytania o koszty, zamówienia i zapasy już teraz. Gdy migracja nastąpi, przepinamy podłączenie z SQL na OData. Sposób zadawania pytań przez kontrolera i kierowników zostaje ten sam.

Jedna techniczna przestroga, o której warto wiedzieć: w AX 2012 wymiary finansowe siedzą inaczej niż w D365. W AX 2009 był jeden ciąg znaków (dimension string), w AX 2012 to osobna tabela DimensionAttributeValueSet powiązana przez DimensionAttributeValueCombination. Przy pisaniu zapytań SQL bez uwzględnienia tej struktury wyniki sumowania per wymiar będą błędne. To błąd, który dość łatwo przeoczyć przy pierwszym podejściu.

Od czego zaczynamy wdrożenie

Pierwsza rozmowa: ustalamy, kto ma zadawać pytania i jakich odpowiedzi naprawdę potrzebuje. Kontroler pyta inaczej niż kierownik projektu, a dział AP inaczej niż zarząd. Nie ma sensu wyciągać wszystkich encji naraz. Lepiej zacząć od dwóch, trzech źródeł i budować na tym, co firma odpytuje każdego tygodnia.

Potem dostęp: razem z działem IT albo zewnętrznym dostawcą D365 tworzymy App Registration w AAD, przypisujemy minimalną rolę i testujemy pierwsze zapytania OData. Zazwyczaj jedno spotkanie z osobą zarządzającą środowiskiem D365 wystarczy, żeby wszystko zadziałało.

Następnie pierwsza warstwa odpowiedzi. Asystent dostaje strukturę encji, kilka przykładowych pytań i zaczyna odpowiadać na prawdziwych danych. Testujemy na produkcji z uprawnieniami tylko do odczytu, bo wyniki na danych testowych i na rzeczywistych transakcjach potrafią się różnić. Szczególnie gdy firma ma niestandardowe wymiary finansowe albo polską lokalizację D365 z własnymi encjami dla JPK_VAT.

Jeśli chcesz zobaczyć, jak to wygląda przy podobnych systemach ERP, sprawdź realne wdrożenia. Albo umów się na 15 minut rozmowy, żeby omówić specyfikę Twojego środowiska D365 albo AX 2012.