Adatsablon a rendeléstől a pénz beérkezéséig tartó számlázási folyamathoz
Adatsablon a rendeléstől a pénz beérkezéséig tartó számlázási folyamathoz
- Javasolt attribútumok
- Követendő fő tevékenységek
- Útmutató az adatok kinyeréséhez az Oracle E-Business Suite rendszerből
A rendeléstől a pénz beérkezéséig tartó számlázási folyamat attribútumai
| Név | Leírás | ||
|---|---|---|---|
|
Esemény időpontja
EventTime
|
A tevékenység pontos dátuma és időpontja. | ||
|
Leírás
Az esemény időpontja az egyes tevékenységekhez tartozó időbélyeg, amely megadja az események sorrendjét az adott esetben. Ez az adat szolgál a process mining időalapú elemzéseinek alapjául. Ebből számíthatók ki a fontos teljesítménymutatók, például az átfutási idők, a tevékenységek közötti időtartamok és a folyamat átfutási ideje. Például a „Számla kiállítva” és a „Számla jóváhagyva” esemény időpontjának különbsége megadja a jóváhagyás időtartamát. A megbízható folyamatelemzéshez pontos és teljes időbélyegekre van szükség.
Miért fontos?
Minden eseményhez időbeli kontextust ad, így kiszámíthatók az időtartamok, elemezhető a folyamat teljesítménye, és feltárhatók a szűk keresztmetszetek.
Hol szerezhető be?
Az Oracle EBS-táblák különböző dátummezőiből származik, például a RA_CUSTOMER_TRX_ALL és az AR_CASH_RECEIPTS_ALL táblák CREATION_DATE vagy LAST_UPDATE_DATE mezőiből.
Példák
2023-04-15T10:00:00Z2023-04-20T14:35:10Z2023-05-15T00:00:00Z
|
|||
|
Számlaszám
InvoiceNumber
|
Az egyes számladokumentumok egyedi azonosítója, amely a számlázási folyamat elsődleges esetazonosítójaként szolgál. | ||
|
Leírás
A számlaszám az order-to-cash számlázási elemzés alapja, mert minden számlázási tranzakciót egyedileg azonosít. Egyetlen folyamatpéldányba rendezi a kapcsolódó tevékenységeket, például a számla kiállítását, jóváhagyását, elküldését, kifizetését és lezárását. Így a számla teljes életciklusa elejétől a végéig áttekinthető. A process mining során a számlaszám szerinti elemzés megmutatja a teljes átfutási időt, feltárja a számlakezelés eltérő változatait, és azonosítja a fizetést késleltető szűk keresztmetszeteket. Segítségével minden egyes számla útja nyomon követhető a kiállítástól a kiegyenlítésig.
Miért fontos?
Ez az esetazonosító kapcsolja össze az összes kapcsolódó eseményt, így minden egyes számla teljes folyamata rekonstruálható és elemezhető.
Hol szerezhető be?
Ez jellemzően az Oracle Receivables RA_CUSTOMER_TRX_ALL táblájában szereplő tranzakciószám.
Példák
INV-9234501788144US-2023-001293
|
|||
|
Tevékenység neve
ActivityName
|
A számla életciklusának egy adott időpontjában bekövetkezett konkrét üzleti esemény neve. | ||
|
Leírás
A tevékenység neve a számlázási folyamat egy lépését vagy mérföldkövét jelöli, például: „Számla kiállítva”, „Számla jóváhagyva” vagy „Ügyfélfizetés beérkezett”. Az adott számlaszámhoz tartozó tevékenységek időrendi sorrendje adja ki a folyamat menetét. Ez az attribútum a process mining alapja: ebből épül fel a folyamattérkép, és ez teszi lehetővé a folyamatváltozatok elemzését, valamint az eltérések és az utómunka feltárását. A tevékenységnevek egyértelműsége és következetessége elengedhetetlen az érdemi elemzéshez, például az egyes lépések közötti idő kiszámításához vagy a folyamatkövetés vizsgálatához.
Miért fontos?
Ez az attribútum teszi lehetővé a folyamat menetének feltárását és megjelenítését, valamint a folyamatváltozatok, a szűk keresztmetszetek és az utómunka elemzését.
Hol szerezhető be?
Jellemzően úgy állítják elő, hogy a különböző Oracle EBS-táblákból származó státuszváltozásokat, eseménytípusokat, illetve rekordlétrehozási és -frissítési eseményeket szabványos tevékenységnevekhez rendelik. Ilyen tábla például az AR_PAYMENT_SCHEDULES_ALL és a RA_CUSTOMER_TRX_ALL.
Példák
Számla kiállítvaSzámla jóváhagyvaElérkezett a fizetési határidőÜgyfélfizetés beérkezett
|
|||
|
Felhasználó
User
|
A tevékenységet végző személy felhasználói azonosítója. | ||
|
Leírás
Ez az attribútum azonosítja azt a munkatársat vagy rendszerfelhasználót, aki egy folyamatlépést végrehajtott, például jóváhagyott egy számlát vagy hozzárendelt egy pénzbeérkezést. Segít megérteni a folyamat emberi oldalát. A felhasználó szerinti elemzés feltárhatja a képzési igényeket, a munkaterhelés egyenlőtlenségeit és az egyéni teljesítménykülönbségeket. Megmutathatja például, kikhez kapcsolódik a legtöbb utómunka vagy a leghosszabb jóváhagyási idő, így célzott folyamatfejlesztésre ad lehetőséget.
Miért fontos?
Lehetővé teszi az egyéni teljesítmény elemzését, és segít azonosítani a kiemelkedően teljesítő felhasználókat, a képzési igényeket és a lehetséges munkaterhelési egyenlőtlenségeket.
Hol szerezhető be?
A különböző tranzakciós táblák CREATED_BY vagy LAST_UPDATED_BY mezőjéhez hasonló felhasználói azonosítókból származik. Az azonosítót az FND_USER táblával összekapcsolva lekérhető a felhasználó neve.
Példák
JSMITHBWILLIAMSCDAVIS
|
|||
|
Fizetési határidő
DueDate
|
Az a dátum, ameddig az ügyfélnek ki kell fizetnie a számlát. | ||
|
Leírás
A fizetési határidő a számla fizetési feltételek alapján meghatározott esedékességi dátuma. Ehhez viszonyítva mérhető a tényleges fizetési teljesítmény. Ez az attribútum szükséges az olyan KPI-k kiszámításához, mint a határidőben történő fizetések aránya, valamint a számlák korosítási jelentéseinek elkészítéséhez. A process mining segítségével elemezhetők a fizetési szokások, például azonosíthatók a rendszeresen késve fizető ügyfelek, illetve felmérhető, hogyan befolyásolják a folyamat késedelmei a határidőben történő pénzbeszedést.
Miért fontos?
Viszonyítási alapként szolgál a fizetési teljesítmény méréséhez, a számlák korosításához, valamint a késedelmes fizetés és a behajthatatlan követelés kockázatának felméréséhez.
Hol szerezhető be?
Az AR_PAYMENT_SCHEDULES_ALL tábla DUE_DATE oszlopában található.
Példák
2023-05-152023-06-302023-07-01
|
|||
|
Részleg
Department
|
A tevékenységet végző felhasználó részlege vagy funkcionális csapata. | ||
|
Leírás
A részleg attribútum szervezeti kontextust ad a tevékenységet végző felhasználóhoz, például „Vevőkövetelések” vagy „Értékesítési működés”. Így az elemzés csapat- vagy részlegszinten is összesíthető. Ez segít megérteni, hogyan működnek együtt a szervezet különböző egységei, és hogyan befolyásolják a számlázási folyamatot. Feltárhatók vele egy részleg rendszerszintű problémái, összehasonlítható a csapatok teljesítménye, és elemezhető az erőforrások elosztása. Például a „Számlajóváhagyási ciklusidő” dashboard részlegenkénti bontásban is megtekinthető.
Miért fontos?
Lehetővé teszi a folyamat teljesítményének szervezeti egységek szerinti elemzését, megmutatja a csapatok közötti eltéréseket, és segít feltárni az egyes részlegekre jellemző szűk keresztmetszeteket.
Hol szerezhető be?
Jellemzően a felhasználói adatokat a szervezet HR-hierarchiájával kapcsolják össze, gyakran a PER_ALL_ASSIGNMENTS_F vagy egy hasonló HR-tábla alapján.
Példák
VevőkövetelésekPénzügyi működésSzámlázási szolgáltatások
|
|||
|
Számla státusza
InvoiceStatus
|
A számla aktuális státusza az életciklusa során. | ||
|
Leírás
A számla státusza az aktuális állapotot mutatja, például „Nyitott”, „Lezárt” vagy „Vitatott”. Pillanatképet ad a számla előrehaladásáról. Ez az attribútum szükséges például a „Számlák korosítása és státusza” dashboard elkészítéséhez, amelyen gyorsan áttekinthető a különböző állapotú számlák száma és értéke. Segít előtérbe helyezni a nyitott számlák behajtását, és összefoglalja a vevőkövetelés-állomány általános helyzetét.
Miért fontos?
Megmutatja a számlák aktuális állapotát, ami elengedhetetlen a működési dashboardokhoz, a munkaterhelés kezeléséhez és a behajtási tevékenységek rangsorolásához.
Hol szerezhető be?
Az AR_PAYMENT_SCHEDULES_ALL tábla STATUS oszlopában található („OP” a nyitott, „CL” a lezárt számlát jelöli).
Példák
NyitottLezártVitatott
|
|||
|
Számla teljes összege
TotalInvoiceAmount
|
A számla teljes pénzértéke, az összes tétellel, adóval és díjjal együtt. | ||
|
Leírás
Ez az attribútum az ügyfélnek küldött számla teljes pénzértékét mutatja. A számlázási folyamat pénzügyi elemzésének egyik alapvető mérőszáma. A process mining során a számla teljes összege alapján csoportosíthatók és szűrhetők az esetek. Az elemzők például összehasonlíthatják a nagy és kis értékű számlák folyamatát, hogy kiderüljön, eltérően kezelik-e őket. Az attribútum a pénzügyi hatás elemzéséhez is szükséges, például a jóváhagyásra váró számlák értékének kiszámításához.
Miért fontos?
Lehetővé teszi a pénzügyi hatás elemzését, így a felhasználók az összegek alapján rangsorolhatják a problémákat, és megérthetik, hogyan befolyásolja a számla értéke a folyamatot.
Hol szerezhető be?
Valószínűleg az AR_PAYMENT_SCHEDULES_ALL tábla AMOUNT_DUE_ORIGINAL mezőjéből származik, vagy az adott számlához tartozó RA_CUSTOMER_TRX_LINES_ALL adataiból számítják ki.
Példák
1500.0012550.75500.50
|
|||
|
Ügyfélazonosító
CustomerId
|
A számlát kapó ügyfél egyedi azonosítója. | ||
|
Leírás
Az ügyfélazonosító összekapcsolja a számlát a törzsadatokban szereplő ügyfélszámlával. Így az egyes ügyfelek folyamatteljesítménye összesíthető és összehasonlítható. Az elemzők ezzel az attribútummal olyan dashboardokat készíthetnek, amelyek megmutatják az ügyfelek fizetési szokásait, feltárják, kikhez kapcsolódik a legtöbb kifogás vagy utómunka, és összehasonlítják a számlafeldolgozás idejét az ügyfélszegmensek között. Segítségével a folyamat egészéről az ügyfélközpontú elemzésre lehet váltani.
Miért fontos?
Lehetővé teszi az ügyfélközpontú elemzést, és segít feltárni a fizetési szokásokat, a gyakori kifogásokat, valamint az egyes ügyfelekhez kapcsolódó folyamateltéréseket.
Hol szerezhető be?
Az RA_CUSTOMER_TRX_ALL táblában található SOLD_TO_CUSTOMER_ID vagy BILL_TO_CUSTOMER_ID mezőben.
Példák
CUST-100239845ACME-US-01
|
|||
|
Fizetési feltételek
PaymentTerms
|
Az ügyfél számlafizetési határidejét meghatározó, előre egyeztetett feltételek. | ||
|
Leírás
A fizetési feltételek határozzák meg a fizetés módját és határidejét, például a „30 napos fizetési határidő” vagy a „60 napos fizetési határidő”. Ezek alapján számítható ki a számla esedékessége. A fizetési feltételek a törzsadatok fontos elemei, és közvetlenül befolyásolják a pénzforgalmat. A fizetési feltételek szerinti elemzésből kiderül, hogyan hatnak az egyes feltételek a fizetési szokásokra és a vevőkövetelések átlagos beszedési idejére (DSO). Megmutathatja például, hogy a rövidebb fizetési határidejű ügyfelek hamarabb fizetnek-e. Az eredmények segíthetnek eldönteni, milyen fizetési feltételeket érdemes kínálni az egyes ügyfélcsoportoknak.
Miért fontos?
Közvetlenül befolyásolja a számla esedékességét és a pénzforgalom előrejelzését. Elemzésével felmérhető az egyes hitelpolitikák hatékonysága.
Hol szerezhető be?
Az RA_TERMS_B táblából származik, az RA_CUSTOMER_TRX_ALL tábla TERM_ID mezőjén keresztül kapcsolódik.
Példák
30 napos fizetési határidő60 napos fizetési határidőFizetés átvételkor
|
|||
|
Forrásrendszer
SourceSystem
|
Az a nyilvántartó rendszer, amelyből az adatokat kinyerték. | ||
|
Leírás
Ez az attribútum azonosítja azt a forrásalkalmazást, ahonnan az eseményadatok származnak. Ennél a folyamatnál ez minden esetben az Oracle E-Business Suite. Több rendszer használatakor ez a mező elengedhetetlen az adatok eredetének követéséhez és a hibakereséshez. Egyetlen rendszer esetén is szükséges az adatirányításhoz, mert igazolja, hogy az adatok a várt forrásból származnak.
Miért fontos?
Biztosítja az adatok nyomon követhetőségét és kontextusát, ami elengedhetetlen az adatirányításhoz és a több vállalati rendszerből származó adatok összekapcsolásához.
Hol szerezhető be?
Az adatkinyerés során beállított állandó érték, amely azonosítja a forrás ERP-rendszert.
Példák
Oracle E-Business SuiteOracle EBS R12
|
|||
|
Határidőre fizetve
IsPaidOnTime
|
Számított jelző, amely megmutatja, hogy a számlát legkésőbb az esedékesség napján kifizették-e. | ||
|
Leírás
Ez az igen/nem érték a „Fizetés beérkezett” időbélyeg és a számla esedékességi dátumának összehasonlításából származik. Igaz értéket kap, ha a fizetés határidőre vagy korábban érkezett, és hamisat, ha késve. A jelzővel egyszerűen készíthetők a fizetési teljesítményt mérő KPI-k és dashboardok. Közvetlenül felhasználható a „Határidőre történő fizetések aránya” KPI kiszámításához, és a számlák határidőre fizetett, illetve késedelmes csoportokra szűréséhez, további okfeltáró elemzés céljából.
Miért fontos?
Közvetlenül támogatja a „Határidőre történő fizetések aránya” KPI-t, és megkönnyíti a számlák határidőre fizetett, illetve késedelmes csoportokba sorolását.
Hol szerezhető be?
Az adatátalakítás során számítjuk ki. Logika: IF (Timestamp('Customer Payment Received') <= Date('DueDate')) THEN true ELSE false.
Példák
truefalse
|
|||
|
Pénznem
Currency
|
A számla pénzösszegeinek pénznemkódja. | ||
|
Leírás
Ez az attribútum adja meg, hogy milyen pénznemben, például USD-ben vagy EUR-ban szerepelnek a számla összegei. A pénzügyi mutatók értelmezéséhez szükséges kontextust biztosítja. Nemzetközi működés adatainak elemzésekor a pénznem attribútum elengedhetetlen a pénzügyi értékek helyes értelmezéséhez és összehasonlításához. A dashboardokon pénznem szerint lehet szűrni, vagy árfolyamokat lehet alkalmazni az összevont jelentésekhez.
Miért fontos?
A pénzügyi attribútumok értelmezéséhez szükséges kontextust biztosítja, így több pénznem használatakor is pontos elemzést tesz lehetővé.
Hol szerezhető be?
Jellemzően az RA_CUSTOMER_TRX_ALL tábla INVOICE_CURRENCY_CODE oszlopában található.
Példák
USDEURGBP
|
|||
|
Ügyfél neve
CustomerName
|
A számlát kapó ügyfél hivatalos neve. | ||
|
Leírás
Az ügyfél neve azonosítja az ügyfelet a felhasználók számára. Az ügyfélazonosító az összekapcsoláshoz és az egyedi azonosításhoz kell, a név pedig a jelentésekben és a dashboardokon jelenik meg. Így az elemzés könnyebben értelmezhető, mert a felhasználóknak nem kell azonosítókat keresgélniük. Az attribútum a felhasználóbarát vizualizációkhoz is szükséges, például az ügyfelenkénti átlagos fizetési késedelmet bemutató oszlopdiagramhoz.
Miért fontos?
Az ügyfelek neve szűréskor és csoportosításkor is jól olvasható, így a dashboardok és jelentések könnyebben használhatók, az elemzés pedig közérthetőbb.
Hol szerezhető be?
A számla fejlécében szereplő ügyfélazonosító alapján kapcsolják össze a HZ_PARTIES és a HZ_CUST_ACCOUNTS táblával.
Példák
Global Corp Inc.Innovate Solutions Ltd.Test Company LLC
|
|||
|
Ügyfél országa
Country
|
Az ügyfél számlázási címének országa. | ||
|
Leírás
Ez az adat az ügyfél számlázási címéhez tartozó országot jelöli, így földrajzi szemponttal egészíti ki a folyamatelemzést. Az országonkénti elemzés feltárhatja a fizetési szokások, a folyamat hatékonysága vagy a helyi szabályoknak való megfelelés regionális eltéréseit. A „Fizetési szokások ügyfelenként” dashboardon például összehasonlítható, hogy jelentősen eltér-e az átlagos fizetési késedelem az egyes országokban.
Miért fontos?
Földrajzi szempontból teszi elemezhetővé a folyamatot, és megmutatja az ügyfélszokások, a szabályozás hatásának vagy a működési teljesítménynek a regionális eltéréseit.
Hol szerezhető be?
Az ügyfél számlázási címének adatai a HZ_LOCATIONS és az FND_TERRITORIES táblából származnak, az ügyfélszámla-táblákon keresztül összekapcsolva.
Példák
USANémetországEgyesült Királyság
|
|||
|
Újramunkálás történt
IsRework
|
Számított jelző, amely megmutatja, hogy a számlánál történt-e utómunka, például módosítás vagy ismételt jóváhagyás. | ||
|
Leírás
Ez az igen/nem jelző akkor kap igaz értéket, ha a számla folyamatában utómunkára utaló tevékenység szerepel, például „Számla módosítva” vagy egy második „Számla jóváhagyva” esemény. Így gyorsan azonosíthatók a szokásos, hatékony folyamattól eltérő számlák. Az adat fontos az olyan KPI-k számításához, mint a „Számlahibák aránya” és a „Kézi utómunka aránya”. Segítségével mérhető az utómunka gyakorisága, kiszűrhetők a nem hatékony esetek, és feltárhatók az okok, például azok a felhasználók vagy részlegek, amelyekhez leggyakrabban kapcsolódik utómunka.
Miért fontos?
Jelzi, ha a számlához a szokásosnál több lépésre volt szükség. Így mérhető a folyamat hatékonyságvesztése, és elemezhető az utómunka oka és hatása.
Hol szerezhető be?
Az adatátalakítás során számítjuk ki: az esethez tartozó események között megkeressük a meghatározott tevékenységsorozatokat, például a „Számla jóváhagyva” eseményt követő „Számla módosítva” eseményt.
Példák
truefalse
|
|||
|
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 az utolsó adatkinyerés időbélyegét adja meg, így megállapítható, mennyire frissek az elemzett adatok. A felhasználók ebből látják, hogy a dashboardok és elemzések a folyamat legfrissebb állapotát mutatják-e. Segít reális elvárásokat kialakítani az adatok késésével kapcsolatban, és a megbízható adatmodell fontos metaadata.
Miért fontos?
Tájékoztatja a felhasználókat az adatok frissességéről, így láthatják, mennyire aktuális a folyamatelemzés.
Hol szerezhető be?
Az adatkinyerés, -átalakítás és -betöltés (ETL) során minden rekordhoz létrehozott és hozzárendelt metaadatmező.
Példák
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Üzleti egység
BusinessUnit
|
A vállalat azon üzleti vagy működési egysége, amely a számlát kiállította. | ||
|
Leírás
Az üzleti egység a tranzakcióért felelős szervezeti egységet jelöli. Az Oracle EBS rendszerben ezt gyakran a működési egység képviseli. Az adat segítségével összehasonlítható a folyamat teljesítménye a vállalat különböző részein. Kiderülhet, hogy egyes üzleti egységek hatékonyabban működnek, gyakrabban érkezik be hozzájuk időben a fizetés, vagy több vitás ügyük van. Az eredmények alapján megoszthatók a bevált gyakorlatok, és célzott intézkedések hozhatók.
Miért fontos?
Lehetővé teszi a szervezeti egységek teljesítményének összehasonlítását, és segít feltárni a bevált gyakorlatokat, valamint az egyes területek sajátos problémáit.
Hol szerezhető be?
A működési egységre vonatkozó információ a legtöbb tranzakciós táblában, például az RA_CUSTOMER_TRX_ALL táblában az ORG_ID mezőn keresztül érhető el.
Példák
Egyesült Államok, működésEMEA-szolgáltatásokGlobális gyártás
|
|||
|
Vevői rendelés száma
SalesOrderNumber
|
Az eredeti vevői rendelés azonosítója, amely alapján a számla készült. | ||
|
Leírás
A vevői rendelés száma közvetlen kapcsolatot teremt a rendeléstől a pénz beérkezéséig tartó folyamat korábbi, „Rendeléskezelés” szakaszával. Összeköti a számlázást az ügyfél eredeti megrendelésével. Ez az adat lehetővé teszi a folyamatok közötti, tágabb elemzést. Az elemzők például megvizsgálhatják, hogy bizonyos rendeléstípusok rendszeresen számlázási vitához vagy fizetési késedelemhez vezetnek-e. Olyan fontos összefüggésekre világíthat rá, amelyek a számlázási folyamat önálló vizsgálatakor rejtve maradnak.
Miért fontos?
Összeköti a számlázást a megelőző értékesítési folyamattal, így a rendeléstől a pénz beérkezéséig tartó folyamat egésze elemezhető, és az okok is feltárhatók.
Hol szerezhető be?
Jellemzően a számlasorokat tartalmazó RA_CUSTOMER_TRX_LINES_ALL tábla hivatkozási vagy interfészattribútum-mezőjében található, például az INTERFACE_LINE_ATTRIBUTE1 mezőben vagy egy hasonló leíró flexfieldben.
Példák
SO-54321601882ORD-2023-9910
|
|||
|
Vevőkövetelések átlagos beszedési ideje
DaysSalesOutstanding
|
A számla kiállítása és a fizetés beérkezése között eltelt napok száma. | ||
|
Leírás
A vevőkövetelések átlagos beszedési ideje (DSO) azt mutatja meg, átlagosan hány nap telik el a számla kiállítása és a fizetés beérkezése között. Ezt az értéket minden számlára külön számítjuk ki. Az összesített KPI átlagot mutat, de a számlánkénti érték részletesebb elemzést tesz lehetővé. Eloszlások készíthetők belőle, azonosíthatók a kiugró értékek, és időben is követhetők a beszedési hatékonyság változásai. A „DSO alakulása” dashboard időszakonként jeleníti meg ennek az adatnak az átlagát.
Miért fontos?
Számlánként méri a beszedés hatékonyságát. Az adat alapul szolgál az időbeli változások elemzéséhez, és segít feltárni a magas DSO-val összefüggő tényezőket.
Hol szerezhető be?
Az adatátalakítás során számítjuk ki. Logika: Timestamp('Customer Payment Received') - Timestamp('Invoice Generated').
Példák
304592
|
|||
A rendeléstől a pénz beérkezéséig tartó számlázási folyamat tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
|
Pénzbeérkezés hozzárendelve és egyeztetve
|
A beérkezett ügyfélfizetést sikeresen hozzárendelték egy vagy több konkrét számlához, így csökkent a fennálló tartozás. Ez a fizetés és a tartozás egyeztetését jelenti. | ||
|
Miért fontos?
Ez a fizetési folyamat utolsó lépése, és elengedhetetlen a pénzbeérkezés-hozzárendelési ciklusidő méréséhez. Az itt jelentkező késedelem miatt pontatlanná válhatnak az ügyfélszámla-egyenlegek, és romolhat a hitelkezelés.
Hol szerezhető be?
Az esemény időbélyeggel, külön rögzül, amikor az AR_RECEIVABLE_APPLICATIONS_ALL táblában létrejön egy, a pénzbeérkezést egy tranzakcióhoz kapcsoló rekord.
Rögzítés
Az esemény időpontja az AR_RECEIVABLE_APPLICATIONS_ALL táblában szereplő rekord létrehozásának időbélyege (GL_DATE vagy APPLY_DATE).
Eseménytípus
explicit
|
|||
|
Számla elküldve az ügyfélnek
|
A számlát hivatalosan továbbították az ügyfélnek, nyomtatott vagy elektronikus formában. Ekkor kezdődik az ügyfél fizetési határidejének visszaszámlálása. | ||
|
Miért fontos?
Ez fontos mérföldkő a számlaküldés átfutási idejének és a fizetésig eltelt időnek a méréséhez. Segít elkülöníteni a belső feldolgozás késedelmét az ügyfél fizetési szokásaitól.
Hol szerezhető be?
Az Oracle EBS nem mindig rögzíti ezt az eseményt külön, szabványos mezőben. Az esemény időpontja kikövetkeztethető az „Invoice Print” párhuzamos program időbélyegéből, vagy az elektronikus kézbesítéskor beállított egyéni jelzőből.
Rögzítés
A számlanyomtatási program befejezési dátumából vagy az elektronikus továbbításhoz használt egyéni logikából következtethető ki.
Eseménytípus
inferred
|
|||
|
Számla kiállítva
|
Új számlatranzakció jön létre a rendszerben. Ezt az eseményt jellemzően az „Autoinvoice Import Program” indítja el, amely feldolgozza a teljesített vevői rendelési sorokat, de kézi számlarögzítés is kiválthatja a Receivables modulban. | ||
|
Miért fontos?
Ez a számlázási folyamat kezdőpontja. Az esemény és a későbbi események közötti idő elemzésével meghatározható a számla teljes életciklusa, és feltárhatók a folyamat korai szakaszának szűk keresztmetszetei.
Hol szerezhető be?
Az Oracle Receivables RA_CUSTOMER_TRX_ALL táblájában szereplő tranzakció létrehozási dátumaként rögzül. Az esemény időbélyegeként a TRX_DATE vagy a CREATION_DATE használható.
Rögzítés
Az esemény időpontja az RA_CUSTOMER_TRX_ALL táblában szereplő rekord létrehozásának időbélyege.
Eseménytípus
explicit
|
|||
|
Számla lezárva
|
A számlát hivatalosan lezárták, vagyis a fizetések, jóváíró számlák és/vagy módosítások miatt az egyenlege nullára csökkent. Ezzel sikeresen lezárul a számla életciklusa. | ||
|
Miért fontos?
Ez a folyamat elsődleges végpontja. A „Számla kiállítva” és a „Számla lezárva” esemény közötti teljes átfutási idő az order-to-cash számlázási ciklus hatékonyságának fontos mutatója.
Hol szerezhető be?
Az AR_PAYMENT_SCHEDULES_ALL tábla STATUS mezőjének „CL” (Closed) értékre változásából következtethető ki. Időbélyegként a lezárást kiváltó utolsó tranzakció dátuma használható.
Rögzítés
Az AR_PAYMENT_SCHEDULES_ALL táblában a státusz „CL” értékre változásából következtethető ki. Az időbélyeg az utolsó kapcsolódó hozzárendelés időpontja.
Eseménytípus
inferred
|
|||
|
Ügyfélfizetés beérkezett
|
Az ügyfél befizetését pénzbeérkezésként rögzítették a rendszerben. Ekkor előfordulhat, hogy a befizetést még nem rendelték hozzá egy konkrét számlához. | ||
|
Miért fontos?
Ez fontos mérföldkő a vevőkövetelések átlagos behajtási idejének (DSO) kiszámításához. A számla kiállítása és a fizetés beérkezése közötti idő a behajtás hatékonyságának egyik fő mérőszáma.
Hol szerezhető be?
Az esemény időbélyeggel, külön rögzül az AR_CASH_RECEIPTS_ALL táblában szereplő rekord létrehozásakor.
Rögzítés
Az esemény időpontja az AR_CASH_RECEIPTS_ALL táblában szereplő rekord létrehozásának időbélyege.
Eseménytípus
explicit
|
|||
|
Elérkezett a fizetési határidő
|
Számított esemény, amely azt a napot jelöli, amikor a számla a fizetési feltételek szerint esedékessé válik. Nem felhasználói vagy rendszertevékenységhez kapcsolódik, de fontos időbeli mérföldkő. | ||
|
Miért fontos?
Ez az esemény elengedhetetlen a határidőben fizető ügyfelek arányának kiszámításához és a fizetési szokások elemzéséhez. Viszonyítási alapként szolgál annak megállapításához, hogy a fizetés korábban, határidőre vagy késve történt-e.
Hol szerezhető be?
Ezt nem rögzítik eseményként. Az adott számlához tartozó AR_PAYMENT_SCHEDULES_ALL tábla TERM_DUE_DATE mezőjét kell összevetni a rendszer dátumával.
Rögzítés
Az aktuális időbélyeg és az AR_PAYMENT_SCHEDULES_ALL.TERM_DUE_DATE összehasonlításával határozható meg.
Eseménytípus
calculated
|
|||
|
Fizetés visszafordítva
|
A korábban beérkezett ügyfélfizetést visszafordították. Ez jellemzően fedezethiány (NSF) vagy más banki feldolgozási hiba miatt történik. | ||
|
Miért fontos?
A fizetések visszafordítása megnehezíti a pénzforgalom előrejelzését, és további adminisztrációt igényel. Az események követése segít azonosítani a problémás ügyfeleket vagy fizetési módokat.
Hol szerezhető be?
Ez az Oracle Receivables rendszerben külön műveletként rögzül. A visszafordítás bejegyzéseket hoz létre az AR_CASH_RECEIPT_HISTORY_ALL táblában, a státusz pedig például „REVERSED” értéket kap.
Rögzítés
Az AR_CASH_RECEIPT_HISTORY_ALL táblában a státusz „REVERSED” értékre változásából azonosítható.
Eseménytípus
explicit
|
|||
|
Fizetési emlékeztető kiküldve
|
Fizetési felszólítást vagy emlékeztetőt küldtek az ügyfélnek egy lejárt számláról. Ez fontos tevékenység a követelésbehajtási folyamatban. | ||
|
Miért fontos?
A tevékenység követése elengedhetetlen a behajtási stratégia hatékonyságának méréséhez. Elemezhető, hogyan alakul a fizetési arány az emlékeztetők kiküldése előtt és után.
Hol szerezhető be?
Az Oracle Advanced Collections használata esetén a fizetési felszólítás kiküldése külön eseményként rögzül. A modul nélkül ezt a tevékenységet gyakran a rendszeren kívül végzik, ezért előfordulhat, hogy nem követhető megbízhatóan.
Rögzítés
Az Oracle Advanced Collections modulban Dunning Correspondence eseményként rögzül.
Eseménytípus
explicit
|
|||
|
Jóváíró számla létrehozva
|
Jóváíró számlatranzakció jön létre, amelyet gyakran egy meglévő számlához rendelnek hozzá számlázási hiba javításakor vagy visszáru feldolgozásakor. Ez különálló, de kapcsolódó tranzakció a vevőkövetelések között. | ||
|
Miért fontos?
A jóváíró számlák nagy száma a rendelésteljesítés, az árazás vagy az eredeti számlázás pontosságának korábbi szakaszban jelentkező problémáira utalhat. Ezen események elemzése segít feltárni a bevételkiesés és az ügyfél-elégedetlenség kiváltó okait.
Hol szerezhető be?
Új tranzakcióként rögzül az RA_CUSTOMER_TRX_ALL táblában. A CUST_TRX_TYPE_ID egy „CM” (Credit Memo) besorolású típusra hivatkozik. A PREVIOUS_CUSTOMER_TRX_ID mező kapcsolja össze az eredeti számlával.
Rögzítés
Az esemény egy jóváíró számlatípusú rekord létrehozása az RA_CUSTOMER_TRX_ALL táblában.
Eseménytípus
explicit
|
|||
|
Leírásba helyezés rögzítve
|
Módosítással a fennmaradó számlaegyenleg egészét vagy egy részét behajthatatlan követelésként leírják. Erre jellemzően akkor kerül sor, amikor a behajtási lehetőségek kimerültek. | ||
|
Miért fontos?
A leírás közvetlen bevételkiesést jelent. Gyakoriságának és értékének elemzése segít a hitelpolitikák finomításában és a behajthatatlan tartozások pénzügyi hatásának megértésében.
Hol szerezhető be?
A számlához kapcsolódó, meghatározott típusú módosítási tranzakcióként rögzül. Az esemény az AR_ADJUSTMENTS_ALL táblában található, és egy leírásra beállított követeléskezelési tevékenységtípushoz kapcsolódik.
Rögzítés
Az esemény egy „Write-Off” tevékenységtípusú rekord létrehozása az AR_ADJUSTMENTS_ALL táblában.
Eseménytípus
explicit
|
|||
|
Számla jóváhagyva
|
A kézzel rögzített vagy ellenőrzött számla hivatalos belső jóváhagyása, mielőtt elküldik az ügyfélnek. Ez a tevékenység része lehet egy beállított Oracle Workflow folyamatnak, vagy történhet a státusz kézi módosításával. | ||
|
Miért fontos?
A jóváhagyási idő követése elengedhetetlen a „Számlajóváhagyási ciklusidő” KPI méréséhez. Az itt jelentkező késedelem közvetlenül kitolja a számlázást, és meghosszabbítja a pénzkonverziós ciklust.
Hol szerezhető be?
Ez gyakran a rendszer beállításaitól függ. Az esemény kikövetkeztethető a workflow-táblák (például a WF_ITEM_ACTIVITY_STATUSES) státuszváltozásaiból, vagy esetleg az RA_CUSTOMER_TRX_ALL táblában található számla leíró flexfieldjéből.
Rögzítés
A workflow-táblák státuszváltozásaiból vagy egyéni státuszmezőkből következtethető ki.
Eseménytípus
inferred
|
|||
|
Számla módosítva
|
Egy meglévő, még nem véglegesített számlát frissítettek vagy javítottak. Ez történhetett például a tételek, az összegek vagy a számlázási adatok módosításával, mielőtt a számlát véglegesítették vagy elküldték. | ||
|
Miért fontos?
A gyakori módosítások a folyamat hatékonysági problémáira, az adatok minőségi hibáira vagy felhasználói hibára utalhatnak. A tevékenység elemzésével számszerűsíthető az utómunka és annak hatása az átfutási időre, valamint mérhető például a „Számlahibák aránya” KPI.
Hol szerezhető be?
A nem véglegesített számlák esetében az RA_CUSTOMER_TRX_ALL táblában szereplő CREATION_DATE és LAST_UPDATE_DATE összehasonlításával következtethető ki. Ha az auditálás engedélyezett, a módosítások közvetlenebbül is nyomon követhetők.
Rögzítés
Az RA_CUSTOMER_TRX_ALL táblában szereplő LAST_UPDATE_DATE mező változásainak követésével következtethető ki.
Eseménytípus
inferred
|
|||
|
Vevői kifogás rögzítve
|
Az ügyfél hivatalosan kifogást emelt a számla ellen, ezért a kifogás rendezéséig szünetel a követelésbehajtás. Ezt gyakran az Oracle Advanced Collections modulban kezelik, vagy a státusz kézi módosításával rögzítik. | ||
|
Miért fontos?
A kifogások késleltetik a fizetést, így közvetlenül befolyásolják a pénzforgalmat. Gyakoriságuk és rendezési idejük követésével feltárhatók a termékekkel, szolgáltatásokkal vagy a számlázás pontosságával kapcsolatos visszatérő problémák.
Hol szerezhető be?
Az Oracle Advanced Collections használata esetén ez külön tranzakcióként rögzül. Enélkül az esemény a számlán beállított „dispute” státuszból vagy zárolásból következtethető ki.
Rögzítés
Az Oracle Advanced Collections modulban tranzakcióként rögzül, vagy a számla státuszváltozásából következtethető ki.
Eseménytípus
explicit
|
|||
Útmutatók az adatok kinyeréséhez
Kezdje el most?
Használja ezt a sablont, hogy gyorsan elindítsa a rendeléstől a pénz beérkezéséig tartó számlázási folyamat process mining elemzését. Kezdje el még ma feltárni az összefüggéseket és javítani a működés hatékonyságát.
Gyorsítsa fel most a rendeléstől a pénz beérkezéséig tartó számlázási folyamatot
Rövidítse 30%-kal a számlázási ciklust, és gyorsítsa fel a pénz beérkezését.
Nincs szükség bankkártyára. A beállítás percek alatt elvégezhető.