Vaše datová šablona pro správu úvěrů a vymáhání pohledávek
Vaše datová šablona pro správu úvěrů a vymáhání pohledávek
- Doporučené atributy pro podrobnou analýzu
- Aktivity důležité pro zjištění průběhu procesu
- Podrobný návod k extrakci dat
Atributy správy úvěrů a vymáhání pohledávek
| Název | Popis | ||
|---|---|---|---|
| Čas události EventTime | Přesné datum a čas, kdy k činnosti došlo, tedy časové razítko události. | ||
| Popis Čas události neboli časové razítko zaznamenává přesný okamžik, kdy k činnosti došlo. Je nezbytný pro chronologické seřazení událostí a sestavení přesného průběhu procesu. Bez přesných časových razítek nelze správně určit pořadí událostí. Při analýze se tento atribut používá k výpočtu doby trvání a cyklů mezi činnostmi, což je důležité pro měření výkonnosti. Slouží například k výpočtu KPI, jako je doba řešení sporu nebo doba úhrady faktury. Umožňuje také analyzovat vývoj výkonnosti procesu v různých obdobích. Proč je to důležité Toto časové razítko je nezbytné pro řazení událostí, výpočet doby trvání a cyklů i analýzu výkonnosti procesu v čase. Kde data získat Odvozuje se z různých datových polí v tabulkách Oracle Fusion Financials, například z TRX_DATE v RA_CUSTOMER_TRX_ALL pro vytvoření faktury nebo z data vytvoření inkasního úkonu. Příklady 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Číslo faktury InvoiceNumber | Jedinečný identifikátor každé zákaznické faktury, který slouží jako hlavní identifikátor případu v procesu správy úvěrů. | ||
| Popis Číslo faktury je hlavní identifikátor, který propojuje všechny události a činnosti související s jednou pohledávkou, od jejího vytvoření až po konečné uhrazení nebo odpis. Umožňuje zobrazit celý životní cyklus faktury od začátku do konce. Při analýze process mining se tento atribut používá k rekonstrukci průběhu každé faktury. Seskupením všech souvisejících činností pod jedno číslo faktury mohou analytici zobrazit průběh procesu, určit obvyklé i odchylné cesty a měřit dobu trvání celého procesu nebo jeho konkrétních fází, například řešení sporů či zaúčtování plateb. Proč je to důležité Jde o nezbytné ID případu, které propojuje všechny související kroky procesu a umožňuje rekonstruovat a analyzovat průběh každé faktury od vystavení po uzavření. Kde data získat Tento identifikátor se v Oracle Fusion Financials obvykle nachází v tabulce RA_CUSTOMER_TRX_ALL ve sloupci TRX_NUMBER. Příklady INV-1005679884321AR-2023-04-112 | |||
| Název činnosti ActivityName | Název konkrétní obchodní události nebo úkolu, ke kterému v určitém okamžiku došlo v procesu správy úvěrů. | ||
| Popis Tento atribut popisuje jeden krok životního cyklu faktury, například „Vystavení faktury“, „Zahájení upomínacího řízení“ nebo „Přijetí platby“. Každá činnost představuje samostatnou událost, která posouvá případ dál. Analýza pořadí a četnosti činností je základem process mining. Pomáhá odhalit skutečný průběh procesu, určit úzká místa, kde se případy zdržují, odhalit opakované činnosti a porovnat skutečný proces s navrženým nebo ideálním postupem. Název činnosti je nezbytný pro tvorbu map procesů a výpočet doby mezi jednotlivými kroky. Proč je to důležité Tento atribut určuje kroky v mapě procesu a umožňuje zobrazit a analyzovat životní cyklus faktury od začátku do konce. Kde data získat Jde o koncepční pole odvozené z různých obchodních událostí v Oracle Fusion Financials. Obvykle vzniká mapováním stavů transakcí, dat událostí nebo konkrétních akcí z modulů, jako jsou Receivables (AR) a Advanced Collections. Příklady Vystavení fakturyZahájení upomínacího řízeníPřijetí platbyZaevidování sporu | |||
| Poslední aktualizace dat LastDataUpdate | Časové razítko označující, kdy byla data této události naposledy obnovena nebo získána ze zdrojového systému. | ||
| Popis Tento atribut označuje datum a čas posledního získání dat. Jde o metadata, která nejsou součástí samotného obchodního procesu, ale pomáhají určit aktuálnost analyzovaných dat. Analytici podle tohoto časového razítka ověří, že pracují s aktuálními informacemi, a zjistí, k jakému okamžiku data sahají. Je důležité pro správu dat i pro nastavení očekávání uživatelů ohledně aktuálnosti údajů v dashboardech a reportech. Proč je to důležité Ukazuje aktuálnost dat, aby analytici i další zainteresovaní věděli, nakolik jsou data včasná a relevantní. Kde data získat Tato hodnota se generuje a zapisuje do každého záznamu při získávání a načítání dat (ETL). Příklady 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Zdrojový systém SourceSystem | Systém, ze kterého data pocházejí. | ||
| Popis Tento atribut označuje zdrojovou aplikaci, ve které byla data události zaznamenána. V prostředí s více IT systémy se na jednom procesu od začátku do konce může podílet několik systémů. Uvedení zdrojového systému je důležité pro správu dat, řešení problémů a pochopení jejich kontextu. Pokud se události z různých systémů spojí do jednoho pohledu na proces, pomáhá určit jejich původ a zachovat přehled o původu dat. Proč je to důležité Upřesňuje původ dat, což je důležité pro jejich ověření a správu i pro pochopení technologického kontextu procesu. Kde data získat Obvykle jde o statickou hodnotu přidanou při získávání dat, která označuje původ záznamů. Příklady Oracle Fusion FinancialsOracle AROracle Collections | |||
| Částka faktury InvoiceAmount | Celková peněžní hodnota faktury. | ||
| Popis Částka faktury představuje celkovou hodnotu zboží nebo služeb vyúčtovaných zákazníkovi. Jde o důležitý finanční údaj pro pochopení peněžního dopadu procesu. Při analýze se částka faktury používá k určení priorit inkasa, aby se pozornost zaměřila na faktury po splatnosti s vysokou hodnotou. Pomáhá také analyzovat platební chování podle hodnoty transakce a vypočítat finanční dopad odpisů. Dashboardy, jako je analýza míry odpisů faktur, tento údaj využívají k posouzení rozsahu finančních ztrát. Proč je to důležité Doplňuje finanční kontext procesu a umožňuje upřednostnit faktury s vysokou hodnotou i analyzovat peněžní dopad neefektivity procesu. Kde data získat Údaj lze získat z tabulky AR_PAYMENT_SCHEDULES_ALL, která obsahuje částku splatnou za fakturu. Příklady 5000.001250.75250000.00 | |||
| Číslo zákazníka CustomerNumber | Jedinečný identifikátor zákazníka spojeného s fakturou. | ||
| Popis Číslo zákazníka propojuje fakturu s konkrétním zákaznickým účtem. Díky tomu lze proces správy úvěrů a inkasa rozdělit do skupin a analyzovat podle vlastností zákazníků. Analytici mohou podle čísla zákazníka zjistit, zda někteří zákazníci pravidelně platí pozdě, častěji zpochybňují faktury nebo vyžadují více inkasních úkonů. Tyto informace jsou důležité pro tvorbu inkasních strategií pro jednotlivé zákazníky, úpravu platebních podmínek a identifikaci rizikových skupin. Podporují také analýzy, jako je analýza míry odpisů faktur podle skupiny zákazníků. Proč je to důležité Umožňuje rozdělit proces podle zákazníků a odhalit vzorce, rizika i příležitosti pro přizpůsobení inkasních strategií. Kde data získat Obvykle se nachází v tabulce RA_CUSTOMER_TRX_ALL ve sloupci BILL_TO_CUSTOMER_ID, který odkazuje na HZ_CUST_ACCOUNTS. Příklady CUST-0012389455ACME-CORP-US | |||
| Datum splatnosti DueDate | Datum, do kterého má být faktura zaplacena. | ||
| Popis Datum splatnosti je důležitý smluvně sjednaný termín úhrady. Slouží jako základ pro měření včasnosti plateb. Tento atribut je zásadní pro identifikaci faktur po splatnosti a výpočet počtu dní po splatnosti. Je hlavním vstupem pro určení, kdy zahájit upomínací postup, a používá se při výpočtu KPI, jako jsou dny inkasa pohledávek (DSO). Je také nezbytný pro tvorbu přehledů o stáří pohledávek. Proč je to důležité Slouží jako základ pro určení, zda je faktura po splatnosti, zahájení vymáhání pohledávky a analýzu stáří pohledávek. Kde data získat V tabulce AR_PAYMENT_SCHEDULES_ALL je dostupné ve sloupci DUE_DATE. Příklady 2023-05-302023-06-152023-07-01 | |||
| Pracovník inkasa Collector | Jméno nebo ID pracovníka inkasa přiřazeného k faktuře. | ||
| Popis Pracovník inkasa je osoba nebo tým odpovědný za správu inkasních činností u faktury po splatnosti. Toto přiřazení je důležitým krokem v workflow inkasa. Tento atribut je důležitý pro řízení výkonnosti a přidělování zdrojů v oddělení inkasa. Analýza výsledků jednotlivých pracovníků pomáhá vedoucím posoudit jejich efektivitu, určit potřebu školení a vyrovnat pracovní zátěž. Dashboard efektivity přiřazování pracovníků inkasa využívá tento atribut k porovnání úspěšnosti a doby trvání cyklu u jednotlivých pracovníků. Proč je to důležité Umožňuje analyzovat výkonnost jednotlivých pracovníků nebo týmů, lépe rozdělovat zdroje a zvyšovat celkovou efektivitu inkasa. Kde data získat Tyto informace se obvykle ukládají v modulu Oracle Advanced Collections, často v tabulkách, jako je IEX_CASES_ALL_B, nebo v souvisejících tabulkách přiřazení. Příklady Jan NovákJana NovákováTým vymáhání pohledávek A | |||
| Skupina zákazníků CustomerSegment | Zařazení zákazníka do vymezené skupiny, například podle velikosti, odvětví nebo strategického významu. | ||
| Popis Skupina zákazníků je kategoriální atribut, který sdružuje zákazníky se společnými vlastnostmi. Skupiny lze vymezit například jako „strategičtí zákazníci“, „malé a střední firmy“ nebo „velké podniky“, případně podle odvětví, například „výroba“ nebo „maloobchod“. Tento atribut umožňuje porovnávat výsledky procesů mezi skupinami. Analytici mohou například zjistit, zda má některá skupina více sporů nebo delší cyklus úhrady. Tyto poznatky pomáhají přizpůsobit úvěrové zásady a inkasní strategie potřebám a rizikům jednotlivých skupin a podporují dashboardy, jako je analýza míry odpisů faktur. Proč je to důležité Umožňuje porovnávat výsledky a rizika procesu mezi různými skupinami zákazníků. Kde data získat Údaj se často spravuje v kmenových datech zákazníků (HZ_CUST_ACCOUNTS nebo souvisejících tabulkách) nebo se odvozuje z vlastností zákazníka, například z tržeb či odvětví. Příklady Velký podnikMalá a střední firmaVeřejná správaStrategický partner | |||
| Úroveň upomínání DunningLevel | Fáze nebo úroveň upomínacího postupu, která byla u faktury použita. | ||
| Popis Úroveň upomínání vyjadřuje intenzitu upomínky, která se obvykle postupně zvyšuje. Například úroveň 1 může znamenat zdvořilou e-mailovou upomínku, zatímco úroveň 3 může představovat formální dopis nebo telefonát. Analýza procesu podle úrovně upomínání pomáhá posoudit účinnost upomínací strategie. Dashboard účinnosti upomínání pomocí tohoto atributu zobrazuje, kolik případů z jednotlivých kroků upomínání končí platbou. Firma tak může zjistit, které kroky fungují nejlépe, a upravit načasování i obsah upomínek, aby zvýšila úspěšnost vymáhání pohledávek. Proč je to důležité Zaznamenává fázi vymáhání pohledávky, která je důležitá pro vyhodnocení účinnosti upomínací strategie. Kde data získat Tato data se spravují v modulu Oracle Advanced Collections. Najdete je v tabulkách s historií upomínek, například IEX_DUNNINGS. Příklady Úroveň 1: upomínkaÚroveň 2: upozorněníÚroveň 3: poslední výzva | |||
| Uživatel User | Uživatel nebo systémové ID osoby či systému, který provedl danou činnost. | ||
| Popis Tento atribut určuje konkrétního zaměstnance nebo automatizovaný systém odpovědný za provedení činnosti, například schválení úvěrového limitu, zaúčtování platby nebo vyřízení reklamace. Analýza činností podle uživatele je důležitá pro pochopení rozložení pracovní zátěže, výkonu jednotlivců a shody s pravidly. U automatizovaných činností pomáhá sledovat zapojení systémových procesů. Sledování chování uživatelů může také odhalit potřebu školení nebo možné podvodné jednání. Proč je to důležité Přiřazuje činnosti konkrétním osobám nebo automatizovaným systémům a umožňuje sledovat výkon, analyzovat pracovní zátěž a provádět audit. Kde data získat Zdrojovými údaji jsou sloupce CREATED_BY nebo LAST_UPDATED_BY v různých transakčních a historických tabulkách Oracle Fusion Financials. Příklady jsmithspecialista_pohledavek_1SYSTEM_AUTOMATION | |||
| Čas ukončení EndTime | Časové razítko označující dokončení činnosti, která má určitou dobu trvání. | ||
| Popis U činností s jasným začátkem a koncem tento atribut zaznamenává čas dokončení. Mnohé události v process mining proběhnou okamžitě, jiné, například „Šetření reklamace“, mohou trvat určitou dobu. Samostatný čas ukončení umožňuje přesně vypočítat dobu zpracování činnosti. Je to přesnější než odvozovat dobu trvání od začátku následující činnosti, zejména pokud mezi činnostmi nastávají prodlevy. Tento údaj je důležitý pro analýzu využití zdrojů a určení konkrétních kroků, které v procesu zabírají nejvíce času. Proč je to důležité Umožňuje přesně vypočítat dobu trvání jednotlivých činností a lépe porozumět úzkým místům i využití zdrojů. Kde data získat Často jde o koncepční atribut. Zdrojem může být časové razítko poslední aktualizace nebo konkrétní pole s datem uzavření v tabulkách odpovídajících dané činnosti. Příklady 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| Datum příslibu platby PromiseToPayDate | Datum, kdy zákazník slíbil provést platbu. | ||
| Popis Při vymáhání pohledávky se zákazník může zavázat, že zaplatí v budoucnu. Datum tohoto příslibu se zaznamenává, aby bylo možné závazek sledovat. Tento atribut je důležitý pro řízení workflow vymáhání a vyhodnocení spolehlivosti příslibů zákazníků. Porovnáním data příslibu platby se skutečným datem přijetí platby lze zjistit, jak často zákazníci své přísliby dodrží. Údaj pomáhá přesněji předpovídat peněžní toky a rozhodnout, kdy zintenzivnit vymáhání, pokud zákazník příslib nesplní. Proč je to důležité Sleduje závazky zákazníků k úhradě, pomáhá předpovídat příchozí platby a vyhodnocovat výsledky jednání o vymáhání pohledávek. Kde data získat Ukládá se v modulu Oracle Advanced Collections, pravděpodobně v tabulkách, jako je IEX_PROMISES_T. Příklady 2023-06-102023-06-252023-07-05 | |||
| Důvod reklamace DisputeReason | Důvod, který zákazník uvedl při reklamaci faktury. | ||
| Popis Když zákazník reklamuje fakturu, obvykle uvede důvod, například „Nesprávná cena“, „Poškozené zboží“ nebo „Duplicitní faktura“. Tento atribut zaznamenává uvedený důvod. Analýza důvodů reklamací pomáhá odhalit jejich skutečné příčiny. Umožňuje najít opakující se problémy v předcházejících procesech, například při správě objednávek nebo fakturaci, které vedou ke zpoždění plateb. Když firma sleduje četnost jednotlivých důvodů reklamací, může cíleně řešit jejich příčiny a zkrátit dobu vyřízení reklamace. Proč je to důležité Pomáhá odhalit příčiny reklamací faktur a zlepšit předcházející procesy tak, aby se podobné reklamace neopakovaly. Kde data získat Pokud je správa reklamací formalizovaná, tyto informace se obvykle zaznamenávají v modulech Oracle Advanced Collections nebo Oracle Channel Revenue Management. Mohou být uloženy například v tabulkách AR_DISPUTE_HISTORY. Příklady Nesprávné množstvíNesoulad v ceněPoškozené zbožíSlužba nebyla poskytnuta | |||
| Měna faktury InvoiceCurrency | Měna, ve které je částka faktury uvedena. | ||
| Popis Tento atribut určuje měnu faktury, například USD, EUR nebo GBP. V mezinárodních organizacích se faktury často vystavují v různých měnách. Analýza dat ve více měnách vyžaduje pečlivé zpracování. Tento atribut umožňuje filtrovat pohled na proces podle měny nebo použít správné směnné kurzy pro konsolidované finanční výkaznictví. Zajišťuje správnou interpretaci peněžních hodnot a srovnání částek na stejném základě. Proč je to důležité Je nezbytný pro správnou interpretaci finančních dat ve více měnách a přesnou finanční analýzu. Kde data získat Obvykle se nachází v tabulce RA_CUSTOMER_TRX_ALL ve sloupci INVOICE_CURRENCY_CODE. Příklady USDEURGBPJPY | |||
| Obchodní jednotka BusinessUnit | Konkrétní obchodní jednotka nebo organizační složka, která vystavila fakturu. | ||
| Popis Ve velkých organizacích se provoz často dělí mezi několik obchodních jednotek. Tento atribut určuje, ke které jednotce faktura patří. Analýza procesu podle obchodní jednotky umožňuje porovnat výsledky různých částí organizace. Může odhalit rozdíly v uplatňování úvěrové politiky a pravidel pro vymáhání pohledávek i ukázat, kterým jednotkám se správa pohledávek daří lépe. Organizace tak může sdílet osvědčené postupy a podle potřeby sjednotit procesy. Proč je to důležité Umožňuje porovnat výsledky jednotlivých organizačních jednotek a najít osvědčené postupy i oblasti ke zlepšení. Kde data získat V tabulce RA_CUSTOMER_TRX_ALL je dostupný ve sloupci ORG_ID, který odkazuje na organizační strukturu. Příklady Obchodní jednotka Severní AmerikaObchodní jednotka EMEADivize globálních služeb | |||
| Odepsaná IsWrittenOff | Logická hodnota určující, zda byla faktura odepsána jako nedobytná pohledávka. | ||
| Popis Tento odvozený příznak označuje faktury, které společnost považuje za nedobytné a vyřadila je z aktivních pohledávek. Obvykle jde o konečný a nežádoucí výsledek zpracování faktury. Tento atribut je nezbytný pro výpočet KPI míry odpisu faktur a související analýzu v dashboardu. Analytici mohou vybrat případy neúspěšného vymáhání a hledat jejich společné znaky, například segment zákazníka nebo hodnotu faktury, které mohou souviset s vyšším rizikem odpisu. Tyto poznatky pomáhají zlepšit úvěrovou politiku a strategie vymáhání. Proč je to důležité Jasně označuje případy neúspěšného vymáhání, což je nezbytné pro analýzu příčin nedobytných pohledávek a výpočet míry odpisů. Kde data získat Jde o vypočítané pole. Určí se ověřením, zda případ obsahuje činnost „Odpis faktury“ nebo zda je stav faktury „Odepsaná“. Příklady truefalse | |||
| Platební podmínky PaymentTerms | Dohodnuté podmínky, které určují, kdy má být platba uhrazena. | ||
| Popis Platební podmínky stanovují, kdy se očekává úhrada od zákazníka, například „Net 30“ nebo „Net 60“. Podle těchto podmínek se vypočítá datum splatnosti faktury. Analýza plateb podle platebních podmínek může odhalit zajímavé souvislosti. Zákazníci s kratší lhůtou mohou například častěji platit pozdě. Tyto informace lze využít při revizi a úpravě úvěrové politiky i při rozdělení zákazníků do skupin s odlišnými strategiemi vymáhání. Pomáhají také pochopit, proč jsou některé faktury po splatnosti. Proč je to důležité Poskytuje kontext o dohodnutém termínu úhrady a umožňuje porovnat platební chování při různých úvěrových podmínkách. Kde data získat Údaj je uložen v tabulce RA_TERMS a propojen s transakcí faktury. Příklady Net 30Net 60Splatné při přijetí | |||
| Po splatnosti IsOverdue | Logická hodnota určující, zda již uplynulo datum splatnosti faktury. | ||
| Popis Tento odvozený atribut jednoduše určuje, zda je faktura po splatnosti. Obvykle se vypočítá porovnáním aktuálního data nebo data platby s datem splatnosti faktury. Příznak se hodí k filtrování a segmentaci analýz. Analytici díky němu rychle vyberou faktury po splatnosti a prozkoumají jejich průběh, účinnost vymáhání i další vlastnosti. Usnadňuje také tvorbu dashboardů a KPI zaměřených na správu pohledávek po splatnosti, například dashboardu Stárnutí a stav faktur po splatnosti. Proč je to důležité Jasně označuje všechny faktury po splatnosti, které jsou hlavním předmětem procesu vymáhání pohledávek. Kde data získat Jde o vypočítané pole. Logika: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Příklady truefalse | |||
| Počet dní po splatnosti DaysOverdue | Počet dní, o které je faktura po splatnosti. | ||
| Popis Tato vypočítaná metrika vyjadřuje, jak dlouho je nezaplacená faktura po splatnosti. Vypočítá se jako rozdíl mezi aktuálním datem u otevřených faktur nebo datem platby u uzavřených faktur a datem splatnosti. Počet dní po splatnosti je důležitým ukazatelem pro analýzu stáří pohledávek a stanovení priorit při vymáhání. Jde o hlavní metriku dashboardu Stárnutí a stav faktur po splatnosti, kde se faktury řadí do časových pásem, například 1–30 dní nebo 31–60 dní po splatnosti. Tým vymáhání se tak může zaměřit na nejstarší a nejrizikovější pohledávky. Proč je to důležité Vyjadřuje délku prodlení s platbou a slouží jako hlavní metrika pro stanovení priorit při vymáhání i analýzu stáří pohledávek. Kde data získat Jde o vypočítané pole. Logika: CurrentDate - DueDate u otevřených faktur nebo PaymentDate - DueDate u uzavřených faktur. Příklady 1545920 | |||
| Stav faktury InvoiceStatus | Aktuální stav faktury v průběhu jejího zpracování. | ||
| Popis Stav faktury ukazuje, v jaké fázi se faktura právě nachází. Mezi běžné stavy patří „Otevřená“, „Zaplacená“, „Rozporovaná“, „Po splatnosti“ nebo „Odepsaná“. Tento atribut poskytuje přehled o stavu pohledávek. V process mining se tento atribut hodí k filtrování případů podle konkrétních skupin, například podle všech otevřených faktur po splatnosti. Je důležitou dimenzí dashboardu Stárnutí a stav faktur po splatnosti. Poskytuje okamžitý přehled o aktuálním stavu portfolia faktur a pomáhá určit priority při vymáhání pohledávek. Proč je to důležité Rychle ukazuje aktuální stav faktury a usnadňuje filtrování i určování priorit při vymáhání pohledávek. Kde data získat Obvykle je dostupný ve sloupci STATUS tabulky AR_PAYMENT_SCHEDULES_ALL. Příklady OtevřenáUzavřenáRozporovanáVe vymáhání | |||
| Výše úvěrového limitu CreditLimitAmount | Maximální výše úvěru schválená zákazníkovi. | ||
| Popis Výše úvěrového limitu představuje celkovou úvěrovou expozici, kterou je společnost ochotna přijmout vůči konkrétnímu zákazníkovi. Stanovuje se při posuzování úvěrového rizika. Tento atribut je nezbytný pro dashboard Dopad rozhodnutí o úvěrovém limitu. Porovnáním schváleného úvěrového limitu s následným platebním chováním a odpisy pohledávek může firma posoudit účinnost své politiky řízení úvěrového rizika. Analýza může ukázat, zda příliš vysoké limity přispívají k vyšším ztrátám z nedobytných pohledávek, a pomoci upravit proces schvalování úvěrů. Proč je to důležité Pomáhá posoudit účinnost politiky řízení úvěrového rizika porovnáním schváleného limitu s výsledky plateb a odpisy pohledávek. Kde data získat Spravuje se v Oracle Credit Management a obvykle se ukládá v tabulkách s úvěrovými profily zákazníků, například HZ_CUST_PROFILE_AMTS. Příklady 10000.0050000.00250000.00 | |||
Aktivity správy úvěrů a vymáhání pohledávek
| Aktivita | Popis | ||
|---|---|---|---|
| Odpis faktury | Označuje formální rozhodnutí ukončit inkasní činnost a zaúčtovat částku faktury jako nedobytnou pohledávku. Jde o explicitní finanční transakci, která upraví zůstatek faktury na nulu. | ||
| Proč je to důležité Jde o neúspěšný koncový bod procesu inkasa. Analýza odpisů podle skupiny zákazníků, regionu nebo úvěrového limitu pomáhá upravit úvěrové zásady a strategie inkasa tak, aby se omezily ztráty. Kde data získat Událost se výslovně zaznamenává při vytvoření úpravy v tabulce AR_ADJUSTMENTS_ALL s hodnotou RECEIVABLES_TRX_ID odkazující na nedobytnou pohledávku nebo odpis. Zachycení Datum vytvoření záznamu v AR_ADJUSTMENTS_ALL s typem činnosti odpovídajícím odpisu. Typ události explicit | |||
| Přijetí platby | Označuje přijetí peněz od zákazníka, které ještě nemusí být přiřazeny ke konkrétní faktuře. Událost se zaznamená při vytvoření transakce příjmu hotovosti v systému. | ||
| Proč je to důležité Jde o důležitý milník v procesu inkasa, který potvrzuje přijetí peněz. Doba mezi touto událostí a přiřazením platby měří efektivitu interního zpracování. Kde data získat Událost se výslovně zaznamenává podle RECEIPT_DATE v tabulce AR_CASH_RECEIPTS_ALL. Přijatou platbu lze následně propojit s fakturou, na kterou byla přiřazena, prostřednictvím AR_RECEIVABLE_APPLICATIONS_ALL. Zachycení RECEIPT_DATE z AR_CASH_RECEIPTS_ALL, propojené prostřednictvím tabulek pro přiřazení plateb. Typ události explicit | |||
| Přiřazení platby | Označuje přiřazení přijaté platby ke konkrétní faktuře, čímž se sníží její neuhrazený zůstatek. Tím se platba formálně propojí s fakturou. | ||
| Proč je to důležité Tato činnost potvrzuje, že faktura byla uhrazena. Je skutečným koncovým bodem výpočtu doby inkasa pohledávek (DSO) a cyklu zaúčtování platby. Kde data získat Jde o explicitně zaznamenanou událost podle APPLY_DATE v tabulce AR_RECEIVABLE_APPLICATIONS_ALL, která propojuje příjem hotovosti se zákaznickou transakcí (fakturou). Zachycení APPLY_DATE z AR_RECEIVABLE_APPLICATIONS_ALL pro příslušnou fakturu. Typ události explicit | |||
| Uplynutí data splatnosti | Vypočítaná událost, ke které dojde, když aktuální datum překročí datum splatnosti faktury a faktura ještě není plně uhrazena. Označuje změnu stavu faktury z „aktuální“ na „po splatnosti“. | ||
| Proč je to důležité Jde o důležitý milník, který spouští inkaso a upomínání. Analýza počtu a hodnoty faktur po splatnosti je nezbytná pro řízení pracovního kapitálu a posuzování úvěrového rizika. Kde data získat Událost se vypočítá porovnáním aktuálního data systému s hodnotou DUE_DATE v tabulce AR_PAYMENT_SCHEDULES_ALL u faktur se stavem STATUS „OP“ (Open). Zachycení Vypočítaná událost: nastane, když SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE. Typ události calculated | |||
| Vystavení faktury | Označuje vytvoření záznamu faktury v Oracle Fusion Financials. Jde o oficiální začátek životního cyklu faktury v modulu pohledávek a hlavní výchozí bod analýzy. | ||
| Proč je to důležité Jde o počáteční událost průběhu faktury. Všechny následné výpočty doby trvání, například DSO a doby úhrady faktury, vycházejí z tohoto časového údaje. Kde data získat Jde o explicitně zaznamenanou událost z pole CREATION_DATE nebo TRX_DATE v tabulce RA_CUSTOMER_TRX_ALL pro konkrétní TRX_NUMBER (číslo faktury). Zachycení Čas události odpovídá hodnotě CREATION_DATE z tabulky RA_CUSTOMER_TRX_ALL. Typ události explicit | |||
| Zahájení upomínacího řízení | Označuje formální zahájení upomínání faktury po splatnosti, často odesláním první oficiální upomínky. Událost se obvykle zaznamená při spuštění dávkového procesu upomínání, který zahrne danou fakturu. | ||
| Proč je to důležité Sledování této činnosti je důležité pro měření účinnosti upomínání a dodržování příslušných pravidel. Poskytuje výchozí bod pro měření doby od zahájení upomínání do přijetí platby. Kde data získat Událost se zaznamenává v modulu Oracle Advanced Collections. Označuje ji datum vytvoření záznamu upomínky v tabulkách, jako je IEX_DUNNINGS, propojeného s ID transakce. Zachycení Datum vytvoření záznamu v tabulce IEX_DUNNINGS přiřazeného k faktuře. Typ události explicit | |||
| Dokončení kontroly úvěruschopnosti | Označuje dokončení posouzení úvěruschopnosti zákazníka spojeného s fakturou. Tato událost se obvykle odvozuje propojením data vytvoření faktury s posledním datem dokončení kontroly úvěruschopnosti daného zákaznického účtu. Poskytuje výchozí bod pro analýzu úvěrových procesů. | ||
| Proč je to důležité Analýza doby od kontroly úvěruschopnosti po zadání objednávky pomáhá odhalit prodlevy v počátečních fázích cyklu od objednávky po inkaso. Je základem pro měření KPI doby schvalování úvěrového limitu a pochopení vlivu úvěrových rozhodnutí. Kde data získat Událost se odvozuje dotazem na HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE u zákazníka uvedeného na faktuře (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). Čas události odpovídá hodnotě LAST_CREDIT_REVIEW_DATE, která předchází CREATION_DATE faktury. Zachycení Propojte fakturu s posledním datem kontroly úvěruschopnosti zákazníka před vytvořením faktury. Typ události inferred | |||
| Dokončení úkonu pracovníka inkasa | Označuje ruční úkon pracovníka inkasa, například telefonát, odeslání e-mailu nebo zaznamenání poznámky o kontaktu. Tyto úkony se v modulu inkasa zaznamenávají jako „activities“ nebo „interactions“. | ||
| Proč je to důležité Sledování úkonů pracovníků inkasa pomáhá měřit efektivitu ručního workflow inkasa. Umožňuje analyzovat četnost činností a jejich souvislost s úspěšností plateb. Kde data získat Údaje se získávají z tabulek historie kontaktů nebo činností v Oracle Advanced Collections, například z JTF_IH_ACTIVITIES, propojených se zákazníkem a případně s konkrétní fakturou. Zachycení Čas vytvoření záznamů v JTF_IH_ACTIVITIES s příslušným výsledkem nebo kódem důvodu. Typ události explicit | |||
| Odeslání faktury zákazníkovi | Označuje formální doručení faktury zákazníkovi, elektronicky nebo v tištěné podobě. Událost může být zaznamenána modulem pro doručování nebo odvozena z data tisku faktury. | ||
| Proč je to důležité Tato činnost označuje začátek lhůty, ve které má zákazník zaplatit. Její sledování pomáhá přesně vypočítat počet dní po splatnosti a analyzovat prodlevy mezi vystavením faktury a informováním zákazníka. Kde data získat Údaj lze získat z LAST_PRINTED_DATE v RA_CUSTOMER_TRX_ALL. Případně ho lze odvodit z integračních záznamů e-mailového doručování nebo jiných komunikačních platforem. Zachycení Použijte LAST_PRINTED_DATE z RA_CUSTOMER_TRX_ALL nebo stav ze záznamu o doručení. Typ události inferred | |||
| Přiřazení inkasní strategie | Nastane, když je faktuře nebo zákazníkovi po splatnosti přiřazena automatizovaná inkasní strategie. Ta určuje posloupnost kroků a činností, kterými se bude systém nebo pracovník inkasa řídit. | ||
| Proč je to důležité Tato událost poskytuje přehled o automatizaci procesu inkasa. Analýza přiřazených strategií a jejich výsledků pomáhá optimalizovat přístupy k inkasu pro různé skupiny zákazníků. Kde data získat Událost se zaznamenává v modulu Oracle Advanced Collections. Obvykle ji lze zjistit podle data vytvoření přiřazení strategie v tabulkách, jako je IEX_STRATEGIES, nebo v souvisejících objektech. Zachycení Datum vytvoření pracovní položky strategie v tabulkách inkasa propojených se zákazníkem nebo transakcí. Typ události explicit | |||
| Uzavření faktury | Nastane, když se neuhrazený zůstatek faktury sníží na nulu, ať už úhradou, přiřazením dobropisu nebo úpravou. Označuje úspěšné dokončení životního cyklu faktury. | ||
| Proč je to důležité Tato událost představuje jeden z hlavních úspěšných koncových bodů procesu. Sledování uzavírání faktur je základem pro pochopení celkového stavu portfolia pohledávek. Kde data získat Událost se odvozuje ze změny stavu v tabulce AR_PAYMENT_SCHEDULES_ALL, kdy se STATUS změní na „CL“ (Closed). Čas události odpovídá hodnotě LAST_UPDATE_DATE této změny. Zachycení Zjistěte, kdy se hodnota AR_PAYMENT_SCHEDULES_ALL.STATUS u faktury změní na „CL“. Typ události inferred | |||
| Vyřešení sporu | Označuje, že zaevidovaný spor byl prošetřen a bylo nalezeno řešení. Událost se zaznamená při odebrání příznaku sporu z faktury. | ||
| Proč je to důležité Tato událost označuje konec cyklu řešení sporu. Doba mezi událostmi „Zaevidování sporu“ a „Vyřešení sporu“ je důležitým KPI pro měření efektivity provozu a jeho vlivu na peněžní tok. Kde data získat Událost se odvozuje ze změny hodnoty STATUS v AR_PAYMENT_SCHEDULES_ALL z „DS“ (Disputed) zpět na „OP“ (Open) nebo na „CL“ (Closed) po vystavení dobropisu či provedení úpravy. Zachycení Zjistěte, kdy se hodnota AR_PAYMENT_SCHEDULES_ALL.STATUS změní z „DS“ na jiný stav. Typ události inferred | |||
| Zaevidování sporu | Označuje, že zákazník formálně zpochybnil fakturu, částečně nebo v plném rozsahu. Událost se obvykle zaznamená změnou stavu splátkového kalendáře faktury. | ||
| Proč je to důležité Tato činnost zahajuje proces řešení sporu. Analýza doby od zaevidování sporu do jeho vyřešení je důležitá pro odhalení úzkých míst, která zdržují inkaso. Kde data získat Událost se odvozuje ze změny stavu v tabulce AR_PAYMENT_SCHEDULES_ALL, kdy se pole STATUS změní na „DS“ (Disputed). Čas lze získat z auditních tabulek nebo z data poslední aktualizace. Zachycení Zjistěte, kdy se hodnota AR_PAYMENT_SCHEDULES_ALL.STATUS u faktury změní na „DS“. Typ události inferred | |||
| Zaznamenání příslibu úhrady | Označuje formální dohodu zaznamenanou v systému, ve které se zákazník zavázal zaplatit v konkrétní den. Jde o jeden z důležitých výsledků inkasních činností. | ||
| Proč je to důležité Sledování příslibů úhrady a míry jejich plnění je důležitým ukazatelem výkonnosti pracovníků inkasa. Pomáhá předpovídat peněžní tok z pohledávek po splatnosti a vyhodnocovat efektivitu pracovníků. Kde data získat Příslib se výslovně vytvoří v Oracle Advanced Collections. Datum vytvoření se získává z tabulky IEX_PROMISE_DETAILS. Zachycení Datum vytvoření z tabulky IEX_PROMISE_DETAILS pro příslušnou fakturu. Typ události explicit | |||
Návody k extrakci dat
Kroky
- Otevřete Oracle BI Publisher: Přihlaste se do prostředí Oracle Fusion Financials. Klikněte na ikonu Navigator a přejděte do části Reports and Analytics výběrem Tools > Reports and Analytics.
- Vytvořte nový datový model: V podokně Reports and Analytics klikněte na tlačítko 'Browse Catalog'. V katalogu klikněte na rozbalovací nabídku 'New' a vyberte 'Data Model'.
- Definujte datovou sadu SQL Query: V editoru Data Model klikněte na ikonu '+' a přidejte datovou sadu. Vyberte 'SQL Query'.
- Nastavte zdroj dat: V novém okně datové sady zadejte výstižný název, například 'CreditCollectionsEventLog'. Jako zdroj dat vyberte 'FSCM' nebo příslušnou databázi aplikace Oracle Fusion. V poli Type of SQL nastavte 'Standard SQL'.
- Zadejte SQL dotaz: Zkopírujte celý SQL dotaz z části 'query' tohoto dokumentu a vložte jej do textového pole SQL Query.
- Definujte parametry dotazu: Dotaz používá parametry, například
:P_START_DATEa:P_END_DATE, které omezují časové období. BI Publisher je rozpozná automaticky. Můžete je nastavit jako výzvy pro uživatele a určit jejich datový typ jako 'Date'. - Uložte a otestujte datový model: Uložte datový model do sdílené nebo vlastní složky. Ověřte funkčnost dotazu na kartě 'Data'. Zadejte ukázkové hodnoty parametrů, například nedávné časové období, a kliknutím na 'View' zobrazte ukázková data. Zkontrolujte, že se správně zobrazují všechny sloupce.
- Vytvořte novou sestavu: Vraťte se do katalogu, klikněte na rozbalovací nabídku 'New' a vyberte 'Report'. V dialogovém okně 'Create Report' zvolte 'Use Data Model' a vyhledejte právě uložený datový model.
- Nastavte vlastnosti sestavy: Pro extrakci dat postačí jednoduchá tabulka. Nastavte výchozí výstupní formát. Pro process mining doporučujeme CSV. Klikněte na 'View a List', v seznamu 'Output Formats' najděte 'CSV' a zaškrtněte jeho políčko. Ostatní formáty můžete zrušit, aby se sestava uživatelům snadněji používala.
- Uložte sestavu: Uložte ji do stejné složky jako datový model.
- Naplánujte extrakci: Extrakci můžete automatizovat naplánováním sestavy. Otevřete ji, klikněte na 'Actions' a vyberte 'Schedule'. Nastavte četnost, například denně, výstupní formát CSV a cílové umístění, například adresář na content serveru nebo externí server přes FTP.
Konfigurace
- Předpoklady: Uživatel, který sestavu vytváří a spouští, musí mít odpovídající role BI, například 'BI Administrator' nebo 'BI Author', a oprávnění k zabezpečení dat pro přístup k příslušným tabulkám Financials (AR, IEX, HZ, JTF).
- Zdroj dat: Dotaz spusťte nad hlavní databází aplikace, která se obvykle jmenuje 'FSCM'.
- Parametry časového období: Pomocí parametrů
:P_START_DATEa:P_END_DATEomezte objem dat. Při prvním testování použijte krátké období, například jeden měsíc. V produkčním provozu se obvykle používá průběžné období 3 až 6 měsíců. - Filtrování: U velkých organizací zvažte přidání parametru
BU_NAME(název organizační jednotky) do klauzuleWHEREve společném tabulkovém výrazuinvoices_base. Data tak budete zpracovávat vždy jen pro jednu organizační jednotku. - Výkon: Dotaz spojuje několik rozsáhlých transakčních tabulek. Spuštění za dlouhé období bez filtrů může v BI Publisheru trvat dlouho nebo skončit vypršením časového limitu. Naplánujte sestavu na dobu mimo špičku.
- Výstupní formát: Ověřte, že výchozí nebo naplánovaný výstupní formát je CSV. Výsledkem bude přehledný soubor s oddělovači, který lze snadno načíst do nástrojů process mining. Zkontrolujte, zda jsou správně nastaveny oddělovač a kódování znaků.
Ukázkový dotaz sql
WITH invoices_base AS (
SELECT
trx.customer_trx_id,
trx.trx_number AS InvoiceNumber,
hca.account_number AS CustomerNumber,
hcp.class_category || ':' || hcp.class_code AS CustomerSegment, -- Example of segment, may need adjustment
ps.amount_due_original AS InvoiceAmount,
coll.name AS Collector,
ps.due_date AS DueDate,
trx.creation_date AS InvoiceCreationDate,
trx.created_by AS InvoiceCreatedBy,
ps.payment_schedule_id
FROM
ra_customer_trx_all trx
JOIN ar_payment_schedules_all ps ON trx.customer_trx_id = ps.customer_trx_id
JOIN hz_cust_accounts hca ON trx.bill_to_customer_id = hca.cust_account_id
JOIN hz_customer_profiles hcp ON hca.cust_account_id = hcp.cust_account_id AND hcp.site_use_id IS NULL
LEFT JOIN iex_delinquencies_all del ON ps.payment_schedule_id = del.payment_schedule_id
LEFT JOIN JTF_RS_RESOURCE_EXTNS_VL coll ON del.collector_id = coll.resource_id
WHERE
trx.creation_date BETWEEN TO_DATE(:P_START_DATE, 'YYYY-MM-DD') AND TO_DATE(:P_END_DATE, 'YYYY-MM-DD')
AND trx.complete_flag = 'Y'
AND ps.class = 'INV'
)
-- 1. Credit Review Completed
SELECT
ib.InvoiceNumber AS "InvoiceNumber",
'Credit Review Completed' AS "ActivityName",
cr.review_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber AS "CustomerNumber",
ib.CustomerSegment AS "CustomerSegment",
ib.InvoiceAmount AS "InvoiceAmount",
ib.Collector AS "Collector",
NULL AS "DunningLevel",
ib.DueDate AS "DueDate",
cr.created_by AS "User"
FROM
invoices_base ib
JOIN
hz_credit_reviews cr ON ib.CustomerNumber = (SELECT hca.account_number FROM hz_cust_accounts hca WHERE hca.cust_account_id = cr.cust_account_id)
WHERE cr.review_date = (SELECT MAX(cr_inner.review_date) FROM hz_credit_reviews cr_inner WHERE cr_inner.cust_account_id = cr.cust_account_id AND cr_inner.review_date < ib.InvoiceCreationDate)
UNION ALL
-- 2. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS "ActivityName",
trx.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.created_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
UNION ALL
-- 3. Invoice Sent To Customer
SELECT
ib.InvoiceNumber,
'Invoice Sent To Customer' AS "ActivityName",
trx.last_printed_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
trx.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ra_customer_trx_all trx ON ib.customer_trx_id = trx.customer_trx_id
WHERE trx.last_printed_date IS NOT NULL
UNION ALL
-- 4. Payment Due Date Passed
SELECT
ib.InvoiceNumber,
'Payment Due Date Passed' AS "ActivityName",
ps.due_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
'SYSTEM' AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.due_date < SYSDATE AND ps.status = 'OP'
UNION ALL
-- 5. Dunning Procedure Initiated
SELECT
ib.InvoiceNumber,
'Dunning Procedure Initiated' AS "ActivityName",
dunn.dunning_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
TO_CHAR(dunn.dunning_level) AS "DunningLevel",
ib.DueDate,
dunn.created_by AS "User"
FROM
invoices_base ib
JOIN iex_dunning_transactions dunt ON ib.customer_trx_id = dunt.transaction_id
JOIN iex_dunnings dunn ON dunt.dunning_id = dunn.dunning_id
UNION ALL
-- 6. Collection Strategy Assigned
SELECT
ib.InvoiceNumber,
'Collection Strategy Assigned' AS "ActivityName",
strat.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
strat.created_by AS "User"
FROM
invoices_base ib
JOIN iex_strategy_work_items swi ON ib.payment_schedule_id = swi.payment_schedule_id
JOIN iex_strategies_vl strat ON swi.strategy_id = strat.strategy_id
UNION ALL
-- 7. Collector Action Completed
SELECT
ib.InvoiceNumber,
task_type.name AS "ActivityName",
task.actual_end_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
res.source_name AS "User"
FROM
invoices_base ib
JOIN jtf_task_references_b ref ON ib.customer_trx_id = ref.object_id AND ref.object_type_code = 'OKC_K_HEADER'
JOIN jtf_tasks_b task ON ref.task_id = task.task_id
JOIN jtf_task_types_vl task_type ON task.task_type_id = task_type.task_type_id
JOIN jtf_rs_resource_extns_vl res ON task.owner_id = res.resource_id
WHERE task.actual_end_date IS NOT NULL
UNION ALL
-- 8. Promise To Pay Created
SELECT
ib.InvoiceNumber,
'Promise To Pay Created' AS "ActivityName",
prom.creation_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
prom.created_by AS "User"
FROM
invoices_base ib
JOIN iex_promise_details prom ON ib.payment_schedule_id = prom.payment_schedule_id
UNION ALL
-- 9. Dispute Registered
SELECT
ib.InvoiceNumber,
'Dispute Registered' AS "ActivityName",
ps.dispute_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.amount_in_dispute IS NOT NULL AND ps.dispute_date IS NOT NULL
UNION ALL
-- 10. Dispute Resolved
SELECT
ib.InvoiceNumber,
'Dispute Resolved' AS "ActivityName",
disp.resolution_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
disp.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_disputes_all disp ON ib.payment_schedule_id = disp.payment_schedule_id
WHERE disp.status = 'CLOSED' AND disp.resolution_date IS NOT NULL
UNION ALL
-- 11. Payment Received
SELECT
ib.InvoiceNumber,
'Payment Received' AS "ActivityName",
cr.receipt_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
cr.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
JOIN ar_cash_receipts_all cr ON app.cash_receipt_id = cr.cash_receipt_id
WHERE app.status = 'APP'
UNION ALL
-- 12. Payment Applied
SELECT
ib.InvoiceNumber,
'Payment Applied' AS "ActivityName",
app.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
app.created_by AS "User"
FROM
invoices_base ib
JOIN ar_receivable_applications_all app ON ib.payment_schedule_id = app.applied_payment_schedule_id
WHERE app.status = 'APP'
UNION ALL
-- 13. Invoice Closed
SELECT
ib.InvoiceNumber,
'Invoice Closed' AS "ActivityName",
ps.gl_date_closed AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
ps.last_updated_by AS "User"
FROM
invoices_base ib
JOIN ar_payment_schedules_all ps ON ib.payment_schedule_id = ps.payment_schedule_id
WHERE ps.status = 'CL' AND ps.gl_date_closed IS NOT NULL
UNION ALL
-- 14. Invoice Written Off
SELECT
ib.InvoiceNumber,
'Invoice Written Off' AS "ActivityName",
adj.apply_date AS "EventTime",
'Oracle Fusion Financials' AS "SourceSystem",
SYSDATE AS "LastDataUpdate",
ib.CustomerNumber,
ib.CustomerSegment,
ib.InvoiceAmount,
ib.Collector,
NULL AS "DunningLevel",
ib.DueDate,
adj.created_by AS "User"
FROM
invoices_base ib
JOIN ar_adjustments_all adj ON ib.customer_trx_id = adj.customer_trx_id
JOIN ar_receivables_trx_all rt ON adj.receivables_trx_id = rt.receivables_trx_id
WHERE rt.name = '[Your Write-Off Activity Name]' -- Example: 'Bad Debt Write-off' Chcete začít?
Pomocí této šablony připravte data k analýze a zjistěte, jak probíhá správa úvěrů a vymáhání pohledávek. Začněte zlepšovat proces ještě dnes.
Začněte zlepšovat správu úvěrů a vymáhání pohledávek ještě dnes
Zkraťte dobu průchodu procesem o 30 % a zlepšete finanční zdraví firmy v Oracle Fusion.
Platební kartu nepotřebujete. Začít můžete během několika minut.