> Ciągłe doskonalenie procesów > Order to Cash fakturowanie i wystawianie faktur > Salesforce Sales Cloud > Szablon danych

Szablon danych Order to Cash: fakturowanie

Salesforce Sales Cloud

← Wróć do przewodnika ulepszania procesów

Atrybuty procesu Order to Cash: fakturowanie(19) Działania w procesie Order to Cash: fakturowanie(13) Instrukcje pozyskiwania danych(3)

Szablon danych Order to Cash: fakturowanie

Ten szablon przedstawia najważniejsze atrybuty danych i działania potrzebne do skutecznej analizy procesu Order to Cash: fakturowanie. Zawiera listę informacji do zebrania w dzienniku zdarzeń oraz praktyczne wskazówki dotyczące ich pozyskiwania. Skorzystajcie z niego, aby usprawnić działania związane z process mining i uzyskać przydatne informacje o procesie.

Zalecane atrybuty do zebrania
Najważniejsze działania do śledzenia
Wskazówki dotyczące pozyskiwania danych

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

Pobierz szablon

Atrybuty procesu Order to Cash: fakturowanie

To zalecane pola danych, które warto uwzględnić w dzienniku zdarzeń, aby kompleksowo analizować proces Order to Cash: fakturowanie i rejestrować wszystkie istotne informacje.

3 Wymagane 5 Zalecane 11 Opcjonalne

	Nazwa	Opis
	Czas zdarzenia EventTime	Timestamp wskazujący, kiedy wystąpiła dana czynność.
Opis Ten atrybut określa datę i godzinę każdej czynności. Jest niezbędny do ustalenia kolejności zdarzeń i analizy wyników. Timestamps wyznaczają sekwencję zdarzeń i pozwalają obliczyć czas między nimi. W analizie procesu czas zdarzenia służy do obliczania wszystkich miar opartych na czasie, w tym czasu cyklu, czasu oczekiwania i czasu trwania poszczególnych czynności. Jest podstawą KPI, takich jak „Average Invoice Cycle Time” i „DSO”, oraz dashboardów „Invoice Approval Cycle Time” i „Payment Reconciliation Performance”. Dlaczego to ważne Ten timestamp pozwala prawidłowo ustalić kolejność zdarzeń i obliczyć miary wyników, takie jak czas cyklu i czas trwania czynności. Dzięki temu można wykrywać opóźnienia. Skąd pobrać Dane często pochodzą z systemowych pól timestamp, takich jak `CreatedDate` lub `LastModifiedDate` obiektu Invoice albo powiązanych rekordów Task lub Event. Przykłady 2023-04-15T10:00:00Z2023-04-16T14:30:00Z2023-05-20T09:05:12Z
	Nazwa czynności ActivityName	Nazwa konkretnego zdarzenia biznesowego, które wystąpiło w procesie fakturowania.
Opis Ten atrybut opisuje osiągnięty etap lub kamień milowy w cyklu życia faktury, na przykład „Wystawienie faktury” lub „Otrzymanie płatności”. Czynności te tworzą węzły mapy procesu. Analiza sekwencji nazw czynności jest podstawą process mining. Pokazuje rzeczywisty przebieg procesu i pozwala porównać go z zaprojektowanym przebiegiem. Ułatwia wykrywanie odchyleń, wąskich gardeł między poszczególnymi etapami i pętli poprawek. Wspiera też dashboardy, takie jak „Billing Process Rework & Errors” i „Billing Compliance Violation Report”. Dlaczego to ważne Atrybut określa etapy procesu, tworzy podstawę mapy procesu i umożliwia analizę workflow, wąskich gardeł oraz odchyleń. Skąd pobrać Atrybut jest zwykle ustalany na podstawie zmian pola Status obiektu Invoice lub rekordów powiązanych obiektów, takich jak Task lub Event, które rejestrują konkretne działania. Przykłady Wystawienie fakturyZatwierdzenie fakturyWysłanie faktury do klientaPłatność otrzymana
	Numer faktury InvoiceNumber	Unikalny identyfikator każdej faktury, który służy jako główny identyfikator sprawy w procesie fakturowania.
Opis Numer faktury to główny atrybut, który łączy wszystkie powiązane czynności dotyczące fakturowania w jedną sprawę. Każdy numer oznacza osobny dokument rozliczeniowy wysłany klientowi. W analizie process mining ten atrybut pozwala śledzić cały cykl życia faktury, od jej wystawienia po otrzymanie płatności i zamknięcie. Jest niezbędny do utworzenia mapy procesu i obliczania KPI dla poszczególnych spraw, takich jak „Average Invoice Cycle Time” i „Days Sales Outstanding”. Analiza według numeru faktury pomaga wykrywać wąskie gardła, pętle poprawek i odstępstwa od zasad w poszczególnych przypadkach. Dlaczego to ważne To podstawowy identyfikator, który łączy wszystkie powiązane zdarzenia dotyczące faktury i pozwala prześledzić cały proces fakturowania dla każdej transakcji. Skąd pobrać Zazwyczaj jest to klucz główny obiektu Invoice w Salesforce Sales Cloud, często zapisany w polu `InvoiceNumber` lub podobnym polu z unikalnym identyfikatorem. Przykłady INV-00582INV-01934INV-10345
	Dział fakturowania BillingDepartment	Dział lub zespół odpowiedzialny za czynności związane z fakturowaniem.
Opis Ten atrybut określa grupę funkcjonalną, do której należy odpowiedzialny użytkownik, na przykład „Accounts Receivable” lub „Sales Operations”. Zazwyczaj ustala się ją na podstawie profilu lub roli użytkownika w Salesforce. Analiza wyników według działu pomaga ustalić, kto odpowiada za proces, i wykryć problemy systemowe w poszczególnych zespołach. Jest wykorzystywana na dashboardach „Payment Reconciliation Performance” i „Billing Team Workload & Performance” do porównywania efektywności i wykorzystania zasobów w różnych obszarach. Dlaczego to ważne Umożliwia analizę wyników pracy zespołu lub działu oraz pomaga wykrywać wąskie gardła, ograniczenia zasobów i braki szkoleniowe dotyczące konkretnych grup. Skąd pobrać Informacje te są zwykle zapisane w obiekcie User w Salesforce, w polach takich jak `Department` lub `Role.Name`. Przykłady NależnościOperacje finansoweZespół windykacji
	Łączna kwota faktury InvoiceTotalAmount	Łączna wartość pieniężna faktury.
Opis Ten atrybut określa łączną kwotę należną od klienta za dostarczone towary lub usługi. Jest to ważna miara finansowa przypisana do każdej sprawy dotyczącej faktury. Analiza łącznej kwoty faktury pomaga ustalać priorytety dla faktur o wysokiej wartości i sprawdzać, jak wyniki procesu różnią się w przypadku małych i dużych transakcji. Można jej używać do segmentacji danych na dashboardach, na przykład by sprawdzić, czy zatwierdzanie faktur o wyższej wartości trwa dłużej lub czy są one opłacane z opóźnieniem. Ułatwia to zarządzanie ryzykiem finansowym i skuteczne planowanie działań windykacyjnych. Dlaczego to ważne Umożliwia analizę wpływu finansowego, pomaga ustalać priorytety dla faktur o wysokiej wartości i sprawdzać, jak kwota wpływa na przebieg procesu, na przykład czas zatwierdzania lub opóźnienia w płatnościach. Skąd pobrać Prawdopodobnie jest to standardowe pole walutowe w obiekcie Invoice, na przykład `GrandTotal` lub podobne pole podsumowujące. Przykłady 5400.5012500.00850.75
	Status faktury InvoiceStatus	Bieżący status faktury w jej cyklu życia.
Opis Ten atrybut określa bieżący stan faktury, na przykład „Draft”, „Awaiting Approval”, „Sent”, „Paid” lub „Void”. Pokazuje, na jakim etapie procesu znajduje się faktura. Status faktury to ważny wymiar filtrowania i segmentacji. Analitycy mogą skupić się na wybranych grupach, na przykład fakturach oczekujących na płatność lub odrzuconych. Ułatwia to ustalanie priorytetów i analizę cech faktur, które zatrzymują się na określonych etapach. Dlaczego to ważne Pokazuje bieżący stan faktury i umożliwia filtrowanie oraz analizę spraw otwartych, zamkniętych i problematycznych. Skąd pobrać Zazwyczaj jest to standardowe pole listy wyboru o nazwie `Status` w obiekcie Invoice w Salesforce. Przykłady Oczekuje na zatwierdzenieZatwierdzonaWysłana do klientaOpłaconaOdpisana
	Termin płatności faktury PaymentDueDate	Data, do której klient ma zapłacić fakturę.
Opis Ten atrybut określa termin płatności podany na fakturze. Oblicza się go na podstawie daty wystawienia faktury i uzgodnionych warunków płatności. Termin płatności faktury jest ważny przy planowaniu finansowym i zarządzaniu należnościami. Stanowi punkt odniesienia do oceny faktycznej terminowości płatności. Jest niezbędny do obliczenia KPI „On-Time Payment Rate” oraz do tworzenia dashboardów śledzących terminowość płatności, takich jak „Days Sales Outstanding (DSO) Trend”. Dlaczego to ważne To punkt odniesienia przy ocenie terminowości płatności, obliczaniu DSO i uruchamianiu działań windykacyjnych, takich jak wysyłanie przypomnień o płatności. Skąd pobrać To standardowe pole daty w obiekcie Invoice w Salesforce, często nazywane `DueDate`. Przykłady 2023-05-152023-06-302023-07-01
	Użytkownik odpowiedzialny UserResponsible	Użytkownik lub agent, który wykonał daną czynność.
Opis Ten atrybut wskazuje użytkownika Salesforce odpowiedzialnego za daną czynność, na przykład zatwierdzenie faktury lub zaksięgowanie płatności. Często jest to osoba, która ostatnio zmodyfikowała rekord lub jest właścicielem zadania. Analiza procesu według użytkownika odpowiedzialnego pomaga ocenić wyniki pracy zespołu, rozkład obciążenia i potrzeby szkoleniowe. Wspiera dashboard „Billing Team Workload & Performance”, umożliwiając porównywanie wyników i analizę przydziału zasobów. Pomaga też ustalać przyczyny opóźnień lub błędów. Dlaczego to ważne Umożliwia analizę wyników pracy poszczególnych osób i zespołów oraz równoważenie obciążenia. Pomaga też wskazać osoby osiągające najlepsze wyniki i użytkowników, którzy potrzebują dodatkowego szkolenia. Skąd pobrać Informacje można znaleźć w polach takich jak `LastModifiedById` obiektu Invoice lub `OwnerId` powiązanych obiektów Task albo niestandardowych. Aby uzyskać nazwę użytkownika, należy połączyć te identyfikatory z obiektem User. Przykłady Alice JohnsonBob WilliamsCharlie Brown
	Czas zakończenia zdarzenia EventEndTime	Znacznik czasu wskazujący, kiedy zakończono działanie.
Opis Ten atrybut zapisuje czas zakończenia działania. Wiele działań związanych z fakturowaniem to zdarzenia chwilowe, w których czas rozpoczęcia jest równy czasowi zakończenia. Inne, na przykład etap akceptacji, mogą trwać określony czas. Czas zakończenia pozwala dokładnie obliczyć czas realizacji działania, czyli okres, w którym pracownik lub system aktywnie wykonuje zadanie. Dzięki temu można odróżnić czas pracy od oczekiwania i dokładniej ocenić sprawność procesu. Dlaczego to ważne Pozwala dokładnie obliczyć czas realizacji działań i odróżnić aktywną pracę od oczekiwania, co ułatwia rzetelną ocenę sprawności procesu. Skąd pobrać To pole często nie występuje w standardzie. Może być konieczne wyliczenie jego wartości na podstawie pola StartTime kolejnego działania w danym przypadku albo zapisanie jej w polu niestandardowym. Przykłady 2023-04-15T10:05:00Z2023-04-16T14:32:10Z2023-05-20T09:05:12Z
	Czy płatność była opóźniona IsLatePayment	Wyliczana flaga wskazująca, czy płatność wpłynęła po terminie.
Opis Ten atrybut logiczny jest wyliczany przez porównanie znacznika czasu działania „Otrzymano płatność od klienta” z „Termin płatności”. Przyjmuje wartość true, jeśli płatność była opóźniona, a w przeciwnym razie false. Flaga upraszcza analizę zachowań płatniczych i skuteczności windykacji. Jest podstawą KPI „Odsetek płatności terminowych” i pozwala podzielić klientów na płacących terminowo oraz z opóźnieniem, a następnie przeprowadzić dalszą analizę. Dla każdej faktury jasno wskazuje, czy płatność została zrealizowana na czas. Dlaczego to ważne Zapewnia czytelny miernik skuteczności windykacji, wspiera KPI „Odsetek płatności terminowych” i pozwala analizować czynniki prowadzące do opóźnień. Skąd pobrać Tego atrybutu nie ma w systemie źródłowym. Oblicza go warstwa ETL lub narzędzie process mining, porównując datę płatności z polem `PaymentDueDate`. Przykłady truefalse
	Czy wystąpiła poprawka IsRework	Wyliczana flaga wskazująca, czy faktura przeszła cykl poprawek.
Opis Ten atrybut logiczny jest wyliczany podczas przetwarzania danych. Przyjmuje wartość true, jeśli sekwencja działań dotyczących faktury wskazuje na poprawki, na przykład powrót do wcześniejszego etapu po jego zakończeniu (np. „Faktura poprawiona” po „Faktura zaakceptowana”). Flaga ułatwia szybkie wykrywanie i mierzenie nieefektywności procesu. Jest bezpośrednio wykorzystywana w KPI „Odsetek faktur wymagających poprawek” oraz dashboardzie „Poprawki i błędy w procesie fakturowania”. Analitycy mogą dzięki niej wyodrębnić przypadki, w których poprawki są kosztowne i czasochłonne. Dlaczego to ważne Flaga bezpośrednio mierzy nieefektywność procesu, wskazując przypadki z cyklami poprawek. Pomaga znaleźć źródła błędów i obliczyć koszt niskiej jakości. Skąd pobrać Tego atrybutu nie ma w systemie źródłowym. Oblicza go narzędzie process mining lub warstwa ETL na podstawie sekwencji działań dla każdego przypadku. Przykłady truefalse
	Data ostatniej aktualizacji danych LastDataUpdate	Timestamp ostatniego odświeżenia danych z systemu źródłowego.
Opis Ten atrybut wskazuje, kiedy ostatnio pobrano z Salesforce Sales Cloud dane do analizy process mining. Jest to pole metadanych dodawane do całego zbioru danych przy każdym odświeżeniu. Timestamp pozwala ocenić aktualność analizy. Dzięki niemu można sprawdzić, czy wyświetlane dashboardy i KPI uwzględniają najnowsze dane. To ważne przy podejmowaniu terminowych i świadomych decyzji biznesowych na podstawie wyników analizy procesu. Dlaczego to ważne Informuje o aktualności danych, dzięki czemu decyzje można podejmować na podstawie bieżącego obrazu procesu. Skąd pobrać Wartość jest generowana i zapisywana w zbiorze danych przez narzędzie ETL lub potok danych podczas każdego uruchomienia. Przykłady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Kraj rozliczeniowy BillingCountry	Kraj podany w adresie rozliczeniowym na fakturze.
Opis Ten atrybut określa kraj z adresu rozliczeniowego klienta. Jest ważnym wymiarem geograficznym przy segmentacji danych o procesie. Analiza procesu fakturowania według krajów pomaga wykryć regionalne różnice w wynikach, zgodności z przepisami i zachowaniach klientów. Może pokazać, czy w niektórych krajach cykle płatności są dłuższe, częściej występują poprawki albo obowiązują szczególne wymogi prawne wpływające na proces. Ułatwia to ujednolicanie procesów w skali międzynarodowej i ich dostosowanie do lokalnych warunków. Dlaczego to ważne Umożliwia analizę geograficzną i wykrywanie regionalnych różnic w wynikach, wymogach dotyczących zgodności oraz zachowaniach płatniczych. Skąd pobrać To część standardowego złożonego pola adresu w obiekcie Invoice, zwykle `BillingCountry`. Przykłady USANiemcyJaponiaBrazylia
	Liczba dni do otrzymania płatności DaysSalesOutstanding	Liczba dni od wysłania faktury do otrzymania płatności.
Opis Days Sales Outstanding (DSO) to wskaźnik finansowy określający średnią liczbę dni, po których firma otrzymuje płatność za sprzedaż. Oblicza się go jako czas między zdarzeniami „Wysłano fakturę do klienta” i „Otrzymano płatność od klienta”. Ten KPI jest jednym z głównych mierników procesu Order to Cash. Dzięki temu atrybutowi można go obliczyć dla każdej faktury. Wspiera dashboard „Trend Days Sales Outstanding (DSO)” i pomaga monitorować oraz poprawiać przepływy pieniężne. Dlaczego to ważne To ważny KPI służący do oceny skuteczności procesu windykacji i jego bezpośredniego wpływu na przepływy pieniężne firmy. Skąd pobrać To atrybut wyliczany według wzoru `(Timestamp('Customer Payment Received') - Timestamp('Invoice Sent to Customer'))`. Przykłady 32 dni58 dni29 dni
	Nazwa klienta CustomerName	Nazwa klienta lub konta, na które wystawiono fakturę.
Opis Ten atrybut wskazuje klienta lub firmę, na którą wystawiono fakturę. Zazwyczaj jest powiązany z rekordem Account w Salesforce. Analiza procesu według klienta pomaga zrozumieć zachowania poszczególnych klientów i wykryć problemy, które mogą dotyczyć najważniejszych kont. Może pokazać, czy niektórzy klienci regularnie płacą po terminie, wymagają częstszych poprawek faktur lub mają złożone procedury zatwierdzania. Takie informacje pomagają zarządzać relacjami z klientami i dostosowywać działania windykacyjne. Dlaczego to ważne Umożliwia analizę z perspektywy klienta i wykrywanie wzorców, na przykład wskazanie klientów, którzy często płacą po terminie lub wymagają większej liczby poprawek faktur. Pomaga to lepiej zarządzać relacjami z klientami. Skąd pobrać Dane pochodzą z pola `Account.Name`, powiązanego z obiektem Account przez relację odnośnika z obiektu Invoice. Przykłady ABC CorporationGlobal Tech Inc.Innovate Solutions LLC
	Opiekun klienta AccountOwner	Przedstawiciel handlowy lub opiekun odpowiedzialny za konto klienta.
Opis Ten atrybut wskazuje osobę w firmie odpowiedzialną za relację z klientem. Zwykle jest to przedstawiciel handlowy lub opiekun przypisany do obiektu Account w Salesforce. Opiekun klienta nie uczestniczy bezpośrednio w fakturowaniu, ale może być przydatnym wymiarem analizy. Problemy z fakturowaniem wpływają na relacje z klientami, a ten atrybut pozwala powiązać wyniki procesu z obszarem handlowym. Można dzięki niemu sprawdzić, czy na kontach obsługiwanych przez określone osoby częściej występują problemy z fakturami. Dlaczego to ważne Łączy wyniki procesu fakturowania z osobą odpowiedzialną za relację handlową z klientem. Pomaga ocenić wpływ błędów i opóźnień w fakturowaniu na działalność firmy. Skąd pobrać To pole `Owner.Name` z obiektu Account powiązanego z fakturą. Przykłady David MillerSophia GarciaJames Wilson
	System źródłowy SourceSystem	Wskazuje system, z którego pochodzą dane.
Opis Ten atrybut określa aplikację źródłową, w której wygenerowano dane zdarzenia. W tym procesie będzie to zazwyczaj „Salesforce Sales Cloud”. W środowisku z wieloma zintegrowanymi systemami pole to jest niezbędne do śledzenia pochodzenia danych i rozwiązywania problemów. Ułatwia zrozumienie ich kontekstu oraz prawidłowe łączenie i interpretowanie zdarzeń z różnych systemów w narzędziu process mining. Dlaczego to ważne Podaje ważne informacje o pochodzeniu danych, niezbędne do zarządzania nimi, ich weryfikacji i analizy w środowisku z wieloma systemami. Skąd pobrać Zazwyczaj jest to stała wartość dodawana podczas procesu ekstrakcji, transformacji i ładowania danych (ETL), która oznacza źródło zbioru danych. Przykłady Salesforce Sales CloudSFSC
	Waluta faktury InvoiceCurrency	Kod waluty, w której podano kwotę na fakturze, na przykład USD lub EUR.
Opis Ten atrybut wskazuje walutę, w której wystawiono fakturę. Jest szczególnie istotny dla organizacji działających w wielu krajach. Pole to dostarcza niezbędnego kontekstu do analiz finansowych. Umożliwia prawidłowe sumowanie kwot i porównywanie wskaźników procesu w różnych strefach walutowych. Przy analizie finansowych KPI należy używać go jako filtra, aby nie łączyć kwot w różnych walutach. Dlaczego to ważne Dostarcza niezbędnego kontekstu dla kwot pieniężnych, co pozwala rzetelnie analizować i raportować dane finansowe, zwłaszcza w operacjach międzynarodowych. Skąd pobrać Zwykle jest to standardowe pole `CurrencyIsoCode`, dostępne w instancjach Salesforce z włączoną obsługą wielu walut. Przykłady USDEURGBPJPY
	Warunki płatności PaymentTerms	Uzgodnione warunki płatności za fakturę, na przykład „30 dni” lub „płatność przy odbiorze”.
Opis Ten atrybut określa zasady dotyczące terminu i sposobu opłacenia faktury. Często wpływa na obliczenie terminu płatności i może uwzględniać rabaty za wcześniejszą zapłatę. Analiza według warunków płatności pozwala sprawdzić, jak różne ustalenia wpływają na zachowania płatnicze. Jest niezbędna w dashboardzie „Wykorzystanie rabatów za wcześniejszą płatność”, który porównuje daty płatności z ustalonymi warunkami i pomaga wykryć niewykorzystane możliwości oszczędności. Pozwala też wyjaśnić, dlaczego cykle płatności niektórych faktur są dłuższe lub krótsze. Dlaczego to ważne Dostarcza informacji o terminach płatności i jest niezbędny do analizy zachowań płatniczych, DSO oraz skuteczności programów rabatowych za wcześniejszą płatność. Skąd pobrać Te informacje są prawdopodobnie zapisane na liście wyboru lub w polu tekstowym obiektu Invoice albo powiązanego z nim obiektu Account w Salesforce. Przykłady 30 dni60 dni2% rabatu przy płatności w ciągu 10 dni, termin płatności 30 dniPłatność przy odbiorze

Wymagane Zalecane Opcjonalne

Działania w procesie Order to Cash: fakturowanie

To najważniejsze kroki procesu i kamienie milowe, które warto zapisać w dzienniku zdarzeń, aby prawidłowo odkrywać przebieg procesu i oceniać jego wyniki.

5 Zalecane 8 Opcjonalne

	Działanie	Opis
	Otrzymanie płatności od klienta	Klient zapłacił za fakturę, a środki wpłynęły na konto. Zwykle rejestruje się to przez utworzenie powiązanego rekordu „Payment” i połączenie go z fakturą.
Dlaczego to ważne To najważniejszy etap procesu odzyskiwania należności. Wyznacza koniec okresu uwzględnianego przy obliczaniu DSO i potwierdza otrzymanie należności. Skąd pobrać Zdarzenie rejestruje się na podstawie daty utworzenia rekordu obiektu niestandardowego „Payment” powiązanego z obiektem Invoice. Można je też wywnioskować ze zmiany statusu faktury na „Paid”. Rejestrowanie Utworzenie powiązanego rekordu Payment. Typ zdarzenia explicit
	Wysłanie faktury do klienta	Zatwierdzona faktura została oficjalnie dostarczona klientowi e-mailem, pocztą lub przez portal. Zdarzenie często rejestruje się po uzupełnieniu pola „Sent Date” albo zmianie statusu na „Sent”.
Dlaczego to ważne To początek okresu oczekiwania na płatność i punkt wyjścia do obliczenia wskaźnika Days Sales Outstanding (DSO). Jest to ważny etap przy śledzeniu komunikacji z klientem i terminów płatności. Skąd pobrać Zdarzenie można wywnioskować z uzupełnienia pola „Sent Date” obiektu Invoice lub zmiany statusu na „Sent”. Jeśli fakturę wysłano za pomocą zintegrowanego narzędzia pocztowego, zdarzenie może być też zapisane w Activity History. Rejestrowanie Timestamp uzupełnienia pola „Sent_Date__c”. Typ zdarzenia inferred
	Wystawienie faktury	To zdarzenie oznacza utworzenie nowego rekordu faktury w Salesforce. Rozpoczyna proces fakturowania danej transakcji i zwykle następuje po realizacji zamówienia lub spełnieniu warunku określonego w umowie. Zdarzenie rejestruje się na podstawie timestampu utworzenia rekordu faktury.
Dlaczego to ważne To główne zdarzenie rozpoczynające proces fakturowania. Analiza czasu od tego momentu do otrzymania płatności pozwala zmierzyć cały cykl Order-to-Cash i wykryć opóźnienia na etapie wprowadzania danych. Skąd pobrać Zdarzenie można ustalić na podstawie daty utworzenia (pola CreatedDate) obiektu niestandardowego Invoice lub podobnego obiektu reprezentującego fakturę w Salesforce. Rejestrowanie Timestamp utworzenia obiektu faktury. Typ zdarzenia explicit
	Zamknięcie faktury	Cykl życia faktury dobiegł końca, ponieważ została ona w pełni opłacona i uzgodniona. To ostatnia czynność w przypadku prawidłowo rozliczonej faktury, zwykle rejestrowana jako zmiana statusu.
Dlaczego to ważne To główne zdarzenie kończące proces. Pozwala dokładnie obliczyć całkowity czas jego trwania i jednoznacznie określić moment zakończenia na potrzeby analizy. Skąd pobrać Zdarzenie można wywnioskować z timestampu zmiany statusu obiektu Invoice na „Closed”, „Paid in Full” lub inny status końcowy. Rejestrowanie Zmiana statusu faktury na końcowy „Closed”. Typ zdarzenia inferred
	Zatwierdzenie faktury	Upoważniony użytkownik sprawdził i zatwierdził fakturę, potwierdzając jej poprawność i gotowość do wysłania klientowi. Zdarzenie zwykle rejestruje się, gdy status faktury zmienia się na „Approved”.
Dlaczego to ważne To ważny etap, od którego zależą dalsze czynności w procesie fakturowania. Opóźnienia na tym etapie tworzą poważne wąskie gardła i wpływają na DSO oraz całkowity czas procesu. Mierzy je dashboard „Invoice Approval Cycle Time”. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu obiektu Invoice na „Approved”. Jeśli używane są Salesforce Approval Processes, można je odczytać bezpośrednio z historii obiektu ProcessInstance. Rejestrowanie Zmiana statusu faktury na „Approved” lub zakończenie formalnego etapu zatwierdzania. Typ zdarzenia inferred
	Odpisanie faktury	Podjęto decyzję o umorzeniu należności, a fakturę zamknięto bez pełnej zapłaty. To alternatywne, niepomyślne zakończenie procesu fakturowania.
Dlaczego to ważne Śledzenie odpisów pozwala oszacować utracone przychody i wskazać klientów lub sytuacje prowadzące do powstania nieściągalnych należności. To ważna ścieżka wyjątków, którą warto monitorować ze względu na kondycję finansową firmy. Skąd pobrać Zdarzenie można wywnioskować z timestampu zmiany statusu obiektu Invoice na „Written Off” lub „Canceled - Bad Debt”. Rejestrowanie Zmiana statusu faktury na „Written Off”. Typ zdarzenia inferred
	Odrzucenie faktury	Osoba zatwierdzająca odrzuciła fakturę, zwykle z powodu błędów lub niezgodności. Fakturę trzeba poprawić i ponownie przekazać do zatwierdzenia. Zdarzenie rejestruje się jako zmianę statusu rekordu faktury na „Rejected”.
Dlaczego to ważne To zdarzenie oznacza konieczność ponownej pracy i wskazuje na nieefektywność procesu. Analiza liczby odrzuceń pomaga wykryć częste źródła błędów i ustalić ich przyczyny na potrzeby dashboardu „Billing Process Rework & Errors”. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu obiektu Invoice na „Rejected”. Informacje o odrzuceniu mogą też znajdować się w komentarzach w historii formalnego procesu zatwierdzania. Rejestrowanie Zmiana statusu faktury na „Rejected”. Typ zdarzenia inferred
	Poprawienie faktury	Ręczna korekta lub aktualizacja faktury po jej odrzuceniu albo wykryciu błędu. Zdarzenie można często wywnioskować ze zmiany statusu faktury na wcześniejszy, na przykład z „Rejected” z powrotem na „Draft”.
Dlaczego to ważne Wykrywanie pętli korekt jest niezbędne do obliczenia KPI „Invoice Rework Rate”. Duża liczba korekt wskazuje na problemy z początkowym wystawianiem faktur, które powodują opóźnienia. Skąd pobrać Zdarzenie można wywnioskować z historii zmian pól, wykrywając zmianę statusu z późniejszego etapu, na przykład „Rejected” lub „Approved”, na wcześniejszy, na przykład „Draft” lub „In Progress”. Rejestrowanie Status faktury cofa się do wcześniejszego etapu procesu. Typ zdarzenia inferred
	Przekazanie faktury do zatwierdzenia	Faktura została przygotowana i przekazana do wewnętrznej weryfikacji przed wysłaniem do klienta. Zdarzenie zwykle rejestruje się jako zmianę pola statusu rekordu faktury, na przykład z „Draft” na „Pending Approval”.
Dlaczego to ważne Śledzenie tego zdarzenia pozwala ustalić, ile czasu faktura spędza w kolejce do zatwierdzenia. To pierwszy krok do obliczenia KPI „Average Invoice Approval Time”. Skąd pobrać Zdarzenie można wywnioskować z historii zmian pól obiektu Invoice, gdy status zmienia się na przykład na „Submitted for Approval” lub „In Review”. Rejestrowanie Zmiana statusu faktury na „Pending Approval”. Typ zdarzenia inferred
	Rozliczenie i uzgodnienie płatności	Otrzymana płatność została w pełni dopasowana do konkretnej faktury i rozliczona w systemie, co zamyka należność. Zdarzenie rejestruje się jako końcową zmianę statusu płatności lub faktury.
Dlaczego to ważne To ostatni etap cyklu konwersji gotówki. Dashboard „Payment Reconciliation Performance” wykorzystuje to zdarzenie do pomiaru efektywności zespołu finansowego w rozliczaniu wpływów. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu faktury lub powiązanego obiektu Payment na końcowy, na przykład „Reconciled” lub „Applied”. Rejestrowanie Zmiana statusu faktury lub płatności na „Reconciled”. Typ zdarzenia inferred
	Upłynięcie terminu płatności faktury	To zdarzenie obliczane, które wskazuje moment, w którym zgodnie z warunkami płatności należy uregulować fakturę. Nie jest wynikiem działania użytkownika, lecz wynika z danych faktury.
Dlaczego to ważne To zdarzenie stanowi punkt odniesienia przy analizie terminowości płatności i obliczaniu KPI „On-Time Payment Rate”. Pozwala odróżnić płatności terminowe od opóźnionych. Skąd pobrać To zdarzenie obliczane na podstawie porównania bieżącego timestampu z polem „Due Date” obiektu Invoice. Nie jest zapisywane jako zdarzenie w Salesforce. Rejestrowanie Obliczane przez porównanie bieżącej daty z polem Due Date faktury. Typ zdarzenia calculated
	Wysłanie przypomnienia o płatności	Do klienta wysłano wiadomość przypominającą o zbliżającym się lub zaległym terminie płatności. Zdarzenie często zapisuje się jako rekord Activity (Task lub Email) powiązany z fakturą.
Dlaczego to ważne Śledzenie przypomnień pozwala ocenić skuteczność działań windykacyjnych. Jest niezbędne do analizy na dashboardzie „Payment Reminder Effectiveness” i obliczenia KPI „Payment Reminder Trigger Rate”. Skąd pobrać Zdarzenie rejestruje się na podstawie utworzenia rekordu Activity (Task lub Email) powiązanego z obiektem Invoice. Temat lub typ rekordu wskazuje, że jest to przypomnienie o płatności. Rejestrowanie Utworzenie powiązanego rekordu Task lub Email o określonym typie lub temacie. Typ zdarzenia explicit
	Zaksięgowanie płatności w księdze	Otrzymana płatność została formalnie zarejestrowana w systemie finansowo-księgowym firmy lub księdze. Zdarzenie można odczytać ze zmiany statusu płatności lub faktury po wykonaniu integracji.
Dlaczego to ważne To zdarzenie pozwala odróżnić otrzymanie płatności od jej uzgodnienia w księgach. Czas między wpływem środków a ich zaksięgowaniem może wskazywać na opóźnienia w wewnętrznych procesach księgowych. Skąd pobrać Zdarzenie można wywnioskować ze zmiany statusu obiektu Payment lub Invoice na przykład na „Posted” lub „Exported to ERP”. Status jest często aktualizowany przez integrację API. Rejestrowanie Zmiana statusu płatności lub faktury na „Posted”. Typ zdarzenia inferred

Zalecane Opcjonalne

Instrukcje pozyskiwania danych

Jak pobrać dane z Salesforce Sales Cloud

Kroki

Sprawdź wymagania wstępne: Upewnij się, że masz odpowiednie uprawnienia w Salesforce, w tym „Run Reports”, „Create and Customize Reports” oraz „Export Reports”. Sprawdź, czy dla kluczowych pól statusu w obiektach Invoice i Payment włączono śledzenie historii pól. W tym celu przejdź do Setup > Object Manager, wybierz odpowiedni obiekt, otwórz Fields & Relationships i kliknij „Set History Tracking”.
Określ strategię raportowania: Ten proces wymaga utworzenia kilku raportów, ponieważ działania pochodzą z różnych rekordów lub zdarzeń, takich jak utworzenie faktury, zmiana statusu czy powiązana płatność. Utwórz osobny raport dla każdego źródła, a następnie połącz wyniki poza Salesforce.
Utwórz raport dotyczący utworzenia rekordów: Zacznij od najprostszych zdarzeń. Utwórz raport dla działań „Utworzono fakturę” i „Otrzymano płatność od klienta”. Przejdź do zakładki Reports i kliknij „New Report”. Wybierz typ raportu obejmujący obiekt Invoice, na przykład „Invoices”, albo obiekt Payment. Dodaj kolumny odpowiadające atrybutom dziennika zdarzeń. W przypadku działania „Utworzono fakturę” pole CreatedDate rekordu faktury będzie wartością EventTime.
Utwórz raport historii pól: Aby zarejestrować zmiany statusu, takie jak „Przekazano fakturę do akceptacji”, „Zaakceptowano fakturę”, „Odrzucono fakturę” i „Poprawiono fakturę”, utwórz raport typu „Invoice History”. Ten specjalny typ raportu udostępnia zmiany rejestrowane przez funkcję śledzenia historii pól. Ustaw filtr, aby uwzględnić zmiany pola Status.
Utwórz raport dotyczący zdarzeń opartych na dacie: W przypadku zdarzeń takich jak „Wysłano fakturę do klienta” lub „Nadszedł termin płatności” utwórz raport dla obiektu Invoice. Jako EventTime wykorzystaj pola daty, takie jak Sent_Date__c lub Payment_Due_Date__c. Ustaw filtr, aby uwzględnić tylko rekordy, w których te pola nie są puste.
Utwórz raport dotyczący powiązanych działań: Aby uwzględnić zdarzenia takie jak „Wysłano przypomnienie o płatności”, utwórz raport łączący działania (Tasks lub Events) z fakturami. Użyj typu raportu, takiego jak „Activities with Invoices”, albo utwórz własny. Ustaw filtr na działania, których temat lub typ wskazuje na przypomnienie.
Dodaj standardowe kolumny do wszystkich raportów: W każdym raporcie uwzględnij kolumny, które można przypisać do wymaganej struktury dziennika zdarzeń: InvoiceNumber, pole określające EventTime (np. CreatedDate lub datę zmiany pola), UserResponsible (np. LastModifiedById) oraz inne zalecane atrybuty.
Wyeksportuj raporty do plików CSV: Uruchom każdy raport osobno. Na ekranie wyników raportu otwórz menu rozwijane, wybierz „Export”, a następnie format „Details Only” z rozszerzeniem .csv. Powtórz te czynności dla wszystkich utworzonych raportów.
Połącz i przekształć dane: Otwórz wyeksportowane pliki CSV w arkuszu kalkulacyjnym lub użyj narzędzia do przygotowywania danych. W każdym pliku dodaj kolumnę ActivityName i wpisz w niej nazwę odpowiadającego działania, np. „Utworzono fakturę” dla wszystkich wierszy z pierwszego raportu. Przypisz kolumny źródłowe, takie jak Invoice: Created Date, do standardowych nagłówków dziennika zdarzeń, takich jak EventTime.
Utwórz końcowy dziennik zdarzeń: Połącz przekształcone dane z poszczególnych plików CSV w jeden plik główny. Upewnij się, że nagłówki kolumn mają dokładnie takie nazwy: InvoiceNumber, ActivityName, EventTime, UserResponsible itd. Ten połączony plik będzie końcowym dziennikiem zdarzeń.
Zapisz plik w odpowiednim formacie: Zapisz połączony plik CSV z kodowaniem UTF-8. Plik jest gotowy do przesłania do ProcessMind.

Konfiguracja

Typy raportów: Prawdopodobnie trzeba będzie utworzyć kilka niestandardowych typów raportów, aby połączyć obiekty nadrzędne, takie jak Account, z obiektami podrzędnymi i dalszymi, takimi jak Invoice, Payment i Activity. Utwórz je w Setup > Report Types.
Śledzenie historii pól: To niezbędny element konfiguracji. W obiekcie Invoice włącz śledzenie historii dla każdego pola Status. Bez tego nie można rejestrować zmian statusu, takich jak „Zaakceptowano” lub „Odrzucono”. Historia nie jest zapisywana wstecz.
Filtry danych: Zawsze ustawiaj filtr daty w raportach, aby ograniczyć ilość danych. Dobrą praktyką jest filtrowanie według daty utworzenia głównego obiektu i uwzględnianie ostatnich 3–6 miesięcy, np. Invoice: Created Date równa się LAST 180 DAYS.
Usługa eksportu danych: Zamiast uruchamiać osobne raporty, można skorzystać z wbudowanej usługi Data Export (Setup > Data Export). Usługa eksportuje wszystkie dane organizacji co tydzień lub co miesiąc. Zapewnia pełną kopię danych, ale wymaga późniejszego filtrowania, łączenia i przekształcania ich w dziennik zdarzeń.
Uprawnienia użytkownika: Osoba pobierająca dane musi mieć dostęp do odczytu wszystkich odpowiednich obiektów, takich jak Account, Order, Invoice__c, Payment__c i Activity, oraz ich pól. Potrzebuje też uprawnień do tworzenia i eksportowania raportów.

Przykładowe zapytanie config

// This is a configuration guide for building multiple Salesforce reports.
// The data from these separate CSV exports must be manually combined and transformed into a single event log.

// Report 1: Invoice Generated
// Report Type: Invoices (or your custom invoice object report type)
// Filters: 
// 1. Created Date GREATER OR EQUAL [Start Date]
// 2. Created Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Invoice Generated' (static text) -> ActivityName
// - Created Date -> EventTime
// - Created By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 2: Invoice Status Changes (Submitted, Approved, Rejected, Corrected, Closed, Written Off)
// Report Type: Invoice History (or your custom object's history report type)
// Filters:
// 1. Edit Date GREATER OR EQUAL [Start Date]
// 2. Edit Date LESS OR EQUAL [End Date]
// 3. Field/Event EQUALS 'Status' (or the name of your status field)
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - New Value (transformed*) -> ActivityName 
// - Edit Date -> EventTime
// - Edited By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - New Value -> InvoiceStatus
// - [Invoice Total Amount] -> InvoiceTotalAmount
// - [Invoice Payment Due Date] -> PaymentDueDate
// *Transformation Logic for ActivityName: 
//   - IF New Value = 'Pending Approval' THEN 'Invoice Submitted for Approval'
//   - IF New Value = 'Approved' THEN 'Invoice Approved'
//   - IF New Value = 'Rejected' THEN 'Invoice Rejected'
//   - IF New Value = 'Draft' AND Old Value = 'Rejected' THEN 'Invoice Corrected'
//   - IF New Value = 'Closed' THEN 'Invoice Closed'
//   - IF New Value = 'Written Off' THEN 'Invoice Written Off'

// Report 3: Invoice Sent to Customer
// Report Type: Invoices
// Filters:
// 1. [Sent Date Field] NOT EQUAL TO "" (not null)
// 2. [Sent Date Field] GREATER OR EQUAL [Start Date]
// 3. [Sent Date Field] LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Invoice Sent to Customer' (static text) -> ActivityName
// - [Sent Date Field] -> EventTime
// - Last Modified By -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 4: Payment Due Date Reached
// Report Type: Invoices
// Filters:
// 1. Payment Due Date NOT EQUAL TO "" (not null)
// 2. Payment Due Date GREATER OR EQUAL [Start Date]
// 3. Payment Due Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice Number -> InvoiceNumber
// - 'Payment Due Date Reached' (static text) -> ActivityName
// - Payment Due Date -> EventTime
// - 'System' (static text) -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - Status -> InvoiceStatus
// - Total Amount -> InvoiceTotalAmount
// - Payment Due Date -> PaymentDueDate

// Report 5: Payment Reminder Issued
// Report Type: Activities with Invoices (or similar custom report type)
// Filters:
// 1. Task or Event Subject CONTAINS 'Payment Reminder'
// 2. Created Date GREATER OR EQUAL [Start Date]
// 3. Created Date LESS OR EQUAL [End Date]
// Columns to Export & Map:
// - Invoice: Invoice Number -> InvoiceNumber
// - 'Payment Reminder Issued' (static text) -> ActivityName
// - Created Date -> EventTime
// - Assigned To -> UserResponsible
// - [Billing Department Field] -> BillingDepartment
// - [Invoice Status Field] -> InvoiceStatus
// - [Invoice Total Amount] -> InvoiceTotalAmount
// - [Invoice Payment Due Date] -> PaymentDueDate

// Report 6: Customer Payment Received & Status Changes (Posted, Applied)
// Report Type: Payments with Invoices (or similar custom report type)
// This report combines multiple events from the Payment record.
// Filters:
// 1. Payment: Created Date GREATER OR EQUAL [Start Date]
// 2. Payment: Created Date LESS OR EQUAL [End Date]
// Part A: Payment Received
// Columns to Export & Map:
// - Invoice: Invoice Number -> InvoiceNumber
// - 'Customer Payment Received' (static text) -> ActivityName
// - Payment: Created Date -> EventTime
// - Payment: Created By -> UserResponsible
// Part B: Payment Posted and Applied (Requires exporting and transforming multiple rows for the same payment if status changes)
// You may need a separate Payment History Report, similar to Report 2.
// Assuming a simple status field on the Payment for this example:
//   - IF Payment Status = 'Posted' THEN 'Payment Posted to Ledger'
//   - IF Payment Status = 'Applied' THEN 'Cash Applied/Reconciled'

Kroki

Wymagania i konfiguracja: Upewnij się, że na komputerze jest zainstalowany Python w wersji 3.6 lub nowszej. Zainstaluj wymagane biblioteki, uruchamiając w terminalu polecenie: pip install simple-salesforce pandas. Przygotuj też nazwę użytkownika Salesforce, hasło i token bezpieczeństwa. Aby uzyskać token, zaloguj się do Salesforce, przejdź do ustawień osobistych i wybierz opcję „Reset My Security Token”.
Włącz śledzenie historii pól: Zaloguj się do organizacji Salesforce jako administrator. Przejdź do Setup, a następnie do Object Manager. Odszukaj główny obiekt faktury, na przykład Invoice__c, i otwórz „Fields & Relationships”. Kliknij „Set History Tracking”. Włącz śledzenie pola określającego status faktury, na przykład Status__c. Powtórz te czynności dla obiektu płatności, na przykład Payment__c, i odpowiadającego mu pola statusu.
Zapisz i skonfiguruj skrypt: Zapisz udostępniony skrypt Python w pliku extract_invoices.py. Otwórz go w edytorze tekstu i uzupełnij wartości zastępcze w sekcji „Salesforce Credentials and Settings”. Podaj SF_USERNAME, SF_PASSWORD, SF_SECURITY_TOKEN i SF_INSTANCE_URL. Ustaw START_DATE i END_DATE, aby określić okres ekstrakcji.
Dostosuj nazwy obiektów i pól: Dokładnie sprawdź zapytania SOQL w skrypcie. Zawiera on przykładowe nazwy, takie jak Invoice__c, Payment__c, Status__c, Total_Amount__c i inne. Zastąp je rzeczywistymi nazwami API obiektów i pól używanych w danej instancji Salesforce do obsługi rozliczeń i faktur.
Uruchom skrypt ekstrakcji: Otwórz terminal lub wiersz polecenia, przejdź do katalogu, w którym zapisano skrypt, i uruchom polecenie: python extract_invoices.py. Skrypt połączy się z Salesforce API, wykona zapytania i przetworzy dane.
Monitoruj postęp skryptu: Podczas pobierania i przetwarzania danych dla poszczególnych typów zdarzeń skrypt będzie wyświetlać komunikaty o stanie w konsoli. W zależności od wolumenu danych i limitów API może to potrwać. Zwracaj uwagę na komunikaty o błędach, które mogą wskazywać na nieprawidłowe dane logowania lub nazwy API.
Sprawdź plik wynikowy: Po pomyślnym zakończeniu skrypt utworzy w tym samym katalogu plik salesforce_billing_event_log.csv. Otwórz go w arkuszu kalkulacyjnym, aby sprawdzić zawartość i upewnić się, że zawiera oczekiwane dane.
Przygotuj plik do przesłania: Wygenerowany plik CSV zawiera wymagane kolumny InvoiceNumber, ActivityName i EventTime, a także inne zalecane atrybuty. Jest gotowy do bezpośredniego przesłania do narzędzia process mining, bez dodatkowego formatowania.

Konfiguracja

Dane logowania do Salesforce: Podaj nazwę użytkownika Salesforce, hasło i token bezpieczeństwa. Token jest wymagany do korzystania z API spoza zaufanych zakresów adresów IP organizacji.
Adres URL instancji Salesforce: Podaj domenę instancji Salesforce, na przykład your_instance.my.salesforce.com. W przypadku sandboxa adres będzie inny, na przykład test.salesforce.com.
Filtry zakresu dat: Skrypt zawiera zmienne START_DATE i END_DATE. Warto zacząć od krótszego zakresu, na przykład 3–6 miesięcy, aby ograniczyć wolumen danych i zmieścić się w limitach API. Daty te filtrują początkowe zapytanie według daty utworzenia faktury.
Nazwy API obiektów i pól: Skrypt zawiera przykładowe nazwy API obiektów i pól, na przykład Invoice__c i Status__c. Zastąp je dokładnymi nazwami z modelu danych Salesforce. Można je znaleźć w Salesforce Setup, w sekcji Object Manager.
Wymagania dotyczące śledzenia: Dokładność dziennika zdarzeń, zwłaszcza w zakresie zmian statusu, zależy od tego, czy funkcja Field History Tracking była włączona dla odpowiednich pól przed wystąpieniem transakcji. Jeśli nie była, zmiany historyczne nie zostaną uwzględnione.
Limity wywołań API: Salesforce ogranicza liczbę wywołań API w ciągu 24 godzin. W przypadku bardzo dużych zbiorów danych warto podzielić ekstrakcję na krótsze zakresy dat lub zaplanować ją poza godzinami szczytu, aby uniknąć przekroczenia limitów.

Przykładowe zapytanie python

import pandas as pd
from simple_salesforce import Salesforce
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Salesforce Credentials and Settings ---
class=class="hl-string">"hl-comment"># IMPORTANT: Replace all placeholder values with your actual Salesforce information.
SF_USERNAME = class="hl-string">'[your_salesforce_username]'
SF_PASSWORD = class="hl-string">'[your_salesforce_password]'
SF_SECURITY_TOKEN = class="hl-string">'[your_salesforce_security_token]' class=class="hl-string">"hl-comment"># Append this to your password if required
SF_INSTANCE_URL = class="hl-string">'https://[your_instance].my.salesforce.com' class=class="hl-string">"hl-comment"># e.g., na1.salesforce.com

class=class="hl-string">"hl-comment"># --- Extraction Period ---
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'

class=class="hl-string">"hl-comment"># --- Object and Field API Name Placeholders ---
class=class="hl-string">"hl-comment"># Replace these with the actual API names from your Salesforce org.
INVOICE_OBJECT = class="hl-string">'Invoice__c'
INVOICE_NUMBER_FIELD = class="hl-string">'Name'
INVOICE_STATUS_FIELD = class="hl-string">'Status__c'
INVOICE_TOTAL_AMOUNT_FIELD = class="hl-string">'Total_Amount__c'
INVOICE_DUE_DATE_FIELD = class="hl-string">'Due_Date__c'

PAYMENT_OBJECT = class="hl-string">'Payment__c'
PAYMENT_INVOICE_LOOKUP_FIELD = class="hl-string">'Invoice__c' class=class="hl-string">"hl-comment"># Lookup field from Payment to Invoice
PAYMENT_STATUS_FIELD = class="hl-string">'Status__c'

class=class="hl-string">"hl-comment"># --- Main Script ---
def main():
    print(class="hl-string">"Connecting to Salesforce...")
    sf = Salesforce(username=SF_USERNAME, password=SF_PASSWORD, security_token=SF_SECURITY_TOKEN, instance_url=SF_INSTANCE_URL)
    print(class="hl-string">"Connection successful.")

    all_events = []

    class=class="hl-string">"hl-comment"># 1. Get base Invoice data
    print(class="hl-string">"Fetching base invoice data...")
    soql_invoices = fclass="hl-string">"""
        SELECT Id, {INVOICE_NUMBER_FIELD}, CreatedDate, CreatedById, LastModifiedById, 
               {INVOICE_STATUS_FIELD}, {INVOICE_TOTAL_AMOUNT_FIELD}, {INVOICE_DUE_DATE_FIELD}
        FROM {INVOICE_OBJECT}
        WHERE CreatedDate >= {START_DATE} AND CreatedDate <= {END_DATE}
    """
    invoices_data = sf.query_all(soql_invoices)[class="hl-string">'records']
    df_invoices = pd.DataFrame(invoices_data).drop(columns=[class="hl-string">'attributes'])
    invoice_ids = class="hl-string">"','".join(df_invoices[class="hl-string">'Id'].tolist())

    class=class="hl-string">"hl-comment"># Activity: Invoice Generated & Payment Due Date Reached
    print(class="hl-string">"Processing 'Invoice Generated' and 'Payment Due Date Reached' events...")
    generated_events = df_invoices.copy()
    generated_events[class="hl-string">'ActivityName'] = class="hl-string">'Invoice Generated'
    generated_events[class="hl-string">'EventTime'] = pd.to_datetime(generated_events[class="hl-string">'CreatedDate']).dt.tz_localize(None)
    generated_events[class="hl-string">'UserResponsible'] = generated_events[class="hl-string">'CreatedById']
    all_events.append(generated_events)

    due_date_events = df_invoices[df_invoices[INVOICE_DUE_DATE_FIELD].notna()].copy()
    due_date_events[class="hl-string">'ActivityName'] = class="hl-string">'Payment Due Date Reached'
    due_date_events[class="hl-string">'EventTime'] = pd.to_datetime(due_date_events[INVOICE_DUE_DATE_FIELD]).dt.tz_localize(None)
    due_date_events[class="hl-string">'UserResponsible'] = None class=class="hl-string">"hl-comment"># System-generated event
    all_events.append(due_date_events)

    class=class="hl-string">"hl-comment"># 2. Get Invoice Status Changes from Field History
    print(class="hl-string">"Fetching invoice status changes...")
    soql_invoice_history = fclass="hl-string">"""
        SELECT ParentId, Field, OldValue, NewValue, CreatedDate, CreatedById
        FROM {INVOICE_OBJECT}History
        WHERE ParentId IN ('{invoice_ids}') AND Field = '{INVOICE_STATUS_FIELD}'
    """
    invoice_history_data = sf.query_all(soql_invoice_history)[class="hl-string">'records']
    if invoice_history_data:
        df_invoice_history = pd.DataFrame(invoice_history_data).drop(columns=[class="hl-string">'attributes'])
        df_invoice_history = df_invoice_history.merge(df_invoices[[class="hl-string">'Id', INVOICE_NUMBER_FIELD, INVOICE_TOTAL_AMOUNT_FIELD, INVOICE_DUE_DATE_FIELD]], left_on=class="hl-string">'ParentId', right_on=class="hl-string">'Id')
        df_invoice_history[class="hl-string">'EventTime'] = pd.to_datetime(df_invoice_history[class="hl-string">'CreatedDate']).dt.tz_localize(None)
        df_invoice_history[class="hl-string">'UserResponsible'] = df_invoice_history[class="hl-string">'CreatedById']

        class=class="hl-string">"hl-comment"># Map status changes to Activity Names
        status_map = {
            (class="hl-string">'Draft', class="hl-string">'Pending Approval'): class="hl-string">'Invoice Submitted for Approval',
            (class="hl-string">'Pending Approval', class="hl-string">'Approved'): class="hl-string">'Invoice Approved',
            (class="hl-string">'Pending Approval', class="hl-string">'Rejected'): class="hl-string">'Invoice Rejected',
            (class="hl-string">'Rejected', class="hl-string">'Draft'): class="hl-string">'Invoice Corrected',
            (class="hl-string">'Approved', class="hl-string">'Sent'): class="hl-string">'Invoice Sent to Customer',
            (class="hl-string">'Approved', class="hl-string">'Closed'): class="hl-string">'Invoice Closed',
            (class="hl-string">'Sent', class="hl-string">'Closed'): class="hl-string">'Invoice Closed',
            (class="hl-string">'Approved', class="hl-string">'Written Off'): class="hl-string">'Invoice Written Off'
        }
        df_invoice_history[class="hl-string">'ActivityName'] = df_invoice_history.apply(lambda row: status_map.get((str(row[class="hl-string">'OldValue']), str(row[class="hl-string">'NewValue']))), axis=1)
        df_invoice_history.rename(columns={class="hl-string">'NewValue': INVOICE_STATUS_FIELD}, inplace=True)
        all_events.append(df_invoice_history.dropna(subset=[class="hl-string">'ActivityName']))

    class=class="hl-string">"hl-comment"># 3. Get Payment Reminders from Tasks
    print(class="hl-string">"Fetching payment reminder tasks...")
    soql_tasks = fclass="hl-string">"""
        SELECT WhatId, ActivityDate, CreatedById, CreatedDate
        FROM Task
        WHERE WhatId IN ('{invoice_ids}') AND Subject LIKE '%Payment Reminder%'
    """
    task_data = sf.query_all(soql_tasks)[class="hl-string">'records']
    if task_data:
        df_tasks = pd.DataFrame(task_data).drop(columns=[class="hl-string">'attributes'])
        df_tasks = df_tasks.merge(df_invoices[[class="hl-string">'Id', INVOICE_NUMBER_FIELD, INVOICE_STATUS_FIELD, INVOICE_TOTAL_AMOUNT_FIELD, INVOICE_DUE_DATE_FIELD]], left_on=class="hl-string">'WhatId', right_on=class="hl-string">'Id')
        df_tasks[class="hl-string">'ActivityName'] = class="hl-string">'Payment Reminder Issued'
        df_tasks[class="hl-string">'EventTime'] = pd.to_datetime(df_tasks[class="hl-string">'CreatedDate']).dt.tz_localize(None)
        df_tasks[class="hl-string">'UserResponsible'] = df_tasks[class="hl-string">'CreatedById']
        all_events.append(df_tasks)

    class=class="hl-string">"hl-comment"># 4. Get Payment Data
    print(class="hl-string">"Fetching payment data...")
    soql_payments = fclass="hl-string">"""
        SELECT Id, {PAYMENT_INVOICE_LOOKUP_FIELD}, CreatedDate, CreatedById, LastModifiedById, {PAYMENT_STATUS_FIELD}
        FROM {PAYMENT_OBJECT}
        WHERE {PAYMENT_INVOICE_LOOKUP_FIELD} IN ('{invoice_ids}')
    """
    payment_data = sf.query_all(soql_payments)[class="hl-string">'records']
    if payment_data:
        df_payments = pd.DataFrame(payment_data).drop(columns=[class="hl-string">'attributes'])
        df_payments = df_payments.merge(df_invoices[[class="hl-string">'Id', INVOICE_NUMBER_FIELD, INVOICE_TOTAL_AMOUNT_FIELD, INVOICE_DUE_DATE_FIELD]], left_on=PAYMENT_INVOICE_LOOKUP_FIELD, right_on=class="hl-string">'Id', suffixes=(class="hl-string">'_payment', class="hl-string">'_invoice'))
        payment_ids = class="hl-string">"','".join(df_payments[class="hl-string">'Id_payment'].tolist())
        
        class=class="hl-string">"hl-comment"># Activity: Customer Payment Received
        payment_received_events = df_payments.copy()
        payment_received_events[class="hl-string">'ActivityName'] = class="hl-string">'Customer Payment Received'
        payment_received_events[class="hl-string">'EventTime'] = pd.to_datetime(payment_received_events[class="hl-string">'CreatedDate']).dt.tz_localize(None)
        payment_received_events[class="hl-string">'UserResponsible'] = payment_received_events[class="hl-string">'CreatedById']
        all_events.append(payment_received_events)
        
        class=class="hl-string">"hl-comment"># 5. Get Payment Status Changes
        print(class="hl-string">"Fetching payment status changes...")
        soql_payment_history = fclass="hl-string">"""
            SELECT ParentId, Field, OldValue, NewValue, CreatedDate, CreatedById
            FROM {PAYMENT_OBJECT}History
            WHERE ParentId IN ('{payment_ids}') AND Field = '{PAYMENT_STATUS_FIELD}'
        """
        payment_history_data = sf.query_all(soql_payment_history)[class="hl-string">'records']
        if payment_history_data:
            df_payment_history = pd.DataFrame(payment_history_data).drop(columns=[class="hl-string">'attributes'])
            df_payment_history = df_payment_history.merge(df_payments[[class="hl-string">'Id_payment', INVOICE_NUMBER_FIELD, INVOICE_TOTAL_AMOUNT_FIELD, INVOICE_DUE_DATE_FIELD]], left_on=class="hl-string">'ParentId', right_on=class="hl-string">'Id_payment')
            df_payment_history[class="hl-string">'EventTime'] = pd.to_datetime(df_payment_history[class="hl-string">'CreatedDate']).dt.tz_localize(None)
            df_payment_history[class="hl-string">'UserResponsible'] = df_payment_history[class="hl-string">'CreatedById']

            payment_status_map = {
                (class="hl-string">'Received', class="hl-string">'Posted'): class="hl-string">'Payment Posted to Ledger',
                (class="hl-string">'Posted', class="hl-string">'Reconciled'): class="hl-string">'Cash Applied/Reconciled'
            }
            df_payment_history[class="hl-string">'ActivityName'] = df_payment_history.apply(lambda row: payment_status_map.get((str(row[class="hl-string">'OldValue']), str(row[class="hl-string">'NewValue']))), axis=1)
            df_payment_history.rename(columns={class="hl-string">'NewValue': INVOICE_STATUS_FIELD}, inplace=True)
            all_events.append(df_payment_history.dropna(subset=[class="hl-string">'ActivityName']))

    class=class="hl-string">"hl-comment"># --- Final Assembly ---
    print(class="hl-string">"Assembling final event log...")
    final_df = pd.concat(all_events, ignore_index=True)

    class=class="hl-string">"hl-comment"># Standardize column names
    final_df.rename(columns={
        INVOICE_NUMBER_FIELD: class="hl-string">'InvoiceNumber',
        INVOICE_STATUS_FIELD: class="hl-string">'InvoiceStatus',
        INVOICE_TOTAL_AMOUNT_FIELD: class="hl-string">'InvoiceTotalAmount',
        INVOICE_DUE_DATE_FIELD: class="hl-string">'PaymentDueDate'
    }, inplace=True)

    class=class="hl-string">"hl-comment"># Select and order columns for the final event log
    required_cols = {
        class="hl-string">'InvoiceNumber': None,
        class="hl-string">'ActivityName': None,
        class="hl-string">'EventTime': None,
        class="hl-string">'UserResponsible': None,
        class="hl-string">'InvoiceStatus': None,
        class="hl-string">'InvoiceTotalAmount': None,
        class="hl-string">'PaymentDueDate': None
    }
    for col in required_cols:
        if col not in final_df.columns:
            final_df[col] = required_cols[col]
    
    class=class="hl-string">"hl-comment"># We cannot extract Billing Department directly from this model, so we will add it as an empty column
    final_df[class="hl-string">'BillingDepartment'] = None

    final_df = final_df[list(required_cols.keys()) + [class="hl-string">'BillingDepartment']]

    class=class="hl-string">"hl-comment"># Sort by case and event time
    final_df.sort_values(by=[class="hl-string">'InvoiceNumber', class="hl-string">'EventTime'], inplace=True)

    class=class="hl-string">"hl-comment"># Save to CSV
    output_filename = class="hl-string">'salesforce_billing_event_log.csv'
    final_df.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%S.%f')
    print(fclass="hl-string">"Event log saved to {output_filename}")

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

Kroki

Wybierz platformę ETL lub iPaaS z obsługiwanym konektorem Salesforce Sales Cloud i utwórz połączenie, korzystając z wymaganej metody uwierzytelniania Salesforce. W konfiguracji platformy podaj wyłącznie ciąg połączenia, dane logowania, identyfikator organizacji lub wartości właściwe dla danego środowiska.
Sprawdź, czy połączona organizacja Salesforce udostępnia obiekt faktury, historię statusów faktur lub źródło audytowe, powiązane rekordy aktywności, rekordy płatności oraz wymagane rekordy integracji księgowej. Zastąp każdą nazwę obiektu lub pola w nawiasach odpowiednią nazwą skonfigurowaną w środowisku Salesforce.
Skonfiguruj parametry ekstrakcji przyrostowej, określając datę początkową i końcową. W zależności od procesu uwzględnij datę utworzenia faktury, zmiany statusu, aktywności, płatności, księgowania, uzgodnienia i zamknięcia. Pobierz dane z odpowiednio długiego okresu wstecz, aby uwzględnić sprawy utworzone przed wybranym okresem, ale nadal aktywne w jego trakcie.
Dodaj pełne zapytanie poniżej do komponentu zapytań Salesforce lub transformacji w narzędziu ETL. Jeśli konektor nie obsługuje przedstawionej składni, odtwórz tę samą logikę za pomocą wizualnych komponentów źródła, filtra, złączenia, pola obliczanego i unii. Nie zakładaj, że ProcessMind sam wywnioskuje zdarzenia ze zmian statusu. Każda aktywność musi zostać zapisana jako osobny wiersz dziennika zdarzeń.
Skonfiguruj mapowania źródeł dla obiektu faktury, historii statusów faktur lub źródła audytowego, powiązanych rekordów aktywności, rekordów płatności, rekordów księgowania w księdze głównej i rekordów uzgodnień. Numer faktury przypisz do InvoiceNumber, etykietę aktywności do ActivityName, a odpowiedni znacznik czasu do EventTime. Zachowaj zalecane atrybuty, jeśli ich wartości są dostępne w źródle.
Zastosuj reguły transformacji. Ujednolić strefę czasową wszystkich znaczników czasu, ustandaryzować wartości statusów, ustawić typ liczbowy dla InvoiceTotalAmount, typ daty lub znacznika czasu dla PaymentDueDate oraz usunąć rekordy bez InvoiceNumber lub EventTime. Dla zdarzenia Payment Due Date Reached utwórz osobny wiersz z wartością PaymentDueDate w polu EventTime tylko wtedy, gdy termin płatności przypada w okresie ekstrakcji i dostępny jest rekord faktury.
Usuń duplikaty zdarzeń na podstawie InvoiceNumber, ActivityName, EventTime i identyfikatora rekordu źródłowego, jeśli jest dostępny. Zachowaj osobne wystąpienia, gdy źródło zawiera wiele prawidłowych zgłoszeń, odrzuceń, przypomnień, korekt, płatności, księgowań lub uzgodnień.
Sprawdź, czy wynik zawiera wszystkie 13 wymaganych wartości ActivityName, każdy wiersz ma InvoiceNumber i EventTime, a znaczniki czasu zdarzeń w ramach każdej faktury są uporządkowane prawidłowo, o ile pozwalają na to dane źródłowe.
Zapisz przekształcone dane w pliku CSV, Parquet lub innym formacie dziennika zdarzeń obsługiwanym przez ProcessMind. Użyj InvoiceNumber jako identyfikatora case, ActivityName jako kolumny aktywności, a EventTime jako kolumny czasu zdarzenia. Dodaj UserResponsible, BillingDepartment, InvoiceStatus, InvoiceTotalAmount i PaymentDueDate jako dodatkowe atrybuty.
Wyeksportuj gotowy dziennik zdarzeń i prześlij go do ProcessMind. Podczas importu sprawdź, czy ProcessMind odczytuje wiersze w podanej postaci i nie musi wyznaczać brakujących aktywności.

Konfiguracja

Konektor: Użyj gotowego konektora Salesforce na platformie ETL lub iPaaS. Uwierzytelnij połączenie za pomocą użytkownika integracyjnego z uprawnieniami do odczytu wszystkich skonfigurowanych źródeł faktur, historii statusów, aktywności, płatności, księgi głównej i uzgodnień.
Mapowanie obiektów i pól: Zastąp [Invoice object], [Invoice Number field], [Invoice Created Date field] i pozostałe wpisy w nawiasach nazwami z docelowej organizacji Salesforce. W konfiguracjach Salesforce często występują niestandardowe obiekty i pola, dlatego mapowania należy zweryfikować, a nie zakładać z góry.
Zakres dat: Zacznij od danych z 3–6 miesięcy. Wydłuż okres wstecz, jeśli faktury mogą pozostawać otwarte przez kilka okresów sprawozdawczych. Uwzględnij też margines na zmiany statusu, płatności, przypomnienia i uzgodnienia.
Ekstrakcja przyrostowa: Jeśli to możliwe, użyj znacznika kontrolnego opartego na czasie ostatniej modyfikacji źródła, do której dane zostały pomyślnie pobrane. Zapisuj ten znacznik poza dziennikiem zdarzeń i ponownie przetwarzaj krótki nakładający się okres, aby nie pominąć aktualizacji, które dotarły z opóźnieniem.
Filtry: Filtruj według firmy, jednostki biznesowej, podmiotu prawnego, waluty, typu faktury i etapu procesu tylko wtedy, gdy wymaga tego analiza. Zastąp [Company filter] i [Document type filter] kryteriami właściwymi dla organizacji albo usuń je, jeśli nie mają zastosowania.
Historia statusów: W miarę możliwości korzystaj ze źródła, które zachowuje każdą zmianę statusu. Sam bieżący status faktury nie wystarczy do wiarygodnego odtworzenia wcześniejszych zdarzeń zatwierdzenia, odrzucenia, korekty, wysłania, zamknięcia lub odpisania.
Zdarzenie wyliczane na podstawie terminu płatności: Payment Due Date Reached jest generowane na podstawie PaymentDueDate i nie oznacza działania użytkownika Salesforce. Należy ustalić, czy zdarzenie ma być generowane dla wszystkich faktur, czy tylko dla tych, które pozostały otwarte do terminu płatności.
Powiązane rekordy: Skonfiguruj złączenia na podstawie rzeczywistych kluczy relacji w organizacji Salesforce. Nie zakładaj, że faktura, płatność, aktywność, księgowanie lub uzgodnienie korzystają z tego samego pola relacji w każdej implementacji.
Wydajność: Filtruj rekordy źródłowe według daty przed wykonaniem złączeń, wybieraj tylko wymagane pola, korzystaj z paginacji konektora, włącz ekstrakcję przyrostową i dziel duże zakresy dat na części, jeśli platforma to obsługuje. Unikaj wielokrotnego pobierania całej historii.
Typy danych: Ujednolić strefę czasową znaczników czasu, zachować oryginalny znacznik czasu ze źródła, jeśli jest potrzebny do audytu, i użyć typu dziesiętnego dla InvoiceTotalAmount.
Wymagania wstępne: Licencja ETL lub iPaaS musi obejmować konektor Salesforce, użytkownik integracyjny musi mieć włączony dostęp do API oraz uprawnienia do obiektów, pól i rekordów we wszystkich skonfigurowanych źródłach.
Bezpieczeństwo: Przechowuj dane logowania w menedżerze sekretów platformy, ogranicz dostęp do pobranych danych do upoważnionych użytkowników i przestrzegaj limitów Salesforce oraz zasad organizacji dotyczących wywołań API i przechowywania danych.

Przykładowe zapytanie config

SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Invoice Generated' AS ActivityName,
    CAST(i.[Invoice Created Date field] AS TIMESTAMP) AS EventTime,
    CAST(i.[Invoice Created By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(i.[Invoice Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
WHERE i.[Invoice Number field] IS NOT NULL
  AND i.[Invoice Created Date field] >= [Start date parameter]
  AND i.[Invoice Created Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Invoice Submitted for Approval' AS ActivityName,
    CAST(h.[Status Change Date field] AS TIMESTAMP) AS EventTime,
    CAST(h.[Changed By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(h.[New Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Invoice status history object] h ON h.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND h.[New Status field] = 'Pending Approval'
  AND h.[Status Change Date field] >= [Start date parameter]
  AND h.[Status Change Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Invoice Approved' AS ActivityName,
    CAST(h.[Status Change Date field] AS TIMESTAMP) AS EventTime,
    CAST(h.[Changed By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(h.[New Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Invoice status history object] h ON h.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND h.[New Status field] = 'Approved'
  AND h.[Status Change Date field] >= [Start date parameter]
  AND h.[Status Change Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Invoice Rejected' AS ActivityName,
    CAST(h.[Status Change Date field] AS TIMESTAMP) AS EventTime,
    CAST(h.[Changed By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(h.[New Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Invoice status history object] h ON h.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND h.[New Status field] = 'Rejected'
  AND h.[Status Change Date field] >= [Start date parameter]
  AND h.[Status Change Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Invoice Corrected' AS ActivityName,
    CAST(h.[Status Change Date field] AS TIMESTAMP) AS EventTime,
    CAST(h.[Changed By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(h.[New Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Invoice status history object] h ON h.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND h.[Previous Status field] = 'Rejected'
  AND h.[New Status field] = 'Draft'
  AND h.[Status Change Date field] >= [Start date parameter]
  AND h.[Status Change Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Invoice Sent to Customer' AS ActivityName,
    CAST(COALESCE(i.[Sent Date field], h.[Status Change Date field]) AS TIMESTAMP) AS EventTime,
    CAST(COALESCE(i.[Sent By field], h.[Changed By field]) AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(COALESCE(h.[New Status field], i.[Invoice Status field]) AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
LEFT JOIN [Invoice status history object] h
  ON h.[Invoice relationship field] = i.[Invoice record identifier field]
 AND h.[New Status field] = 'Sent'
WHERE i.[Invoice Number field] IS NOT NULL
  AND (i.[Sent Date field] IS NOT NULL OR h.[Status Change Date field] IS NOT NULL)
  AND COALESCE(i.[Sent Date field], h.[Status Change Date field]) >= [Start date parameter]
  AND COALESCE(i.[Sent Date field], h.[Status Change Date field]) < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Payment Due Date Reached' AS ActivityName,
    CAST(i.[Payment Due Date field] AS TIMESTAMP) AS EventTime,
    CAST(NULL AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(i.[Invoice Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
WHERE i.[Invoice Number field] IS NOT NULL
  AND i.[Payment Due Date field] IS NOT NULL
  AND i.[Payment Due Date field] >= [Start date parameter]
  AND i.[Payment Due Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Payment Reminder Issued' AS ActivityName,
    CAST(a.[Activity Date field] AS TIMESTAMP) AS EventTime,
    CAST(a.[Assigned User field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(i.[Invoice Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Activity object] a ON a.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND a.[Activity Type field] IN ('Task', 'Email')
  AND a.[Reminder Indicator field] = TRUE
  AND a.[Activity Date field] >= [Start date parameter]
  AND a.[Activity Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Customer Payment Received' AS ActivityName,
    CAST(p.[Payment Received Date field] AS TIMESTAMP) AS EventTime,
    CAST(p.[Recorded By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(i.[Invoice Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Payment object] p ON p.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND p.[Payment Received Date field] IS NOT NULL
  AND p.[Payment Received Date field] >= [Start date parameter]
  AND p.[Payment Received Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Payment Posted to Ledger' AS ActivityName,
    CAST(p.[Ledger Posting Date field] AS TIMESTAMP) AS EventTime,
    CAST(p.[Posted By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(i.[Invoice Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Payment object] p ON p.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND p.[Ledger Posting Date field] IS NOT NULL
  AND p.[Ledger Posting Date field] >= [Start date parameter]
  AND p.[Ledger Posting Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Cash Applied/Reconciled' AS ActivityName,
    CAST(r.[Reconciliation Date field] AS TIMESTAMP) AS EventTime,
    CAST(r.[Reconciled By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(i.[Invoice Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Reconciliation object] r ON r.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND r.[Reconciliation Date field] IS NOT NULL
  AND r.[Reconciliation Date field] >= [Start date parameter]
  AND r.[Reconciliation Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Invoice Closed' AS ActivityName,
    CAST(h.[Status Change Date field] AS TIMESTAMP) AS EventTime,
    CAST(h.[Changed By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(h.[New Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Invoice status history object] h ON h.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND h.[New Status field] = 'Closed'
  AND h.[Status Change Date field] >= [Start date parameter]
  AND h.[Status Change Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]
UNION ALL
SELECT
    CAST(i.[Invoice Number field] AS VARCHAR(255)) AS InvoiceNumber,
    'Invoice Written Off' AS ActivityName,
    CAST(h.[Status Change Date field] AS TIMESTAMP) AS EventTime,
    CAST(h.[Changed By field] AS VARCHAR(255)) AS UserResponsible,
    CAST(i.[Billing Department field] AS VARCHAR(255)) AS BillingDepartment,
    CAST(h.[New Status field] AS VARCHAR(255)) AS InvoiceStatus,
    CAST(i.[Invoice Total Amount field] AS DECIMAL(18,2)) AS InvoiceTotalAmount,
    CAST(i.[Payment Due Date field] AS DATE) AS PaymentDueDate
FROM [Invoice object] i
JOIN [Invoice status history object] h ON h.[Invoice relationship field] = i.[Invoice record identifier field]
WHERE i.[Invoice Number field] IS NOT NULL
  AND h.[New Status field] = 'Written Off'
  AND h.[Status Change Date field] >= [Start date parameter]
  AND h.[Status Change Date field] < [End date parameter]
  AND [Company filter]
  AND [Document type filter]

Gotowi do rozpoczęcia?

Wykorzystajcie ten szablon, aby rozpocząć analizę procesu i znaleźć możliwości jego usprawnienia. Zacznijcie optymalizować proces fakturowania już dziś.

Wróć do przewodnika ulepszania procesów

Pobierz szablon

Szybsze płatności: usprawnij fakturowanie O2C

Skróć cykl fakturowania o 30% i popraw przepływy pieniężne.

Rozpocznij okres próbny

Karta kredytowa nie jest wymagana. Konfiguracja zajmuje kilka minut.

Szablon danych Order to Cash: fakturowanie

Szablon danych Order to Cash: fakturowanie

Atrybuty procesu Order to Cash: fakturowanie

Działania w procesie Order to Cash: fakturowanie

Instrukcje pozyskiwania danych

Kreator raportów Salesforce i usługa eksportu danych

Kroki

Konfiguracja

Przykładowe zapytanie config

Skrypt Python korzystający z Salesforce REST API

Kroki

Konfiguracja

Przykładowe zapytanie python

Ekstrakcja za pomocą narzędzia ETL i gotowego konektora Salesforce

Kroki

Konfiguracja

Przykładowe zapytanie config

Gotowi do rozpoczęcia?

Szybsze płatności: usprawnij fakturowanie O2C