Hitelkezelési és követelésbehajtási adatsablon
Hitelkezelési és követelésbehajtási adatsablon
- Az elemzéshez javasolt attribútumok
- A folyamat feltárásához követendő fő tevékenységek
- Útmutató az adatok kinyeréséhez lépésről lépésre
A hitelkezelés és a követelésbehajtás attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Esemény időpontja EventTime | A tevékenység pontos dátuma és időpontja, vagyis az esemény időbélyege. | ||
| Leírás Az esemény időpontja, vagyis az időbélyeg rögzíti, hogy pontosan mikor történt egy tevékenység. Az események időrendi sorrendbe állításához és a folyamat pontos rekonstruálásához elengedhetetlen. Pontos időbélyegek nélkül nem állapítható meg megbízhatóan az események sorrendje. Az elemzés során ezzel az attribútummal számítható ki a tevékenységek közötti időtartam és ciklusidő, ami elengedhetetlen a teljesítmény méréséhez. Segítségével például kiszámítható a vitarendezési ciklusidő vagy a számlafizetési ciklusidő KPI. Emellett lehetővé teszi a folyamat teljesítményének időbeli alakulását vizsgáló elemzéseket. Miért fontos? Ez az időbélyeg szükséges az események sorrendbe állításához, a ciklusidők és időtartamok kiszámításához, valamint a folyamat teljesítményének időbeli elemzéséhez. Hol szerezhető be? Az Oracle Fusion Financials tábláinak különböző dátummezőiből származik. Ilyen például a számla létrehozásakor használt TRX_DATE a RA_CUSTOMER_TRX_ALL táblában, vagy egy követeléskezelési művelet létrehozási dátuma. Példák 2023-04-15T10:00:00Z2023-05-01T14:30:00Z2023-05-20T09:15:22Z | |||
| Számlaszám InvoiceNumber | Az egyes ügyfélszámlák egyedi azonosítója, amely a hitelkezelési folyamat elsődleges ügyazonosítójaként szolgál. | ||
| Leírás A számlaszám az a központi azonosító, amely összekapcsolja az egyetlen követeléshez tartozó összes eseményt és tevékenységet a létrehozástól a végső kiegyenlítésig vagy leírásig. Segítségével a számla teljes életciklusa elejétől a végéig áttekinthető. A process mining elemzésben ez az attribútum szolgál az egyes számlák folyamatának rekonstruálására. Ha az összes kapcsolódó tevékenységet egy számlaszám alá rendezi, az elemzők megjeleníthetik a folyamatokat, azonosíthatják a jellemző és az eltérő útvonalakat, valamint mérhetik a teljes folyamat vagy egyes szakaszok, például a vitarendezés vagy a fizetés könyvelésének ciklusidejét. Miért fontos? Ez az alapvető ügyazonosító kapcsolja össze az összes kapcsolódó folyamatlépést, így rekonstruálható és elemezhető a számla útja a kiállítástól a lezárásig. Hol szerezhető be? Ez az azonosító az Oracle Fusion Financials rendszer RA_CUSTOMER_TRX_ALL táblájában, TRX_NUMBER néven található. Példák INV-1005679884321AR-2023-04-112 | |||
| Tevékenység neve ActivityName | A hitelkezelési folyamat egy adott időpontban bekövetkezett üzleti eseményének vagy feladatának neve. | ||
| Leírás Ez az attribútum a számla életciklusának egy-egy lépését írja le, például: „Számla létrehozva”, „Behajtási felszólítás elindítva” vagy „Fizetés beérkezett”. Minden tevékenység külön esemény, amely előreviszi az ügyet. A tevékenységek sorrendjének és gyakoriságának elemzése a process mining alapja. Segít feltárni a tényleges folyamatot, azonosítani az elakadások szűk keresztmetszeteit, felismerni az ismételt tevékenységekkel járó újramunkálási ciklusokat, és összevetni a tényleges folyamatot a tervezett vagy ideális folyamattal. A tevékenység neve alapvető a folyamattérképek létrehozásához és a lépések közötti átmeneti idők kiszámításához. Miért fontos? Ez az attribútum határozza meg a folyamattérkép lépéseit, így a számla életciklusa az elejétől a végéig megjeleníthető és elemezhető. Hol szerezhető be? Ez az Oracle Fusion Financials különböző üzleti eseményeiből származtatott fogalmi mező. Gyakran a tranzakcióállapotok, eseménydátumok vagy a modulokból, például a követeléskezelésből (AR) és az Advanced Collections modulból származó konkrét műveletek megfeleltetésével állítják elő. Példák Számla létrehozvaBehajtási felszólítás elindítvaFizetés beérkezettVita bejelentve | |||
| Forrásrendszer SourceSystem | Az a rendszer, amelyből az adatok származnak. | ||
| Leírás Ez az attribútum azonosítja azt a forrásalkalmazást, amelyben az esemény adatait rögzítették. Összetett IT-környezetben egyetlen teljes folyamatban több rendszer is részt vehet. A forrásrendszer megadása fontos az adatkezeléshez, a hibakereséshez és az adatok hátterének megértéséhez. Ha több rendszer eseményeit egyetlen folyamatnézetben egyesítik, ez az attribútum segít megkülönböztetni őket, és biztosítja az adatok eredetének nyomon követhetőségét. Miért fontos? Egyértelművé teszi az adatok eredetét, ami elengedhetetlen az adatok ellenőrzéséhez és kezeléséhez, valamint a folyamat technológiai hátterének megértéséhez. Hol szerezhető be? Ez általában az adatkinyerés során hozzáadott, állandó érték, amely azonosítja a rekordok forrását. Példák Oracle Fusion FinancialsOracle AROracle Collections | |||
| Utolsó adatfrissítés LastDataUpdate | Az az időbélyeg, amely megmutatja, mikor frissítették vagy nyerték ki utoljára az esemény adatait a forrásrendszerből. | ||
| Leírás Ez az attribútum jelöli a legutóbbi adatkinyerés dátumát és időpontját. Olyan metaadatmező, amely nem része magának az üzleti folyamatnak, de fontos annak megértéséhez, mennyire frissek az elemzett adatok. Az elemzők ezzel az időbélyeggel ellenőrizhetik, hogy naprakész adatokkal dolgoznak-e, és megállapíthatják, meddig terjednek az adatok. Az adatkezeléshez is elengedhetetlen, és segít tisztázni a felhasználók elvárásait a dashboardokon és jelentésekben szereplő adatok aktualitásával kapcsolatban. Miért fontos? Jelzi az adatok frissességét, így az elemzők és az érintettek tudják, mennyire aktuálisak és relevánsak az adatok. Hol szerezhető be? Ezt az értéket az ETL-folyamat során állítják elő, és minden rekordhoz hozzárendelik. Példák 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Felhasználó User | A tevékenységet végrehajtó felhasználó vagy rendszerazonosító. | ||
| Leírás Ez az attribútum azonosítja azt a munkatársat vagy automatizált rendszerfelhasználót, aki egy tevékenységért felelős, például jóváhagy egy hitelkeretet, könyvel egy befizetést vagy rendez egy vitát. A tevékenységek felhasználó szerinti elemzése segít megérteni a munkaterhelés eloszlását, az egyéni teljesítményt és a megfelelést. Automatizált tevékenységeknél nyomon követhető vele a rendszerfolyamatok közreműködése. A felhasználói viselkedés figyelésével a képzési igények és az esetleges csalárd tevékenységek is felismerhetők. Miért fontos? Az egyes tevékenységeket konkrét személyekhez vagy automatizált rendszerekhez rendeli, így elemezhető a teljesítmény és a munkaterhelés, valamint elvégezhető az ellenőrzés. Hol szerezhető be? Az Oracle Fusion Financials különböző tranzakciós és előzménytábláinak CREATED_BY vagy LAST_UPDATED_BY oszlopából származik. Példák jsmithar_specialist_1SYSTEM_AUTOMATION | |||
| Fizetési felszólítás szintje DunningLevel | A számlára alkalmazott fizetési felszólítási eljárás szakasza vagy szintje. | ||
| Leírás A fizetési felszólítás szintje mutatja, milyen határozott emlékeztetőt kap az ügyfél. A felszólítások jellemzően idővel egyre határozottabbá válnak. Az 1. szint például egy udvarias e-mailes emlékeztető lehet, a 3. szint pedig hivatalos levél vagy telefonhívás. A folyamat szintenkénti elemzésével felmérhető, mennyire hatékony a felszólítási stratégia. A felszólítások hatékonyságát bemutató dashboard ezt az attribútumot használja annak megjelenítésére, hogy az egyes felszólítási lépések után milyen arányban érkezik be a fizetés. Így megállapítható, mely intézkedések működnek a legjobban, és hogyan érdemes módosítani az emlékeztetők időzítését és tartalmát a hatékonyabb követeléskezelés érdekében. Miért fontos? Nyomon követi a követeléskezelés szigorításának szakaszát, ami elengedhetetlen a felszólítási stratégia hatékonyságának értékeléséhez. Hol szerezhető be? Az adatokat az Oracle Advanced Collections modul kezeli. A felszólítási előzményekhez kapcsolódó táblákban, például az IEX_DUNNINGS táblában találhatók. Példák 1. szint: emlékeztető2. szint: figyelmeztetés3. szint: végső felszólítás | |||
| Fizetési határidő DueDate | Az a dátum, ameddig a számlát ki kell fizetni. | ||
| Leírás A fizetési határidő a szerződésben rögzített dátum, amelyhez a fizetés időben történő teljesítését viszonyítjuk. Ez az attribútum alapvető a lejárt számlák azonosításához és a késedelem napjainak kiszámításához. Segítségével meghatározható, mikor kell elindítani a fizetési felszólítási eljárást, és olyan KPI-k is kiszámíthatók, mint a vevőkövetelések átlagos beszedési ideje (DSO). A kintlévőségeket koruk szerint csoportosító kimutatások elkészítéséhez is nélkülözhetetlen. Miért fontos? Viszonyítási alapot ad annak megállapításához, hogy lejárt-e a számla, mikor kell elindítani a követeléskezelést, és hogyan elemezhetők a kintlévőségek kor szerint. Hol szerezhető be? Az AR_PAYMENT_SCHEDULES_ALL táblában DUE_DATE néven található. Példák 2023-05-302023-06-152023-07-01 | |||
| Követeléskezelő Collector | A számlához rendelt követeléskezelő neve vagy azonosítója. | ||
| Leírás A követeléskezelő az a munkatárs vagy csapat, aki a lejárt számlák behajtásáért felel. A hozzárendelés a követeléskezelési munkafolyamat fontos lépése. Ez az attribútum elengedhetetlen a követeléskezelési terület teljesítményének méréséhez és az erőforrások elosztásához. A követeléskezelőnkénti eredmények elemzésével a vezetők felmérhetik az egyéni teljesítményt, azonosíthatják a képzési igényeket, és kiegyensúlyozhatják a munkaterhelést. A követeléskezelői feladatkiosztás eredményességét mérő dashboard közvetlenül erre az attribútumra támaszkodik, amikor összehasonlítja a különböző követeléskezelők sikerességi arányát és ciklusidejét. Miért fontos? Lehetővé teszi az egyes követeléskezelők és csapatok teljesítményének elemzését, segít optimalizálni az erőforrások elosztását és javítani a követeléskezelés hatékonyságát. Hol szerezhető be? Ezt az adatot általában az Oracle Advanced Collections modulban tárolják, gyakran az IEX_CASES_ALL_B táblában vagy kapcsolódó hozzárendelési táblákban. Példák John SmithJane DoeA beszedési csapat | |||
| Számla összege InvoiceAmount | A számla teljes pénzösszege. | ||
| Leírás A számla összege az ügyfélnek kiszámlázott termékek vagy szolgáltatások teljes értékét jelöli. Ez fontos pénzügyi attribútum a folyamat pénzügyi hatásának megértéséhez. Az elemzés során a számla összege segít rangsorolni a követeléskezelési feladatokat, így először a nagy értékű lejárt számlák kezelhetők. Az összeg alapján a tranzakció értéke szerinti fizetési szokások is elemezhetők, és kiszámítható a leírások pénzügyi hatása. Az olyan dashboardok, mint a számlaleírási arány elemzése, ezt az értéket használják a pénzügyi veszteségek mértékének felmérésére. Miért fontos? Pénzügyi hátteret ad a folyamatelemzéshez, így rangsorolhatók a nagy értékű számlák, és felmérhető a folyamat hatékonysági problémáinak pénzügyi hatása. Hol szerezhető be? Az adat az AR_PAYMENT_SCHEDULES_ALL táblából nyerhető ki, amely a számlák esedékes összegét tárolja. Példák 5000.001250.75250000.00 | |||
| Ügyfélszám CustomerNumber | A számlához tartozó ügyfél egyedi azonosítója. | ||
| Leírás Az ügyfélszám kapcsolja össze a számlát egy adott ügyfélszámlával. Ez lehetővé teszi a hitelkezelési és követeléskezelési folyamat ügyféljellemzők szerinti szegmentálását és elemzését. Az ügyfélszám segítségével az elemzők megvizsgálhatják, hogy bizonyos ügyfelek rendszeresen késve fizetnek-e, gyakrabban vitatják-e a számlákat, vagy több behajtási intézkedést igényelnek-e. Ez az információ elengedhetetlen az ügyfélre szabott követeléskezelési stratégiák kialakításához, a fizetési feltételek módosításához és a magas kockázatú ügyfélszegmensek azonosításához. Közvetlenül támogatja például a számlaleírási arány ügyfélszegmens szerinti elemzését. Miért fontos? Lehetővé teszi a folyamat ügyfelenkénti szegmentálását, így feltárhatók a mintázatok és kockázatok, valamint kialakíthatók a célzott követeléskezelési stratégiák. Hol szerezhető be? A RA_CUSTOMER_TRX_ALL tábla BILL_TO_CUSTOMER_ID mezőjében található, amely a HZ_CUST_ACCOUNTS táblához kapcsolódik. Példák CUST-0012389455ACME-CORP-US | |||
| Ügyfélszegmens CustomerSegment | Az ügyfél meghatározott csoportba sorolása például méret, iparág vagy stratégiai jelentőség alapján. | ||
| Leírás Az ügyfélszegmens olyan kategória, amely közös jellemzők alapján csoportosítja az ügyfeleket. A szegmensek alapulhatnak például az ügyfél típusán, például „stratégiai”, „kis- és középvállalkozás” vagy „nagyvállalat”, illetve az iparágán, például „gyártás” vagy „kiskereskedelem”. Ez az attribútum összehasonlító elemzésekhez használható. Segítségével összevethető a folyamat teljesítménye a különböző szegmensekben, például megállapítható, hogy egyes csoportoknál gyakoribbak-e a viták vagy hosszabb-e a fizetési ciklus. Az eredmények alapján az egyes szegmensek igényeihez és kockázataihoz igazíthatók a hitelpolitikák és a követeléskezelési stratégiák. Az attribútum olyan dashboardokat is támogat, mint a számlaleírási arány elemzése. Miért fontos? Összehasonlító elemzést tesz lehetővé, és megmutatja, hogyan tér el a folyamat teljesítménye és kockázata az egyes ügyfélcsoportok között. Hol szerezhető be? Gyakran az ügyféltörzsadatokban (HZ_CUST_ACCOUNTS vagy kapcsolódó táblákban) kezelik, vagy olyan ügyféljellemzőkből származtatják, mint az árbevétel vagy az iparág. Példák NagyvállalatKis- és középvállalkozásKormányzati szervezetStratégiai partner | |||
| A vita oka DisputeReason | Az ügyfél által a számlával kapcsolatban kifogásként megadott ok. | ||
| Leírás Ha az ügyfél vitatja a számlát, általában megadja ennek okát, például „hibás ár”, „sérült áru” vagy „duplikált számla”. Ezt rögzíti ez az attribútum. A kifogások okainak elemzése segít feltárni a problémák gyökerét. Azonosíthatók vele a megrendeléskezeléshez vagy számlázáshoz hasonló korábbi folyamatok visszatérő hibái, amelyek késleltetik a fizetést. Az okok kategorizálásával és gyakoriságuk nyomon követésével célzottan kezelhetők a kiváltó problémák, ami hozzájárul a viták rendezési idejének csökkentéséhez. Miért fontos? Segít feltárni a számlaviták kiváltó okait, így a korábbi folyamatok fejlesztésével megelőzhetők a hasonló viták. Hol szerezhető be? Ha a viták kezelése formalizált, az adatokat jellemzően az Oracle Advanced Collections vagy az Oracle Channel Revenue Management modulban rögzítik. Az AR_DISPUTE_HISTORY táblában is tárolhatják. Példák Hibás mennyiségÁreltérésSérült áruA szolgáltatás nem teljesült | |||
| Befejezés időpontja EndTime | Az időtartammal rendelkező tevékenység befejezésének időbélyege. | ||
| Leírás Ez az attribútum rögzíti azoknak a tevékenységeknek a befejezési időpontját, amelyeknek egyértelmű kezdete és vége van. A process mining során sok esemény pillanatnyi, de például a „vita kivizsgálása” hosszabb ideig is tarthat. A külön befejezési időponttal pontosan kiszámítható a tevékenységek feldolgozási ideje. Ez pontosabb, mint az időtartamot a következő tevékenység kezdő időpontjából kikövetkeztetni, különösen, ha közben üresjárat van. Az attribútum fontos az erőforrások kihasználtságának elemzéséhez és annak megállapításához, mely lépések tartanak a legtovább. Miért fontos? Pontos képet ad az egyes tevékenységek időtartamáról, így könnyebben feltárhatók a szűk keresztmetszetek és elemezhető az erőforrások kihasználtsága. Hol szerezhető be? Ez gyakran fogalmi attribútum. Forrása lehet a „last updated” időbélyeg vagy a tevékenységhez tartozó forrástáblák valamelyikének „close date” mezője. Példák 2023-04-15T11:30:00Z2023-05-02T09:00:00Z2023-05-21T16:45:00Z | |||
| Fizetési feltételek PaymentTerms | A megállapodás szerinti feltételek, amelyek meghatározzák a fizetési határidőt. | ||
| Leírás A fizetési feltételek rögzítik, milyen határidővel kell az ügyfélnek fizetnie, például „30 napos” vagy „60 napos” fizetési határidővel. Ezek alapján számítható ki a számla esedékessége. A fizetési teljesítés feltételek szerinti elemzése hasznos mintázatokat tárhat fel. Előfordulhat például, hogy a rövidebb fizetési határidővel rendelkező ügyfelek gyakrabban késnek. Ez az információ segíthet a hitelpolitika felülvizsgálatában és finomításában, valamint az ügyfelek eltérő követeléskezelési stratégiák szerinti csoportosításában. Arra is magyarázatot adhat, miért válik egyes számlák fizetése késedelmessé. Miért fontos? Megmutatja a megállapodás szerinti fizetési ütemezést, így a különböző hitelfeltételek mellett teljesített fizetések is összehasonlíthatók. Hol szerezhető be? Az adatokat a RA_TERMS tábla tárolja, amely a számlatranzakcióhoz kapcsolódik. Példák 30 napos fizetési határidő60 napos fizetési határidőFizetés átvételkor | |||
| Fizetési ígéret dátuma PromiseToPayDate | Az a dátum, amelyre az ügyfél a fizetést ígérte. | ||
| Leírás A követeléskezelés során az ügyfél vállalhatja, hogy egy későbbi időpontban fizet. A vállalás nyomon követéséhez rögzítik a fizetési ígéret dátumát. Ez az attribútum segít a követeléskezelési munkafolyamatok irányításában és az ügyfélvállalások megbízhatóságának értékelésében. A fizetési ígéret dátumát összevetve a tényleges fizetés beérkezésének dátumával megállapítható, milyen arányban teljesülnek az ígéretek. Pontosabb pénzforgalmi előrejelzést tesz lehetővé, és segít eldönteni, mikor kell szigorítani a követeléskezelést, ha az ügyfél nem tartja be az ígéretét. Miért fontos? Nyomon követi az ügyfelek fizetési vállalásait, így pontosabban jelezhető előre a pénzbeáramlás, és értékelhető a követeléskezelési egyeztetések eredményessége. Hol szerezhető be? Az Oracle Advanced Collections modul tárolja, valószínűleg az IEX_PROMISES_T táblához hasonló táblákban. Példák 2023-06-102023-06-252023-07-05 | |||
| Hitelkeret összege CreditLimitAmount | Az ügyfél számára jóváhagyott maximális hitelösszeg. | ||
| Leírás A hitelkeret összege azt a teljes hitelkitettséget jelöli, amelyet a vállalat egy adott ügyféllel szemben vállalni kész. Az összeget a hitelbírálat során határozzák meg. Ez az attribútum alapvető a hitelkeret-döntések hatását bemutató dashboardhoz. A jóváhagyott hitelkeret és a későbbi fizetési magatartás, illetve leírások összevetésével értékelhető a hitelkockázati szabályzat hatékonysága. Az elemzés feltárhatja, hogy a túl magas hitelkeretek növelik-e a behajthatatlan követelések arányát, és segíthet finomítani a hiteljóváhagyási folyamatot. Miért fontos? A jóváhagyott hitelkeret, a fizetési eredmények és a leírások összevetésével értékelhető a hitelkockázati szabályzat hatékonysága. Hol szerezhető be? Az adatokat az Oracle Credit Management kezeli, és jellemzően az ügyfél hitelprofiljához kapcsolódó táblákban, például a HZ_CUST_PROFILE_AMTS táblában tárolja. Példák 10000.0050000.00250000.00 | |||
| Késedelmes napok száma DaysOverdue | A fizetési határidő lejárta óta eltelt napok száma. | ||
| Leírás Ez a számított mutató azt fejezi ki, hány napja késik egy ki nem fizetett számla. Nyitott számlánál az aktuális dátum és a fizetési határidő, lezárt számlánál pedig a fizetés dátuma és a fizetési határidő közötti különbségből számítható ki. A késedelmes napok száma alapvető mutató a kintlévőségek kor szerinti elemzéséhez és a követeléskezelési feladatok rangsorolásához. A lejárt számlák korát és állapotát bemutató dashboardon a számlák késedelmi időszakok szerint csoportosíthatók, például 1–30 vagy 31–60 napos késedelem alapján. Így a követeléskezelő csapat a legrégebbi és legkockázatosabb tartozásokra összpontosíthat. Miért fontos? Megmutatja a fizetési késedelem mértékét, és alapul szolgál a követelések rangsorolásához, valamint a kintlévőségek kor szerinti elemzéséhez. Hol szerezhető be? Számított mező. Nyitott számlánál a logika: CurrentDate - DueDate; lezárt számlánál: PaymentDate - DueDate. Példák 1545920 | |||
| Leírták-e IsWrittenOff | Logikai jelző, amely megmutatja, hogy a számlát behajthatatlan követelésként leírták-e. | ||
| Leírás Ez a származtatott jelző azokat a számlákat azonosítja, amelyeket a vállalat behajthatatlannak minősített, és kivezetett az aktív követelésállományából. Ez általában a számla nem kívánatos végállapota. Ez az attribútum elengedhetetlen a számlaleírási arány KPI kiszámításához és a kapcsolódó dashboard elemzéséhez. Segítségével elkülöníthetők a sikertelen követeléskezelési esetek, és feltárhatók a leírás magasabb kockázatával összefüggő jellemzők, például az ügyfélszegmens vagy a számlaérték. Az eredmények felhasználhatók a hitelpolitika és a követeléskezelési stratégiák fejlesztésére. Miért fontos? Egyértelműen azonosítja a sikertelen követeléskezelési eseteket, ami elengedhetetlen a behajthatatlan tartozások okainak elemzéséhez és a leírási arány kiszámításához. Hol szerezhető be? Számított mező. Akkor kap értéket, ha az esethez tartozik „Invoice Written Off” tevékenység, vagy a számla állapota „Written Off”. Példák truefalse | |||
| Lejárt-e IsOverdue | Logikai jelző, amely megmutatja, hogy lejárt-e a számla fizetési határideje. | ||
| Leírás Ez a származtatott attribútum egyszerű igen/nem értékkel jelzi, hogy lejárt-e a számla. Általában az aktuális dátumot vagy a fizetés dátumát hasonlítja össze a számla fizetési határidejével. Az elemzés során könnyen szűrhet és csoportosíthat ezzel a jelzővel. Gyorsan kiválaszthatók a lejárt számlák, majd elemezhetők a folyamatútvonalaik, a követeléskezelési intézkedések eredményessége és más jellemzőik. Egyszerűbbé teszi a lejárt kintlévőségek kezelésére szolgáló dashboardok és KPI-k összeállítását, például a lejárt számlák korát és állapotát bemutató dashboardét. Miért fontos? Egyszerűen és egyértelműen azonosítja az összes lejárt számlát, amelyek a követeléskezelési folyamat elsődleges célcsoportját alkotják. Hol szerezhető be? Számított mező. A logika: IF CurrentDate > DueDate AND Status != 'Paid' THEN True ELSE False. Példák truefalse | |||
| Számla állapota InvoiceStatus | A számla aktuális állapota az életciklusa során. | ||
| Leírás A számla állapota megmutatja, hol tart éppen a számla a folyamatban. Gyakori állapot például a „Nyitott”, „Fizetett”, „Vitatott”, „Lejárt” vagy „Leírt”. Ez az attribútum gyors áttekintést ad a követelésállomány helyzetéről. A process mining során ezzel az attribútummal meghatározott számlacsoportokra szűrhet, például az összes nyitott, lejárt számlára. A lejárt számlák korát és állapotát bemutató dashboard egyik fő dimenziójaként azonnal láthatóvá teszi a számlaállomány aktuális helyzetét, és segít rangsorolni a követeléskezelési feladatokat. Miért fontos? Gyors áttekintést ad a számla aktuális állapotáról, így könnyebb szűrni és rangsorolni a követeléskezelési feladatokat. Hol szerezhető be? Az AR_PAYMENT_SCHEDULES_ALL tábla STATUS nevű mezőjében található. Példák NyitottLezártVitatottKöveteléskezelés alatt | |||
| Számla pénzneme InvoiceCurrency | Az a pénznem, amelyben a számla összege szerepel. | ||
| Leírás Ez az attribútum határozza meg a számla pénznemét, például USD, EUR vagy GBP. A nemzetközi szervezetek gyakran többféle pénznemben állítanak ki számlákat. A több pénznemben szereplő adatok elemzése körültekintést igényel. Ezzel az attribútummal pénznem szerint szűrhető a folyamatnézet, vagy alkalmazhatók a konszolidált pénzügyi jelentésekhez szükséges árfolyamok. Így a pénzösszegek helyesen értelmezhetők, és az összegek összehasonlítása azonos alapon történik. Miért fontos? Több pénznem használatakor elengedhetetlen a pénzügyi adatok helyes értelmezéséhez és a pontos elemzéshez. Hol szerezhető be? A RA_CUSTOMER_TRX_ALL tábla INVOICE_CURRENCY_CODE mezőjében található. Példák USDEURGBPJPY | |||
| Üzleti egység BusinessUnit | Az a konkrét üzleti egység vagy szervezeti egység, amely kiállította a számlát. | ||
| Leírás A nagy szervezetek működése gyakran több üzleti egységre oszlik. Ez az attribútum megmutatja, melyik üzleti egységhez tartozik a számla. Az üzleti egységek szerinti elemzés lehetővé teszi a szervezeten belüli teljesítmény összehasonlítását. Rávilágíthat arra, ha az egyes egységek eltérően alkalmazzák a hitel- és követeléskezelési szabályokat, és megmutathatja, melyik egység kezeli hatékonyabban a kintlévőségeit. Az eredmények segítenek megosztani a bevált gyakorlatokat és szükség esetén egységesíteni a folyamatokat. Miért fontos? Lehetővé teszi a szervezeti egységek teljesítményének összehasonlítását, és segít azonosítani a bevált gyakorlatokat, valamint a fejlesztendő területeket. Hol szerezhető be? A RA_CUSTOMER_TRX_ALL táblában, az ORG_ID mezőn keresztül érhető el. Ez a mező kapcsolódik a szervezeti struktúrához. Példák Észak-amerikai üzleti egységEMEA üzleti egységGlobális szolgáltatási divízió | |||
A hitelkezelés és a követelésbehajtás tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Behajtási felszólítás elindítva | A lejárt számlához kapcsolódó behajtási folyamat hivatalos kezdetét jelöli, amely gyakran az első hivatalos felszólító levél elküldésével jár. Az eseményt általában akkor rögzítik, amikor a számlát tartalmazó felszólítási köteg lefut. | ||
| Miért fontos? Ennek a tevékenységnek a nyomon követése elengedhetetlen a behajtási felszólítások eredményességének és a vonatkozó szabályok betartásának méréséhez. Kiindulópontot ad annak méréséhez, mennyi idő alatt vezet a felszólítás fizetéshez. Hol szerezhető be? Az Oracle Advanced Collections modulban rögzítik. Az eseményt a számlához kapcsolt behajtási rekord létrehozási dátuma jelöli az olyan táblákban, mint az IEX_DUNNINGS. Rögzítés A számlához tartozó rekord létrehozási dátuma az IEX_DUNNINGS táblában. Eseménytípus explicit | |||
| Fizetés beérkezett | Az ügyféltől érkező pénz beérkezését jelöli, amelyet még nem feltétlenül rendeltek hozzá egy adott számlához. Akkor rögzítik, amikor a rendszerben létrejön a pénzbeérkezési tranzakció. | ||
| Miért fontos? Ez fontos mérföldkő a követeléskezelési folyamatban, mert jelzi, hogy a pénz beérkezett. A beérkezés és a számlához rendelés közötti idő a belső feldolgozás hatékonyságát mutatja. Hol szerezhető be? Az AR_CASH_RECEIPTS_ALL tábla RECEIPT_DATE mezőjéből olvasható ki. A beérkezés ezután az AR_RECEIVABLE_APPLICATIONS_ALL táblán keresztül kapcsolható ahhoz a számlához, amelyre elszámolták. Rögzítés Az AR_CASH_RECEIPTS_ALL tábla RECEIPT_DATE mezője, az alkalmazási táblákon keresztül összekapcsolva. Eseménytípus explicit | |||
| Fizetés elszámolva | A beérkezett fizetés adott számlához rendelését jelöli, amely csökkenti a számla fennálló egyenlegét. Ekkor kapcsolják össze hivatalosan a fizetést a számlával. | ||
| Miért fontos? Ez a tevékenység igazolja, hogy a számlát kifizették. Ez a Days Sales Outstanding (DSO) számításának és a fizetés könyvelési ciklusának tényleges végpontja. Hol szerezhető be? Ez kifejezetten rögzített esemény, amely az AR_RECEIVABLE_APPLICATIONS_ALL tábla APPLY_DATE mezőjéből olvasható ki. A tábla a pénzbeérkezést az ügyféltranzakcióhoz, vagyis a számlához kapcsolja. Rögzítés Az adott számlához tartozó APPLY_DATE mező az AR_RECEIVABLE_APPLICATIONS_ALL táblából. Eseménytípus explicit | |||
| Lejárt a fizetési határidő | Számított esemény: akkor következik be, ha az aktuális dátum későbbi a számla esedékességi dátumánál, és a számlát még nem fizették ki teljesen. Ekkor a számla „rendezett” állapotból „lejárt” állapotba kerül. | ||
| Miért fontos? Ez fontos mérföldkő, amely elindítja a követeléskezelést és a behajtási felszólításokat. A lejárt számlák számának és értékének elemzése elengedhetetlen a forgótőke kezeléséhez és a hitelkockázat felméréséhez. Hol szerezhető be? Az esemény úgy számítható ki, hogy a rendszer aktuális dátumát összevetjük az AR_PAYMENT_SCHEDULES_ALL tábla DUE_DATE mezőjével azoknál a számláknál, amelyek STATUS értéke „OP” (Open). Rögzítés Számított esemény: akkor következik be, ha SYSDATE > AR_PAYMENT_SCHEDULES_ALL.DUE_DATE. Eseménytípus calculated | |||
| Számla leírva | A követelés behajtásának megszüntetéséről és a számla összegének behajthatatlan tartozásként való elszámolásáról hozott hivatalos döntést jelöli. Ez egy kifejezetten rögzített pénzügyi tranzakció, amely nullára módosítja a számla egyenlegét. | ||
| Miért fontos? Ez a követeléskezelési folyamat sikertelen végpontja. Az ügyfélszegmens, régió vagy hitelkeret szerinti leírások elemzése segít finomítani a hitelpolitikát és a követeléskezelési stratégiákat a veszteségek mérsékléséhez. Hol szerezhető be? Az eseményt kifejezetten rögzíti az AR_ADJUSTMENTS_ALL táblában létrehozott korrekció, amelynek RECEIVABLES_TRX_ID mezője behajthatatlan tartozáshoz vagy leíráshoz kapcsolódó tevékenységre mutat. Rögzítés A leírási tevékenységtípushoz tartozó rekord létrehozási dátuma az AR_ADJUSTMENTS_ALL táblában. Eseménytípus explicit | |||
| Számla létrehozva | Az Oracle Fusion Financials rendszerben rögzített számlatranzakció létrehozását jelöli. Ez a követeléskezelési modulban a számla életciklusának hivatalos kezdete, és az elemzés elsődleges kiindulópontja. | ||
| Miért fontos? Ez a számlafolyamat kezdő eseménye. Minden további ciklusidő-számítás, például a Days Sales Outstanding (DSO) és a számlafizetési ciklusidő, ettől az időbélyegtől függ. Hol szerezhető be? Ez egy kifejezetten rögzített esemény, amely a RA_CUSTOMER_TRX_ALL tábla CREATION_DATE vagy TRX_DATE oszlopából olvasható ki az adott TRX_NUMBER (Invoice Number) alapján. Rögzítés Az esemény időbélyege a RA_CUSTOMER_TRX_ALL tábla CREATION_DATE mezője. Eseménytípus explicit | |||
| Fizetési ígéret rögzítve | A rendszerben rögzített hivatalos megállapodást jelöli, amelyben az ügyfél vállalja, hogy egy adott napon fizet. Ez a követeléskezelési tevékenységek egyik fontos eredménye. | ||
| Miért fontos? A fizetési ígéretek és azok teljesítési arányának nyomon követése fontos teljesítménymutató a követeléskezelők számára. Segít előre jelezni a lejárt követelésekből várható pénzbeáramlást és értékelni a követeléskezelők eredményességét. Hol szerezhető be? Az eseményt kifejezetten az Oracle Advanced Collections rendszerben hozzák létre. A létrehozás dátuma az IEX_PROMISE_DETAILS táblából olvasható ki. Rögzítés A megfelelő számlához tartozó dátum az IEX_PROMISE_DETAILS táblából. Eseménytípus explicit | |||
| Hitelvizsgálat befejezve | A számlához tartozó ügyfél hitelképességi vizsgálatának befejezését jelöli. Az eseményt általában úgy állapítják meg, hogy a számla létrehozásának dátumát összekapcsolják az ügyfélszámlához tartozó legutóbbi hitelvizsgálat befejezési dátumával. Ez ad kiindulópontot a hitelelemzéshez. | ||
| Miért fontos? A hitelvizsgálat és a rendelés leadása között eltelt idő elemzésével feltárhatók a rendeléstől a pénz beérkezéséig tartó folyamat kezdeti szakaszának késései. Ez az adat alapul szolgál a hiteljóváhagyási ciklusidő KPI méréséhez, és segít megérteni a hiteldöntések hatását. Hol szerezhető be? Az esemény a számlán szereplő ügyfél HZ_CREDIT_PROFILE.LAST_CREDIT_REVIEW_DATE mezőjének lekérdezésével állapítható meg (RA_CUSTOMER_TRX_ALL.BILL_TO_CUSTOMER_ID). Az esemény időpontja az a LAST_CREDIT_REVIEW_DATE, amely megelőzi a számla CREATION_DATE értékét. Rögzítés Kapcsolja össze a számlát az ügyfél számla létrehozása előtti legutóbbi hitelvizsgálati dátumával. Eseménytípus inferred | |||
| Követeléskezelési stratégia hozzárendelve | Akkor következik be, amikor automatikus követeléskezelési stratégiát rendelnek a lejárt számlához vagy az ügyfélhez. Ez határozza meg a rendszer vagy a követeléskezelő által követendő lépések és tevékenységek sorát. | ||
| Miért fontos? Ez az esemény betekintést ad a követeléskezelési folyamat automatizálásába. A különböző ügyfélszegmensekhez rendelt stratégiák és azok eredményeinek elemzése segít optimalizálni a követeléskezelést. Hol szerezhető be? Az Oracle Advanced Collections modulban rögzítik. Az esemény általában az IEX_STRATEGIES táblában vagy kapcsolódó objektumokban szereplő stratégia-hozzárendelés létrehozási dátumából állapítható meg. Rögzítés Az ügyfélhez vagy tranzakcióhoz kapcsolódó követeléskezelési táblákban szereplő stratégiai feladat létrehozási dátuma. Eseménytípus explicit | |||
| Követeléskezelői tevékenység befejezve | A követeléskezelő által végrehajtott kézi tevékenységet jelöli, például telefonhívást, e-mail-küldést vagy egy kapcsolatfelvételi megjegyzés rögzítését. Ezeket a követeléskezelési modulban „tevékenységként” vagy „kapcsolatfelvételként” naplózzák. | ||
| Miért fontos? A követeléskezelői tevékenységek nyomon követésével mérhető a kézi követeléskezelési munkafolyamat hatékonysága és eredményessége. Elemezhető a tevékenységek gyakorisága és a sikeres fizetéssel való összefüggése. Hol szerezhető be? Az Oracle Advanced Collections kapcsolatfelvételi vagy tevékenységi előzményeit tartalmazó tábláiból, például a JTF_IH_ACTIVITIES táblából olvasható ki. Az adatok az ügyfélhez, esetleg az adott számlához kapcsolódnak. Rögzítés A JTF_IH_ACTIVITIES táblában szereplő, megfelelő eredmény- vagy indokkóddal rendelkező rekordok létrehozási időbélyege. Eseménytípus explicit | |||
| Számla elküldve az ügyfélnek | Azt jelzi, hogy a számlát hivatalosan eljuttatták az ügyfélhez, elektronikusan vagy nyomtatott formában. Az eseményt rögzítheti a kézbesítési modul, vagy megállapítható a számla nyomtatási dátumából. | ||
| Miért fontos? Ez a tevékenység jelöli a fizetési határidő számításának kezdetét. Nyomon követésével pontosan kiszámíthatók a késedelmes napok, és elemezhető a számla kiállítása és az ügyfél értesítése közötti esetleges késés. Hol szerezhető be? A RA_CUSTOMER_TRX_ALL tábla LAST_PRINTED_DATE mezőjéből olvasható ki. Esetleg az e-mail-kézbesítő rendszerek vagy más kommunikációs platformok integrációs naplóiból is megállapítható. Rögzítés Használja a RA_CUSTOMER_TRX_ALL tábla LAST_PRINTED_DATE mezőjét vagy a kézbesítési naplóban szereplő állapotot. Eseménytípus inferred | |||
| Számla lezárva | Akkor következik be, amikor a számla fennálló egyenlege nullára csökken, akár fizetés, jóváíró számla alkalmazása, akár korrekció révén. Ez jelöli a számla életciklusának sikeres lezárását. | ||
| Miért fontos? Ez az esemény a folyamat egyik elsődleges sikeres végpontja. A számlák lezárásának nyomon követése alapvető a követelésállomány általános állapotának megértéséhez. Hol szerezhető be? Az esemény az AR_PAYMENT_SCHEDULES_ALL tábla állapotváltozásából állapítható meg, amikor a STATUS értéke „CL” (Closed) lesz. Az időbélyeg a változáshoz tartozó LAST_UPDATE_DATE. Rögzítés Észlelje, amikor a számlához tartozó AR_PAYMENT_SCHEDULES_ALL.STATUS értéke „CL” lesz. Eseménytípus inferred | |||
| Vita bejelentve | Azt jelzi, hogy az ügyfél a számlát részben vagy egészben hivatalosan vitatja. Ezt általában a számlához tartozó fizetési ütemezés állapotának változása rögzíti. | ||
| Miért fontos? Ez a tevékenység jelöli a vitarendezési folyamat kezdetét. A bejelentés és a rendezés között eltelt idő elemzésével feltárhatók a pénzbeszedést késleltető szűk keresztmetszetek. Hol szerezhető be? Az esemény az AR_PAYMENT_SCHEDULES_ALL tábla állapotváltozásából állapítható meg, amikor a STATUS mező értéke „DS” (Disputed) lesz. Az időbélyeg auditálási táblákból vagy az utolsó módosítás dátumából nyerhető ki. Rögzítés Észlelje, amikor a számlához tartozó AR_PAYMENT_SCHEDULES_ALL.STATUS értéke „DS”-re változik. Eseménytípus inferred | |||
| Vita rendezve | Azt jelzi, hogy a bejelentett vitát kivizsgálták, és megállapodás született a rendezéséről. Akkor rögzítik, amikor megszűnik a számla vitatott állapota. | ||
| Miért fontos? Ez az esemény jelöli a vitarendezési ciklus végét. A „Vita bejelentve” esemény és e között eltelt idő fontos KPI a működési hatékonyság és a pénzforgalomra gyakorolt hatás méréséhez. Hol szerezhető be? Az esemény akkor állapítható meg, amikor az AR_PAYMENT_SCHEDULES_ALL tábla STATUS mezője „DS” (Disputed) értékről „OP” (Open) értékre, vagy jóváíró számla, illetve korrekció után „CL” (Closed) értékre változik. Rögzítés Észlelje, amikor az AR_PAYMENT_SCHEDULES_ALL.STATUS értéke „DS”-ről más állapotra változik. Eseménytípus inferred | |||
Adatkinyerési útmutatók
Lépések
- Nyissa meg az Oracle BI Publishert: Jelentkezzen be az Oracle Fusion Financials-környezetbe. A Navigator ikonra kattintva nyissa meg a Reports and Analytics területet, majd válassza a Tools > Reports and Analytics lehetőséget.
- Hozzon létre új adatmodellt: A Reports and Analytics panelen kattintson a „Browse Catalog” gombra. A katalógusban nyissa meg a „New” legördülő menüt, majd válassza a „Data Model” lehetőséget.
- Állítsa be az SQL Query adatkészletet: Az adatmodell-szerkesztőben kattintson a „+” ikonra új adatkészlet hozzáadásához, majd válassza az „SQL Query” lehetőséget.
- Állítsa be az adatforrást: Az új adatkészlet ablakában adjon beszédes nevet az adatkészletnek, például „CreditCollectionsEventLog”. Adatforrásként válassza az „FSCM” adatbázist vagy a megfelelő Oracle Fusion alkalmazás adatbázisát. Az SQL típusa legyen „Standard SQL”.
- Adja meg az SQL-lekérdezést: Másolja ki a dokumentum „query” szakaszában megadott teljes SQL-lekérdezést, és illessze be az SQL Query szövegmezőbe.
- Adja meg a lekérdezés paramétereit: A lekérdezés olyan paramétereket használ, mint a
:P_START_DATEés a:P_END_DATE, amelyekkel szűrhető a dátumtartomány. A BI Publisher automatikusan felismeri ezeket. Beállíthatja őket felhasználói adatbekérésként, „Date” adattípussal. - Mentse és tesztelje az adatmodellt: Mentse az adatmodellt egy megosztott vagy egyéni mappába. A lekérdezés ellenőrzéséhez nyissa meg a „Data” lapot, adjon meg próbaértékeket a paraméterekhez, például egy közelmúltbeli dátumtartományt, majd kattintson a „View” gombra a kimeneti adatok megtekintéséhez. Ellenőrizze, hogy minden oszlop megfelelően jelenik-e meg.
- Hozzon létre új jelentést: Lépjen vissza a katalógusba, kattintson a „New” legördülő menüre, majd válassza a „Report” lehetőséget. A „Create Report” párbeszédpanelen válassza a „Use Data Model” lehetőséget, és keresse meg az imént mentett adatmodellt.
- Állítsa be a jelentés tulajdonságait: A jelentésszerkesztőben az adatok kinyeréséhez elegendő egy egyszerű táblázatos elrendezés. Állítsa be az alapértelmezett kimeneti formátumot. Process mininghez a CSV-formátum ajánlott. Ehhez kattintson a „View a List” elemre, keresse meg a „CSV” formátumot az „Output Formats” listában, majd jelölje be a mellette lévő négyzetet. A használat egyszerűsítéséhez a többi formátum jelölését törölheti.
- Mentse a jelentést: Mentse a jelentést az adatmodellel azonos mappába.
- Ütemezze az adatkinyerést: Az adatkinyerés automatizálásához ütemezze a jelentést. Nyissa meg a jelentést, kattintson az „Actions” elemre, majd válassza a „Schedule” lehetőséget. Állítsa be az ütemezés gyakoriságát, például naponta, adja meg a CSV kimeneti formátumot, és válassza ki a kézbesítés helyét, például egy tartalomkiszolgáló könyvtárát vagy egy FTP-n keresztül elérhető külső szervert.
Konfiguráció
- Előfeltételek: A jelentést létrehozó és futtató felhasználónak megfelelő BI-szerepkörrel, például „BI Administrator” vagy „BI Author” jogosultsággal, valamint az alapul szolgáló Financials-táblákhoz (AR, IEX, HZ, JTF) hozzáférést biztosító adatbiztonsági engedélyekkel kell rendelkeznie.
- Adatforrás: A lekérdezést a fő alkalmazás-adatbázison kell futtatni, amelynek neve általában „FSCM”.
- Dátumtartomány-paraméterek: Az adatmennyiség korlátozásához feltétlenül használja a
:P_START_DATEés a:P_END_DATEparamétereket. Az első teszthez válasszon rövid időszakot, például egy hónapot. Éles futtatásnál általában 3–6 hónapos gördülő időszak megfelelő. - Szűrés: Nagy szervezeteknél érdemes
BU_NAME(Business Unit Name) paramétert hozzáadni azinvoices_baseközös táblakifejezésWHEREfeltételéhez, így egyszerre egy üzleti egység adatait dolgozhatja fel. - Teljesítmény: A lekérdezés több nagy tranzakciós táblát kapcsol össze. Szűrés nélkül, hosszú időszakra futtatva sokáig tarthat, vagy időtúllépést okozhat a BI Publisherben. Ütemezze a jelentést a kevésbé forgalmas időszakokra.
- Kimeneti formátum: Ellenőrizze, hogy az alapértelmezett vagy ütemezett kimeneti formátum CSV legyen. Így a process mining eszközök által könnyen feldolgozható, tagolt fájlt kap. Ellenőrizze a CSV kimeneti beállításait, különösen az elválasztójelet és a karakterkódolást.
Példa-lekérdezés 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' Készen áll a kezdésre?
Ezzel a sablonnal előkészítheti adatait az elemzéshez, és értékes információkat nyerhet hitelkezelési és követelésbehajtási folyamatáról. Kezdje el még ma a folyamatfejlesztést.
Kezdje el még ma optimalizálni a hitelkezelést és a követelésbehajtást
Csökkentse a folyamat átfutási idejét 30%-kal, és javítsa pénzügyi helyzetét Oracle Fusionben.
Nincs szükség bankkártyára. Kezdje el néhány perc alatt.