Szablon danych dla procesu od zakupu do płatności: zamówienia zakupu
Szablon danych dla procesu od zakupu do płatności: zamówienia zakupu
- Zalecane atrybuty do zebrania
- Działania do śledzenia przy mapowaniu procesów
- Praktyczne wskazówki dotyczące pobierania danych
Atrybuty procesu od zakupu do płatności: zamówienia zakupu
| Nazwa | Opis | ||
|---|---|---|---|
|
Czas zdarzenia
EventTime
|
Dokładna data i godzina wystąpienia określonej aktywności lub zdarzenia. | ||
|
Opis
Ten znacznik czasu określa, kiedy miała miejsce każda aktywność w procesie obsługi zamówienia zakupu. Stanowi chronologiczną podstawę procesu i pozwala prawidłowo uporządkować zdarzenia. W analizie procesu znaczniki czasu zdarzeń są niezbędne do obliczania czasu cyklu, odstępów między aktywnościami i całkowitego czasu trwania case. Pomagają wykrywać wąskie gardła, mierzyć wyniki względem SLA i analizować przebieg procesu w czasie. Można na ich podstawie obliczyć na przykład czas między utworzeniem a zatwierdzeniem zamówienia zakupu.
Dlaczego to ważne
Znaczniki czasu są niezbędne do obliczania wszystkich miar opartych na czasie, takich jak czas cyklu i czas trwania. Miary te pomagają wykrywać wąskie gardła procesu.
Skąd pobrać
Dane pobiera się z pól daty i godziny w różnych tabelach, na przykład CreatedDateTime w PurchTable lub dat księgowania w powiązanych tabelach dzienników.
Przykłady
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-11-05T09:12:00Z
|
|||
|
Nazwa aktywności
ActivityName
|
Nazwa konkretnego zdarzenia biznesowego lub etapu, który wystąpił w cyklu życia zamówienia zakupu. | ||
|
Opis
Ten atrybut opisuje pojedynczy etap procesu obsługi zamówienia zakupu, na przykład „Utworzono zamówienie zakupu”, „Zatwierdzono zamówienie zakupu” lub „Zaksięgowano przyjęcie towarów”. Kolejność tych aktywności tworzy przebieg procesu dla każdego zamówienia zakupu. Analiza aktywności stanowi podstawę process mining. Umożliwia wizualizację mapy procesu, wykrywanie wariantów oraz identyfikację często powtarzanych aktywności i tych, które powodują opóźnienia. Znajomość kolejności i częstotliwości aktywności jest niezbędna do usprawniania procesu.
Dlaczego to ważne
Ten atrybut jest niezbędny do utworzenia mapy procesu i poznania kolejności zdarzeń składających się na cykl życia zamówienia zakupu.
Skąd pobrać
Wartość wyznacza się na podstawie logiki biznesowej i zmian statusu w tabelach takich jak PurchTable i PurchReqTable oraz powiązanych dziennikach księgowań, takich jak VendPackingSlipJour lub VendInvoiceJour.
Przykłady
Utworzono zamówienie zakupuZatwierdzono zamówienie zakupuZaksięgowano przyjęcie towarówZafakturowano zamówienie zakupu
|
|||
|
Zamówienie zakupu
PurchaseOrderNumber
|
Unikalny identyfikator zamówienia zakupu, używany jako główny case w analizie procesu. | ||
|
Opis
Numer zamówienia zakupu to główny identyfikator łączący wszystkie powiązane działania, od przygotowania projektu po zakończenie lub anulowanie. Każdy unikalny numer odpowiada jednej instancji procesu obsługi zamówienia zakupu. W process mining ten atrybut służy do odtworzenia pełnego przebiegu każdego zamówienia zakupu. Analiza według tego identyfikatora pokazuje cały cykl życia zamówienia i pomaga wykrywać typowe ścieżki, odstępstwa oraz wąskie gardła dla poszczególnych zamówień.
Dlaczego to ważne
To podstawowy identyfikator potrzebny do odtworzenia przebiegu procesu i analizy drogi każdego zamówienia zakupu od początku do końca.
Skąd pobrać
To klucz główny w tabeli nagłówków zamówień zakupu, zwykle PurchTable, w polu PurchId w Microsoft Dynamics 365.
Przykłady
PO-001245PO-001246PO-001247
|
|||
|
Ostatnia aktualizacja danych
LastDataUpdate
|
Znacznik czasu wskazujący, kiedy ostatnio odświeżono dane dotyczące procesu. | ||
|
Opis
Ten atrybut zapisuje datę i godzinę ostatniej ekstrakcji danych z systemu źródłowego. Informuje, jak aktualne są analizowane dane. Znajomość czasu ostatniej aktualizacji pozwala ocenić, czy analizowane dane odzwierciedlają bieżący przebieg procesu. Ułatwia też ocenę przydatności analizy i planowanie regularnego odświeżania danych.
Dlaczego to ważne
Informuje, na ile aktualne są dane, dzięki czemu można ocenić, jak świeża jest analiza procesu.
Skąd pobrać
To atrybut metadanych generowany i zapisywany podczas wczytywania danych.
Przykłady
2024-05-21T05:00:00Z
|
|||
|
System źródłowy
SourceSystem
|
Wskazuje system, z którego pobrano dane. | ||
|
Opis
Ten atrybut wskazuje aplikację źródłową, z której pochodzą dane zamówień zakupu. W tym modelu danych wartością będzie zwykle „Microsoft Dynamics 365”. W dużych organizacjach procesy zakupowe mogą obejmować kilka systemów. Ten atrybut wspiera zarządzanie danymi i pozwala ustalić ich pochodzenie, co ma szczególne znaczenie przy łączeniu danych z różnych źródeł.
Dlaczego to ważne
Informuje o pochodzeniu danych, co ma znaczenie dla zarządzania danymi, ich weryfikacji i poznania środowiska technologicznego procesu.
Skąd pobrać
To stała wartość dodawana podczas ekstrakcji i transformacji danych w celu oznaczenia zbioru danych.
Przykłady
Microsoft Dynamics 365 F&OD365
|
|||
|
Łączna wartość zamówienia zakupu
PurchaseOrderTotalAmount
|
Łączna wartość pieniężna zamówienia zakupu. | ||
|
Opis
Ten atrybut określa łączny koszt wszystkich towarów i usług ujętych w zamówieniu zakupu. To ważna miara finansowa procesu zakupowego. Analiza procesu według wartości zamówienia może ujawnić istotne zależności. Na przykład zamówienia o wyższej wartości mogą podlegać bardziej rygorystycznej akceptacji lub mieć dłuższy czas realizacji. Atrybut służy też do raportowania finansowego i grupowania zamówień według przedziałów wartości na potrzeby analizy.
Dlaczego to ważne
Umożliwia analizę finansową procesu zakupowego i pomaga ustalić, jak wartość zamówienia wpływa na przebieg procesu, na przykład czas i ścieżkę akceptacji.
Skąd pobrać
Wartość można obliczyć, sumując LineAmount w tabeli PurchLine dla danego PurchId, albo pobrać z pól kwoty w nagłówku tabeli PurchTable.
Przykłady
5250.00120.50150000.00
|
|||
|
Nazwa dostawcy
VendorName
|
Nazwa dostawcy, dla którego utworzono zamówienie zakupu. | ||
|
Opis
Ten atrybut zawiera nazwę zewnętrznego dostawcy towarów lub usług. To ważny wymiar analizy zakupów. Podział procesu według dostawcy pozwala ocenić jego wyniki. Można analizować terminowość dostaw, liczbę zwrotów i wyniki kontroli jakości dla każdego dostawcy. Ułatwia to wskazanie rzetelnych partnerów oraz tych, którzy mogą powodować opóźnienia lub problemy z jakością.
Dlaczego to ważne
Ten atrybut wspiera ocenę dostawców, umożliwiając analizę czasu dostawy, liczby zwrotów i ogólnej rzetelności każdego z nich.
Skąd pobrać
Konto dostawcy jest przechowywane w PurchTable w polu OrderAccount. Nazwę pobiera się przez połączenie z VendTable.
Przykłady
Contoso Office SuppliesFabrikam RoboticsNorthwind Traders
|
|||
|
Nazwa użytkownika
UserName
|
Nazwa użytkownika, który wykonał określoną aktywność. | ||
|
Opis
Ten atrybut wskazuje osobę odpowiedzialną za wykonanie zdarzenia, na przykład utworzenie, zatwierdzenie lub zmianę zamówienia zakupu. Może zawierać identyfikator użytkownika systemu lub imię i nazwisko. Analiza aktywności użytkowników pomaga ocenić rozkład obciążenia, określić potrzeby szkoleniowe i wskazać osoby lub zespoły związane z odstępstwami od procesu. Jest niezbędna w dashboardach dotyczących pracy osób zatwierdzających. Pozwala też filtrować proces według aktywności wykonanych przez konkretnych użytkowników.
Dlaczego to ważne
Umożliwia analizę wyników według użytkownika, pomaga wykrywać wąskie gardła związane z konkretnymi osobami i wskazuje odpowiedzialność za poszczególne etapy procesu.
Skąd pobrać
Dane można znaleźć w polach takich jak CreatedBy lub ModifiedBy w tabelach, na przykład PurchTable. Informacje o użytkownikach są zwykle przechowywane w tabeli UserInfo.
Przykłady
Alice JohnsonBob WilliamsAdministrator systemu
|
|||
|
Status zamówienia zakupu
PurchaseOrderStatus
|
Bieżący status zamówienia zakupu w jego cyklu życia. | ||
|
Opis
Ten atrybut wskazuje bieżący stan zamówienia zakupu, na przykład „Otwarte”, „Przyjęte”, „Zafakturowane” lub „Anulowane”. Odzwierciedla wynik ostatniej aktywności. Śledzenie statusu pomaga sprawdzić stan wszystkich otwartych zamówień zakupu. W process mining można analizować wyniki case, na przykład filtrować zamówienia zakończone statusem „Anulowane”, aby ustalić przyczyny anulowania.
Dlaczego to ważne
Pokazuje bieżący stan zamówienia zakupu. Ułatwia filtrowanie case i analizę wyników procesu, takich jak odsetek zakończonych lub anulowanych zamówień.
Skąd pobrać
Dane znajdują się w PurchTable. Główne pola statusu to DocumentState i PurchStatus.
Przykłady
OtwartePrzyjęteZafakturowaneAnulowane
|
|||
|
Wymagana data dostawy
RequestedDeliveryDate
|
Data, do której firma oczekuje od dostawcy dostawy towarów lub usług. | ||
|
Opis
Datę określa się w zamówieniu zakupu, aby przekazać dostawcy oczekiwany termin dostawy. Stanowi punkt odniesienia przy ocenie terminowości dostaw. Ten atrybut jest niezbędny w dashboardzie „Terminowość dostawców” i przy pomiarze KPI „wskaźnik dostaw na czas”. Porównanie RequestedDeliveryDate z faktyczną datą przyjęcia towarów pozwala ocenić rzetelność dostawców i wykrywać powtarzające się opóźnienia w łańcuchu dostaw.
Dlaczego to ważne
To punkt odniesienia przy pomiarze terminowości dostaw, ważny KPI służący do oceny rzetelności dostawców i sprawności łańcucha dostaw.
Skąd pobrać
Zazwyczaj znajduje się w tabeli PurchTable (na poziomie nagłówka) lub PurchLine (na poziomie pozycji) jako DeliveryDate.
Przykłady
2023-11-152023-12-012024-01-20
|
|||
|
Czy dostawa była terminowa
IsOnTimeDelivery
|
Wartość logiczna wskazująca, czy towary przyjęto w dniu wymaganej dostawy lub wcześniej. | ||
|
Opis
Ten obliczany atrybut porównuje znacznik czasu działania „Zaksięgowanie przyjęcia towaru” z datą RequestedDeliveryDate. Przyjmuje wartość „true”, jeśli data przyjęcia przypada w dniu wymaganej dostawy lub wcześniej. Atrybut ten bezpośrednio wspiera obliczanie KPI „Odsetek dostaw na czas”. Ułatwia analizę efektywności dostawców oraz filtrowanie i wizualizację dostaw terminowych i opóźnionych, co jest podstawą dashboardu „Terminowość dostaw dostawców”.
Dlaczego to ważne
Jednoznacznie wskazuje, czy dostawa była terminowa, i ułatwia obliczanie KPI dotyczących terminowości oraz ocenę dostawców.
Skąd pobrać
To obliczany atrybut wyznaczany przez porównanie RequestedDeliveryDate z wartością EventTime działania „Zaksięgowanie przyjęcia towaru”.
Przykłady
truefalse
|
|||
|
Czy zamówienie zakupu zostało zmienione
IsPurchaseOrderChanged
|
Wartość logiczna wskazująca, czy zamówienie zakupu zmieniono po jego wstępnym zatwierdzeniu. | ||
|
Opis
Ten obliczany atrybut przyjmuje wartość „true”, jeśli po działaniu „Zatwierdzenie zamówienia zakupu” w danym case wystąpi działanie „Zmiana zamówienia zakupu”. Ułatwia analizę poprawek i modyfikacji. Atrybut ten służy do obliczania KPI „Odsetek zmian zamówień zakupu po zatwierdzeniu” oraz do analizy na dashboardzie „Trendy zmian zamówień zakupu”. Pozwala łatwo wyodrębnić zamówienia wymagające poprawek i ustalić przyczyny zmian.
Dlaczego to ważne
Ułatwia mierzenie liczby poprawek i częstotliwości zmian, które wskazują na niestabilność i niską efektywność procesu.
Skąd pobrać
To obliczany atrybut wyznaczany na podstawie kolejności działań w dzienniku zdarzeń.
Przykłady
truefalse
|
|||
|
Dział
DepartmentName
|
Nazwa działu, który zgłosił zapotrzebowanie zakupu lub złożył zamówienie. | ||
|
Opis
Ten atrybut wskazuje jednostkę biznesową lub dział odpowiedzialny za zakup. Często ustala się go na podstawie osoby, która utworzyła zapotrzebowanie zakupu. Analiza procesu według działu pomaga zrozumieć, jak różne części organizacji korzystają z procesu zakupowego. Ułatwia wskazanie działów, w których akceptacja trwa dłużej, częściej zmienia się zamówienia zakupu lub występują określone wzorce zakupowe. Dzięki temu można zaplanować ukierunkowane usprawnienia.
Dlaczego to ważne
Umożliwia porównanie wyników procesu między jednostkami biznesowymi i pomaga wykrywać zachowania charakterystyczne dla danego działu, wąskie gardła oraz nieefektywności.
Skąd pobrać
Informacje te są często powiązane z osobą zgłaszającą lub tworzącą zapotrzebowanie zakupu (PurchReqTable) albo zamówienie zakupu (PurchTable) oraz z jej działem w module HR.
Przykłady
FinanseITProdukcjaMarketing
|
|||
|
Imię i nazwisko osoby zatwierdzającej
ApproverName
|
Imię i nazwisko użytkownika, który zatwierdził zamówienie zakupu lub etap workflow zatwierdzania. | ||
|
Opis
Ten atrybut wskazuje kierownika lub użytkownika, który formalnie zatwierdził zamówienie zakupu, umożliwiając jego dalszą realizację. W przypadku wielopoziomowego workflow zatwierdzania jedno zamówienie może mieć kilku zatwierdzających. Śledzenie osób zatwierdzających jest podstawą analiz na dashboardach „Czas zatwierdzania zamówienia zakupu” i „Wskaźniki efektywności osób zatwierdzających”. Pozwala mierzyć czas potrzebny każdej osobie na zatwierdzenie, wykrywać wąskie gardła w ścieżce akceptacji oraz oceniać rozkład obciążenia i efektywność.
Dlaczego to ważne
Umożliwia analizę procesu zatwierdzania, pomaga wykrywać wąskie gardła oraz mierzyć efektywność i obciążenie poszczególnych osób zatwierdzających.
Skąd pobrać
Informacje o zatwierdzeniach są zwykle przechowywane w tabelach śledzących workflow, a nie bezpośrednio w PurchTable. Trzeba odpytać historię workflow powiązaną z zamówieniem zakupu.
Przykłady
Charles GreenDiana PrinceEdward Nigma
|
|||
|
Kategoria zakupu
PurchaseCategory
|
Klasyfikacja kupowanego towaru lub usługi, na przykład „sprzęt IT” albo „materiały biurowe”. | ||
|
Opis
Ten atrybut pozwala grupować pozycje zamówień zakupu według kategorii. Ułatwia analizę struktury wydatków i różnic w przebiegu procesu dla różnych rodzajów zakupów. Filtrowanie analizy procesu według kategorii zakupu może ujawnić różnice w sposobie realizacji. Na przykład zakup środków trwałych może trwać dłużej i być bardziej złożony niż zakup materiałów eksploatacyjnych. Atrybut ten służy na dashboardach do analizy zmian zamówień i zwrotów według kategorii.
Dlaczego to ważne
Pozwala podzielić proces według rodzaju kupowanych towarów lub usług i sprawdzić, jak różnią się jego przebieg i wydatki w poszczególnych kategoriach.
Skąd pobrać
Kategorie pozycji są powiązane z udostępnionymi produktami (InventTable), które są następnie używane w PurchLine. Same informacje o kategoriach znajdują się w tabelach zarządzania kategoriami.
Przykłady
Sprzęt ITMateriały biuroweUsługi profesjonalneSurowce
|
|||
|
Kod firmy
CompanyCode
|
Identyfikator podmiotu prawnego lub firmy składającej zamówienie zakupu. | ||
|
Opis
W środowisku obejmującym wiele firm ten atrybut wskazuje podmiot prawny dokonujący zakupu. Jest to podstawowa informacja organizacyjna. Pozwala porównywać proces P2P między podmiotami prawnymi w ramach jednej organizacji. Może ujawnić różnice w efektywności procesu, zgodności i zarządzaniu dostawcami, a także pomóc w standaryzacji.
Dlaczego to ważne
Niezbędny w organizacjach obejmujących wiele podmiotów prawnych. Umożliwia porównywanie i standaryzację procesu zakupowego między nimi.
Skąd pobrać
To pole DataAreaId, występujące w niemal każdej tabeli Dynamics 365, w tym w PurchTable.
Przykłady
USMFDEMFGBSI
|
|||
|
Miejsce dostawy
DeliveryLocation
|
Konkretna lokalizacja, magazyn lub adres, pod który należy dostarczyć towary. | ||
|
Opis
Ten atrybut określa fizyczne miejsce dostawy pozycji zamówienia zakupu. Może to być magazyn, konkretne biuro lub miejsce realizacji projektu. Analiza procesu według miejsca dostawy pomaga wykrywać opóźnienia i wąskie gardła charakterystyczne dla danego regionu lub lokalizacji, zwłaszcza przy przyjmowaniu towarów. Dashboard „Czas obsługi przyjęcia towaru” może wykorzystywać ten atrybut do porównania efektywności w różnych lokalizacjach.
Dlaczego to ważne
Pomaga wykrywać różnice w przebiegu procesu i opóźnienia związane z konkretną lokalizacją, zwłaszcza na etapach przyjęcia towaru i kontroli jakości.
Skąd pobrać
Adres i miejsce dostawy są zapisane w PurchTable. Można je też domyślnie pobrać z ustawień firmy lub dostawcy.
Przykłady
Magazyn główny ABiuro w budynku CCentrum dystrybucyjne na zachodnim wybrzeżu
|
|||
|
Powód zwrotu
ReturnReason
|
Powód podany przy zwrocie dostawcy towarów z zamówienia zakupu. | ||
|
Opis
Gdy wystąpi działanie „Zwrot towaru do dostawcy”, ten atrybut zapisuje uzasadnienie zwrotu, na przykład „towar uszkodzony”, „dostarczono niewłaściwy produkt” lub „niska jakość”. Dane te są bardzo przydatne na dashboardzie „Odsetek zwrotów z zamówień zakupu”. Analiza przyczyn zwrotów pomaga ustalić ich źródło: jakość towarów dostawcy, błędy przy składaniu zamówień czy problemy z dostawą. Dzięki temu można podjąć konkretne działania, aby ograniczyć liczbę zwrotów.
Dlaczego to ważne
Pokazuje, dlaczego towary są zwracane, i pomaga ustalić, czy problem dotyczy jakości dostawcy, poprawności zamówienia czy logistyki.
Skąd pobrać
Powody zwrotu są zwykle zapisywane w transakcjach zleceń zwrotu lub jako kody przyczyn powiązane z dziennikami ujemnych przyjęć.
Przykłady
Uszkodzony podczas transportuDostarczono niewłaściwy produktNie przeszedł kontroli jakości
|
|||
|
Zapotrzebowanie zakupu
PurchaseRequisitionNumber
|
Identyfikator zapotrzebowania zakupu poprzedzającego zamówienie zakupu. | ||
|
Opis
Ten atrybut łączy zamówienie zakupu z pierwotnym wnioskiem wewnętrznym, czyli zapotrzebowaniem zakupu. Nie każde zamówienie zakupu wynika z zapotrzebowania. To powiązanie jest niezbędne do analizy całego procesu „od zapotrzebowania do zamówienia zakupu”. Pozwala mierzyć KPI „czas przekształcenia zapotrzebowania w zamówienie zakupu” i sprawdzać, jak szybko potrzeby wewnętrzne przekładają się na zamówienia u dostawców. Pomaga też analizować zgodność, na przykład wykrywać zamówienia zakupu utworzone bez formalnego zapotrzebowania.
Dlaczego to ważne
Łączy zamówienie zakupu z pierwotnym zapotrzebowaniem, umożliwiając analizę czasu od zgłoszenia potrzeby do złożenia zamówienia i kontrolę zgodności procesu.
Skąd pobrać
Dane znajdują się w tabeli PurchLine, w polu PurchReqId, które wskazuje powiązany rekord w PurchReqTable.
Przykłady
PR-000871PR-000872PR-000873
|
|||
Działania w procesie od zakupu do płatności: zamówienia zakupu
| Działanie | Opis | ||
|---|---|---|---|
|
Utworzono zamówienie zakupu
|
To zdarzenie oznacza utworzenie w systemie roboczego dokumentu zamówienia zakupu. Rejestruje się je na podstawie znacznika czasu utworzenia rekordu nagłówka zamówienia, często po zatwierdzeniu zapotrzebowania. | ||
|
Dlaczego to ważne
To przejście od wewnętrznego zapotrzebowania do formalnego dokumentu zakupu. Jest punktem wyjścia do pomiaru czasu obsługi i akceptacji zamówienia zakupu.
Skąd pobrać
Zdarzenie oznacza utworzenie rekordu w PurchTable. Znacznik czasu aktywności znajduje się w polu createdDateTime tej tabeli.
Rejestrowanie
Dla każdego zamówienia zakupu pobierz znacznik czasu utworzenia z PurchTable.
Typ zdarzenia
explicit
|
|||
|
Utworzono zapotrzebowanie zakupu
|
To zdarzenie oznacza utworzenie zapotrzebowania zakupu, czyli formalnego wniosku o towary lub usługi. Jest rejestrowane w chwili utworzenia nowego rekordu w tabeli zapotrzebowań zakupu i wyznacza początek zapotrzebowania na zakup. | ||
|
Dlaczego to ważne
To początkowe zdarzenie procesu zamówienia zakupu. Analiza czasu od tego momentu do utworzenia zamówienia pozwala ocenić sprawność procesu wewnętrznego i szybkość reakcji na zapotrzebowanie.
Skąd pobrać
Zdarzenie odpowiada utworzeniu rekordu w PurchReqTable. Czas zdarzenia wyznacza znacznik czasu utworzenia rekordu (createdDateTime).
Rejestrowanie
Dla każdego zapotrzebowania zakupu pobierz znacznik czasu utworzenia z PurchReqTable.
Typ zdarzenia
explicit
|
|||
|
Wysłano zamówienie zakupu do dostawcy
|
To zdarzenie oznacza przekazanie zatwierdzonego zamówienia zakupu dostawcy. Rejestruje się je przy potwierdzeniu zamówienia, które tworzy dziennik potwierdzenia i zwykle uruchamia wysyłkę dokumentu. | ||
|
Dlaczego to ważne
To pierwszy etap kontaktu z dostawcą i początek pomiaru czasu realizacji dostawy. Ma znaczenie przy ocenie dostawców i pomiarze KPI „wskaźnik dostaw na czas”.
Skąd pobrać
Zdarzenie oznacza utworzenie rekordu w tabeli PurchPurchaseOrderJour, czyli dzienniku potwierdzeń zamówień zakupu. Datę utworzenia tego dziennika przyjmuje się za znacznik czasu aktywności.
Rejestrowanie
Użyj znacznika czasu utworzenia pierwszego rekordu PurchPurchaseOrderJour dla danego zamówienia zakupu.
Typ zdarzenia
explicit
|
|||
|
Zakończono obsługę zamówienia zakupu
|
Oznacza pomyślne zakończenie cyklu życia zamówienia zakupu, gdy wszystkie towary zostały przyjęte, a faktury zaksięgowane. Zdarzenie zwykle wywnioskuje się ze zmiany statusu zamówienia na końcowy, zamknięty. | ||
|
Dlaczego to ważne
To zdarzenie wyznacza koniec pomyślnej instancji procesu. Pomiar „całkowitego czasu obsługi zamówienia zakupu” od utworzenia do zakończenia daje pełny obraz sprawności procesu.
Skąd pobrać
Zdarzenie można wywnioskować z pól statusu w PurchTable, na przykład gdy DocumentState ma wartość „Invoiced”, a statusy pozycji wskazują na pełne przyjęcie i zafakturowanie.
Rejestrowanie
Ustal znacznik czasu zmiany statusu nagłówka i pozycji zamówienia zakupu na końcowy, zamknięty, na przykład „Invoiced”.
Typ zdarzenia
inferred
|
|||
|
Zaksięgowano przyjęcie towarów
|
Oznacza formalne zarejestrowanie w systemie towarów przyjętych w ramach zamówienia zakupu. Zdarzenie jest rejestrowane przy zaksięgowaniu dziennika przyjęcia produktów. | ||
|
Dlaczego to ważne
To ważny etap, który aktualizuje stan zapasów i rozpoczyna proces uzgadniania faktury. Wyznacza koniec pomiaru „wskaźnika dostaw na czas” i czasu realizacji dostawy.
Skąd pobrać
Zdarzenie można odczytać z utworzenia dziennika przyjęcia produktów przechowywanego w VendPackingSlipJour. Pole createdDateTime lub PackingSlipDate w tej tabeli wskazuje, kiedy towary zostały formalnie przyjęte.
Rejestrowanie
Użyj znacznika czasu utworzenia lub zaksięgowania rekordu VendPackingSlipJour powiązanego z zamówieniem zakupu.
Typ zdarzenia
explicit
|
|||
|
Zatwierdzono zamówienie zakupu
|
Oznacza ostateczną akceptację zamówienia zakupu, która upoważnia do wysłania go do dostawcy. Zdarzenie zwykle wywnioskuje się ze zmiany statusu zamówienia albo odczytuje bezpośrednio z historii workflow. | ||
|
Dlaczego to ważne
To ważny etap, ponieważ dalsze działania są możliwe dopiero po zatwierdzeniu zamówienia zakupu. Jego analiza pomaga wykrywać wąskie gardła akceptacji i mierzyć KPI „czas akceptacji zamówienia zakupu”.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany pola DocumentState w PurchTable na „Approved”. Można też użyć znacznika czasu zakończenia ostatniego etapu akceptacji w WorkflowTrackingStatusTable.
Rejestrowanie
Ustal znacznik czasu zmiany pola DocumentState w PurchTable na „Approved”.
Typ zdarzenia
inferred
|
|||
|
Anulowano zamówienie zakupu
|
Oznacza zakończenie zamówienia zakupu przed jego pełną realizacją. Zdarzenie rejestruje się na podstawie określonej zmiany statusu dokumentu zamówienia. | ||
|
Dlaczego to ważne
Anulowanie to ważna ścieżka wyjątkowa. Analiza częstotliwości i przyczyn anulowań może ujawnić problemy z planowaniem lub rzetelnością dostawców.
Skąd pobrać
Zdarzenie można wywnioskować ze zmiany pola DocumentState w PurchTable na „Canceled”. Znacznik czasu tej zmiany wyznacza moment zdarzenia.
Rejestrowanie
Ustal znacznik czasu ustawienia pola DocumentState w PurchTable na „Canceled”.
Typ zdarzenia
inferred
|
|||
|
Dostawca potwierdził zamówienie zakupu
|
Oznacza potwierdzenie przez dostawcę otrzymania zamówienia i jego warunków. Często jest to ręczne wprowadzenie danych na podstawie korespondencji z dostawcą. | ||
|
Dlaczego to ważne
Potwierdzenie dostawcy daje pewność, że zamówienie jest realizowane. Opóźnienia lub rozbieżności na tym etapie mogą sygnalizować problemy z realizacją.
Skąd pobrać
Zdarzenie zwykle wywnioskuje się z uzupełnienia pól daty lub statusu związanych z potwierdzeniem w PurchTable, na przykład daty potwierdzenia dostawy. Może nie być osobnym zdarzeniem.
Rejestrowanie
Wywnioskuj zdarzenie z uzupełnienia konkretnego pola daty potwierdzenia w PurchTable lub PurchLine.
Typ zdarzenia
inferred
|
|||
|
Przekazano zamówienie zakupu do akceptacji
|
Oznacza moment formalnego przekazania roboczego zamówienia zakupu do workflow akceptacji. Zwykle jest to jawna czynność użytkownika rejestrowana w dziennikach workflow. | ||
|
Dlaczego to ważne
To zdarzenie rozpoczyna cykl akceptacji zamówienia zakupu. Jego śledzenie pozwala dokładnie zmierzyć czas oczekiwania na akceptację i całkowity czas jej trwania.
Skąd pobrać
Zdarzenie można odczytać z tabeli WorkflowTrackingStatusTable dla zamówienia zakupu. Tabela rejestruje przekazanie do akceptacji i jego znacznik czasu.
Rejestrowanie
W historii workflow powiązanej z rekordem PurchTable znajdź zdarzenie „Submitted”.
Typ zdarzenia
explicit
|
|||
|
Przeprowadzono kontrolę jakości
|
Oznacza zakończenie kontroli jakości przyjętych towarów. Zdarzenie jest często obsługiwane w module zarządzania jakością lub rejestrowane jako zmiana statusu. | ||
|
Dlaczego to ważne
Ten etap może być istotnym wąskim gardłem między przyjęciem towarów a udostępnieniem ich do użycia. Analiza czasu jego trwania pomaga poprawić KPI „czas kontroli jakości”.
Skąd pobrać
Zdarzenie można wywnioskować z zakończenia zlecenia kontroli jakości (InventQualityOrderTable) powiązanego z przyjęciem zamówienia zakupu. Zdarzenie wyznacza znacznik czasu zmiany statusu na „Passed” lub „Failed”.
Rejestrowanie
Śledź znacznik czasu zakończenia statusu w InventQualityOrderTable powiązanej z pozycją zamówienia zakupu.
Typ zdarzenia
inferred
|
|||
|
Zafakturowano zamówienie zakupu
|
To zdarzenie oznacza otrzymanie i zaksięgowanie faktury dostawcy powiązanej z zamówieniem zakupu. Łączy proces zakupowy z procesem płatności. | ||
|
Dlaczego to ważne
To ostatni etap przed płatnością i ważny punkt przy obliczaniu ostatecznego kosztu zakupu. Wyznacza koniec analizy uzgadniania trójstronnego.
Skąd pobrać
Zdarzenie rejestruje się przy zaksięgowaniu dziennika faktury dostawcy (VendInvoiceJour) dopasowanego do zamówienia zakupu. Znacznik czasu stanowi pole InvoiceDate lub data księgowania tego rekordu.
Rejestrowanie
Użyj znacznika czasu księgowania z tabeli VendInvoiceJour powiązanej z rekordem PurchTable.
Typ zdarzenia
explicit
|
|||
|
Zatwierdzono zapotrzebowanie zakupu
|
Oznacza formalne zatwierdzenie zapotrzebowania zakupu przez upoważnionego kierownika. Zdarzenie jest zwykle rejestrowane w historii workflow lub na podstawie zmiany statusu rekordu zapotrzebowania. | ||
|
Dlaczego to ważne
Zatwierdzenie to ważny etap, który umożliwia przekształcenie zapotrzebowania w zamówienie zakupu. Opóźnienia na tym etapie wpływają na cały harmonogram zakupów.
Skąd pobrać
Zdarzenie można odczytać z tabeli WorkflowTrackingStatusTable powiązanej z zapotrzebowaniem zakupu albo wywnioskować ze zmiany pola statusu w PurchReqTable na „Approved”.
Rejestrowanie
Użyj znacznika czasu zakończenia ostatniego etapu akceptacji w historii workflow zapotrzebowania.
Typ zdarzenia
explicit
|
|||
|
Zmieniono zamówienie zakupu
|
To zdarzenie obejmuje każdą zmianę zamówienia zakupu po jego zatwierdzeniu. Dynamics 365 może przechowywać kolejne wersje zamówienia, co pozwala wykrywać wprowadzone zmiany. | ||
|
Dlaczego to ważne
Śledzenie zmian pomaga wykrywać ponowną pracę, oceniać stabilność procesu i mierzyć „wskaźnik zmian zamówień zakupu”. Zmiany mogą powodować opóźnienia i różnice w kosztach.
Skąd pobrać
Zdarzenie można wywnioskować, porównując różne wersje zamówienia zakupu zapisane w tabelach archiwalnych lub tabelach wersji, na przykład PurchTableHistory. Wzrost numeru wersji oznacza zmianę.
Rejestrowanie
Znajdź rekordy, w których numer wersji w PurchTable wzrósł po zatwierdzeniu zamówienia.
Typ zdarzenia
inferred
|
|||
|
Zwrócono towary dostawcy
|
Oznacza zwrot wcześniej przyjętych towarów dostawcy z powodu uszkodzenia, niezgodności lub innych problemów. Zdarzenie rejestruje się przez zaksięgowanie transakcji zwrotu. | ||
|
Dlaczego to ważne
Zwroty wskazują na problemy w procesie i dodatkowe koszty. Śledzenie tego zdarzenia pomaga obliczyć „wskaźnik zwrotów zamówień zakupu” i wykrywać problemy z dostawcami lub produktami.
Skąd pobrać
Zdarzenie można wywnioskować z utworzenia zamówienia zakupu z ujemną ilością albo osobnego dokumentu zwrotu powiązanego z pierwotnym zamówieniem. Czas zdarzenia wyznacza data transakcji zaksięgowania zwrotu.
Rejestrowanie
Znajdź zaksięgowane zamówienie zwrotu zakupu lub notę debetową powiązaną z pierwotnym zamówieniem zakupu.
Typ zdarzenia
explicit
|
|||
Instrukcje pobierania danych
Gotowi do rozpoczęcia?
Ten szablon zawiera wszystko, czego potrzeba, aby rozpocząć usprawnianie procesu obsługi zamówień zakupu w ramach procesu od zakupu do płatności. Już dziś zacznijcie usprawniać operacje zakupowe.
Już teraz usprawnijcie proces od zakupu do płatności: zamówienia zakupu
Wykryjcie nieefektywności i skróćcie cykl P2P nawet o 30%.
Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.