Szablon danych do analizy obsługi płatności zobowiązań
Szablon danych do analizy obsługi płatności zobowiązań
- Atrybuty procesu do analizy finansowej
- Najważniejsze etapy procesu śledzenia płatności
- Szczegółowe instrukcje eksportu danych z Dynamics 365
Atrybuty procesu obsługi płatności zobowiązań
| Nazwa | Opis | ||
|---|---|---|---|
| Aktywność Activity | Konkretne zadanie lub zmiana statusu, która miała miejsce. | ||
| Opis Ten atrybut opisuje zdarzenie lub etap procesu, na przykład „Utworzono fakturę”, „Zatwierdzono fakturę” lub „Zaksięgowano płatność”. Zamienia techniczne typy transakcji i zmiany statusu workflow na czytelne zdarzenia biznesowe. W Dynamics 365 aktywności te często ustala się na podstawie połączenia danych o wstawieniu rekordu do tabeli, na przykład nowego rekordu w Dlaczego to ważne Określa przebieg procesu i kolejność zdarzeń na mapie procesu. Skąd pobrać Ustalane na podstawie różnych tabel transakcji i dzienników historii workflow Przykłady Utworzono fakturęZatwierdzono fakturęWygenerowano płatność | |||
| Czas zdarzenia EventTime | Znacznik czasu wystąpienia aktywności. | ||
| Opis Ten atrybut zapisuje dokładną datę i godzinę wystąpienia danej aktywności. Służy do porządkowania zdarzeń chronologicznie i obliczania czasu między etapami. W Dynamics 365 dane pochodzą zwykle z pól Dlaczego to ważne Niezbędne do obliczania czasu realizacji i czasu oczekiwania oraz wykrywania wąskich gardeł. Skąd pobrać Systemowe pola CreatedDateTime lub ModifiedDateTime w tabelach transakcji Przykłady 2023-10-01T08:30:00Z2023-10-01T14:15:22Z2023-10-05T09:00:00Z | |||
| Numer faktury InvoiceNumber | Unikatowy identyfikator przypisany do faktury od dostawcy. | ||
| Opis Numer faktury jest jednoznacznym identyfikatorem case w tym widoku procesu. Łączy wszystkie zdarzenia dotyczące jednej faktury od dostawcy, umożliwiając analizę całego przebiegu, od otrzymania po rozliczenie. W Microsoft Dynamics 365 odpowiada zwykle polu Dlaczego to ważne To podstawowy identyfikator, który łączy rozproszone aktywności związane z obsługą zobowiązań w jedną instancję procesu. Skąd pobrać Tabela: VendInvoiceJour, pole: InvoiceId Przykłady INV-2023-00198223344ACME-OCT-22 | |||
| Data ostatniej aktualizacji danych LastDataUpdate | Znacznik czasu wyodrębnienia lub odświeżenia danych. | ||
| Opis Informuje, jak aktualne są dane używane w analizie. Pomaga ustalić, czy analizowane są dane bieżące, czy migawka z wcześniejszego okresu. Wartość jest zwykle generowana przez proces ETL (Extract, Transform, Load), a nie pobierana z pola w samym Dynamics 365. Dlaczego to ważne Pomaga budować zaufanie do dashboardów i KPI. Skąd pobrać Wygenerowane przez skrypt wyodrębniający dane Przykłady 2023-10-25T12:00:00Z2023-11-01T06:00:00Z | |||
| System źródłowy SourceSystem | Nazwa systemu, z którego pochodzą dane. | ||
| Opis Wskazuje oprogramowanie lub środowisko, z którego wyodrębniono dane procesu. W tym przypadku będzie to instancja Microsoft Dynamics 365. Atrybut jest szczególnie przydatny w środowiskach z wieloma systemami, w których dane mogą pochodzić z systemów ERP i zewnętrznych rozwiązań do skanowania. Dlaczego to ważne Zapewnia możliwość śledzenia pochodzenia danych w analizach obejmujących wiele systemów. Skąd pobrać Wartość zakodowana na stałe lub skonfigurowana podczas wyodrębniania danych Przykłady Dynamics 365 F&OD365 PRODMicrosoft Dynamics | |||
| Data faktury InvoiceDate | Data dokumentu podana na fakturze. | ||
| Opis Data widniejąca na fakturze dostawcy. W Dynamics 365 odpowiada za nią pole W analizie „Czas realizacji od początku do końca” służy do pomiaru całego cyklu z perspektywy dostawcy. Dlaczego to ważne Wyznacza początek okresu przeterminowania faktury. Skąd pobrać Tabela: VendInvoiceJour, pole: InvoiceDate Przykłady 2023-10-012023-10-15 | |||
| Dział Department | Dział odpowiedzialny za koszt. | ||
| Opis Wymiar finansowy wskazujący dział w organizacji. W Dynamics 365 wymiary są przechowywane dynamicznie, często w polu Atrybut jest wykorzystywany w widoku „Złożoność relacji z dostawcami”, aby sprawdzić, które działy generują największy wolumen faktur AP. Dlaczego to ważne Umożliwia analizę danych na poziomie działów i przypisanie odpowiedzialności. Skąd pobrać Tabela: VendInvoiceJour, pole: DefaultDimension (wymaga widoku DimensionAttributeLevelValue) Przykłady ITFinanseOperacje | |||
| Identyfikator użytkownika UserId | Identyfikator użytkownika, który wykonał daną czynność. | ||
| Opis Wskazuje użytkownika systemu odpowiedzialnego za daną czynność, na przykład zatwierdzenie faktury lub zaksięgowanie płatności. Dane pochodzą z pól W analizie „Blokady płatności i utrudnienia” pozwala sprawdzić, czy niektórzy pracownicy częściej powodują blokady. Dlaczego to ważne Umożliwia analizę działań użytkowników i rozdziału obowiązków. Skąd pobrać Pola systemowe CreatedBy/ModifiedBy w tabelach transakcji i historii Przykłady jdoeadminworkflow_sys | |||
| Kod firmy CompanyCode | Identyfikator jednostki prawnej lub spółki zależnej. | ||
| Opis Określa jednostkę prawną w organizacji, w której przetwarzana jest faktura. W Microsoft Dynamics 365 wartość ta jest ściśle określana przez systemowe pole Atrybut jest niezbędny do analizy czasu realizacji od początku do końca i porównywania wyników między spółkami zależnymi lub jednostkami geograficznymi. Dlaczego to ważne Umożliwia porównywanie różnych jednostek biznesowych lub krajów. Skąd pobrać Tabela: VendInvoiceJour, pole: DataAreaId Przykłady USMFDEMFGBSI | |||
| Konto dostawcy VendorAccount | Unikatowy numer konta dostawcy. | ||
| Opis Unikatowy identyfikator dostawcy uczestniczącego w transakcji. W Dynamics 365 odpowiada polu Atrybut ten jest podstawą widoku „Złożoność relacji z dostawcami”, który pozwala analizować wyniki i problemy w relacji z konkretnym dostawcą. Dlaczego to ważne Umożliwia analizę wyników procesu według dostawcy. Skąd pobrać Tabela: VendInvoiceJour, pole: InvoiceAccount lub OrderAccount Przykłady US-101V000452001 | |||
| Kwota faktury InvoiceAmount | Łączna wartość pieniężna faktury. | ||
| Opis Łączna wartość faktury w walucie transakcji. W Dynamics 365 można ją znaleźć w polach takich jak Wykorzystywana w dashboardzie „Wykrywanie ryzyka podwójnej płatności” do zestawiania kwot z danymi dostawców. Dlaczego to ważne Niezbędna do analizy wartości wydatków i ryzyka finansowego. Skąd pobrać Tabela: VendInvoiceJour, pole: InvoiceAmount Przykłady 1500.00245.5010000.00 | |||
| Nazwa dostawcy VendorName | Nazwa organizacji dostawcy. | ||
| Opis Nazwa opisowa dostawcy. W D365 konto dostawcy pełni funkcję klucza obcego do globalnej książki adresowej ( Czytelne nazwy ułatwiają korzystanie z widoku „Złożoność relacji z dostawcami” i dashboardów użytkownikom biznesowym. Dlaczego to ważne Uzupełnia numer konta dostawcy o kontekst. Skąd pobrać Tabela: DirPartyTable (przez VendTable), pole: Name Przykłady Contoso Office SupplyFabrikam ElectronicsLitware Inc. | |||
| Numer zamówienia zakupu PurchaseOrderNumber | Numer referencyjny powiązanego zamówienia zakupu. | ||
| Opis Łączy fakturę z pierwotnym dokumentem zakupu. W Dynamics 365 odpowiada za to pole Ten atrybut pozwala w dashboardzie „Dopasowanie faktur do zamówień zakupu i trendy rozbieżności” odróżnić faktury powiązane z zamówieniem zakupu od faktur bez takiego powiązania. Dlaczego to ważne Niezbędny do analizy odsetka zgodności w procesie od zakupu do płatności. Skąd pobrać Tabela: VendInvoiceJour, pole: PurchId Przykłady PO-000455000342PO-22-998 | |||
| Termin płatności DueDate | Data, do której należy opłacić fakturę. | ||
| Opis Umowny termin, do którego należy uregulować płatność, aby uniknąć kar. W Dynamics 365 jest zapisany w polu To podstawowy punkt odniesienia dla KPI „Odsetek płatności terminowych”. Pomaga też ustalać priorytety w widoku „Przepustowość i wolumen procesu AP”. Dlaczego to ważne Punkt odniesienia do pomiaru terminowości płatności. Skąd pobrać Tabela: VendInvoiceJour lub VendTrans, pole: DueDate Przykłady 2023-11-302023-12-15 | |||
| Czy płatność jest zablokowana IsPaymentBlocked | Informacja, czy płatność za fakturę jest obecnie zablokowana. | ||
| Opis Wartość logiczna wskazująca, czy faktura jest wstrzymana. W Dynamics 365 często ustala się ją na podstawie statusu To podstawowa informacja w analizie „Blokady płatności i utrudnienia”, która pokazuje przerwy w procesie. Dlaczego to ważne Pozwala wykryć bieżące źródła utrudnień i ręczne interwencje. Skąd pobrać Tabela: VendTrans, pole: Approved (wartość odwrócona) lub dedykowane pola wstrzymania Przykłady truefalse | |||
| Metoda płatności PaymentMethod | Sposób opłacenia faktury, na przykład czekiem, przelewem lub EFT. | ||
| Opis Określa sposób przekazania środków dostawcy. W Dynamics 365 odpowiada za to pole Atrybut jest wykorzystywany w dashboardzie „Czas realizacji płatności” do oceny efektywności różnych typów partii płatności. Dlaczego to ważne Pozwala wyjaśnić różnice w czasie realizacji płatności. Skąd pobrać Tabela: VendInvoiceJour (połączona z informacjami PaymMode) lub VendTrans Przykłady CZEKACHPRZELEW | |||
| Numer dowodu księgowego VoucherNumber | Numer dowodu księgowego powiązanego z transakcją. | ||
| Opis Wewnętrzny identyfikator zapisu księgowego w księdze głównej. W Dynamics 365 pole Choć jest to pole techniczne, przydaje się w audycie „Ścieżka procesu i kontrola zgodności”, ponieważ pozwala powiązać zapisy z księgą główną na potrzeby uzgodnień. Dlaczego to ważne Identyfikator przydatny podczas audytu finansowego i uzgodnień. Skąd pobrać Tabela: VendInvoiceJour, pole: LedgerVoucher Przykłady VOU-10023INV-ACC-992 | |||
| Termin skonta CashDiscountDate | Termin, do którego należy zapłacić, aby skorzystać ze skonta. | ||
| Opis Termin skorzystania z rabatu za wcześniejszą płatność. W Dynamics 365 odpowiada mu pole Atrybut zasila dashboard „Wykorzystanie skonta”, który pozwala określić wartość utraconych oszczędności. Dlaczego to ważne Bezpośrednio wpływa na KPI efektywności finansowej procesu. Skąd pobrać Tabela: VendInvoiceJour lub VendTrans, pole: CashDiscDate Przykłady 2023-10-102023-10-20 | |||
| Waluta Currency | Kod waluty faktury. | ||
| Opis Kod ISO waluty, w której wystawiono fakturę. W Dynamics 365 odpowiada za niego pole Przydaje się do ujednolicania kwot w mapowaniu „Kwota czynności”, jeśli wymagane jest przeliczenie wielu walut. Dlaczego to ważne Niezbędny kontekst do interpretacji wartości finansowych. Skąd pobrać Tabela: VendInvoiceJour, pole: CurrencyCode Przykłady USDEURGBP | |||
| Warunki płatności PaymentTerms | Kod określający uzgodnione warunki płatności. | ||
| Opis Kod konfiguracji określający terminy płatności i skonta, na przykład Net30. W Dynamics 365 odpowiada mu pole Analiza tego atrybutu w zestawieniu z „Czasem cyklu” pozwala sprawdzić, czy opóźnienia w procesie naruszają uzgodnione warunki. Dlaczego to ważne Uzupełnia kontekst potrzebny do obliczenia terminu płatności. Skąd pobrać Tabela: VendInvoiceJour, pole: PaymTermId Przykłady Net302%10Net30COD | |||
Działania w procesie obsługi płatności zobowiązań
| Działanie | Opis | ||
|---|---|---|---|
| Utworzono dziennik płatności | Faktura zostaje wybrana i dodana do wiersza dziennika płatności. Oznacza zamiar dokonania płatności i zwykle rozpoczyna workflow jej weryfikacji. | ||
| Dlaczego to ważne Oznacza przejście od zobowiązania do obsługi wypłaty środków. Służy do pomiaru czasu realizacji płatności. Skąd pobrać LedgerJournalTrans.CreatedDateTime. Faktura jest powiązana przez pole MarkedInvoice lub tabele rozliczeń. Rejestrowanie Rejestrowane w chwili utworzenia rekordu w LedgerJournalTrans Typ zdarzenia explicit | |||
| Utworzono fakturę | Utworzenie w systemie rekordu oczekującej faktury od dostawcy. Oznacza wprowadzenie faktury do workflow Dynamics 365, ręcznie lub przez import jednostki danych. | ||
| Dlaczego to ważne Wyznacza początek pomiaru czasu realizacji procesu. Pozwala sprawdzić, jak długo faktury pozostają w systemie przed przetworzeniem lub zaksięgowaniem. Skąd pobrać Znacznik czasu utworzenia VendInvoiceInfoTable.CreatedDateTime lub VendInvoiceInfoTable.RecId. Dotyczy nagłówka oczekującej faktury od dostawcy. Rejestrowanie Rejestrowane w chwili utworzenia rekordu w VendInvoiceInfoTable Typ zdarzenia explicit | |||
| Uzgodniono fakturę z zamówieniem zakupu | System prawidłowo łączy wiersz faktury z zamówieniem zakupu lub przyjęciem towaru. Ta aktywność oznacza weryfikację faktury względem zamówienia. | ||
| Dlaczego to ważne Niezbędne do obliczenia KPI odsetka faktur uzgodnionych z zamówieniem zakupu za pierwszym razem. Pozwala odróżnić obsługę bez ręcznej ingerencji od faktur wymagających ręcznej interwencji. Skąd pobrać VendInvoiceInfoLine.PurchId i VendInvoiceInfoTable.MatchStatus. Wnioskowane, gdy MatchStatus zmienia się na Passed. Rejestrowanie Porównanie pola MatchStatus przed zmianą i po niej Typ zdarzenia inferred | |||
| Wygenerowano płatność | System generuje plik płatności (EFT, ISO20022) lub drukuje czeki. Status płatności w wierszu dziennika zmienia się na Sent lub Generated. | ||
| Dlaczego to ważne Wspiera KPI opóźnienia od zatwierdzenia do realizacji. Potwierdza wygenerowanie dyspozycji płatności. Skąd pobrać LedgerJournalTrans.PaymentStatus zmienia się na Sent/Recieved. Często wnioskowane na podstawie aktualizacji wiersza. Rejestrowanie Porównanie pola PaymentStatus przed zmianą i po niej Typ zdarzenia inferred | |||
| Zaksięgowano fakturę | Faktura zostaje zaksięgowana w księdze głównej, tworząc zobowiązanie w systemie. Rekord przechodzi z tabel oczekujących do tabel zaksięgowanych transakcji. | ||
| Dlaczego to ważne Ważny etap oznaczający ujęcie zobowiązania w księgach. Po tej aktywności fakturę można uwzględnić w płatności. Skąd pobrać Utworzenie rekordu w VendInvoiceJour i VendTrans. TransDate oznacza datę księgowania. Rejestrowanie Rejestrowane po wykonaniu transakcji X Typ zdarzenia explicit | |||
| Zaksięgowano płatność | Dziennik płatności zostaje zaksięgowany w księdze głównej, co rozlicza fakturę i zeruje saldo dostawcy. Na tym kończy się proces finansowy. | ||
| Dlaczego to ważne Ostatnia aktywność uwzględniana przy obliczaniu średniego czasu od faktury do płatności. Potwierdza zakończenie księgowania zmniejszenia stanu środków pieniężnych. Skąd pobrać Zaksięgowano LedgerJournalTrans. Aktualizacja VendTrans wskazuje rozliczenie. Zdarzeniem jest zaksięgowanie dziennika. Rejestrowanie Rejestrowane po wykonaniu transakcji X Typ zdarzenia explicit | |||
| Zatwierdzono fakturę | Instancja workflow dla oczekującej faktury osiąga status ukończony lub zatwierdzony. Fakturę można teraz zaksięgować w księdze głównej. | ||
| Dlaczego to ważne Pozwala obliczyć średni czas zatwierdzania. Opóźnienia na tym etapie bezpośrednio ograniczają możliwość skorzystania ze skonta za wcześniejszą płatność. Skąd pobrać WorkflowTrackingStatusTable.CreatedDateTime, gdy TrackingStatus ma wartość Completed. Alternatywnie VendInvoiceInfoTable.RequestStatus ma wartość Approved. Rejestrowanie Rejestrowane w chwili zakończenia instancji workflow Typ zdarzenia explicit | |||
| Nie udało się uzgodnić faktury | Podczas uzgadniania wykryto rozbieżność między fakturą a zamówieniem zakupu lub przyjęciem towaru, na przykład różnicę w cenie lub ilości. Często wstrzymuje to proces do czasu wyjaśnienia rozbieżności. | ||
| Dlaczego to ważne Wskazuje konkretne problemy na etapie uzgadniania. Zasila dashboard dotyczący uzgadniania zamówień zakupu i trendów rozbieżności. Skąd pobrać VendInvoiceInfoTable.MatchStatus zmienia się na Failed lub Discrepancy. Rozbieżności są również widoczne w danych o uzgadnianiu wierszy VendInvoiceInfoLine. Rejestrowanie Porównanie pola MatchStatus przed zmianą i po niej Typ zdarzenia inferred | |||
| Przekazano fakturę do zatwierdzenia | Oczekująca faktura zostaje przekazana do silnika workflow w celu weryfikacji. Oznacza przejście od wprowadzania i uzgadniania danych do etapu autoryzacji. | ||
| Dlaczego to ważne Wyznacza początek pomiaru czasu zatwierdzania. Jest niezbędne do analizy sprawności wewnętrznych struktur decyzyjnych. Skąd pobrać WorkflowTrackingStatusTable.CreatedDateTime, gdy ContextTableId jest równy identyfikatorowi VendInvoiceInfoTable, a Status ma wartość Submitted. Rejestrowanie Rejestrowane w chwili rozpoczęcia instancji workflow Typ zdarzenia explicit | |||
| Zablokowano płatność | Transakcja z dostawcą zostaje wstrzymana, co uniemożliwia uwzględnienie jej w propozycji płatności. Często blokadę nakłada się ręcznie w przypadku sporu. | ||
| Dlaczego to ważne Wspiera analizę blokad płatności i problematycznych etapów. Ujawnia ręczne interwencje opóźniające wypływ środków. Skąd pobrać Flaga VendTrans.Approved ma wartość No lub wypełniono określone pola statusu OnHold. Wymaga śledzenia aktualizacji VendTrans. Rejestrowanie Porównanie pola statusu przed zmianą i po niej Typ zdarzenia inferred | |||
| Zaktualizowano fakturę | Rejestruje zmiany w nagłówku lub wierszach faktury przed jej zaksięgowaniem. Częste aktualizacje mogą wskazywać na problemy z wyodrębnianiem danych lub ręczne poprawki wymagane podczas weryfikacji. | ||
| Dlaczego to ważne Częste aktualizacje mogą wskazywać na powtarzające się poprawki lub niską jakość danych źródłowych, na przykład błędy OCR. Wspiera monitorowanie poprawek i dokładności danych. Skąd pobrać Dziennik bazy danych (SysDatabaseLog) dla VendInvoiceInfoTable, jeśli jest włączony, lub wnioskowanie na podstawie zmian ModifiedDateTime przy częstym odpytywaniu. Rejestrowanie Porównanie ModifiedDateTime w kolejnych wyciągach danych Typ zdarzenia inferred | |||
| Zatwierdzono dziennik płatności | Zatwierdzono workflow dziennika płatności, co upoważnia do wygenerowania płatności. To ostatnia kontrola przed przygotowaniem środków do przekazania. | ||
| Dlaczego to ważne Pozwala oddzielić administracyjne przygotowanie płatności od wąskiego gardła związanego z ich autoryzacją. Skąd pobrać WorkflowTrackingStatusTable powiązane z identyfikatorem LedgerJournalTable (nagłówek). Status ma wartość Completed. Rejestrowanie Rejestrowane w chwili zakończenia instancji workflow Typ zdarzenia explicit | |||
Instrukcje eksportu danych
Kroki
Otwórz obszar roboczy zarządzania danymi: Zaloguj się do środowiska Microsoft Dynamics 365 Finance. Otwórz obszar roboczy Workspaces i wybierz Data Management. To centralne miejsce konfiguracji projektów eksportu danych.
Utwórz projekt eksportu: Wybierz kafelek Export, aby utworzyć projekt danych. Nadaj mu czytelną nazwę, na przykład ProcessMining_AP_Export. W polu Target data format wybierz format docelowy, np. Azure SQL DB dla BYOD lub CSV w przypadku eksportu do pliku.
Dodaj encje danych: Dodawaj kolejno do projektu następujące standardowe encje danych: VendorInvoiceHeaderEntity (faktury oczekujące), VendorInvoiceLineEntity (pozycje faktur), VendorInvoiceJournalHeaderEntity (zaksięgowane faktury), VendorPaymentJournalLineEntity (płatności) oraz WorkflowHistoryEntity (historia akceptacji). Jeśli WorkflowHistoryEntity nie jest dostępna domyślnie, może być konieczne włączenie niestandardowej encji lub udostępnionej do eksportu encji systemowej.
Skonfiguruj filtry encji: Przy każdej encji wybierz ikonę Filter. Ogranicz dane do właściwej wartości CompanyInfo (DataAreaId) i ustaw zakres dat dla pól CreatedDateTime lub InvoiceDate, aby pobrać dane tylko z wybranego okresu analizy, np. z ostatnich 12 miesięcy.
Skonfiguruj cykliczny eksport: Aby dziennik zdarzeń był aktualny, utwórz cykliczne zadanie eksportu danych. Ustaw częstotliwość, np. codziennie lub co godzinę, i włącz opcję Incremental push, jeśli jest dostępna. Dzięki temu eksportowane będą tylko zmienione rekordy, co ograniczy obciążenie systemu.
Wykonaj pierwszy eksport: Uruchom projekt ręcznie po raz pierwszy, wybierając Export now. Sprawdź podsumowanie wykonania, aby upewnić się, że wszystkie rekordy zostały wyeksportowane bez błędów.
Przekształć dane: Po wyeksportowaniu danych do miejsca docelowego, czyli Azure SQL lub plików, użyj skryptu SQL z sekcji Query, aby połączyć tabele. Logika przekształcania łączy rekordy z różnych encji w jeden chronologiczny dziennik zdarzeń.
Przypisz atrybuty: Upewnij się, że w wynikowym zbiorze danych InvoiceNumber jest przypisane do Case ID, EventTime do Timestamp, a Activity do Activity Name, zgodnie z wymaganiami narzędzia process mining.
Sprawdź i prześlij dane: Wykonaj wymienione poniżej kontrole poprawności danych. Po weryfikacji wyeksportuj wynik do pliku CSV lub Parquet i prześlij go do ProcessMind.
Konfiguracja
- Wybór encji: Do etapów procesu przed zaksięgowaniem użyj VendorInvoiceHeaderEntity i VendorInvoiceLineEntity. Jako źródło danych o zaksięgowanym dokumencie użyj VendorInvoiceJournalHeaderEntity. Płatności śledź za pomocą VendorPaymentJournalLineEntity.
- Eksport przyrostowy: Włącz tę opcję w projekcie Data Management, aby po pierwszym pełnym załadowaniu eksportować tylko nowe lub zmienione rekordy. Ma to istotne znaczenie dla wydajności.
- Zakres dat: Filtruj według InvoiceDate >= [Start Date]. Unikaj eksportu bez ograniczeń, który może zakończyć się przekroczeniem limitu czasu.
- Filtr firmy: D365 obsługuje wiele jednostek. Zawsze filtruj według DataAreaId, aby nie łączyć danych z różnych jednostek prawnych, chyba że analiza ma obejmować wiele firm.
- Historia workflow: Standardowe encje historii workflow mogą zawierać dużo danych. Eksportuj tylko historię dotyczącą typów VendInvoice, aby ograniczyć jej ilość.
Przykładowe zapytanie sql
/*
SQL Transformation Script for D365 Finance AP Process
Assumes data is loaded into Staging tables in a SQL environment (BYOD/Data Lake)
*/
SELECT
I.InvoiceNumber AS [InvoiceNumber],
'Invoice Created' AS [Activity],
I.CreatedDateTime AS [EventTime],
I.DataAreaId AS [CompanyCode],
I.InvoiceAccount AS [VendorAccount],
I.InvoiceAmount AS [InvoiceAmount],
I.CurrencyCode AS [Currency],
'D365 FO' AS [SourceSystem],
GETDATE() AS [LastDataUpdate]
FROM Staging_VendorInvoiceHeaderEntity I
UNION ALL
/* Capture updates to invoice headers */
SELECT
I.InvoiceNumber,
'Invoice Updated',
I.ModifiedDateTime,
I.DataAreaId,
I.InvoiceAccount,
I.InvoiceAmount,
I.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceHeaderEntity I
WHERE I.ModifiedDateTime > I.CreatedDateTime
UNION ALL
/* Invoice Matching Activities */
SELECT
I.InvoiceNumber,
'Invoice Matched to PO',
I.ModifiedDateTime,
I.DataAreaId,
I.InvoiceAccount,
I.InvoiceAmount,
I.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceHeaderEntity I
WHERE I.MatchStatus = 'Matched' -- Adjust value based on system config
UNION ALL
SELECT
I.InvoiceNumber,
'Invoice Match Failed',
I.ModifiedDateTime,
I.DataAreaId,
I.InvoiceAccount,
I.InvoiceAmount,
I.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceHeaderEntity I
WHERE I.MatchStatus = 'Failed'
UNION ALL
/* Workflow Activities */
SELECT
RelatedContext AS InvoiceNumber,
CASE
WHEN Status = 'Submitted' THEN 'Invoice Submitted for Approval'
WHEN Status = 'Approved' THEN 'Invoice Approved'
ELSE 'Workflow Activity'
END AS [Activity],
CreatedDateTime AS [EventTime],
DataAreaId,
NULL AS [VendorAccount],
NULL AS [InvoiceAmount],
NULL AS [Currency],
'D365 FO',
GETDATE()
FROM Staging_WorkflowHistoryEntity
WHERE ContextTableId = 12345 -- Replace with TableId for VendInvoiceInfoTable
AND Status IN ('Submitted', 'Approved')
UNION ALL
/* Invoice Posted */
SELECT
J.InvoiceNumber,
'Invoice Posted',
J.PostedDateTime,
J.DataAreaId,
J.InvoiceAccount,
J.InvoiceAmount,
J.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceJournalHeaderEntity J
UNION ALL
/* Payment Block */
SELECT
I.InvoiceNumber,
'Payment Block Applied',
I.ModifiedDateTime,
I.DataAreaId,
I.InvoiceAccount,
I.InvoiceAmount,
I.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorInvoiceJournalHeaderEntity I
WHERE I.OnHold = 'Yes'
UNION ALL
/* Payment Activities */
SELECT
J.InvoiceId AS [InvoiceNumber],
'Payment Journal Created' AS [Activity],
P.CreatedDateTime AS [EventTime],
P.DataAreaId,
P.AccountDisplayValue AS [VendorAccount],
P.DebitAmount AS [InvoiceAmount],
P.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorPaymentJournalLineEntity P
JOIN Staging_VendorInvoiceJournalHeaderEntity J ON P.InvoiceId = J.InvoiceNumber AND P.DataAreaId = J.DataAreaId
UNION ALL
SELECT
J.InvoiceId AS [InvoiceNumber],
'Payment Journal Approved' AS [Activity],
P.ModifiedDateTime AS [EventTime],
P.DataAreaId,
P.AccountDisplayValue,
P.DebitAmount,
P.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorPaymentJournalLineEntity P
JOIN Staging_VendorInvoiceJournalHeaderEntity J ON P.InvoiceId = J.InvoiceNumber AND P.DataAreaId = J.DataAreaId
WHERE P.PaymentStatus = 'Approved'
UNION ALL
SELECT
J.InvoiceId AS [InvoiceNumber],
'Payment Generated' AS [Activity],
P.ModifiedDateTime AS [EventTime],
P.DataAreaId,
P.AccountDisplayValue,
P.DebitAmount,
P.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorPaymentJournalLineEntity P
JOIN Staging_VendorInvoiceJournalHeaderEntity J ON P.InvoiceId = J.InvoiceNumber AND P.DataAreaId = J.DataAreaId
WHERE P.PaymentStatus = 'Sent'
UNION ALL
SELECT
J.InvoiceId AS [InvoiceNumber],
'Payment Posted' AS [Activity],
P.PostedDate AS [EventTime],
P.DataAreaId,
P.AccountDisplayValue,
P.DebitAmount,
P.CurrencyCode,
'D365 FO',
GETDATE()
FROM Staging_VendorPaymentJournalLineEntity P
JOIN Staging_VendorInvoiceJournalHeaderEntity J ON P.InvoiceId = J.InvoiceNumber AND P.DataAreaId = J.DataAreaId
WHERE P.IsPosted = 'Yes' Kroki
Sprawdź połączenie BYOD: Upewnij się, że na komputerze jest zainstalowany SQL Server Management Studio (SSMS) lub podobne narzędzie i że można połączyć się z bazą Azure SQL skonfigurowaną jako miejsce docelowe Bring Your Own Database (BYOD) dla środowiska Dynamics 365 Finance & Operations.
Sprawdź eksport encji: Otwórz obszar roboczy Data Management w Dynamics 365. Sprawdź, czy następujące encje lub odpowiadające im tabele są skonfigurowane do eksportu do bazy BYOD:
VendInvoiceInfoTable(faktury oczekujące),VendInvoiceInfoLine(pozycje oczekujących faktur),VendInvoiceJour(zaksięgowane faktury),VendTrans(transakcje z dostawcami),LedgerJournalTrans(pozycje dziennika),LedgerJournalTable(nagłówki dziennika) iWorkflowTrackingStatusTable(historia workflow).Skonfiguruj zadanie eksportu: Jeśli te tabele nie są obecnie eksportowane, utwórz nowe zadanie eksportu. Jako Target Data Format wybierz bazę BYOD SQL. Wybierz Incremental Push, aby synchronizować dane bez ponownego eksportowania całości. Uruchom zadanie, aby wypełnić tabele.
Przygotuj środowisko SQL: Otwórz SSMS i połącz się z bazą Azure SQL BYOD. Otwórz nowe okno zapytania.
Ustaw parametry: W skrypcie poniżej znajdź sekcję deklaracji zmiennych na początku. Ustaw zmienne
@StartDatei@EndDatezgodnie z analizowanym okresem. Aby ograniczyć dane do konkretnej jednostki prawnej, zmień warunki filtrowaniaDATAAREAID.Uruchom skrypt: Wykonaj cały skrypt T-SQL. Za pomocą
UNION ALLłączy on dane z wielu tabel w jeden ujednolicony dziennik zdarzeń.Sprawdź dane: Sprawdź, czy w kolumnach
InvoiceNumberlubEventTimenie ma wartości null. Upewnij się, że uwzględniono zarówno zaksięgowane faktury zVendInvoiceJour, jak i oczekujące zVendInvoiceInfoTable.Wyeksportuj wynik: Kliknij prawym przyciskiem myszy siatkę wyników w SSMS i wybierz Save Results As.... Zapisz plik jako CSV (Comma Delimited).
Przygotuj plik do przesłania: Otwórz plik CSV w Excelu lub edytorze tekstu i sprawdź, czy format dat jest zgodny z ISO 8601 (YYYY-MM-DD HH:MM:SS), jeśli wymaga tego ProcessMind. Jeśli skrypt wykonał się poprawnie, dalsze przekształcenia nie powinny być potrzebne.
Prześlij dane do ProcessMind: Zaimportuj plik CSV do ProcessMind i przypisz kolumny:
InvoiceNumberdo Case ID,Activitydo Activity Name, aEventTimedo Timestamp.
Konfiguracja
- Strategia eksportu: W przypadku tabel zawierających dużo danych, takich jak
LedgerJournalTransiVendTrans, używaj opcji Incremental Push, aby ograniczyć obciążenie BYOD. Opcję Full Push stosuj tylko wtedy, gdy podejrzewasz niespójności danych. - Obsługa stref czasowych: Dynamics 365 zapisuje dane w UTC. Skrypt zakłada, że dane są w UTC. Jeśli analiza wymaga czasu lokalnego, zastosuj korektę
DATEADDw skrypcie lub podczas importu do ProcessMind. - Filtrowanie według firmy: Kolumna
DataAreaIdwskazuje jednostkę prawną. Domyślnie skrypt pobiera dane ze wszystkich jednostek. Aby ograniczyć dane do konkretnej spółki zależnej, dodajWHERE DataAreaId = 'usmf'(przykład). - Historia workflow: Tabela
WorkflowTrackingStatusTablezawiera istotne znaczniki czasu akceptacji. Upewnij się, że uwzględniono ją w konfiguracji eksportu BYOD, ponieważ często nie jest dodawana domyślnie. - Przechowywanie danych: Sprawdź, czy procedury czyszczenia w D365 nie usuwają historii zakończonych workflow ani zaksięgowanych pozycji dziennika. Ograniczyłoby to zakres danych historycznych dostępnych do analizy process mining.
Przykładowe zapytanie sql
/* T-SQL Extraction Script for D365 AP Payment Processing */
/* Tables required: VendInvoiceInfoTable, VendInvoiceInfoLine, VendInvoiceJour, VendTrans, LedgerJournalTrans, LedgerJournalTable, WorkflowTrackingStatusTable */
DECLARE @StartDate DATETIME = '2023-01-01 00:00:00';
DECLARE @EndDate DATETIME = GETDATE();
WITH RawData AS (
/* 1. Invoice Created: Pending Invoice Header Creation */
SELECT
T1.Num AS InvoiceNumber,
'Invoice Created' AS Activity,
T1.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
T1.InvoiceAccount AS VendorAccount,
T1.DataAreaId AS CompanyCode,
CAST(T1.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
T1.DueDate AS DueDate,
T1.PurchId AS PurchaseOrderNumber,
T1.CreatedBy AS UserId,
T1.VendorName AS VendorName,
T1.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceInfoTable T1
WHERE T1.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 2. Invoice Updated: Modifications to Pending Invoice */
SELECT
T1.Num AS InvoiceNumber,
'Invoice Updated' AS Activity,
T1.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
T1.InvoiceAccount AS VendorAccount,
T1.DataAreaId AS CompanyCode,
CAST(T1.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
T1.DueDate AS DueDate,
T1.PurchId AS PurchaseOrderNumber,
T1.ModifiedBy AS UserId,
T1.VendorName AS VendorName,
T1.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceInfoTable T1
WHERE T1.ModifiedDateTime BETWEEN @StartDate AND @EndDate
AND T1.ModifiedDateTime > T1.CreatedDateTime
UNION ALL
/* 3. Invoice Matched to PO: Line Matching Success */
SELECT
H.Num AS InvoiceNumber,
'Invoice Matched to PO' AS Activity,
L.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
H.InvoiceAccount AS VendorAccount,
H.DataAreaId AS CompanyCode,
CAST(H.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
H.DueDate AS DueDate,
H.PurchId AS PurchaseOrderNumber,
L.ModifiedBy AS UserId,
H.VendorName AS VendorName,
H.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceInfoLine L
JOIN dbo.VendInvoiceInfoTable H ON L.TableRefId = H.TableRefId AND L.DataAreaId = H.DataAreaId
WHERE L.MatchStatus = 1 /* 1 usually denotes Matched/Passed in enum */
AND L.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 4. Invoice Match Failed: Line Matching Discrepancy */
SELECT
H.Num AS InvoiceNumber,
'Invoice Match Failed' AS Activity,
L.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
H.InvoiceAccount AS VendorAccount,
H.DataAreaId AS CompanyCode,
CAST(H.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
H.DueDate AS DueDate,
H.PurchId AS PurchaseOrderNumber,
L.ModifiedBy AS UserId,
H.VendorName AS VendorName,
H.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceInfoLine L
JOIN dbo.VendInvoiceInfoTable H ON L.TableRefId = H.TableRefId AND L.DataAreaId = H.DataAreaId
WHERE L.MatchStatus = 2 /* 2 usually denotes Failed in enum */
AND L.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 5. Invoice Submitted for Approval: Workflow Submission */
SELECT
T1.Num AS InvoiceNumber,
'Invoice Submitted for Approval' AS Activity,
W.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
T1.InvoiceAccount AS VendorAccount,
T1.DataAreaId AS CompanyCode,
CAST(T1.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
T1.DueDate AS DueDate,
T1.PurchId AS PurchaseOrderNumber,
W.User AS UserId,
T1.VendorName AS VendorName,
T1.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.WorkflowTrackingStatusTable W
JOIN dbo.VendInvoiceInfoTable T1 ON W.ContextRecId = T1.RecId
WHERE W.TrackingStatus = 1 /* Submitted */
AND W.ContextTableId = 1425 /* TableId for VendInvoiceInfoTable, adjust if different in version */
AND W.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 6. Invoice Approved: Workflow Completion */
SELECT
T1.Num AS InvoiceNumber,
'Invoice Approved' AS Activity,
W.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
T1.InvoiceAccount AS VendorAccount,
T1.DataAreaId AS CompanyCode,
CAST(T1.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
T1.DueDate AS DueDate,
T1.PurchId AS PurchaseOrderNumber,
W.User AS UserId,
T1.VendorName AS VendorName,
T1.DocumentDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.WorkflowTrackingStatusTable W
JOIN dbo.VendInvoiceInfoTable T1 ON W.ContextRecId = T1.RecId
WHERE W.TrackingStatus = 2 /* Completed/Approved */
AND W.ContextTableId = 1425
AND W.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 7. Invoice Posted: Creation of VendInvoiceJour */
SELECT
J.InvoiceId AS InvoiceNumber,
'Invoice Posted' AS Activity,
J.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
J.InvoiceAccount AS VendorAccount,
J.DataAreaId AS CompanyCode,
CAST(J.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
J.DueDate AS DueDate,
J.PurchId AS PurchaseOrderNumber,
J.CreatedBy AS UserId,
J.InvoicingName AS VendorName,
J.InvoiceDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendInvoiceJour J
WHERE J.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 8. Payment Block Applied: Updated on VendTrans */
SELECT
J.InvoiceId AS InvoiceNumber,
'Payment Block Applied' AS Activity,
VT.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
J.InvoiceAccount AS VendorAccount,
J.DataAreaId AS CompanyCode,
CAST(J.InvoiceAmount AS DECIMAL(18,2)) AS InvoiceAmount,
J.DueDate AS DueDate,
J.PurchId AS PurchaseOrderNumber,
VT.ModifiedBy AS UserId,
J.InvoicingName AS VendorName,
J.InvoiceDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.VendTrans VT
JOIN dbo.VendInvoiceJour J ON VT.Invoice = J.InvoiceId AND VT.AccountNum = J.InvoiceAccount AND VT.DataAreaId = J.DataAreaId
WHERE VT.Approved = 0 /* 0 indicates Not Approved/Blocked */
AND VT.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 9. Payment Journal Created: Line added to Journal */
SELECT
LJT.Invoice AS InvoiceNumber,
'Payment Journal Created' AS Activity,
LJT.CreatedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
LJT.AccountNum AS VendorAccount,
LJT.DataAreaId AS CompanyCode,
CAST(LJT.AmountCurCredit AS DECIMAL(18,2)) AS InvoiceAmount,
NULL AS DueDate,
NULL AS PurchaseOrderNumber,
LJT.CreatedBy AS UserId,
NULL AS VendorName,
LJT.TransDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.LedgerJournalTrans LJT
WHERE LJT.AccountType = 2 /* Vendor */
AND LJT.Invoice IS NOT NULL AND LJT.Invoice <> ''
AND LJT.CreatedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 10. Payment Journal Approved: Workflow on Journal Header */
SELECT
LJT.Invoice AS InvoiceNumber,
'Payment Journal Approved' AS Activity,
LJH.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
LJT.AccountNum AS VendorAccount,
LJT.DataAreaId AS CompanyCode,
CAST(LJT.AmountCurCredit AS DECIMAL(18,2)) AS InvoiceAmount,
NULL AS DueDate,
NULL AS PurchaseOrderNumber,
LJH.ModifiedBy AS UserId,
NULL AS VendorName,
LJT.TransDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.LedgerJournalTable LJH
JOIN dbo.LedgerJournalTrans LJT ON LJH.JournalNum = LJT.JournalNum AND LJH.DataAreaId = LJT.DataAreaId
WHERE LJH.WorkflowApprovalStatus = 2 /* Approved */
AND LJT.AccountType = 2
AND LJT.Invoice IS NOT NULL AND LJT.Invoice <> ''
AND LJH.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 11. Payment Generated: Payment Status Changed to Sent */
SELECT
LJT.Invoice AS InvoiceNumber,
'Payment Generated' AS Activity,
LJT.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
LJT.AccountNum AS VendorAccount,
LJT.DataAreaId AS CompanyCode,
CAST(LJT.AmountCurCredit AS DECIMAL(18,2)) AS InvoiceAmount,
NULL AS DueDate,
NULL AS PurchaseOrderNumber,
LJT.ModifiedBy AS UserId,
NULL AS VendorName,
LJT.TransDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.LedgerJournalTrans LJT
WHERE LJT.PaymentStatus = 2 /* Sent/Generated */
AND LJT.AccountType = 2
AND LJT.Invoice IS NOT NULL AND LJT.Invoice <> ''
AND LJT.ModifiedDateTime BETWEEN @StartDate AND @EndDate
UNION ALL
/* 12. Payment Posted: Journal Line Posted */
SELECT
LJT.Invoice AS InvoiceNumber,
'Payment Posted' AS Activity,
LJT.ModifiedDateTime AS EventTime,
'D365 FO' AS SourceSystem,
GETDATE() AS LastDataUpdate,
LJT.AccountNum AS VendorAccount,
LJT.DataAreaId AS CompanyCode,
CAST(LJT.AmountCurCredit AS DECIMAL(18,2)) AS InvoiceAmount,
NULL AS DueDate,
NULL AS PurchaseOrderNumber,
LJT.ModifiedBy AS UserId,
NULL AS VendorName,
LJT.TransDate AS InvoiceDate,
'Unknown' AS Department
FROM dbo.LedgerJournalTrans LJT
WHERE LJT.Posted = 1 /* Posted */
AND LJT.AccountType = 2
AND LJT.Invoice IS NOT NULL AND LJT.Invoice <> ''
AND LJT.ModifiedDateTime BETWEEN @StartDate AND @EndDate
)
SELECT *
FROM RawData
WHERE InvoiceNumber IS NOT NULL AND InvoiceNumber <> ''
ORDER BY InvoiceNumber, EventTime; Gotowi do rozpoczęcia?
Skorzystaj z tego szablonu, aby przygotować solidną podstawę danych i już dziś zacząć usprawniać workflow płatności. W razie potrzeby nasz zespół pomoże Państwu powiązać odpowiednie tabele Dynamics 365.
Usprawnij obsługę płatności zobowiązań
Skróć czas cyklu o 30 procent i wyeliminuj opóźnienia w D365.
Nie trzeba podawać danych karty płatniczej. Konfiguracja zajmuje pięć minut.