> Ciągłe doskonalenie procesów > Od zamówienia do płatności: obsługa zamówień sprzedaży > Microsoft Dynamics 365 > Szablon danych

Szablon danych do procesu obsługi zamówień sprzedaży, od zamówienia do płatności

Microsoft Dynamics 365

← Wróć do przewodnika ulepszania procesów

Atrybuty procesu obsługi zamówień sprzedaży, od zamówienia do płatności(20) Działania w procesie obsługi zamówień sprzedaży, od zamówienia do płatności(13) Instrukcje pobierania danych(2)

Szablon danych do procesu obsługi zamówień sprzedaży, od zamówienia do płatności

Ten szablon przedstawia uporządkowany zestaw danych potrzebnych do analizy procesu obsługi zamówień sprzedaży, od zamówienia do płatności, w Microsoft Dynamics 365. Zawiera listę atrybutów do zebrania i działań do śledzenia w dzienniku zdarzeń. Znajdą tu Państwo również praktyczne wskazówki dotyczące skutecznego pobierania tych danych z systemu.

Zalecane atrybuty do szczegółowej analizy
Najważniejsze działania w procesie do śledzenia
Wskazówki dotyczące pobierania danych z Microsoft Dynamics 365

Pierwszy raz spotykają się Państwo z dziennikiem zdarzeń? Dowiedz się jak utworzyć dziennik zdarzeń na potrzeby process mining.

Pobierz szablon

Atrybuty procesu obsługi zamówień sprzedaży, od zamówienia do płatności

Poniżej przedstawiono zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby szczegółowo analizować proces obsługi zamówień sprzedaży, od zamówienia do płatności, w Microsoft Dynamics 365.

5 Wymagane 5 Zalecane 10 Opcjonalne

	Nazwa	Opis
	Czynność ActivityName	Nazwa konkretnego zdarzenia biznesowego lub zadania, które wystąpiło w danym momencie procesu obsługi zamówienia sprzedaży.
Opis Ten atrybut oznacza odrębny etap lub zdarzenie w cyklu życia zamówienia sprzedaży, na przykład „Utworzono zamówienie sprzedaży”, „Wysłano towary” lub „Otrzymano płatność”. Kolejność tych czynności dla danego zamówienia tworzy przepływ procesu. Analiza kolejności i częstotliwości czynności oraz przejść między nimi stanowi podstawę process mining. Ułatwia wizualizację mapy procesu, wykrywanie częstych i rzadkich wariantów, wąskich gardeł oraz obszarów wymagających poprawek lub niezgodnych ze standardem. Atrybut ten pomaga zrozumieć, jak proces przebiega w praktyce. Dlaczego to ważne Atrybut określa etapy procesu, dzięki czemu można zbudować i zwizualizować jego przepływ. To główny cel process mining. Skąd pobrać Ten atrybut powstaje przez przypisanie konkretnym zdarzeniom systemowym lub zmianom statusu w tabelach takich jak „SalesTable” oraz powiązanych tabelach logistycznych i finansowych ustandaryzowanych nazw czynności. Przykłady Utworzono zamówienie sprzedażyWysłano towaryUtworzono fakturęOtrzymano płatność
	Godzina rozpoczęcia EventTime	Dokładna data i godzina wystąpienia konkretnej czynności lub zdarzenia.
Opis Czas zdarzenia, czyli timestamp, zapisuje dokładny moment wykonania czynności. Każda czynność w dzienniku zdarzeń ma przypisany timestamp, dzięki czemu dla każdego case powstaje chronologiczny zapis procesu. Ten atrybut jest niezbędny do wszystkich analiz czasowych w process mining. Służy do obliczania czasu między czynnościami i całkowitego czasu realizacji case, analizowania czasu oczekiwania oraz wykrywania wąskich gardeł powodujących opóźnienia. Umożliwia też monitorowanie efektywności w czasie, na przykład pomiar przepustowości w podziale na dni, tygodnie lub miesiące. Dlaczego to ważne Ten timestamp jest niezbędny do obliczania wskaźników opartych na czasie, takich jak czas realizacji i opóźnienia związane z wąskimi gardłami, a także do chronologicznego uporządkowania zdarzeń. Skąd pobrać Wartość pochodzi z różnych pól daty i godziny powiązanych z konkretnymi transakcjami, na przykład z pola „SalesTable.CreatedDateTime” przy utworzeniu zamówienia lub z daty księgowania dziennika płatności. Przykłady 2023-04-15T09:02:11Z2023-04-18T14:30:00Z2023-04-25T11:21:45Z
	Zamówienie sprzedaży SalesOrderNumber	Unikalny identyfikator każdego zamówienia sprzedaży, używany jako główny identyfikator case w procesie.
Opis Numer zamówienia sprzedaży to unikalny kod alfanumeryczny przypisany do każdego zamówienia klienta w Microsoft Dynamics 365. Pełni funkcję głównego identyfikatora case i łączy wszystkie powiązane czynności oraz zdarzenia, od utworzenia zamówienia do jego zamknięcia. W process mining ten atrybut jest niezbędny do odtworzenia pełnego przebiegu każdego zamówienia sprzedaży. Analitycy mogą prześledzić całą sekwencję czynności, zmierzyć czas realizacji case i analizować różnice między poszczególnymi zamówieniami. To podstawa analizy całego procesu. Dlaczego to ważne Ten identyfikator pozwala powiązać wszystkie dotyczące zamówienia zdarzenia i przeanalizować jego przebieg od początku do końca. Skąd pobrać Znajduje się w tabeli „SalesTable”, w polu „SalesId”. Przykłady SO-00102345SO-00102346SO-00102347
	Data ostatniej aktualizacji danych LastDataUpdate	Znacznik czasu wskazujący, kiedy dane zostały ostatnio odświeżone lub pobrane z systemu źródłowego.
Opis Ten atrybut zapisuje datę i godzinę ostatniego pobrania danych z Microsoft Dynamics 365. Dzięki niemu wiadomo, jak aktualne są analizowane dane. Przy analizie procesu aktualność danych ma znaczenie dla podejmowania świadomych decyzji. Znacznik czasu pokazuje, kiedy dane zostały ostatnio zaktualizowane, co ułatwia ocenę, czy wnioski opierają się na bieżących informacjach. Dlaczego to ważne Informuje o aktualności danych, która ma istotny wpływ na trafność i dokładność analizy process mining. Skąd pobrać Wartość jest generowana podczas ekstrakcji danych i dodawana do każdego rekordu w trakcie ich wczytywania. Przykłady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	System źródłowy SourceSystem	Wskazuje system informatyczny, z którego pochodzą dane.
Opis Ten atrybut wskazuje aplikację źródłową, w której zarejestrowano dane o zdarzeniach. W tym przypadku będzie to zazwyczaj „Microsoft Dynamics 365”. W analizie danych z jednego systemu może się wydawać zbędny. Jest jednak istotny przy łączeniu danych z kilku systemów, na przykład z osobnego CRM lub systemu zarządzania magazynem. Pozwala prześledzić pochodzenie danych i ułatwia diagnozowanie problemów z ich ekstrakcją, ponieważ wskazuje źródło poszczególnych rekordów. Dlaczego to ważne Dostarcza informacji o pochodzeniu danych. Jest to szczególnie ważne przy integracji danych z wielu systemów i pozwala prześledzić ich źródło. Skąd pobrać To stała wartość, zwykle dodawana podczas transformacji danych w celu oznaczenia źródła zbioru danych. Przykłady Microsoft Dynamics 365 F&OMicrosoft Dynamics 365 Sales
	Kanał sprzedaży SalesChannel	Kanał, którym wpłynęło zamówienie sprzedaży, na przykład internet, sprzedaż bezpośrednia lub partner.
Opis Kanał sprzedaży wskazuje, skąd pochodzi zamówienie klienta. Może to być sklep internetowy, zespół sprzedaży bezpośredniej, sklep stacjonarny, call center lub sieć partnerów. W Dynamics 365 wymiar ten jest zwykle konfigurowany zgodnie z potrzebami firmy. Analiza procesu według kanału sprzedaży pozwala porównać wyniki poszczególnych kanałów. Na przykład zamówienia internetowe mogą być realizowane szybciej i w większym stopniu automatycznie niż zamówienia przyjmowane telefonicznie. Takie informacje pomagają usprawniać procesy i przydzielać zasoby odpowiednio do kanału. Mogą też zasilać dashboardy, takie jak „Wartość zamówień sprzedaży według segmentu”. Dlaczego to ważne Umożliwia porównanie wyników różnych kanałów sprzedaży i wykrycie nieefektywności lub dobrych praktyk związanych ze sposobem składania zamówień. Skąd pobrać Informacje te są zwykle zapisane w nagłówku zamówienia sprzedaży. Nazwę konkretnego pola można sprawdzić w dokumentacji Microsoft Dynamics 365. Przykłady InternetSprzedaż bezpośredniaPartnerSprzedaż detaliczna
	Nazwa klienta CustomerName	Nazwa klienta, który złożył zamówienie sprzedaży.
Opis Ten atrybut zawiera oficjalną nazwę klienta powiązanego z zamówieniem sprzedaży. Jest pobierany przez połączenie numeru konta klienta z zamówienia z głównymi danymi klientów. Analiza procesu w podziale na klientów pomaga zrozumieć ich zachowania i poziom obsługi. Pozwala ustalić, którzy klienci najczęściej doświadczają opóźnień, mają najwięcej poprawek lub realizują zamówienia niestandardową ścieżką. Takie informacje pomagają poprawiać satysfakcję klientów i skuteczniej zarządzać kluczowymi klientami. Dlaczego to ważne Umożliwia analizę procesu z perspektywy klienta i wykrywanie charakterystycznych dla niego wzorców, opóźnień oraz problemów, które bezpośrednio wpływają na satysfakcję z obsługi. Skąd pobrać Wartość jest pobierana z tabeli „CustTable” na podstawie pola „CustAccount” z tabeli „SalesTable”. Przykłady Contoso LtdAdatum CorporationFabrikam Inc.
	Oczekiwana data dostawy RequestedDeliveryDate	Data dostawy zamówienia wskazana przez klienta.
Opis Ten atrybut przechowuje datę, w której klient początkowo oczekiwał dostawy towarów. Jest zapisywana podczas tworzenia zamówienia i stanowi punkt odniesienia do pomiaru terminowości dostaw z perspektywy klienta. Data ta jest ważnym elementem dashboardu „Terminowość dostaw”. Porównanie „RequestedDeliveryDate” z „ConfirmedDeliveryDate” i faktyczną datą działania „Dostarczono towary” pokazuje, w jakim stopniu firma spełnia oczekiwania klientów. Duże różnice mogą wskazywać na problemy z planowaniem, zapasami lub logistyką. Dlaczego to ważne Odzwierciedla oczekiwania klienta dotyczące dostawy i stanowi punkt odniesienia przy ocenie satysfakcji oraz terminowości dostaw. Skąd pobrać Wartość znajduje się w tabeli „SalesTable”, zwykle w polu „DeliveryDate” lub jego odpowiedniku. Przykłady 2023-05-102023-06-012023-05-25
	Potwierdzona data dostawy ConfirmedDeliveryDate	Data dostawy, którą firma potwierdziła klientowi i do której realizacji się zobowiązała.
Opis Potwierdzona data dostawy to termin, w którym firma zobowiązuje się dostarczyć klientowi towary. Jest ustalana po przeprowadzeniu wewnętrznych kontroli, na przykład sprawdzeniu dostępności zapasów i harmonogramów produkcji. Atrybut ten jest niezbędny do obliczenia KPI „Terminowość dostaw” z perspektywy zobowiązań operacyjnych. Stanowi bardziej realistyczny wewnętrzny punkt odniesienia niż pierwotny termin wskazany przez klienta. Analiza odchyleń od tej daty pomaga wykryć problemy wewnętrzne w logistyce i realizacji zamówień. Dlaczego to ważne Odzwierciedla zobowiązanie firmy wobec klienta i stanowi wewnętrzny punkt odniesienia przy ocenie niezawodności realizacji zamówień oraz wyników operacyjnych. Skąd pobrać Wartość znajduje się w danych pozycji zamówienia sprzedaży, często w tabeli „SalesLine”, w polu takim jak „ConfirmedDlv”. Przykłady 2023-05-122023-06-012023-05-28
	Wartość zamówienia OrderValue	Łączna wartość pieniężna zamówienia sprzedaży.
Opis Ten atrybut określa łączną wartość zamówienia sprzedaży, obejmującą wszystkie pozycje, podatki i opłaty. Jest to ważny wskaźnik finansowy przypisany do każdej sprawy. Wartość zamówienia pozwala analizować proces z uwzględnieniem wartości finansowej. Można sprawdzić, czy zamówienia o wysokiej wartości są obsługiwane inaczej lub częściej się opóźniają niż zamówienia o niższej wartości. Ułatwia to ustalanie priorytetów działań usprawniających i wskazuje sprawy o największym znaczeniu finansowym. Wspiera też dashboardy, takie jak „Wartość zamówień sprzedaży według segmentu”. Dlaczego to ważne Umożliwia podział procesu według wartości finansowej. Pomaga ustalać priorytety usprawnień dla zamówień o wysokiej wartości i oceniać koszty odstępstw od procesu. Skąd pobrać Wartość znajduje się w danych nagłówka zamówienia sprzedaży. Informacje o konkretnej tabeli i polu można znaleźć w dokumentacji Microsoft Dynamics 365. Wartość jest często obliczana na podstawie kwot z pozycji zamówienia. Przykłady 5250.7512300.00899.50
	Czas zakończenia EndTime	Dokładna data i godzina zakończenia działania.
Opis Znacznik czasu End Time wskazuje moment zakończenia działania. Jeśli jest dostępny, pozwala dokładniej zmierzyć czas trwania działania niż szacowanie go na podstawie czasu rozpoczęcia kolejnego działania. Dostęp do czasu rozpoczęcia i zakończenia umożliwia precyzyjne obliczenie „czasu przetwarzania” każdego działania i odróżnienie go od „czasu oczekiwania” między działaniami. Dzięki temu można ustalić, które zadania zajmują najwięcej czasu, a które etapy procesu wiążą się z długimi przestojami. Dlaczego to ważne Umożliwia precyzyjne obliczenie czasu przetwarzania poszczególnych działań i odróżnienie aktywnej pracy od oczekiwania. Skąd pobrać Podobnie jak Start Time, wartość ta pochodzi z różnych pól daty i godziny. Może to być pole „ModifiedDateTime” lub znacznik czasu konkretnej zmiany statusu w tabelach takich jak „SalesTable” lub „WHSLoadTable”. Przykłady 2023-04-15T09:12:30Z2023-04-18T14:35:00Z2023-04-25T11:21:55Z
	Czy wystąpiły poprawki IsRework	Wartość logiczna wskazująca, czy w zamówieniu sprzedaży wystąpiły poprawki, na przykład powtórzenie działania.
Opis Ten obliczany atrybut wskazuje sprawy, których przebieg odbiega od bezpośredniej, standardowej ścieżki procesu. Poprawki są wykrywane na podstawie sekwencji działań wskazujących na powtórzenie etapu. Może to być na przykład cofnięcie potwierdzenia zamówienia i jego ponowne potwierdzenie albo pobranie towarów z magazynu, a następnie zwrócenie ich na stan. Oznaczenie spraw wymagających poprawek jest niezbędne do obliczenia KPI „Odsetek zamówień wymagających poprawek”. Analitycy mogą szybko wyodrębnić i zbadać nieefektywne przebiegi procesu oraz ustalić przyczyny poprawek, takie jak błędy przy wprowadzaniu danych, problemy kredytowe lub braki w zapasach. Ograniczenie liczby poprawek jest częstym celem projektów usprawniających procesy. Dlaczego to ważne Pomaga mierzyć nieefektywność procesu przez oznaczanie spraw, w których trzeba było powtarzać etapy. Umożliwia ukierunkowaną analizę, która pozwala ograniczyć straty i opóźnienia. Skąd pobrać Wartość oblicza narzędzie process mining na podstawie sekwencji działań w każdej sprawie. Na przykład wykrycie sekwencji (A -> B -> C -> B) oznacza sprawę jako wymagającą poprawek. Przykłady truefalse
	Dostawa na czas OnTimeDelivery	Wartość logiczna wskazująca, czy towary dostarczono w potwierdzonym terminie lub wcześniej.
Opis Ten obliczany atrybut porównuje znacznik czasu działania „Dostarczono towary” z wartością „ConfirmedDeliveryDate” dla każdego zamówienia sprzedaży. Przyjmuje wartość „true”, jeśli dostawa nastąpiła w terminie lub wcześniej, i „false”, jeśli była opóźniona. Atrybut ten stanowi podstawę obliczenia KPI „Terminowość dostaw”. Ułatwia analizę, ponieważ pozwala filtrować i agregować zamówienia dostarczone na czas oraz z opóźnieniem. Dzięki temu można szybko wykryć czynniki powiązane z opóźnieniami, takie jak konkretne produkty, klienci, regiony lub sposoby wysyłki. Dlaczego to ważne Bezpośrednio mierzy wyniki realizacji zamówień w odniesieniu do zobowiązań firmy. Ma to znaczenie przy monitorowaniu satysfakcji klientów i niezawodności łańcucha dostaw. Skąd pobrać Wartość jest obliczana przez porównanie „EventTime” działania „Dostarczono towary” z atrybutem „ConfirmedDeliveryDate”. Formuła: (znacznik czasu działania „Dostarczono towary” <= ConfirmedDeliveryDate). Przykłady truefalse
	Kraj CountryRegion	Kraj adresu dostawy klienta.
Opis Ten atrybut wskazuje kraj docelowy wysyłki zamówienia sprzedaży. Jest pobierany z danych adresu dostawy klienta zapisanych w Dynamics 365. Analiza wyników procesu według kraju pomaga wykrywać różnice regionalne. Wysyłki międzynarodowe mogą wymagać dodatkowych etapów, takich jak odprawa celna, co wydłuża czas realizacji. Analiza ułatwia zrozumienie i usprawnianie logistyki na różnych rynkach geograficznych. Dlaczego to ważne Umożliwia analizę geograficzną i pomaga wykrywać regionalne wąskie gardła, problemy ze zgodnością oraz różnice w wynikach łańcucha dostaw. Skąd pobrać Wartość pochodzi z adresu dostawy klienta powiązanego z zamówieniem sprzedaży. Informacje o kraju znajdują się zwykle w tabeli „LogisticsPostalAddress”, połączonej z tabelą „SalesTable” przez odwołanie do adresu dostawy. Przykłady USADEUCANGBR
	Nazwa użytkownika UserName	Nazwa użytkownika, który wykonał działanie.
Opis Ten atrybut wskazuje pracownika lub użytkownika systemu odpowiedzialnego za wykonanie danego zadania, na przykład potwierdzenie zamówienia lub utworzenie faktury. Zazwyczaj jest powiązany z identyfikatorem użytkownika w Microsoft Dynamics 365. Analiza wyników pracy poszczególnych użytkowników pomaga określić potrzeby szkoleniowe, docenić osoby osiągające dobre wyniki i właściwie rozdzielić obciążenie pracą. Jest też niezbędna do zapewnienia zgodności i przeprowadzania audytów, ponieważ pozwala ustalić, kto odpowiada za każde działanie w procesie. Dlaczego to ważne Umożliwia analizę wyników procesu w podziale na osoby lub zespoły. Pomaga wykryć potrzeby szkoleniowe, nierównomierne obciążenie pracą i wąskie gardła związane z zasobami. Skąd pobrać Wartość pochodzi z pól identyfikatora użytkownika, takich jak „CreatedBy” lub „ModifiedBy”, w różnych tabelach transakcyjnych. Następnie dane są łączone z główną tabelą użytkowników, na przykład „UserInfo”, aby pobrać pełne imię i nazwisko. Przykłady Alice JohnsonRobert BrownAdministrator systemu
	Numer produktu ItemNumber	Unikalny identyfikator produktu lub usługi w zamówieniu sprzedaży.
Opis Numer produktu wskazuje konkretny sprzedawany produkt. Ponieważ zamówienie sprzedaży może obejmować wiele produktów, atrybut ten jest zwykle przypisany do danych zdarzeń na poziomie pozycji zamówienia. Analiza procesu według produktu pomaga wykrywać problemy dotyczące konkretnych produktów. Niektóre z nich mogą na przykład wiązać się z dłuższym czasem realizacji, częstszymi poprawkami lub częstszym blokowaniem kredytowym. Pozwala to wprowadzać ukierunkowane usprawnienia w zarządzaniu zapasami, konfiguracji danych produktów lub realizacji zamówień na wybrane pozycje. Dlaczego to ważne Umożliwia analizę na poziomie produktu i pokazuje, czy określone pozycje wiążą się z opóźnieniami, poprawkami lub innymi nieefektywnościami procesu. Skąd pobrać Wartość znajduje się w tabeli „SalesLine”, w polu „ItemId”. Przykłady PROD-00123PROD-00548SVC-00045
	Płatność w terminie OnTimePayment	Wartość logiczna wskazująca, czy płatność wpłynęła w terminie lub wcześniej.
Opis Ten obliczany atrybut porównuje znacznik czasu działania „Otrzymano płatność” z wartością „PaymentDueDate”. Przyjmuje wartość „true”, jeśli płatność wpłynęła w terminie, i „false”, jeśli była opóźniona. Atrybut ten stanowi podstawę KPI „Odsetek płatności terminowych”. Ułatwia podział klientów na płacących w terminie i z opóźnieniem. Wyniki analizy mogą pomóc w ustalaniu zasad kredytowych, strategii windykacji i sposobu zarządzania relacjami z klientami, ponieważ wskazują klientów regularnie spóźniających się z płatnościami. Dlaczego to ważne Mierzy, czy klienci regulują płatności zgodnie z uzgodnionymi warunkami. Ma to podstawowe znaczenie dla zarządzania przepływami pieniężnymi i oceny ryzyka kredytowego. Skąd pobrać Wartość jest obliczana przez porównanie „EventTime” działania „Otrzymano płatność” z atrybutem „PaymentDueDate”. Formuła: (znacznik czasu działania „Otrzymano płatność” <= PaymentDueDate). Przykłady truefalse
	Sposób wysyłki ShippingMethod	Sposób transportu lub przewoźnik, którym towary są dostarczane klientowi.
Opis Ten atrybut określa usługę transportową wykorzystywaną do dostawy, na przykład „transport drogowy”, „transport lotniczy” lub nazwę konkretnego przewoźnika. Jest wybierany podczas obsługi zamówienia z uwzględnieniem preferencji klienta, kosztów i czasu dostawy. Wymiar ten jest niezbędny w dashboardzie „Wyniki według sposobu wysyłki”. Analiza czasu realizacji od działania „Spakowano towary” do „Dostarczono towary” w podziale na sposób wysyłki pomaga ustalić, którzy przewoźnicy dostarczają szybciej i bardziej niezawodnie, a którzy częściej powodują opóźnienia. Ułatwia to planowanie logistyki i wybór przewoźników. Dlaczego to ważne Umożliwia porównanie wyników przewoźników i opcji wysyłki, co pomaga optymalizować logistykę pod kątem kosztów, szybkości i niezawodności. Skąd pobrać Informacje te są zwykle zapisane w nagłówku zamówienia sprzedaży lub powiązanych rekordach realizacji. Szczegóły można znaleźć w dokumentacji Microsoft Dynamics 365. Przykłady FedEx GroundUPS Next Day AirDHL Express
	Status zamówienia sprzedaży SalesOrderStatus	Bieżący status zamówienia sprzedaży w chwili ekstrakcji danych.
Opis Ten atrybut odzwierciedla ogólny status zamówienia sprzedaży, na przykład „Otwarte”, „Zafakturowane”, „Anulowane” lub „Dostarczone”. Jest to zbiorczy status zapisany w nagłówku zamówienia. Dziennik działań pokazuje przebieg procesu, natomiast status końcowy ułatwia filtrowanie i segmentację danych. Analitycy mogą szybko wyodrębnić wszystkie otwarte zamówienia, aby sprawdzić bieżące obciążenie pracą, albo oddzielić zamówienia zrealizowane od anulowanych i przeanalizować przyczyny anulowania. Dlaczego to ważne Pokazuje bieżący stan zamówienia i pozwala filtrować analizę według zamówień otwartych, zamkniętych lub anulowanych. Ułatwia to zarządzanie obciążeniem pracą i analizę wyników. Skąd pobrać Wartość znajduje się w tabeli „SalesTable”, w polu „SalesStatus”. Przykłady Zaległe zamówienieDostarczoneZafakturowaneAnulowane
	Termin płatności PaymentDueDate	Data, do której klient powinien opłacić fakturę.
Opis Termin płatności jest obliczany na podstawie daty faktury i uzgodnionych z klientem warunków płatności. Jest zapisywany na fakturze sprzedaży. Atrybut ten jest podstawą analizy „Zgodność z terminem płatności” oraz KPI „Odsetek płatności terminowych”. Porównanie „PaymentDueDate” z faktyczną datą działania „Otrzymano płatność” pozwala wykrywać opóźnienia, analizować zachowania płatnicze poszczególnych segmentów klientów i podejmować działania poprawiające przepływy pieniężne oraz skracające okres spływu należności (DSO). Dlaczego to ważne Stanowi punkt odniesienia przy ocenie terminowości płatności, co ma znaczenie dla analizy przepływów pieniężnych i skutecznego zarządzania należnościami. Skąd pobrać Wartość znajduje się w tabeli „CustInvoiceJour”, w polu „DueDate”. Przykłady 2023-05-302023-06-152023-06-30

Wymagane Zalecane Opcjonalne

Działania w procesie obsługi zamówień sprzedaży, od zamówienia do płatności

Poniżej przedstawiono najważniejsze etapy procesu i punkty kontrolne, które należy uwzględnić w dzienniku zdarzeń, aby prawidłowo odkrywać i analizować przebieg obsługi zamówień sprzedaży.

6 Zalecane 7 Opcjonalne

	Działanie	Opis
	Otrzymano płatność	Ta czynność oznacza otrzymanie i rozliczenie płatności klienta za fakturę. Zdarzenie występuje w module Accounts Receivable i jest powiązane z fakturą źródłową.
Dlaczego to ważne To ważny etap analizy cyklu konwersji gotówki. Jest niezbędny do pomiaru KPI „Odsetek płatności na czas” i wykrywania opóźnień w pobieraniu należności. Skąd pobrać To jawnie rejestrowane zdarzenie w module Accounts Receivable. Jest pobierane z daty transakcji rozliczenia płatności klienta (CustSettlement), która zamyka transakcję faktury (CustTrans). Rejestrowanie Pobierz datę rozliczenia z tabeli CustSettlement i powiąż ją z fakturą oraz zamówieniem sprzedaży. Typ zdarzenia explicit
	Potwierdzono zamówienie	Ta czynność oznacza formalne potwierdzenie zamówienia sprzedaży i zobowiązanie do dostarczenia określonych towarów lub usług. W Dynamics 365 jest to jawne działanie użytkownika, które generuje dziennik potwierdzenia.
Dlaczego to ważne Potwierdzenie to ważny etap, który oficjalnie rozpoczyna realizację zamówienia. Pomiar czasu od utworzenia do potwierdzenia pokazuje efektywność obsługi po stronie sprzedaży. Skąd pobrać To jawnie rejestrowane zdarzenie, którego źródłem jest data księgowania dziennika potwierdzenia zamówienia sprzedaży (SalesConfirmJour). Timestamp można powiązać z tabelą SalesTable. Rejestrowanie Zarejestruj timestamp księgowania dziennika potwierdzenia zamówienia sprzedaży. Typ zdarzenia explicit
	Utworzono fakturę	Oznacza wystawienie i zaksięgowanie faktury sprzedaży za wysłane towary lub usługi. Jest to podstawowa transakcja finansowa, która formalnie rejestruje należność od klienta.
Dlaczego to ważne Ta czynność rozpoczyna finansową część procesu. Czas od wysyłki do wystawienia faktury ma zasadnicze znaczenie dla KPI „Czas wystawienia faktury” i wpływa na przepływy pieniężne. Skąd pobrać To jawnie rejestrowana transakcja finansowa. Zdarzenie jest pobierane z daty i godziny księgowania dziennika faktury sprzedaży (CustInvoiceJour). Rejestrowanie Zarejestruj timestamp księgowania dziennika faktury sprzedaży. Typ zdarzenia explicit
	Utworzono zamówienie sprzedaży	To zdarzenie oznacza utworzenie zamówienia sprzedaży w systemie przez przedstawiciela handlowego lub za pośrednictwem kanału automatycznego. Jest rejestrowane w chwili utworzenia i zapisania nowego rekordu w głównej tabeli zamówień sprzedaży.
Dlaczego to ważne Ta czynność rozpoczyna każdy przypadek obsługi zamówienia sprzedaży. Dostarcza początkowy timestamp potrzebny do obliczenia całkowitego czasu realizacji zamówienia i analizy przepustowości. Skąd pobrać To jawnie rejestrowane zdarzenie, którego źródłem jest pole „Created date and time” w nagłówku rekordu SalesTable w Microsoft Dynamics 365. Rejestrowanie Odczytaj timestamp utworzenia z encji SalesTable. Typ zdarzenia explicit
	Wysłano towary	To zdarzenie oznacza, że spakowane towary zostały wysłane i opuściły magazyn. W Dynamics 365 jest formalnie rejestrowane przez zaksięgowanie dokumentu wydania.
Dlaczego to ważne To ważny etap, który oznacza koniec wewnętrznej realizacji zamówienia i początek dostawy. Timestamp tego zdarzenia służy do obliczania terminowości wysyłek. Skąd pobrać To jednoznaczne i jawnie rejestrowane zdarzenie, którego źródłem jest data i godzina księgowania dziennika dokumentu wydania (CustPackingSlipJour). Rejestrowanie Zarejestruj timestamp księgowania dziennika dokumentu wydania. Typ zdarzenia explicit
	Zamknięto zamówienie	Końcowy status prawidłowo obsłużonego zamówienia sprzedaży. Oznacza, że zamówienie zostało w całości wysłane i zafakturowane oraz nie są oczekiwane dalsze transakcje. Potwierdza zakończenie procesu.
Dlaczego to ważne Ta czynność jest głównym punktem końcowym prawidłowo zrealizowanych przypadków. Jest niezbędna do obliczania całkowitego czasu realizacji i przepustowości. Skąd pobrać Zdarzenie jest wnioskowane na podstawie pól statusu w tabeli SalesTable. Zamówienie uznaje się za zamknięte, gdy status sprzedaży ma wartość „Invoiced”, a statusy pozycji również mają wartość „Invoiced”. Rejestrowanie Wnioskuj na podstawie zmiany pól statusu w tabeli SalesTable na „Invoiced”. Timestampem jest zwykle data ostatniej powiązanej transakcji, na przykład fakturowania lub płatności. Typ zdarzenia inferred
	Anulowano zamówienie	To zdarzenie oznacza anulowanie zamówienia sprzedaży przed jego pełną wysyłką i zafakturowaniem. Jest alternatywnym, niepomyślnym zakończeniem procesu.
Dlaczego to ważne Śledzenie anulowań pomaga ustalić przyczyny utraty sprzedaży lub niepowodzeń procesu. Analiza tego, kiedy i dlaczego zamówienia są anulowane, może prowadzić do usprawnień. Skąd pobrać Zdarzenie jest wnioskowane na podstawie zmiany pola „Sales status” w tabeli SalesTable na „Canceled”. Timestampem jest moment zarejestrowania tej zmiany statusu. Rejestrowanie Wnioskuj na podstawie zmiany pola statusu w tabeli SalesTable na „Canceled”. Typ zdarzenia inferred
	Dostarczono towary	Oznacza dostarczenie przesyłki pod wskazany przez klienta adres. Informacje te są często aktualizowane na podstawie danych z systemu zewnętrznego przewoźnika lub ręcznego potwierdzenia.
Dlaczego to ważne Ta czynność jest niezbędna do pomiaru KPI „Terminowość dostaw” i ustalenia rzeczywistego czasu realizacji z perspektywy klienta. Pomaga również ocenić pracę przewoźnika. Skąd pobrać W standardowym D365 zdarzenie to nie jest rejestrowane natywnie. Zwykle wnioskuje się o nim na podstawie aktualizacji z integracji z przewoźnikiem lub ręcznej zmiany statusu zamówienia sprzedaży albo przesyłki. Rejestrowanie Wnioskuj na podstawie danych zintegrowanego systemu przewoźnika lub ręcznej zmiany pola statusu. Typ zdarzenia inferred
	Przekazano do magazynu	Oznacza moment formalnego przekazania zamówienia sprzedaży do magazynu w celu kompletacji i wysyłki. Jest to odrębny etap w środowiskach korzystających z modułu Warehouse Management (WMS).
Dlaczego to ważne Ta czynność oddziela obsługę zamówienia od jego fizycznej realizacji. Analiza czasu oczekiwania na przekazanie do magazynu może ujawnić problemy z planowaniem zasobów lub integracją systemów. Skąd pobrać To jawnie rejestrowane zdarzenie, którego źródłem są rekordy przekazania do magazynu (WHSLoadTable, WHSShipmentTable) powiązane z zamówieniem sprzedaży. Rejestrowanie Zarejestruj timestamp utworzenia powiązanego ładunku lub wysyłki magazynowej. Typ zdarzenia explicit
	Przeprowadzono weryfikację zdolności kredytowej	Oznacza zakończenie weryfikacji zdolności kredytowej klienta powiązanego z zamówieniem sprzedaży. Może to być automatyczna kontrola systemowa lub ręczna weryfikacja, która często zmienia status kredytowy zamówienia.
Dlaczego to ważne Analiza czasu trwania i wyników weryfikacji zdolności kredytowej pomaga wykryć wąskie gardła w procesie zatwierdzania zamówień. Częste blokady lub długi czas zatwierdzania mogą znacznie opóźnić realizację zamówienia. Skąd pobrać Zdarzenie jest zwykle wnioskowane na podstawie zmian statusu związanych z zarządzaniem kredytowym w tabeli SalesTable, na przykład zmiany statusu z „On hold” z podanym powodem blokady kredytowej na „Open”. Jeśli używany jest zaawansowany moduł, zdarzenie może być również rejestrowane w tabelach zarządzania kredytowego. Rejestrowanie Wnioskuj na podstawie historii zmian statusu w tabeli SalesTable lub powiązanych tabel blokad kredytowych. Typ zdarzenia inferred
	Skompletowano towary	Oznacza zakończenie fizycznej kompletacji wszystkich pozycji zamówienia z lokalizacji magazynowych. Zdarzenie jest zwykle rejestrowane po zatwierdzeniu przez pracownika listy kompletacyjnej lub zlecenia pracy w module WMS.
Dlaczego to ważne Śledzenie czasu zakończenia kompletacji jest niezbędne do analizy efektywności magazynu. Opóźnienia na tym etapie bezpośrednio wydłużają czas do wysyłki. Skąd pobrać To jawnie rejestrowane zdarzenie w module Warehouse Management. Jest pobierane z timestampu zakończenia pracy magazynowej (WHSWorkTable) związanej z kompletacją zamówienia sprzedaży. Rejestrowanie Zarejestruj timestamp zmiany statusu pracy kompletacyjnej z „Work” na „Closed”. Typ zdarzenia explicit
	Spakowano towary	Ta czynność oznacza zakończenie pakowania, podczas którego skompletowane towary są łączone i przygotowywane do wysyłki. W D365 może zbiegać się z wygenerowaniem dokumentu wydania.
Dlaczego to ważne Czas między kompletacją a pakowaniem może ujawnić wąskie gardła na stanowiskach pakowania. To ważny etap całkowitego czasu realizacji zamówienia. Skąd pobrać Zdarzenie może być jawnie rejestrowane po zakończeniu pakowania kontenera w module WMS lub wnioskowane na podstawie wygenerowania dziennika dokumentu wydania (CustPackingSlipJour), które często oznacza koniec pakowania. Rejestrowanie Wnioskuj na podstawie zakończenia pracy związanej z pakowaniem lub daty utworzenia dziennika dokumentu wydania. Typ zdarzenia inferred
	Zarezerwowano zapasy	To zdarzenie oznacza fizyczną lub automatyczną rezerwację w systemie zapasów wymaganych dla pozycji zamówienia sprzedaży. Dzięki temu towary są dostępne do kompletacji i realizacji zamówienia.
Dlaczego to ważne Śledzenie rezerwacji zapasów pomaga analizować opóźnienia między potwierdzeniem zamówienia a rozpoczęciem pracy magazynu. Jest niezbędne do obliczenia KPI „Czas do przydzielenia zapasów”. Skąd pobrać Zdarzenie można wywnioskować z utworzenia lub aktualizacji rekordów transakcji magazynowych (InventTrans) powiązanych z pozycjami zamówienia sprzedaży, jeśli ich status wskazuje na rezerwację, na przykład „On order” lub „Reserved physical”. Rejestrowanie Wnioskuj na podstawie timestampu oznaczenia transakcji magazynowych (InventTrans) dla zamówienia jako zarezerwowanych. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje pobierania danych

Jak pobrać dane z Microsoft Dynamics 365

Kroki

Skonfiguruj eksport do Azure Data Lake: W środowisku Dynamics 365 Finance and Operations upewnij się, że dodatek „Export to Azure Data Lake” jest zainstalowany i skonfigurowany. Wymaga to połączenia D365 z subskrypcją Azure i docelowym kontem Azure Data Lake Storage Gen2.
Wybierz tabele do eksportu: Otwórz obszar roboczy „Export to Data Lake” w Dynamics 365. Wyszukaj i dodaj do konfiguracji eksportu następujące tabele: SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable i CustTable. Włącz eksport wszystkich wybranych tabel.
Skonfiguruj Azure Synapse Analytics: W portalu Azure utwórz obszar roboczy Azure Synapse Analytics. Nadaj mu wymagane uprawnienia, na przykład „Storage Blob Data Contributor”, do konta Data Lake, w którym przechowywane są dane D365.
Utwórz bezserwerową bazę danych SQL: W Synapse Studio otwórz centrum „Data”. Utwórz bezserwerową bazę danych SQL, która umożliwi wykonywanie zapytań T-SQL na danych w Data Lake.
Utwórz widoki dla tabel D365: Aby uprościć zapytania, utwórz w bezserwerowej bazie danych widoki SQL wskazujące na zreplikowane dane tabel D365 w Data Lake. Dzięki temu nie trzeba odwoływać się bezpośrednio do ścieżek i formatów plików. Przykład: CREATE VIEW dbo.SalesTable AS SELECT * FROM OPENROWSET(BULK 'path/to/salestable', FORMAT='CSV', ...).
Przygotuj zapytanie SQL: Otwórz nowy skrypt SQL w Synapse Studio i połącz się z bezserwerową bazą danych. Skopiuj do edytora pełne zapytanie SQL z tej dokumentacji.
Dostosuj parametry zapytania: Znajdź symbole zastępcze na początku zapytania. Zastąp '{YourDataAreaId}' kodem firmy, którą chcą Państwo analizować. Ustaw wartości '{StartDate}' i '{EndDate}', aby określić zakres dat pobierania danych.
Uruchom zapytanie: Wykonaj cały skrypt SQL. Zapytanie pobierze zdarzenia z różnych tabel i połączy je w jeden ujednolicony dziennik zdarzeń.
Sprawdź i wyeksportuj wyniki: Po zakończeniu zapytania sprawdź wyniki w panelu Synapse Studio, aby upewnić się, że są kompletne i prawidłowo sformatowane. Użyj wbudowanej funkcji eksportu, aby zapisać je jako plik CSV.
Przygotuj plik do przesłania: Otwórz wyeksportowany plik CSV i sprawdź, czy jest zakodowany w UTF-8. Upewnij się, że nagłówki kolumn dokładnie odpowiadają wymaganym atrybutom, na przykład SalesOrderNumber, ActivityName, EventTime itd.
Prześlij dane do ProcessMind: Prześlij końcowy, sprawdzony plik CSV do projektu ProcessMind, aby rozpocząć analizę i wizualizację.

Konfiguracja

Wymagania wstępne: Ta metoda wymaga aktywnej subskrypcji Azure oraz skonfigurowanego dodatku „Export to Azure Data Lake” w środowisku Dynamics 365 F&O. Potrzebne są odpowiednie uprawnienia zarówno w Azure (do zarządzania Synapse i Storage), jak i w D365 (do konfigurowania eksportu danych).
Wymagane moduły D365: Pełne rejestrowanie zdarzeń, zwłaszcza dotyczących operacji magazynowych, wymaga modułu Warehouse Management (WMS). Podstawowe zdarzenia pochodzą z modułów Sales and Marketing oraz Accounts Receivable.
Wybór tabel: Należy włączyć eksport wszystkich tabel używanych w zapytaniu, w tym SalesTable, SalesLine, CustConfirmJour, CustPackingSlipJour, CustInvoiceJour, CustTrans, WHSLoadTable, WHSWorkTable i CustTable. Brak tabeli oznacza brak powiązanych z nią działań.
Filtrowanie według zakresu dat: Zapytanie umożliwia filtrowanie według zakresu dat za pomocą parametrów {StartDate} i {EndDate}. Przy pierwszym pobieraniu danych zaleca się ograniczony zakres, na przykład 3–6 miesięcy, aby czas wykonania zapytania był możliwy do opanowania.
Filtrowanie według firmy (DataAreaId): Symbol zastępczy '{YourDataAreaId}' należy ustawić na konkretną jednostkę prawną w środowisku D365. Zapytanie nie obsługuje analizy wielu firm w jednym uruchomieniu.
Wydajność: W przypadku bardzo dużych zbiorów danych wydajność zapytań w bezserwerowej puli SQL może się różnić. Warto zaplanować pobieranie danych na godziny mniejszego obciążenia systemu. Przy częstym pobieraniu można zapisać końcowy dziennik zdarzeń jako nową tabelę w Data Lake, aby przyspieszyć dalsze przetwarzanie.

Przykładowe zapytanie sql

WITH SalesOrderBase AS (
    SELECT
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME AS CustomerName,
        ST.SHIPPINGDATECONFIRMED AS ConfirmedDeliveryDate,
        ST.DELIVERYDATE AS RequestedDeliveryDate,
        ST.PURCHORDERFORMNUM AS SalesChannel, -- Example mapping, adjust if you use a different field for Sales Channel
        SUM(SL.LINEAMOUNT) AS OrderValue
    FROM dbo.SALESTABLE ST
    LEFT JOIN dbo.SALESLINE SL ON ST.SALESID = SL.SALESID AND ST.DATAREAID = SL.DATAREAID
    LEFT JOIN dbo.CUSTTABLE CT ON ST.CUSTACCOUNT = CT.ACCOUNTNUM AND ST.DATAREAID = CT.DATAREAID
    WHERE ST.DATAREAID = '{YourDataAreaId}'
      AND ST.CREATEDDATETIME >= '{StartDate}' AND ST.CREATEDDATETIME < '{EndDate}'
    GROUP BY
        ST.SALESID,
        ST.DATAREAID,
        CT.NAME,
        ST.SHIPPINGDATECONFIRMED,
        ST.DELIVERYDATE,
        ST.PURCHORDERFORMNUM
)
-- 1. Sales Order Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Sales Order Created' AS ActivityName,
    ST.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID

UNION ALL

-- 2. Credit Check Performed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Credit Check Performed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime, -- This assumes a status change date reflects the credit check time
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.CREDITLIMITTYPE > 0 -- Example condition for a credit check being done. Adjust based on your configuration.

UNION ALL

-- 3. Order Confirmed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Confirmed' AS ActivityName,
    CJ.CONFIRMDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTCONFIRMJOUR CJ ON SO.SALESID = CJ.SALESID AND SO.DATAREAID = CJ.DATAAREAID

UNION ALL

-- 4. Inventory Reserved (approximated by first line item reservation)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Inventory Reserved' AS ActivityName,
    MIN(SL.CREATEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESLINE SL ON SO.SALESID = SL.SALESID AND SO.DATAREAID = SL.DATAREAID
WHERE SL.RESERVATION > 0 -- Identifies lines with a reservation status
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 5. Released To Warehouse
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Released To Warehouse' AS ActivityName,
    WLT.CREATEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSLOADTABLE WLT ON SO.SALESID = WLT.SALESID AND SO.DATAREAID = WLT.DATAAREAID

UNION ALL

-- 6. Goods Picked (approximated by last pick work closure)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Picked' AS ActivityName,
    MAX(WWT.MODIFIEDDATETIME) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.WHSWORKTABLE WWT ON SO.SALESID = WWT.ORDERNUM AND SO.DATAREAID = WWT.DATAAREAID
WHERE WWT.WORKTYPE = 'Pick' AND WWT.WORKSTATUS = 'Closed'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 7. Goods Packed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Packed' AS ActivityName,
    PSJ.CREATEDDATETIME AS EventTime, -- Using creation time of packing slip as proxy
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 8. Goods Shipped
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Shipped' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID

UNION ALL

-- 9. Goods Delivered (placeholder, often requires custom fields)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Goods Delivered' AS ActivityName,
    PSJ.DELIVERYDATE AS EventTime, -- Placeholder, using shipment date. True delivery requires external data.
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTPACKINGSLIPJOUR PSJ ON SO.SALESID = PSJ.SALESID AND SO.DATAREAID = PSJ.DATAAREAID
WHERE 1 = 2 -- This will return no rows unless logic is added to read from a custom field with actual delivery dates

UNION ALL

-- 10. Invoice Created
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Invoice Created' AS ActivityName,
    CIJ.INVOICEDATE AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID

UNION ALL

-- 11. Payment Received (approximated by last settlement date)
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Payment Received' AS ActivityName,
    MAX(CT.SETTLEMENTDATE) AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.CUSTINVOICEJOUR CIJ ON SO.SALESID = CIJ.SALESID AND SO.DATAREAID = CIJ.DATAAREAID
JOIN dbo.CUSTTRANS CT ON CIJ.INVOICEID = CT.INVOICE AND CIJ.DATAAREAID = CT.DATAAREAID
WHERE CT.TRANSTYPE = 'Payment'
GROUP BY SO.SALESID, SO.OrderValue, SO.CustomerName, SO.SalesChannel, SO.RequestedDeliveryDate, SO.ConfirmedDeliveryDate

UNION ALL

-- 12. Order Closed
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Closed' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 4 -- Status for 'Invoiced'

UNION ALL

-- 13. Order Cancelled
SELECT
    SO.SALESID AS SalesOrderNumber,
    'Order Cancelled' AS ActivityName,
    ST.MODIFIEDDATETIME AS EventTime,
    'Dynamics 365' AS SourceSystem,
    GETUTCDATE() AS LastDataUpdate,
    SO.OrderValue,
    SO.CustomerName,
    SO.SalesChannel,
    SO.RequestedDeliveryDate,
    SO.ConfirmedDeliveryDate
FROM SalesOrderBase SO
JOIN dbo.SALESTABLE ST ON SO.SALESID = ST.SALESID AND SO.DATAREAID = ST.DATAREAID
WHERE ST.SALESSTATUS = 3; -- Status for 'Canceled'

Kroki

Wymagania wstępne i konfiguracja: Upewnij się, że zainstalowano Python 3.6 lub nowszy. Zainstaluj wymagane biblioteki Python, uruchamiając w terminalu polecenie: pip install pandas requests msal.
Zarejestruj aplikację w Azure AD: Otwórz portal Azure i zarejestruj nową aplikację w Azure Active Directory. Aplikacja będzie służyć do uwierzytelniania w Dynamics 365 API. Zapisz identyfikator aplikacji (client ID) i identyfikator katalogu (tenant ID).
Utwórz klucz tajny klienta: W nowo zarejestrowanej aplikacji Azure AD utwórz klucz tajny klienta w sekcji „Certificates & secrets”. Od razu skopiuj jego wartość, ponieważ później nie będzie już widoczna. To jest CLIENT_SECRET.
Nadaj uprawnienia do API: W ustawieniach aplikacji Azure AD otwórz „API permissions”. Dodaj uprawnienie „Dynamics ERP” lub „Dynamics 365 for Finance and Operations”. Wybierz „Delegated permissions” i nadaj uprawnienie user_impersonation. Następnie dodaj to samo uprawnienie ponownie, tym razem wybierając „Application permissions”, i nadaj Financials.ReadWrite.All lub, jeśli jest dostępne i wystarczające, bardziej ograniczone uprawnienie tylko do odczytu. Zatwierdź te uprawnienia jako administrator.
Utwórz użytkownika aplikacji w Dynamics 365: W środowisku Dynamics 365 otwórz „System administration” > „Users” > „Users”. Utwórz użytkownika i powiąż go z identyfikatorem aplikacji zarejestrowanej w Azure AD. Przypisz mu rolę zabezpieczeń, na przykład „System administrator” (pełny dostęp) lub rolę niestandardową z prawem odczytu wymaganych encji danych (SalesOrderHeadersV2, SalesOrderLines, SalesPackingSlipHeaders, SalesInvoiceHeadersV2 itd.).
Skonfiguruj skrypt Python: Otwórz dostarczony skrypt Python w edytorze. W sekcji konfiguracji na początku pliku zastąp wartości zastępcze dla D365_URL, TENANT_ID, CLIENT_ID, CLIENT_SECRET, COMPANY_FILTER, START_DATE i END_DATE danymi właściwymi dla Państwa środowiska.
Zdefiniuj mapowanie encji (opcjonalnie): Sprawdź nazwy encji i pól używane w skrypcie. Jeśli w organizacji używane są niestandardowe encje lub pola do śledzenia określonych działań, może być konieczne dostosowanie zapytań OData w skrypcie.
Uruchom skrypt pobierający dane: Uruchom skrypt z wiersza poleceń poleceniem python your_script_name.py. Skrypt uwierzytelni się, pobierze dane dla poszczególnych działań za pomocą Dynamics 365 OData API i przetworzy wyniki. Postęp będzie wyświetlany w konsoli.
Sprawdź plik wynikowy: Po pomyślnym wykonaniu skrypt utworzy w tym samym katalogu plik CSV o nazwie d365_order_to_cash_event_log.csv. Otwórz go i sprawdź poprawność oraz kompletność pobranego dziennika zdarzeń.
Prześlij dane do ProcessMind: Wygenerowany plik CSV ma wymagany układ i można go bezpośrednio przesłać do ProcessMind w celu analizy procesu.

Konfiguracja

D365_URL: Podstawowy adres URL środowiska Dynamics 365 Finance and Operations. Powinien mieć postać https://[your-d365-environment-name].operations.dynamics.com.
TENANT_ID: Identyfikator katalogu (tenant ID) instancji Azure Active Directory. Można go znaleźć na stronie przeglądu rejestracji aplikacji Azure AD.
CLIENT_ID: Identyfikator aplikacji (client ID) zarejestrowanej w Azure AD.
CLIENT_SECRET: Wartość klucza tajnego klienta utworzonego dla aplikacji Azure AD.
COMPANY_FILTER: Określa jednostkę prawną Dynamics 365, na przykład 'USMF', z której zostaną pobrane dane. Ten filtr jest wymagany, aby zapytanie dotyczyło właściwego zbioru danych firmy.
START_DATE / END_DATE: Określają zakres dat pobierania danych w formacie 'YYYY-MM-DD'. Do wstępnej analizy zaleca się okres od 3 do 6 miesięcy, aby zachować równowagę między ilością danych a zakresem analizy. Długi zakres dat może znacznie wydłużyć pobieranie.
Wymagania wstępne: Wymagany jest dostęp do Azure AD, aby zarejestrować aplikację i nadać jej uprawnienia. Potrzebne jest również konto Dynamics 365 z uprawnieniami do tworzenia użytkownika aplikacji i przypisywania ról zabezpieczeń. Przypisana rola musi zapewniać dostęp do odczytu wszystkich encji używanych przez skrypt.

Przykładowe zapytanie python

import requests
import pandas as pd
import msal
import json
import datetime

class=class="hl-string">"hl-comment"># --- CONFIGURATION --- 
class=class="hl-string">"hl-comment"># Replace with your D365 environment and Azure AD App details
D365_URL = class="hl-string">"https://[your-d365-environment-name].operations.dynamics.com"
TENANT_ID = class="hl-string">"[Your-Azure-AD-Tenant-ID]"
CLIENT_ID = class="hl-string">"[Your-Azure-AD-Client-ID]"
CLIENT_SECRET = class="hl-string">"[Your-Azure-AD-Client-Secret]"

class=class="hl-string">"hl-comment"># --- EXTRACTION PARAMETERS ---
COMPANY_FILTER = class="hl-string">"[Your-Company-Code]" class=class="hl-string">"hl-comment"># e.g., class="hl-string">'USMF'
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-12-31"

class=class="hl-string">"hl-comment"># --- SCRIPT --- 

AUTHORITY_URL = fclass="hl-string">"https://login.microsoftonline.com/{TENANT_ID}"
RESOURCE = fclass="hl-string">"{D365_URL}/"
API_ENDPOINT = fclass="hl-string">"{D365_URL}/data"

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD and returns an access token."""
    app = msal.ConfidentialClientApplication(
        client_id=CLIENT_ID,
        client_credential=CLIENT_SECRET,
        authority=AUTHORITY_URL
    )
    result = app.acquire_token_for_client(scopes=[fclass="hl-string">"{RESOURCE}/.default"])
    if class="hl-string">"access_token" in result:
        return result[class="hl-string">'access_token']
    else:
        print(class="hl-string">"Error acquiring token:", result.get(class="hl-string">"error_description"))
        raise Exception(class="hl-string">"Could not authenticate.")

def execute_odata_query(access_token, entity, select_fields, filter_query, expand_fields=None):
    class="hl-string">"""Executes an OData query against a D365 entity and handles pagination."""
    all_results = []
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Prefer': class="hl-string">'odata.maxpagesize=1000' class=class="hl-string">"hl-comment"># Request pagination
    }
    
    query_url = fclass="hl-string">"{API_ENDPOINT}/{entity}?$select={select_fields}&$filter={filter_query}&cross-company=true"
    if expand_fields:
        query_url += fclass="hl-string">"&$expand={expand_fields}"
    
    print(fclass="hl-string">"Querying {entity}...")
    while query_url:
        try:
            response = requests.get(query_url, headers=headers)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raise HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            all_results.extend(data.get(class="hl-string">'value', []))
            query_url = data.get(class="hl-string">'@odata.nextLink') class=class="hl-string">"hl-comment"># Get URL for the next page
        except requests.exceptions.HTTPError as err:
            print(fclass="hl-string">"HTTP Error for {entity}: {err}")
            print(fclass="hl-string">"Response content: {err.response.text}")
            return [] class=class="hl-string">"hl-comment"># Return empty list on error
        except json.JSONDecodeError:
            print(fclass="hl-string">"JSON Decode Error for {entity}. Response was not valid JSON.")
            print(fclass="hl-string">"Response text: {response.text}")
            return []

    print(fclass="hl-string">"...found {len(all_results)} records for {entity}.")
    return all_results

def main():
    class="hl-string">"""Main function to orchestrate the data extraction process."""
    try:
        token = get_access_token()
    except Exception as e:
        print(e)
        return

    all_events = []
    now_utc = datetime.datetime.utcnow().isoformat() + class="hl-string">'Z'

    class=class="hl-string">"hl-comment"># Shared attributes for most queries
    base_select_fields = class="hl-string">"SalesOrderNumber,TotalInvoiceAmount,SalesOrderOriginCode,RequestedShippingDate,ConfirmedShippingDate,CustomerAccount"
    base_expand_fields = class="hl-string">"CustomerV3(CustomerName)"

    class=class="hl-string">"hl-comment"># Common date filter for creation/modification timestamps
    date_filter = fclass="hl-string">"(CreatedDateTime ge {START_DATE}T00:00:00Z and CreatedDateTime le {END_DATE}T23:59:59Z)"

    class=class="hl-string">"hl-comment"># 1. Sales Order Created
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},CreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {date_filter}", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Sales Order Created',
            class="hl-string">'EventTime': record.get(class="hl-string">'CreatedDateTime'),
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 2. Credit Check Performed (based on status change)
    class=class="hl-string">"hl-comment"># This assumes a credit check is reflected by the CreditLimitApprovalStatus. This logic may need adjustment.
    class=class="hl-string">"hl-comment"># We look for orders modified in the period, then check the status.
    modified_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields},ModifiedDateTime,CreditLimitApprovalStatus", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {modified_date_filter} and CreditLimitApprovalStatus ne 'NoCheck'", base_expand_fields)
    for record in data:
        all_events.append({
            class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'),
            class="hl-string">'ActivityName': class="hl-string">'Credit Check Performed',
            class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime'), class=class="hl-string">"hl-comment"># Using ModifiedDateTime as a proxy
            class="hl-string">'OrderValue': record.get(class="hl-string">'TotalInvoiceAmount'),
            class="hl-string">'CustomerName': record.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
            class="hl-string">'SalesChannel': record.get(class="hl-string">'SalesOrderOriginCode'),
            class="hl-string">'RequestedDeliveryDate': record.get(class="hl-string">'RequestedShippingDate'),
            class="hl-string">'ConfirmedDeliveryDate': record.get(class="hl-string">'ConfirmedShippingDate')
        })

    class=class="hl-string">"hl-comment"># 3. Order Confirmed
    confirmation_date_filter = fclass="hl-string">"(ConfirmationDate ge {START_DATE} and ConfirmationDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesConfirmationHeaders', class="hl-string">"SalesOrderNumber,ConfirmationDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {confirmation_date_filter}")
    class=class="hl-string">"hl-comment"># We need to get details from the SalesOrderHeader
    order_numbers = class="hl-string">"'" + class="hl-string">"','".join([rec[class="hl-string">'SalesOrderNumber'] for rec in data if rec.get(class="hl-string">'SalesOrderNumber')]) + class="hl-string">"'"
    if order_numbers != class="hl-string">"''":
        header_data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', base_select_fields, fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({order_numbers})", base_expand_fields)
        header_map = {h[class="hl-string">'SalesOrderNumber']: h for h in header_data}
        for record in data:
            header = header_map.get(record.get(class="hl-string">'SalesOrderNumber'))
            if header:
                all_events.append({
                    class="hl-string">'SalesOrderNumber': header.get(class="hl-string">'SalesOrderNumber'),
                    class="hl-string">'ActivityName': class="hl-string">'Order Confirmed',
                    class="hl-string">'EventTime': str(record.get(class="hl-string">'ConfirmationDate')) + class="hl-string">'T12:00:00Z', class=class="hl-string">"hl-comment"># Date only field, adding midday time
                    class="hl-string">'OrderValue': header.get(class="hl-string">'TotalInvoiceAmount'),
                    class="hl-string">'CustomerName': header.get(class="hl-string">'CustomerV3', {}).get(class="hl-string">'CustomerName'),
                    class="hl-string">'SalesChannel': header.get(class="hl-string">'SalesOrderOriginCode'),
                    class="hl-string">'RequestedDeliveryDate': header.get(class="hl-string">'RequestedShippingDate'),
                    class="hl-string">'ConfirmedDeliveryDate': header.get(class="hl-string">'ConfirmedShippingDate')
                })
    
    class=class="hl-string">"hl-comment"># 4 & 5. Inventory Reserved & Released To Warehouse (WMS)
    class=class="hl-string">"hl-comment"># These are complex. This is a proxy based on Warehouse Work creation time.
    work_date_filter = fclass="hl-string">"(WorkCreatedDateTime ge {START_DATE}T00:00:00Z and WorkCreatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WarehouseWorkHeaders', class="hl-string">"OrderNumber,WorkCreatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {work_date_filter} and WorkType eq 'SalesOrders'")
    for record in data:
        class=class="hl-string">"hl-comment"># Assuming reservation happens just before release to warehouse
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Inventory Reserved', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'OrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Released To Warehouse', class="hl-string">'EventTime': record.get(class="hl-string">'WorkCreatedDateTime')})

    class=class="hl-string">"hl-comment"># 6 & 7. Goods Picked & Goods Packed (WMS)
    class=class="hl-string">"hl-comment"># Proxy using Shipment status updates. This logic may need refinement based on specific WMS setup.
    shipment_date_filter = fclass="hl-string">"(ShipmentStatusLastUpdatedDateTime ge {START_DATE}T00:00:00Z and ShipmentStatusLastUpdatedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'WHSShipmentTables', class="hl-string">"SalesOrderNumber,ShipmentStatus,ShipmentStatusLastUpdatedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {shipment_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Picked', class="hl-string">'Loaded', class="hl-string">'Shipped']:
             all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Picked', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})
        if record.get(class="hl-string">'ShipmentStatus') in [class="hl-string">'Loaded', class="hl-string">'Shipped']:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Packed', class="hl-string">'EventTime': record.get(class="hl-string">'ShipmentStatusLastUpdatedDateTime')})

    class=class="hl-string">"hl-comment"># 8. Goods Shipped (Posting Packing Slip)
    packslip_date_filter = fclass="hl-string">"(ShippingDate ge {START_DATE} and ShippingDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ShippingDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Shipped', class="hl-string">'EventTime': str(record.get(class="hl-string">'ShippingDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 9. Goods Delivered
    class=class="hl-string">"hl-comment"># This is often not a standard field. We use ModifiedDateTime on Packing Slip as a placeholder.
    packslip_mod_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesPackingSlipHeaders', class="hl-string">"SalesOrderNumber,ModifiedDateTime,DeliveryMode", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {packslip_mod_date_filter} and DeliveryMode eq '[Your-Delivered-Status-Code]'")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Goods Delivered', class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})

    class=class="hl-string">"hl-comment"># 10. Invoice Created
    invoice_date_filter = fclass="hl-string">"(InvoiceDate ge {START_DATE} and InvoiceDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'SalesInvoiceHeadersV2', class="hl-string">"SalesOrderNumber,InvoiceDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_date_filter}")
    for record in data:
        all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Invoice Created', class="hl-string">'EventTime': str(record.get(class="hl-string">'InvoiceDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 11. Payment Received
    class=class="hl-string">"hl-comment"># This requires looking at customer payments and settling them to invoices, then to sales orders.
    class=class="hl-string">"hl-comment"># This is a simplified proxy using the ClosedDate of the invoice.
    invoice_closed_date_filter = fclass="hl-string">"(ClosedDate ge {START_DATE} and ClosedDate le {END_DATE})"
    data = execute_odata_query(token, class="hl-string">'CustomerInvoices', class="hl-string">"SalesOrderNumber,ClosedDate", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {invoice_closed_date_filter}")
    for record in data:
        if record.get(class="hl-string">'ClosedDate') and record.get(class="hl-string">'SalesOrderNumber'):
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': class="hl-string">'Payment Received', class="hl-string">'EventTime': str(record.get(class="hl-string">'ClosedDate')) + class="hl-string">'T12:00:00Z'})

    class=class="hl-string">"hl-comment"># 12 & 13. Order Closed & Order Cancelled
    class=class="hl-string">"hl-comment"># These are statuses on the Sales Order Header.
    status_date_filter = fclass="hl-string">"(ModifiedDateTime ge {START_DATE}T00:00:00Z and ModifiedDateTime le {END_DATE}T23:59:59Z)"
    data = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', class="hl-string">"SalesOrderNumber,SalesOrderStatus,ModifiedDateTime", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and {status_date_filter} and (SalesOrderStatus eq 'Invoiced' or SalesOrderStatus eq 'Canceled')")
    for record in data:
        activity = class="hl-string">''
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Invoiced': activity = class="hl-string">'Order Closed'
        if record.get(class="hl-string">'SalesOrderStatus') == class="hl-string">'Canceled': activity = class="hl-string">'Order Cancelled'
        if activity:
            all_events.append({class="hl-string">'SalesOrderNumber': record.get(class="hl-string">'SalesOrderNumber'), class="hl-string">'ActivityName': activity, class="hl-string">'EventTime': record.get(class="hl-string">'ModifiedDateTime')})


    class=class="hl-string">"hl-comment"># --- Final Processing ---
    if not all_events:
        print(class="hl-string">"No events found. Exiting.")
        return

    df = pd.DataFrame(all_events)
    print(fclass="hl-string">"Total events created: {len(df)}")

    class=class="hl-string">"hl-comment"># Drop events without a case ID or timestamp
    df.dropna(subset=[class="hl-string">'SalesOrderNumber', class="hl-string">'EventTime'], inplace=True)
    print(fclass="hl-string">"Events after dropping nulls: {len(df)}")

    class=class="hl-string">"hl-comment"># Fill in missing recommended attributes by merging back header details
    print(class="hl-string">"Enriching data with header attributes...")
    unique_orders = class="hl-string">"'" + class="hl-string">"','".join(df[class="hl-string">'SalesOrderNumber'].unique()) + class="hl-string">"'"
    if unique_orders != class="hl-string">"''":
        header_data_final = execute_odata_query(token, class="hl-string">'SalesOrderHeadersV2', fclass="hl-string">"{base_select_fields}", fclass="hl-string">"dataAreaId eq '{COMPANY_FILTER}' and SalesOrderNumber in ({unique_orders})", base_expand_fields)
        header_df = pd.DataFrame(header_data_final)
        if not header_df.empty:
            header_df = header_df.rename(columns={
                class="hl-string">'TotalInvoiceAmount': class="hl-string">'OrderValue',
                class="hl-string">'SalesOrderOriginCode': class="hl-string">'SalesChannel',
                class="hl-string">'RequestedShippingDate': class="hl-string">'RequestedDeliveryDate',
                class="hl-string">'ConfirmedShippingDate': class="hl-string">'ConfirmedDeliveryDate'
            })
            class=class="hl-string">"hl-comment"># Extract nested customer name
            header_df[class="hl-string">'CustomerName'] = header_df[class="hl-string">'CustomerV3'].apply(lambda x: x.get(class="hl-string">'CustomerName') if isinstance(x, dict) else None)
            df = df.merge(header_df[[class="hl-string">'SalesOrderNumber', class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']], on=class="hl-string">'SalesOrderNumber', how=class="hl-string">'left', suffixes=(class="hl-string">'', class="hl-string">'_y'))
            class=class="hl-string">"hl-comment"># Fill NaNs from merge
            for col in [class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']:
                if col + class="hl-string">'_y' in df.columns:
                    df[col] = df[col].fillna(df[col + class="hl-string">'_y'])
                    df.drop(columns=[col + class="hl-string">'_y'], inplace=True)

    class=class="hl-string">"hl-comment"># Add required static columns
    df[class="hl-string">'SourceSystem'] = class="hl-string">'Microsoft Dynamics 365'
    df[class="hl-string">'LastDataUpdate'] = now_utc

    class=class="hl-string">"hl-comment"># Ensure required columns exist
    final_cols = [class="hl-string">'SalesOrderNumber', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'SourceSystem', class="hl-string">'LastDataUpdate', 
                  class="hl-string">'OrderValue', class="hl-string">'CustomerName', class="hl-string">'SalesChannel', class="hl-string">'RequestedDeliveryDate', class="hl-string">'ConfirmedDeliveryDate']
    for col in final_cols:
        if col not in df.columns:
            df[col] = None
    
    class=class="hl-string">"hl-comment"># Reorder and save
    df = df[final_cols]
    df.to_csv(class="hl-string">'d365_order_to_cash_event_log.csv', index=False)
    print(class="hl-string">"Successfully created d365_order_to_cash_event_log.csv")

if __name__ == class="hl-string">"__main__":
    main()

Gotowi do rozpoczęcia?

Przygotuj dane za pomocą tego szablonu, a następnie prześlij je na naszą platformę, aby uzyskać wgląd w przebieg obsługi zamówień sprzedaży i usprawnić ten proces. Zacznij już dziś.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Usprawnij obsługę zamówień sprzedaży, od zamówienia do płatności

Znajdź nieefektywne działania i skróć czas realizacji o 30%, aby szybciej realizować zamówienia.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.

Szablon danych do procesu obsługi zamówień sprzedaży, od zamówienia do płatności

Szablon danych do procesu obsługi zamówień sprzedaży, od zamówienia do płatności

Atrybuty procesu obsługi zamówień sprzedaży, od zamówienia do płatności

Działania w procesie obsługi zamówień sprzedaży, od zamówienia do płatności

Instrukcje pobierania danych

Zapytanie SQL do Azure Data Lake za pomocą Synapse Analytics

Kroki

Konfiguracja

Przykładowe zapytanie sql

Skrypt Python korzystający z Dynamics 365 OData Web API

Kroki

Konfiguracja

Przykładowe zapytanie python

Gotowi do rozpoczęcia?

Usprawnij obsługę zamówień sprzedaży, od zamówienia do płatności