Šablona dat pro proces Order-to-Cash: fakturace a vystavování faktur
Šablona dat pro proces Order-to-Cash: fakturace a vystavování faktur
- Doporučené atributy ke sběru
- Důležité aktivity ke sledování
- Pokyny k extrakci dat ze SAP S/4HANA
Atributy procesu Order-to-Cash: fakturace a vystavování faktur
| Název | Popis | ||
|---|---|---|---|
| Číslo faktury InvoiceNumber | Jedinečný identifikátor fakturačního dokladu, který slouží jako hlavní identifikátor případu ve fakturačním procesu. | ||
| Popis Číslo faktury, v SAP označované jako číslo fakturačního dokladu, jednoznačně identifikuje každou fakturační transakci. Slouží jako hlavní klíč, který propojuje všechny související aktivity od vytvoření a zaúčtování faktury až po přijetí a spárování platby. V process mining je tento atribut nezbytný pro propojení případů. Všechny události se stejným číslem faktury se seskupí do jedné instance procesu. Díky tomu lze analyzovat celý životní cyklus každé faktury od začátku do konce, sledovat dobu zpracování, odhalovat odchylky a vyhodnocovat průběh jednotlivých faktur. Proč je to důležité Jde o základní identifikátor, který propojuje všechny související fakturační aktivity do jednoho případu a umožňuje analyzovat proces od začátku do konce. Kde data získat Tabulka SAP: VBRK, pole: VBELN Příklady 900012349000567890009012 | |||
| Čas události EventTime | Přesné časové razítko určující, kdy k aktivitě nebo události došlo. | ||
| Popis Čas události uvádí datum a čas každé aktivity a tvoří chronologickou osu procesu. Toto časové razítko je nezbytné pro výpočet dob trvání, dob zpracování a čekání mezi jednotlivými kroky fakturačního procesu. Při analýze se podle času události řadí aktivity za sebou, počítají ukazatele výkonnosti, například doba inkasa pohledávek a doba vystavení faktury, a odhalují časová úzká místa. Umožňuje sledovat změny výkonnosti v čase i délku jednotlivých fází fakturačního cyklu. Proč je to důležité Určuje chronologické pořadí událostí, které je nezbytné pro výpočet časových ukazatelů, například dob zpracování a trvání. Kde data získat Získává se z různých polí data a času podle aktivity, například z data a času vytvoření (VBRK-ERDAT, VBRK-ERZET), časových razítek změn (CDHDR-UDATE, CDHDR-UTIME) nebo data zaúčtování (BKPF-BUDAT). Příklady 2023-04-15T10:30:00Z2023-04-20T14:00:00Z2023-05-10T09:15:00Z | |||
| Název aktivity ActivityName | Název obchodní aktivity nebo události, ke které došlo ve fakturačním procesu, například „Faktura vystavena“ nebo „Platba přijata“. | ||
| Popis Název aktivity popisuje konkrétní krok nebo milník v životním cyklu faktury. Aktivity se odvozují z různých údajů v SAP, například z kódů transakcí, změn stavu dokladů nebo konkrétních záznamů v protokolech. Z nich se sestaví posloupnost průběhu procesu. Analýza pořadí a četnosti těchto aktivit je základem process mining. Umožňuje zobrazit mapu procesu, odhalit běžné i méně časté varianty, najít úzká místa mezi kroky a měřit četnost činností, které nepřinášejí hodnotu, například oprav nebo storen. Proč je to důležité Tento atribut určuje jednotlivé kroky procesu. Umožňuje zobrazit mapy procesů a analyzovat průběh, varianty i úzká místa. Kde data získat Odvozuje se z různých zdrojů, například z kódů transakcí (SY-TCODE), stavů změnových dokladů (tabulky CDHDR/CDPOS) nebo protokolů workflow (například SWW_WI2OBJ). Příklady Faktura vystavenaFaktura zaúčtována do účetnictvíPlatba od zákazníka přijataFaktura stornována | |||
| Čas ukončení EndTime | Přesné časové razítko označující dokončení aktivity nebo události. | ||
| Popis Čas ukončení označuje dokončení aktivity. V process mining se často odvozuje od času zahájení následující aktivity v případu. Pokud systém zaznamenává začátek i konec událostí, lze jej získat přímo. Tento atribut je nezbytný pro výpočet doby zpracování jednotlivých aktivit. Odečtením času zahájení od času ukončení zjistíte, jak dlouho každý krok trval. To je důležité při analýze úzkých míst, například při hledání prodlev ve schvalování faktur. Proč je to důležité Umožňuje vypočítat přesnou dobu trvání, tedy dobu zpracování každé aktivity, což je základem analýzy úzkých míst. Kde data získat Jde o odvozený atribut pro process mining. Obvykle se vypočítá jako StartTime následující události v případu. V některých případech mohou být časy dokončení zaznamenány v konkrétních tabulkách. Příklady 2023-04-15T11:00:00Z2023-04-20T14:05:00Z2023-05-10T09:45:00Z | |||
| Částka faktury InvoiceAmount | Celková čistá hodnota faktury. | ||
| Popis Tento atribut představuje celkovou peněžní hodnotu fakturovaného zboží nebo služeb bez daní. Jde o základní finanční údaj každého případu faktury. Částka faktury se používá v řadě analýz. Umožňuje rozdělit proces podle hodnoty a například zjistit, zda se faktury s vysokou hodnotou zpracovávají jinak nebo se u nich častěji objevují prodlevy. Slouží také jako základ finančního výkaznictví a výpočtu celkové hodnoty neuhrazených pohledávek. Proč je to důležité Vyjadřuje finanční hodnotu každé faktury a umožňuje analýzu podle hodnoty, stanovení priorit při inkasu i posouzení finančního dopadu. Kde data získat Tabulka SAP: VBRK, pole: NETWR Příklady 1500.0025000.50125.75 | |||
| Datum faktury InvoiceDate | Oficiální datum vystavení faktury zákazníkovi. | ||
| Popis Datum faktury, v SAP označované také jako datum fakturace, slouží jako výchozí bod pro řadu finančních výpočtů. Od tohoto data se určují platební podmínky, termíny splatnosti i stáří pohledávky. Jde o důležitý atribut na úrovni případu pro finanční analýzu. Slouží jako základ pro výpočet KPI doby inkasa pohledávek (DSO) a tvorbu přehledů o stáří neuhrazených faktur, které jsou nezbytné pro řízení cash flow a inkasa. Proč je to důležité Jde o hlavní datum pro finanční výpočty. Slouží jako výchozí bod pro DSO, termíny splatnosti i analýzu stáří faktur. Kde data získat Tabulka SAP: VBRK, pole: FKDAT Příklady 2023-03-202023-04-012023-05-18 | |||
| Datum splatnosti PaymentDueDate | Datum, do kterého má zákazník fakturu uhradit. | ||
| Popis Datum splatnosti se vypočítá podle data faktury a dohodnutých platebních podmínek. Určuje termín, do kterého musí být platba přijata, aby faktura nebyla po splatnosti. Tento atribut je důležitý pro sledování efektivity inkasa a prognózování cash flow. Používá se při výpočtu KPI míry včasných plateb i při rozdělování faktur podle stáří. Analýza rozdílu mezi datem splatnosti a skutečným datem platby pomáhá vyhodnotit účinnost různých platebních podmínek. Proč je to důležité Určuje termín, do kterého má zákazník zaplatit. Je proto důležitý pro výpočet míry včasných plateb i správu pohledávek. Kde data získat Toto datum se neukládá přímo. Vypočítá se podle data faktury (VBRK-FKDAT) a klíče platebních podmínek (VBRK-ZTERM) pomocí standardních funkcí SAP pro určení data. Příklady 2023-04-192023-05-012023-06-17 | |||
| Jméno uživatele UserName | ID uživatele, který aktivitu provedl. | ||
| Popis Tento atribut zachycuje ID uživatele SAP odpovědného za konkrétní událost, například vytvoření faktury, zaúčtování dokladu nebo vyrovnání platby. Propojuje tak kroky procesu s jednotlivci nebo týmy, které je provádějí. Analýza podle jména uživatele pomáhá odhalit potřeby školení, rozdíly ve výkonu i nerovnoměrné rozložení práce. Je důležitá také pro analýzu shody, protože ukazuje, kdo provedl důležité aktivity, a pomáhá vysvětlit rozdíly v tom, jak jednotliví uživatelé postupují při stejném procesu. Proč je to důležité Propojuje aktivity procesu s konkrétními uživateli a umožňuje analyzovat pracovní vytížení, výkonnost a shodu na úrovni jednotlivců i týmů. Kde data získat U událostí vytvoření je údaj v poli VBRK-ERNAM. U pozdějších změn je uveden v tabulkách historie změn, například CDHDR-USERNAME, nebo v protokolech workflow. Příklady CBURNSHSIMPSONLLEONARD | |||
| Název zákazníka CustomerName | Název zákazníka, kterému byla faktura vystavena. | ||
| Popis Tento atribut určuje oficiální název fakturovaného zákazníka. Údaj pochází z centrálních kmenových dat zákazníků v SAP. Analýza procesu podle zákazníka pomáhá odhalit vzorce typické pro konkrétní účty. Může například ukázat, kteří zákazníci pravidelně platí pozdě, nejčastěji reklamují nebo u nichž je fakturační proces nejméně efektivní. Na základě těchto poznatků lze cíleně řídit vztahy se zákazníky a přizpůsobit postupy inkasa. Proč je to důležité Umožňuje analyzovat proces z pohledu zákazníků a odhalit platební chování, četnost reklamací i neefektivní postupy u konkrétních účtů. Kde data získat Získává se z kmenových dat zákazníků v tabulce KNA1 (pole: NAME1) a propojuje se přes ID plátce v hlavičce faktury (VBRK-KUNRG). Příklady Elektrárna SpringfieldObchod Kwik-E-MartSpolečnost Cyberdyne Systems | |||
| Region Region | Zeměpisná oblast, ve které se zákazník nachází. | ||
| Popis Atribut region označuje zeměpisnou oblast, například stát nebo provincii, která je spojena s adresou zákazníka. Tyto údaje jsou obvykle součástí kmenového záznamu zákazníka. Tento atribut je důležitý pro dashboard výkonnosti fakturace podle regionů. Umožňuje porovnávat hlavní ukazatele, například dobu zpracování, chybovost a DSO, mezi jednotlivými regiony. Srovnání může odhalit regionální rozdíly v průběhu procesu, shodě nebo efektivitě a pomoci určit, kde se zaměřit na zlepšení a sjednocení osvědčených postupů. Proč je to důležité Umožňuje porovnávat výkonnost fakturace v různých zeměpisných oblastech, odhalovat regionální rozdíly a sjednocovat procesy. Kde data získat Získává se z kmenových dat zákazníků v tabulce KNA1 (pole: REGIO) a propojuje se přes ID plátce v hlavičce faktury (VBRK-KUNRG). Příklady KalifornieNew YorkTexasBádensko-Württembersko | |||
| Číslo zákaznické objednávky SalesOrderNumber | Identifikátor původní zákaznické objednávky, na jejímž základě vznikla faktura. | ||
| Popis Číslo zákaznické objednávky propojuje fakturační doklad s předchozími obchodními aktivitami. Z jedné objednávky může vzniknout jedna nebo více faktur. Toto propojení zachycuje celý tok dokladů. Tento atribut je nezbytný pro skutečně komplexní analýzu procesu Order-to-Cash od začátku do konce. Umožňuje rozšířit pohled na proces i na předchozí fáze a propojit problémy ve fakturaci s jejich možnými příčinami při vytváření nebo plnění objednávky. Pomáhá například vypočítat celkovou dobu vystavení faktury od okamžiku splnění objednávky. Proč je to důležité Propojuje fakturu s původní zákaznickou objednávkou a umožňuje sledovat celý proces Order-to-Cash, nejen samotnou fakturaci. Kde data získat Tabulka SAP: VBRP (položky fakturačního dokladu), pole: AUBEL Příklady 100001231000045610000789 | |||
| Důvod dobropisu CreditMemoReason | Kód důvodu, který uvádí, proč byl vystaven dobropis. | ||
| Popis Pokud je faktura chybná a je třeba ji dobropisovat, k dobropisu se obvykle přiřadí důvod. Díky tomu lze příčiny chyb ve fakturaci přehledně kategorizovat. Tento atribut přímo podporuje KPI míry chybovosti fakturace. Souhrnná analýza důvodů dobropisů pomáhá firmě určit nejčastější typy chyb, například nesprávné ceny nebo vrácení zboží. Na základě těchto zjištění lze zlepšovat procesy, omezit finanční opravy a předělávání práce. Proč je to důležité Kategorizuje důvody vystavení dobropisů, pomáhá určit nejčastější příčiny chyb ve fakturaci a zaměřit zlepšování kvality. Kde data získat Tabulka SAP: VBRK, pole: AUGRU (důvod objednávky). Toto pole se používá u požadavků na dobropis nebo vrubopis, které se následně fakturují. Příklady 001 - Rozdíl v ceně002 - Nízká kvalita005 - Vrácení zákazníkem | |||
| Důvod reklamace faktury CustomerDisputeReason | Důvod, který zákazník uvedl při reklamaci faktury. | ||
| Popis Když zákazník fakturu reklamuje, obvykle se zaznamená důvod. Může jít například o chybnou cenu, nesprávné množství nebo poškozené zboží. Tyto informace mohou být uložené v modulu SAP Dispute Management nebo jako textové poznámky. Analýza důvodů reklamací je základem KPI míry chybovosti fakturace a související analýzy chyb. Pomáhá odhalit hlavní příčiny nepřesností ve fakturaci, řešit systémové problémy v předchozích procesech, zlepšit kvalitu faktur a zvýšit spokojenost zákazníků. Proč je to důležité Ukazuje, proč zákazníci faktury reklamují, a pomáhá přímo odhalit příčiny chyb ve fakturaci i nespokojenosti zákazníků. Kde data získat Pokud používáte SAP Dispute Management, informace najdete například v tabulce UDM_DISPUTE. Jinak je lze odvodit z kódů důvodů v souvisejících dokladech nebo z textových polí. Příklady Nesprávná cenaNesoulad v množstvíPřevzetí poškozeného zboží | |||
| Kód společnosti CompanyCode | Organizační jednotka, za kterou se zaznamenává finanční transakce. | ||
| Popis Kód společnosti je základní organizační jednotka v SAP Financials. Představuje právně samostatnou společnost, pro kterou se sestavují účetní výkazy. Každý fakturační doklad je přiřazen ke konkrétnímu kódu společnosti. Analýza podle kódu společnosti je v organizacích s více společnostmi nezbytná pro porovnání výkonnosti procesů, finančních ukazatelů, jako je DSO, a shody mezi jednotlivými právními subjekty. Slouží jako hlavní organizační filtr pro všechny dashboardy procesů. Proč je to důležité Umožňuje rozdělit analýzu procesů podle právního subjektu a porovnávat výkonnost i konsolidovat finanční údaje napříč organizací. Kde data získat Tabulka SAP: VBRK, pole: BUKRS Příklady 10002000US01 | |||
| Měna Currency | Kód měny, ve které je uvedena částka faktury. | ||
| Popis Tento atribut určuje měnu, ve které jsou částky faktur uvedeny, například USD, EUR nebo JPY. Poskytuje potřebný kontext pro všechny peněžní hodnoty. V mezinárodní organizaci je měna nezbytná pro správnou finanční analýzu a výkaznictví. Umožňuje převést částky na společnou vykazovací měnu a porovnávat výkonnost fakturace v regionech s různými místními měnami. Proč je to důležité Poskytuje potřebný kontext pro všechny peněžní hodnoty a zajišťuje přesnou finanční analýzu i výkaznictví, zejména v mezinárodním provozu. Kde data získat Tabulka SAP: VBRK, pole: WAERK Příklady USDEURGBP | |||
| Platební podmínky PaymentTerms | Kód určující platební podmínky, například lhůtu splatnosti. | ||
| Popis Platební podmínky jsou předem stanovená pravidla dohodnutá se zákazníkem, která určují, kdy má být faktura uhrazena. Příkladem je „Net 30“ (splatnost do 30 dnů) nebo „2/10 Net 30“ (sleva 2 % při úhradě do 10 dnů, jinak splatnost do 30 dnů). Analýza podle platebních podmínek pomáhá posoudit, jak dobře fungují. Porovnáním jednotlivých podmínek se skutečnou dobou úhrady lze zjistit, které z nich nejlépe podporují včasné platby. Firma pak může podmínky upravit a zlepšit cash flow. Proč je to důležité Určuje dohodnutý harmonogram plateb a umožňuje vyhodnotit, které podmínky nejlépe podporují včasné platby zákazníků. Kde data získat Tabulka SAP: VBRK, pole: ZTERM Příklady Z030Z060ZB60 | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko určující, kdy byla data této události naposledy extrahována nebo aktualizována. | ||
| Popis Tento atribut zaznamenává datum a čas posledního načtení dat ze zdrojového systému. Jde o metadata důležitá pro posouzení aktuálnosti analyzovaných dat. Tyto informace slouží k ověření aktuálnosti analýzy a plánování obnovy dat. Zúčastněné strany tak při rozhodování na základě dashboardů a poznatků z process mining vědí, jak aktuální data jsou. Proč je to důležité Ukazuje aktuálnost dat, která je důležitá pro důvěryhodnost analýzy i posouzení její relevance pro současný stav provozu. Kde data získat Toto časové razítko se vytvoří a připojí ke každému záznamu při extrakci a načítání dat (ETL). Příklady 2023-06-01T02:00:00Z2023-06-02T02:00:00Z | |||
| Stav platby PaymentStatus | Aktuální stav úhrady faktury, například otevřená, uhrazená nebo po splatnosti. | ||
| Popis Stav platby ukazuje, v jaké fázi vymáhání pohledávky se faktura nachází. V SAP nejde o jedno samostatné pole. Stav se odvozuje z toho, zda byl příslušný účetní doklad vyrovnán. Tento atribut je nezbytný pro dashboard přehledu neuhrazených faktur podle doby po splatnosti. Umožňuje rozdělit všechny otevřené faktury podle stavu a stáří, aby tým pro správu pohledávek mohl účinně určovat priority. Sledování změn stavů zároveň pomáhá vyhodnocovat samotný proces vymáhání pohledávek. Proč je to důležité Jasně ukazuje stav vymáhání každé faktury, což je důležité pro správu pohledávek a stanovení priorit při jejich vymáhání. Kde data získat Odvozuje se z kontroly stavu vyrovnání účetního dokladu (VBRK-BELNR) ve finančních tabulkách, například BSID (otevřené položky) a BSAD (vyrovnané položky). Příklady OtevřenáUhrazenáPo splatnostiČástečně uhrazená | |||
| Typ fakturačního dokladu BillingDocumentType | Kód, který určuje typ fakturačního dokladu, například fakturu, dobropis nebo storno. | ||
| Popis Typ fakturačního dokladu je důležité pole, které kategorizuje transakce v procesu fakturace. Určuje způsob zpracování dokladu, včetně číselné řady a pravidel účtování. Tento atribut umožňuje filtrovat proces podle konkrétních typů transakcí. Můžete například vytvořit samostatný pohled na dobropisy a zjistit důvody i průběh finančních oprav. Standardní faktury lze analyzovat odděleně od storen, abyste získali jasnější přehled o hlavním fakturačním procesu. Proč je to důležité Kategorizuje transakce a umožňuje zaměřit analýzu na konkrétní typy dokladů, například standardní faktury, dobropisy nebo storna. Kde data získat Tabulka SAP: VBRK, pole: FKART Příklady F2G2S1L2 | |||
| Uhrazeno včas IsPaidOnTime | Logická hodnota určující, zda byla faktura uhrazena v den splatnosti nebo dříve. | ||
| Popis Tento vypočítaný atribut porovnává skutečné datum úhrady s plánovaným datem splatnosti. Vrací hodnotu „true“, pokud byla faktura uhrazena včas, a „false“, pokud byla uhrazena pozdě. Tento příznak usnadňuje výpočet a zobrazení KPI míry včasných plateb. Umožňuje snadno filtrovat a rozdělit faktury na uhrazené včas a po termínu. Díky tomu lze odhalit souvislosti s konkrétními zákazníky, regiony nebo platebními podmínkami, které vedou k pozdním platbám. Proč je to důležité Jednoznačně označí každou fakturu jako uhrazenou včas, nebo po termínu, a usnadňuje tak měření KPI míry včasných plateb. Kde data získat Jde o vypočítané pole. Logika porovnává časové razítko aktivity „Přijata platba od zákazníka“ s hodnotou atributu „PaymentDueDate“. Příklady truefalse | |||
| Zdrojový systém SourceSystem | Určuje konkrétní zdrojový systém, ze kterého byla data extrahována. | ||
| Popis Tento atribut určuje původ dat. Hodí se zejména v prostředích s více instancemi SAP nebo dalšími integrovanými systémy. Obvykle obsahuje ID systému a číslo klienta. Při analýze pomáhá rozlišit procesy a jejich výkonnost v různých systémech nebo organizačních jednotkách. Umožňuje sledovat původ dat a poskytuje potřebný kontext, zejména při spojování dat z více zdrojů do jednoho přehledu procesu. Proč je to důležité Poskytuje důležitý kontext o původu dat, zajišťuje přehlednost v prostředí s více systémy a podporuje správu dat. Kde data získat Obvykle jde o statickou hodnotu nastavenou při extrakci dat, která často kombinuje ID systému (SY-SYSID) a klienta (SY-MANDT). Příklady S4H_PROD_100S4H_QAS_200ECC_PROD_300 | |||
Aktivity procesu Order-to-Cash: fakturace a vystavování faktur
| Aktivita | Popis | ||
|---|---|---|---|
| Faktura uzavřena | Tato aktivita označuje konečný stav faktury, která byla úspěšně uhrazena. Funkčně odpovídá události „Platba přiřazena a spárována“ a znamená, že proces pro tuto fakturu skončil. | ||
| Proč je to důležité Jde o hlavní koncovou událost standardního průběhu procesu. Celková doba procesu do tohoto okamžiku poskytuje úplný přehled o životním cyklu fakturace od začátku do konce. Kde data získat Událost se odvozuje ze stavu zákaznické položky v účetním dokladu. Položka je uzavřená neboli vyrovnaná, pokud jsou vyplněna pole data vyrovnání (BSEG-AUGDT) a čísla vyrovnávacího dokladu (BSEG-AUGBL). Zachycení Událost se odvozuje z vyplněného data vyrovnání (AUGDT) v tabulce BSEG/ACDOCA pro položku faktury. Typ události inferred | |||
| Faktura vystavena | Tato aktivita označuje vytvoření fakturačního dokladu v systému. Jde o zaznamenanou událost, ke které dojde, když uživatel spustí transakci, například VF01, nebo když fakturu vytvoří úloha na pozadí. Vznikne tak nový záznam v tabulce hlaviček fakturačních dokladů. | ||
| Proč je to důležité Jde o hlavní počáteční událost fakturačního procesu. Doba od vyřízení objednávky do této aktivity je důležitá pro měření doby vystavení faktury a odhalení počátečních prodlev v procesu. Kde data získat Při vytvoření se událost zaznamená do tabulky SAP S/4HANA VBRK (fakturační doklad: data hlavičky). Časové razítko tvoří datum vytvoření (VBRK-ERDAT) a čas (VBRK-ERZET). Zachycení Událost se zaznamená podle časového razítka vytvoření záznamu fakturačního dokladu v tabulce VBRK. Typ události explicit | |||
| Faktura zaúčtována do účetnictví | Označuje úspěšné zaúčtování fakturačního dokladu do modulu finančního účetnictví. Jde o důležitý milník, kdy se z faktury stává oficiální pohledávka a vznikají zápisy v hlavní knize. | ||
| Proč je to důležité Tato aktivita potvrzuje, že faktura je platným finančním dokladem. Doba mezi vystavením a zaúčtováním je důležitým ukazatelem výkonnosti, který vypovídá o efektivitě interního zpracování. Kde data získat Událost se zaznamená při vytvoření souvisejícího účetního dokladu. Fakturační doklad (VBRK-VBELN) je propojen s účetním dokladem (BKPF-BELNR) prostřednictvím VBRK-BELNR. Datum zaúčtování je uvedeno v BKPF-BUDAT. Zachycení Událost se zaznamená podle data zaúčtování (BUDAT) účetního dokladu v tabulce BKPF, který je propojen s fakturačním dokladem. Typ události explicit | |||
| Platba od zákazníka přijata | Tato aktivita označuje zaúčtování příchozí platby zákazníka do finančního systému. V této fázi ještě nemusí být platba přiřazena ke konkrétní faktuře, přijaté peníze jsou však již zaznamenány. | ||
| Proč je to důležité Důležitý milník pro výpočet doby inkasa pohledávek (DSO). Označuje přijetí peněz, i když jejich spárování s fakturou ještě nebylo dokončeno. Kde data získat Událost se zaznamená podle data zaúčtování (BKPF-BUDAT) dokladu o platbě zákazníka, obvykle dokladu typu „DZ“ v tabulce BKPF. Zachycení Událost se odvozuje od vytvoření platebního dokladu v BKPF/BSEG. Typ události explicit | |||
| Platba přiřazena a spárována | Označuje okamžik, kdy je příchozí platba zákazníka spárována s neuhrazenou fakturou a použita k jejímu vyrovnání v pomocné knize pohledávek. Z finančního hlediska tím transakce končí. | ||
| Proč je to důležité Měří efektivitu přiřazování plateb. Prodlevy mohou zkreslit skutečný stav zákaznických účtů a zbytečně zatěžovat týmy, které se věnují inkasu. Kde data získat Událost se zaznamená podle data vyrovnání (BSEG-AUGDT) na položce původního účetního dokladu faktury. Toto datum se vyplní při vyrovnání položky vyrovnávacím dokladem. Zachycení Událost se zaznamená podle pole data vyrovnání (AUGDT) v tabulce BSEG/ACDOCA pro položku faktury. Typ události explicit | |||
| Faktura odeslána zákazníkovi | Tato aktivita označuje odeslání faktury zákazníkovi, například tiskem, e-mailem nebo přes EDI. Způsob zaznamenání závisí na nastavení správy výstupů v SAP. | ||
| Proč je to důležité Z pohledu zákazníka jde o okamžik, od kterého začíná běžet lhůta pro platbu. Zpoždění při odeslání faktury přímo ovlivňuje dobu inkasa pohledávek (DSO) i cash flow. Kde data získat Událost lze zaznamenat přímo v tabulkách řízení výstupů, například v NAST u starších metod nebo v odpovídajícím řešení S/4HANA. Pokud se nezaznamenává přímo, často se odvozuje od okamžiku události „Faktura zaúčtována do účetnictví“. Zachycení V protokolech zpracování v tabulkách správy výstupů vyhledejte časové razítko odpovídající typu výstupu faktury. Typ události explicit | |||
| Faktura stornována | K této události dojde, když je již vystavená faktura stornována, obvykle vytvořením odpovídajícího stornovacího dokladu. Tím se zruší původní faktura i její účetní dopad. | ||
| Proč je to důležité Označuje opakované zpracování, opravy nebo chyby ve fakturaci. Častá storna poukazují na závažné problémy v zadávání zákaznických objednávek nebo v nastavení fakturace. Kde data získat Událost se zaznamená při vytvoření stornovacího fakturačního dokladu, například typu „S1“. Tento nový doklad v tabulce VBRK odkazuje na číslo původní faktury v poli VBRK-SFAKN. Zachycení Událost se zaznamená podle data vytvoření stornovacího dokladu v tabulce VBRK, který odkazuje na původní fakturu. Typ události explicit | |||
| Nastal termín splatnosti | Vypočítaná událost, která označuje datum, kdy má být podle dohodnutých platebních podmínek faktura uhrazena. Nejde o transakční událost, datum se odvozuje z údajů faktury. | ||
| Proč je to důležité Toto datum slouží jako důležitý základ pro měření včasnosti plateb a analýzu platebního chování zákazníků. Pomáhá rozlišit včasné a opožděné platby. Kde data získat Vypočítá se podle základního data splatnosti (BSEG-ZFBDT) a platebních podmínek uložených na zákaznické položce účetního dokladu. Zachycení Odvozuje se přičtením počtu dní splatnosti k základnímu datu splatnosti uvedenému na položce účetního dokladu (BSEG). Typ události calculated | |||
| Upomínka k platbě odeslána | Označuje odeslání upomínky zákazníkovi kvůli faktuře po splatnosti. Jde o výslovně zaznamenanou událost, kterou vytvoří automatický upomínkový proces. | ||
| Proč je to důležité Umožňuje vyhodnotit účinnost upomínkového procesu. Pomáhá zjistit, zda upomínky urychlují platby a které stupně upomínání mají největší účinek. Kde data získat Událost se zaznamená v tabulkách historie upomínek (MAHNV, MHND) při spuštění upomínkového běhu (transakce F150) pro neuhrazenou položku faktury. Zachycení Událost se zaznamená podle data spuštění upomínky uvedeného v tabulkách historie upomínek. Typ události explicit | |||
| Vytvořen dobropis | Tato aktivita označuje vytvoření dobropisu, který se vystavuje zákazníkovi při přeúčtování nebo jako dobropis za vrácené zboží. Často se vztahuje k původní faktuře. | ||
| Proč je to důležité Odhalí příčiny finančních úprav po fakturaci. Analýza dobropisů může poukázat na chyby v cenách, problémy s produkty nebo jiné příčiny ztráty výnosů. Kde data získat Dobropis se vytvoří jako nový fakturační doklad v tabulce VBRK s příslušným typem fakturace, například „G2“. Často odkazuje na původní zákaznickou objednávku nebo fakturu. Zachycení Událost se zaznamená při vytvoření fakturačního dokladu typu dobropis v tabulce VBRK. Typ události explicit | |||
| Zákazník vznesl reklamaci | K této aktivitě dojde, když zákazník reklamuje fakturu a reklamace se formálně zaznamená v systému. Vyžaduje to použití modulu SAP Dispute Management. | ||
| Proč je to důležité Odhalí problémy s přesností fakturace, kvalitou produktů nebo poskytováním služeb, které vedou ke zpoždění plateb. Analýza důvodů reklamací pomáhá řešit jejich příčiny a zlepšovat spokojenost zákazníků. Kde data získat Událost se zaznamená při vytvoření případu reklamace v tabulkách Dispute Management, například UDM_CASE. Případ je propojen s položkou účetního dokladu. Zachycení Událost se zaznamená podle časového razítka vytvoření případu reklamace propojeného s fakturou. Typ události explicit | |||
| Zaúčtování faktury blokováno | K této události dojde, když je faktura vytvořena, ale její zaúčtování do finančního účetnictví je automaticky zablokováno, například kvůli kontrole úvěrového limitu nebo nesrovnalostem v datech. Událost se odvozuje z pole stavu zaúčtování fakturačního dokladu. | ||
| Proč je to důležité Odhalí úzká místa, kdy jsou faktury vytvořeny, ale nejsou ihned uvolněny pro finanční účtování, což prodlužuje celý cyklus inkasa. Jde o důležitý ukazatel problémů s kvalitou dat nebo správou úvěrových limitů. Kde data získat Událost se odvozuje z pole stavu zaúčtování v tabulce hlaviček fakturačních dokladů (VBRK-RFBSK). Blokaci označuje například stav „A“ (fakturační doklad blokován pro předání do FI). Zachycení Událost se odvozuje z hodnoty pole stavu zaúčtování (VBRK-RFBSK) bezprostředně po vystavení faktury. Typ události inferred | |||
| Zjištěna oprava fakturace | Vypočítaná událost, která označuje opakování procesu: faktura byla stornována a poté byla pro stejnou zákaznickou objednávku vystavena nová. Nejde o jednu transakci, ale o posloupnost událostí. | ||
| Proč je to důležité Přímo podporuje KPI míry oprav fakturace tím, že vyčísluje počet oprav. Pomáhá tak odhalit neefektivní postupy a měřit náklady na nízkou kvalitu fakturačního procesu. Kde data získat Tento vzorec se vypočítá vyhledáním události „Faktura stornována“, po níž následuje nová událost „Faktura vystavena“. Obě události musí odkazovat na stejný zdrojový doklad, například číslo zákaznické objednávky. Zachycení Odvozuje se z posloupnosti událostí „Faktura stornována“ a „Faktura vystavena“ pro stejnou zákaznickou objednávku. Typ události calculated | |||
Návody na extrakci dat
Kroky
- Předpoklady: Ověřte, že máte uživatelský účet v SAP S/4HANA a potřebná oprávnění k dotazování nad pohledy Core Data Services (CDS). Potřebujete zejména přístup pro čtení k pohledům, jako jsou I_BillingDocument, I_JournalEntryItem, I_Customer, I_Outgmgmtdocumentoutputreq, I_DisputeCase a I_DunningHistory.
- Přístup k nástroji pro extrakci dat: Přihlaste se do systému SAP S/4HANA. K provádění SQL dotazů nad CDS View můžete použít různé nástroje, například SAP HANA Studio, DBeaver připojený přes klienta SAP HANA nebo doplněk SAP Analysis for Microsoft Excel. V tomto návodu předpokládáme, že používáte běžného SQL klienta.
- Určení parametrů systému: Před spuštěním dotazu určete příslušné kódy společností a časové období pro analýzu. Doporučujeme začít s omezeným rozsahem, například s daty za poslední 3 až 6 měsíců, aby dotaz proběhl v přiměřeném čase.
- Příprava SQL dotazu: Zkopírujte celý SQL dotaz z části „query“ tohoto dokumentu do zvoleného SQL klienta.
- Úprava zástupných hodnot: Upravte zástupné hodnoty v dotazu. Nahraďte
'YYYY-MM-DD'požadovaným počátečním a koncovým datem. Hodnotu'XXXX'nahraďte příslušným kódem nebo kódy společností. Podle konfigurace systému může být potřeba upravit také zástupnou hodnotu pro typy dobropisů, například'G2'. - Spuštění dotazu: Spusťte upravený SQL dotaz nad databází SAP S/4HANA. Doba zpracování závisí na objemu dat ve zvoleném období.
- Kontrola výsledků: Po dokončení dotazu zkontrolujte výstup. Výsledkem má být plochá tabulka, v níž každý řádek představuje jednu aktivitu ve fakturačním procesu. Jde o váš záznam událostí.
- Transformace dat (podle potřeby): Dotaz je navržen tak, aby vytvořil záznam událostí ve vhodném formátu. Přesto ověřte, že formát časových značek odpovídá vašemu nástroji process mining. Dotaz používá funkci
ABAP_SYSTEM_UTCL_TO_TIMESTAMPk převodu na standardní časové značky UTC, které jsou kompatibilní s většinou nástrojů. - Export záznamu událostí: Exportujte celý výsledek z SQL klienta do souboru CSV. Soubor uložte v kódování UTF-8, aby nedocházelo k problémům se znaky.
- Nahrání do ProcessMind: Nahrajte vytvořený soubor CSV do platformy ProcessMind a namapujte jeho sloupce, například InvoiceNumber, ActivityName a EventTime, na odpovídající pole v nástroji.
Konfigurace
- Časové období: Nastavte počáteční a koncové datum v klauzuli
WHEREprvního Common Table Expression (CTE). Pro úvodní analýzu doporučujeme období 3 až 6 měsíců, které vyvažuje objem dat a výkon. Filtr se vztahuje naBillingDocumentDate. - Kód společnosti: Omezte extrakci na příslušné právní subjekty filtrem podle jedné nebo více hodnot
CompanyCode. Tento filtr je důležitý pro vymezení rozsahu dat. - Typy dokladů: Dotaz obsahuje logiku pro rozpoznání dobropisů podle hodnoty
BillingDocumentType. Upravte zástupnou hodnotu, například('G2', 'CR'), podle typů dokladů používaných pro dobropisy ve vaší organizaci. - Předpoklady: Přístup k podkladovým CDS View je povinný. Potřebné role a oprávnění vám musí přidělit tým zabezpečení SAP. Aby bylo možné zachytit aktivity jako „Otevření zákaznického sporu“ nebo „Odeslání upomínky“, musí se ve vašem systému používat příslušné moduly SAP Dispute Management a SAP Financials Dunning.
- Výkon: Dotaz používá několik spojení a sjednocení. U velmi rozsáhlých datových sad, například za několik let, zvažte spuštění mimo špičku nebo použití přísnějších filtrů, které omezí počáteční extrakci.
Ukázkový dotaz sql
WITH BaseInvoices AS (
SELECT
bd.BillingDocument AS InvoiceNumber,
bd.CreationDateTime,
bd.BillingDocumentDate AS InvoiceDate,
bd.NetDueDate AS PaymentDueDate,
bd.TotalNetAmount AS InvoiceAmount,
bd.CreatedByUser AS UserName,
bd.SDDocumentPostingStatus,
bd.AccountingDocument,
bd.IsCancelled,
bd.CancelledBillingDocument,
bd.PrecedingSDDocument,
bd.CompanyCode,
bd.BillingDocumentType,
cust.CustomerName,
reg.RegionName AS Region
FROM I_BillingDocument AS bd
LEFT JOIN I_Customer AS cust ON bd.SoldToParty = cust.Customer
LEFT JOIN I_Region AS reg ON cust.Region = reg.Region
WHERE
bd.BillingDocumentDate BETWEEN '2023-01-01' AND '2023-12-31' -- Placeholder: Set your date range
AND bd.CompanyCode = 'XXXX' -- Placeholder: Set your Company Code
AND bd.BillingCategory IN ('M', 'N', 'O', 'P', 'U', 'V', '5', '6') -- Filters for customer invoices/credit memos
)
-- 1. Invoice Generated
SELECT
bi.InvoiceNumber,
'Invoice Generated' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
UNION ALL
-- 2. Invoice Posting Blocked
SELECT
bi.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.SDDocumentPostingStatus = 'A' -- A = Billing document blocked for posting
UNION ALL
-- 3. Invoice Posted To Accounting
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EventTime,
je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(je.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntry AS je ON bi.AccountingDocument = je.AccountingDocument
WHERE bi.AccountingDocument IS NOT NULL AND bi.AccountingDocument <> ''
UNION ALL
-- 4. Invoice Sent To Customer
SELECT DISTINCT
bi.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EventTime,
om.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(om.OutputRequestLastChgDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_Outgmgmtdocumentoutputreq AS om ON bi.InvoiceNumber = om.SenderBusinessObject
WHERE om.OutputRequestStatus = 'S' -- Status 'S' for 'Successfully Processed'
UNION ALL
-- 5. Payment Due Date Reached
SELECT
bi.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EventTime,
'System' AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(bi.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.PaymentDueDate IS NOT NULL AND bi.PaymentDueDate <= CURRENT_DATE
UNION ALL
-- 6. Customer Dispute Opened
SELECT DISTINCT
bi.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EventTime,
dc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(dc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_DisputedItem AS di ON bi.InvoiceNumber = di.BillingDocument
JOIN I_DisputeCase AS dc ON di.DisputeCase = dc.DisputeCase
UNION ALL
-- 7. Payment Reminder Issued
SELECT DISTINCT
bi.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EventTime,
dh.DunningRunUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
CAST(dh.DunningRunDate AS TIMESTAMP) AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.CompanyCode = jei.CompanyCode
JOIN I_DunningHistory AS dh ON jei.CompanyCode = dh.CompanyCode AND jei.Customer = dh.Customer AND jei.AccountingDocument = dh.AccountingDocument
UNION ALL
-- 8, 9, 10. Payment Received, Cash Applied/Reconciled, Invoice Closed
SELECT
bi.InvoiceNumber,
ActivityName,
EventTime,
clearing_je.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
EventTime AS EndTime
FROM BaseInvoices AS bi
JOIN I_JournalEntryItem AS jei ON bi.AccountingDocument = jei.AccountingDocument AND bi.Customer IS NOT NULL
JOIN I_JournalEntry AS clearing_je ON jei.ClearingJournalEntry = clearing_je.AccountingDocument
CROSS JOIN (
VALUES ('Customer Payment Received'), ('Cash Applied/Reconciled'), ('Invoice Closed')
) AS Activities(ActivityName)
WHERE jei.ClearingDate IS NOT NULL AND jei.ClearingJournalEntry IS NOT NULL AND jei.ClearingJournalEntry <> ''
UNION ALL
-- 11. Invoice Cancelled
SELECT
bi.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EventTime,
cancellation_doc.CreatedByUser AS UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(cancellation_doc.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X'
UNION ALL
-- 12. Credit Memo Created
SELECT
bi.InvoiceNumber,
'Credit Memo Created' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EventTime,
bi.UserName,
bi.InvoiceDate,
bi.PaymentDueDate,
bi.InvoiceAmount,
bi.CustomerName,
bi.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(bi.CreationDateTime) AS EndTime
FROM BaseInvoices AS bi
WHERE bi.BillingDocumentType IN ('G2') -- Placeholder: Adjust with your credit memo document types
UNION ALL
-- 13. Billing Rework Identified
WITH CancelledInvoices AS (
SELECT
bi.PrecedingSDDocument,
bi.CompanyCode,
cancellation_doc.CreationDateTime AS CancellationTime
FROM BaseInvoices bi
JOIN I_BillingDocument AS cancellation_doc ON bi.CancelledBillingDocument = cancellation_doc.BillingDocument
WHERE bi.IsCancelled = 'X' AND bi.PrecedingSDDocument IS NOT NULL AND bi.PrecedingSDDocument <> ''
)
SELECT
rework.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EventTime,
rework.UserName,
rework.InvoiceDate,
rework.PaymentDueDate,
rework.InvoiceAmount,
rework.CustomerName,
rework.Region,
ABAP_SYSTEM_UTCL_TO_TIMESTAMP(rework.CreationDateTime) AS EndTime
FROM BaseInvoices AS rework
JOIN CancelledInvoices AS cancelled ON rework.PrecedingSDDocument = cancelled.PrecedingSDDocument
AND rework.CompanyCode = cancelled.CompanyCode
WHERE rework.CreationDateTime > cancelled.CancellationTime AND rework.IsCancelled = ''
ORDER BY InvoiceNumber, EventTime; Kroky
- Ověřte, že máte přímý přístup pro čtení ke schématu SAP HANA, které obsahuje fakturační a související finanční tabulky. Od správce systému si vyžádejte název schématu, údaje pro připojení, povolené časové období, rozsah kódů společností, typy fakturačních dokladů a případné filtry podle zákazníka nebo regionu. V dotazu nahraďte pouze zástupné hodnoty pro připojení a filtry.
- Ověřte zdroje dat SAP S/4HANA a mapování jejich polí v cílovém systému. Dotaz používá VBRK a VBRP pro fakturační data a vyžaduje nakonfigurované zdroje pro účetnictví, správu výstupů, správu sporů, upomínky, příchozí platby, párování a vazby mezi doklady. Zástupné hodnoty zdrojů a polí v hranatých závorkách nahraďte až po ověření v datovém slovníku systému.
- Nastavte období extrakce pomocí včetně počátečního a výlučného koncového časového razítka. Pro první spuštění doporučujeme období tří až šesti měsíců. Omezte extrakci podle kódu společnosti a případně typu fakturace, abyste řídili objem dat a nespojovali nesouvisející fakturační procesy.
- Spusťte dotaz pomocí uživatele databáze HANA s oprávněním pouze pro čtení. Dotaz vytvoří jeden řádek události pro každou výslovně extrahovanou aktivitu. Nespoléhá na to, že ProcessMind události odvodí. Vypočítané aktivity, například Dosažení data splatnosti platby a Zjištění přepracování fakturace, vytváří logika SQL a vrací je jako řádky.
- Ověřte strukturu výsledku. Záznam událostí musí obsahovat sloupce InvoiceNumber, ActivityName, EventTime, UserName, InvoiceDate, PaymentDueDate, InvoiceAmount, CustomerName, Region a EndTime. Zkontrolujte, že každý řádek obsahuje hodnoty InvoiceNumber, ActivityName a EventTime.
- Ověřte význam událostí a jejich vazby. Porovnejte řádky Invoice Generated s údaji o vytvoření hlavičky faktury, řádky Invoice Posted To Accounting se stavem zaúčtování, řádky Invoice Sent To Customer se záznamy o výstupu, řádky plateb s účetními doklady a řádky párování s vyrovnanými položkami faktur. Před použitím v produkci zkontrolujte všechny části závislé na zástupných hodnotách.
- Upravte výsledek pro ProcessMind. Zachovejte jeden řádek na událost, používejte jednotný datový typ časových značek a časové pásmo, ponechte InvoiceNumber jako text, aby se zachovaly úvodní nuly, a zajistěte, aby hodnoty ActivityName přesně odpovídaly požadovaným názvům aktivit. Seřaďte data podle InvoiceNumber a EventTime. Pokud mají události stejné časové razítko, použijte další jednoznačné řazení.
- Exportujte výsledek jako CSV v kódování UTF-8 nebo v jiném tabulkovém formátu podporovaném ProcessMind. Namapujte InvoiceNumber jako identifikátor případu, ActivityName jako sloupec aktivity a EventTime jako časové razítko události. Pokud jsou k dispozici, přidejte doporučené atributy. Poté soubor nahrajte pomocí nakonfigurovaného procesu importu ProcessMind a nakonec zkontrolujte počet řádků a aktivit.
Konfigurace
- Časové období: Začněte s obdobím tří až šesti měsíců. Použijte včetně počátečního a výlučné koncové časové razítko, abyste při postupných spuštěních předešli duplicitním událostem.
- Identifikátor případu: Použijte InvoiceNumber z hlavičky fakturačního dokladu. Zachovejte jej jako řetězec, protože čísla dokladů SAP mohou obsahovat úvodní nuly.
- Požadované aktivity: Extrakce musí vracet samostatné řádky pro tyto aktivity: Vytvoření faktury, Blokace zaúčtování faktury, Zaúčtování faktury do účetnictví, Odeslání faktury zákazníkovi, Dosažení data splatnosti platby, Otevření zákaznického sporu, Odeslání upomínky, Přijetí platby od zákazníka, Přiřazení a párování platby, Uzavření faktury, Storno faktury, Vytvoření dobropisu a Zjištění přepracování fakturace.
- Filtry: Filtry podle Company Code, typu fakturačního dokladu, prodejní organizace, zákazníka, regionu a data použijte až po ověření odpovídajících polí a rozsahu v cílovém systému. Nepředpokládejte, že se všechny typy fakturačních dokladů řídí stejným účetním nebo výstupním procesem.
- Konfigurace zdrojů: Hlavními zdroji fakturačních dat jsou VBRK a VBRP. Zdroje účetních dat, výstupů, sporů, upomínek, plateb, párování a toku dokladů je nutné nakonfigurovat podle nasazené verze SAP S/4HANA a používaných modulů. Zástupné odkazy na zdroje v hranatých závorkách nahraďte ověřenými objekty a poli.
- Vypočítané události: Dosažení data splatnosti platby se odvozuje z platebních podmínek a údajů o splatnosti. Zjištění přepracování fakturace se odvozuje ze vzorců storen a následného vytváření faktur. Jde o řádky událostí vytvořené pomocí SQL, nikoli o nativní transakční záznamy.
- Výkon: Filtry podle data, kódu společnosti, typu fakturace a čísla dokladu zahrňte do dotazu pro každý zdroj. Vybírejte pouze potřebné sloupce, vyhněte se neomezenému spojování s rozsáhlými účetními tabulkami, zpracovávejte data po měsících nebo týdnech a pomocí plánů provádění databáze vyhledejte náročná spojení.
- Přírůstková extrakce: Používejte stabilní kontrolní bod založený na časových značkách vytvoření nebo zaúčtování ve zdrojovém systému. Znovu zpracujte krátké překrývající se období, abyste zachytili opožděné záznamy o výstupech, platbách, sporech a párování. Poté odstraňte duplicity podle InvoiceNumber, ActivityName a EventTime a příslušného klíče zdrojového dokladu.
- Oprávnění: Uživatel provádějící extrakci potřebuje oprávnění ke čtení vybraných objektů a polí ve schématu HANA. Ověřte, že přímý přístup k databázi povolují bezpečnostní pravidla organizace a že jsou splněny požadavky na nakládání s osobními a zákaznickými údaji.
- Funkční předpoklady: Data ze správy výstupů, účetní integrace, správy sporů, upomínek, příchozích plateb a párování jsou k dispozici pouze tehdy, pokud jsou tyto funkce v systému nakonfigurované a používané. Pokud modul nebo zdrojový záznam chybí, chybí i příslušná aktivita, systém ji neodvodí.
- Časové pásmo: Sjednoťte časová razítka podle časového pásma požadovaného v ProcessMind. Zdokumentujte, zda jsou zdrojová časová razítka uložena v UTC, místním čase systému nebo jiném nakonfigurovaném časovém pásmu.
Ukázkový dotaz sql
WITH
billing_headers AS (
SELECT
h.VBELN AS InvoiceNumber,
h.FKDAT AS InvoiceDate,
h.NETWR AS InvoiceAmount,
h.KUNAG AS CustomerNumber,
h.ERDAT AS BillingCreatedDate,
h.ERZET AS BillingCreatedTime,
h.ERNAM AS BillingCreatedBy,
h.BUKRS AS CompanyCode,
h.FKART AS BillingType,
h.FKSTO AS CancellationIndicator,
h.RFBSK AS AccountingPostingStatus,
h.ZTERM AS PaymentTerms,
h.ZFBDT AS BaselineDate,
h.NETDT AS PaymentDueDate,
h.VBELV AS PrecedingDocument
FROM [Your HANA schema].VBRK h
WHERE h.ERDAT >= '[Start date, YYYY-MM-DD]'
AND h.ERDAT < '[End date, YYYY-MM-DD]'
AND h.BUKRS IN ([Company code filter])
AND h.FKART IN ([Billing document type filter])
),
customer_data AS (
SELECT
c.KUNNR AS CustomerNumber,
c.NAME1 AS CustomerName,
c.REGION AS Region
FROM [Your customer master source] c
),
invoice_base AS (
SELECT
b.InvoiceNumber,
b.InvoiceDate,
b.InvoiceAmount,
b.CustomerNumber,
c.CustomerName,
c.Region,
b.BillingCreatedDate,
b.BillingCreatedTime,
b.BillingCreatedBy,
b.CompanyCode,
b.BillingType,
b.CancellationIndicator,
b.AccountingPostingStatus,
b.PaymentTerms,
b.BaselineDate,
b.PaymentDueDate,
b.PrecedingDocument
FROM billing_headers b
LEFT JOIN customer_data c
ON c.CustomerNumber = b.CustomerNumber
),
events AS (
SELECT
i.InvoiceNumber,
'Invoice Generated' AS ActivityName,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EventTime,
i.BillingCreatedBy AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime)) AS EndTime
FROM invoice_base i
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posting Blocked' AS ActivityName,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(a.StatusTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posting blocked status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted To Accounting' AS ActivityName,
a.StatusTimestamp AS EventTime,
a.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
a.StatusTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounting status source] a
ON a.InvoiceNumber = i.InvoiceNumber
AND a.PostingStatus = '[Posted status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
o.SentTimestamp AS EventTime,
o.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
o.SentTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your output management source] o
ON o.InvoiceNumber = i.InvoiceNumber
AND o.OutputStatus = '[Successfully sent status value]'
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Due Date Reached' AS ActivityName,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
CAST(i.PaymentDueDate AS TIMESTAMP) AS EndTime
FROM invoice_base i
WHERE i.PaymentDueDate IS NOT NULL
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Dispute Opened' AS ActivityName,
d.OpenedTimestamp AS EventTime,
d.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
d.OpenedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dispute management source] d
ON d.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
r.IssuedTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.IssuedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your dunning or payment reminder source] r
ON r.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Customer Payment Received' AS ActivityName,
p.ReceivedTimestamp AS EventTime,
p.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
p.ReceivedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your incoming payment source] p
ON p.CustomerNumber = i.CustomerNumber
AND p.CompanyCode = i.CompanyCode
AND p.ReceivedTimestamp >= TO_TIMESTAMP(TO_VARCHAR(i.InvoiceDate))
UNION ALL
SELECT
i.InvoiceNumber,
'Cash Applied/Reconciled' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Closed' AS ActivityName,
cl.ClearedTimestamp AS EventTime,
cl.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
cl.ClearedTimestamp AS EndTime
FROM invoice_base i
INNER JOIN [Your accounts receivable clearing source] cl
ON cl.InvoiceNumber = i.InvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Cancelled' AS ActivityName,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EventTime,
x.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
COALESCE(x.CancellationTimestamp, TO_TIMESTAMP(TO_VARCHAR(i.BillingCreatedDate) || ' ' || TO_VARCHAR(i.BillingCreatedTime))) AS EndTime
FROM invoice_base i
LEFT JOIN [Your billing cancellation or document flow source] x
ON x.InvoiceNumber = i.InvoiceNumber
WHERE i.CancellationIndicator = '[Cancellation indicator value]'
OR x.InvoiceNumber IS NOT NULL
UNION ALL
SELECT
cm.ReferenceInvoiceNumber AS InvoiceNumber,
'Credit Memo Created' AS ActivityName,
cm.CreatedTimestamp AS EventTime,
cm.UserName,
i.InvoiceDate,
i.PaymentDueDate,
cm.Amount AS InvoiceAmount,
i.CustomerName,
i.Region,
cm.CreatedTimestamp AS EndTime
FROM [Your credit memo source] cm
INNER JOIN invoice_base i
ON i.InvoiceNumber = cm.ReferenceInvoiceNumber
UNION ALL
SELECT
i.InvoiceNumber,
'Billing Rework Identified' AS ActivityName,
r.ReworkTimestamp AS EventTime,
r.UserName,
i.InvoiceDate,
i.PaymentDueDate,
i.InvoiceAmount,
i.CustomerName,
i.Region,
r.ReworkTimestamp AS EndTime
FROM invoice_base i
INNER JOIN (
SELECT
old_invoice.InvoiceNumber,
new_invoice.InvoiceNumber AS ReplacementInvoiceNumber,
new_invoice.BillingCreatedDate AS ReworkTimestamp,
new_invoice.BillingCreatedBy AS UserName
FROM invoice_base old_invoice
INNER JOIN invoice_base new_invoice
ON new_invoice.PrecedingDocument = old_invoice.InvoiceNumber
AND new_invoice.BillingCreatedDate > old_invoice.BillingCreatedDate
WHERE old_invoice.CancellationIndicator = '[Cancellation indicator value]'
) r
ON r.InvoiceNumber = i.InvoiceNumber
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
InvoiceDate,
PaymentDueDate,
InvoiceAmount,
CustomerName,
Region,
EndTime
FROM events
WHERE EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Chcete začít?
Použijte tuto šablonu a urychlete přípravu dat. Pak můžete začít zlepšovat proces Order to Cash – fakturace a vystavování faktur. Proměňte data ze SAP S/4H4ANA v užitečné poznatky.
Zkraťte cyklus fakturace Order to Cash a zrychlete peněžní tok o 30 %
Odstraňte neefektivní činnosti a zkraťte fakturační cyklus o 30 %.
Platební kartu nepotřebujete. Začít můžete během několika minut.