Adatsablon az értékesítési rendelések feldolgozásához a rendeléstől a pénz beérkezéséig tartó folyamatban
Adatsablon az értékesítési rendelések feldolgozásához a rendeléstől a pénz beérkezéséig tartó folyamatban
- Javasolt attribútumok
- Követendő fő tevékenységek
- Gyakorlati útmutató az adatkinyeréshez
A rendeléstől a pénz beérkezéséig tartó értékesítésirendelés-feldolgozás attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Értékesítési rendelés SalesOrder | Az értékesítési rendelés egyedi azonosítója, amely az Order to Cash folyamat elsődleges esetazonosítója. | ||
| Leírás Az értékesítési rendelés száma egyedileg azonosítja az ügyfél rendelését annak teljes életciklusa során. Ez kapcsolja össze a rendeléshez tartozó tevékenységeket a létrehozástól és visszaigazolástól a teljesítésen és számlázáson át a végső fizetésig. A process mining során ez az attribútum szükséges ahhoz, hogy az összetartozó események egyetlen esetbe kerüljenek. Az értékesítési rendelés szerinti elemzés teljes képet ad a folyamatról: kiszámítható a teljes átfutási idő, azonosíthatók az egyes rendelések folyamatváltozatai, és nyomon követhető a rendelés útja a különböző részlegeken és rendszereken keresztül. Miért fontos? Ez az esetazonosító. Összekapcsolja a folyamat eseményeit, így végigkövethető egy ügyfélrendelés teljes útja. Hol szerezhető be? Ez az azonosító általában az Oracle Fusion értékesítésirendelés-fejlécét tartalmazó táblában található, például a DOO_HEADERS_ALL táblában. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák SO-100567SO-100568SO-100569 | |||
| Esemény időpontja EventTime | Az az időbélyeg, amely megadja, mikor történt egy adott tevékenység vagy esemény az értékesítési rendelés folyamatában. | ||
| Leírás Ez az attribútum minden folyamati tevékenységhez megadja a dátumot és az időpontot, így meghatározható az események időrendi sorrendje. A folyamatelemzés időbeli alapját adja, és pontosan rögzíti, mikor történt az egyes lépések végrehajtása. A process mining során az EventTime alapján számítható ki a ciklusidő, a tevékenységek közötti időtartam és az eset teljes átfutási ideje. Lehetővé teszi a teljesítmény elemzését, a várakozási időkből adódó szűk keresztmetszetek feltárását és a szolgáltatási szintű megállapodások (SLA-k) határidőinek nyomon követését. Minden időalapú KPI és dashboard az attribútum pontosságára épül. Miért fontos? Ez az időbélyeg szükséges az események időrendi sorba rendezéséhez és az időalapú mutatók, például a ciklusidők és időtartamok kiszámításához. Hol szerezhető be? Származtatott attribútum, amely az Oracle Fusion különböző tábláinak időbélyegmezőiből származik, például a rendelés létrehozásának, a kiszállításnak, a számlázásnak és a fizetésnek az időpontjából. Példák 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Tevékenység neve ActivityName | Az értékesítési rendelés folyamatában történt konkrét üzleti esemény vagy feladat neve. | ||
| Leírás Ez az attribútum írja le, hogy az értékesítési rendeléshez egy adott időpontban melyik lépés tartozott, például „Értékesítési rendelés létrehozva”, „Áru kiszállítva” vagy „Fizetés beérkezett”. Ezeknek a tevékenységeknek a sorrendje adja az egyes esetek folyamatmenetét. Az ActivityName elemzése a process mining alapja. Segítségével megjeleníthető a folyamattérkép, feltárhatók a folyamatváltozatok, és azonosíthatók azok a szűk keresztmetszetek, ahol az esetek feltorlódnak. Erre épül a lépések közötti átmeneti idők kiszámítása és az Order to Cash folyamat működési sorrendjének megértése. Miért fontos? Ez az attribútum határozza meg a folyamattérkép lépéseit, így megjeleníthető és elemezhető a folyamat menete. Hol szerezhető be? Származtatott attribútum. A különböző Oracle Fusion táblák tranzakciós állapotait vagy eseménytípusait, például a rendelés, a szállítmány vagy a számla állapotát, egységes tevékenységnevekhez rendeli. Példák Vevői rendelés létrehozvaTermékek feladvaSzámla létrehozvaFizetés beérkezett | |||
| Automatizált IsAutomated | Jelzi, hogy a tevékenységet a rendszer automatikusan vagy egy felhasználó kézzel hajtotta-e végre. | ||
| Leírás Ez a logikai attribútum megkülönbözteti a rendszer által vezérelt eseményeket, például az automatikus hitelképességi ellenőrzést vagy a rendszer által létrehozott számlát, a felhasználói műveletektől. Az értékét általában a tevékenységhez tartozó felhasználónév alapján határozzák meg: az általános rendszerazonosító automatizálást jelez. Az attribútum elemzésével mérhető a folyamat automatizáltsága, és kiszámítható a „Kézi újramunkálást igénylő rendelések aránya” KPI. Azt is megmutathatja, mely kézi lépések veszik igénybe a legtöbb időt, vagy járnak a legtöbb hibával, így feltárhatók a további automatizálás lehetőségei. Miért fontos? Segít mérni a folyamat automatizáltságát, és feltárni, hogyan csökkenthetők a költséges kézi beavatkozások. Hol szerezhető be? Származtatott mező, amelynek értéke gyakran a UserName attribútumra alkalmazott szabályon alapul. Ha például a felhasználó „SYSTEM” vagy „BATCH”, a jelző értéke true. Példák truefalse | |||
| Értékesítési csatorna SalesChannel | Az a csatorna, amelyen keresztül az értékesítési rendelés beérkezett. | ||
| Leírás Ez az attribútum az értékesítési rendelés forrását jelöli, például „Web”, „Közvetlen értékesítés”, „Partner” vagy „EDI”. Megmutatja, hogyan került be a rendelés a szervezethez. Az értékesítési csatorna szerinti bontás fontos a „Értékesítési csatornák teljesítményének áttekintése” dashboardhoz. Segítségével összehasonlítható a különböző csatornák hatékonysága, átfutási ideje és hibaaránya, így kiderül, melyek működnek a legjobban, és melyeknél érdemes fejleszteni a folyamatot vagy növelni az automatizálást. Miért fontos? Csatornánkénti teljesítményelemzést tesz lehetővé, és segít azonosítani a rendelésfeldolgozás leghatékonyabb és legkevésbé hatékony csatornáit. Hol szerezhető be? Ez az adat az értékesítési rendelés fejlécének erre szolgáló mezőjében tárolható. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák Közvetlen értékesítésWebes portálEDIViszonteladó | |||
| Értékesítési rendelés teljes összege SalesOrderTotalAmount | Az értékesítési rendelés teljes pénzértéke. | ||
| Leírás Ez az attribútum az ügyfélnek a teljes értékesítési rendelésért felszámított összeget jelöli. Tartalmazza az összes tétel, adó és egyéb díj összegét, a kedvezmények levonása előtt. A folyamatelemzésben ez az attribútum értékalapú process mining elemzést tesz lehetővé. Az érték szerint csoportosíthatók a rendelések, például magas és alacsony értékűekre, így összehasonlítható, hogy eltérő folyamatútvonalat követnek-e, vagy más-e az átfutási idejük. Segít abban is, hogy a folyamatfejlesztés a pénzügyileg legjelentősebb esetekre összpontosítson. Miért fontos? Lehetővé teszi a pénzügyi hatás elemzését, segít a nagy értékű rendelések folyamatfejlesztési prioritásainak meghatározásában és a költségek mozgatórugóinak feltárásában. Hol szerezhető be? Általában az Oracle Fusion értékesítésirendelés-fejlécet tartalmazó tábláiban található. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák 5250.00125000.75980.50 | |||
| Felhasználónév UserName | A tevékenységet végrehajtó felhasználó neve vagy azonosítója. | ||
| Leírás Ez az attribútum azonosítja azt a munkatársat vagy rendszerfelhasználót, aki egy adott folyamati lépésért felelős. Segítségével elemezhető az egyéni teljesítmény, a munkaterhelés megoszlása és az előírt eljárások betartása. A felhasználó szerinti elemzés feltárhatja a képzési igényeket, segíthet felismerni a kiemelkedően teljesítő munkatársakat vagy csapatokat, és megmutathatja az egyes felhasználókhoz köthető eltéréseket. A megfelelés és az audit szempontjából is hasznos, mert nyomon követhető, ki milyen műveletet végzett. Miért fontos? Lehetővé teszi a felhasználónkénti teljesítmény és munkaterhelés elemzését, valamint az egyes személyekhez köthető kézi újramunkálási minták feltárását. Hol szerezhető be? Általában az Oracle Fusion tranzakciós tábláinak CREATED_BY vagy LAST_UPDATED_BY mezőiből származik, gyakran egy felhasználói törzstáblához, például az FND_USER táblához kapcsolva. Példák john.smithjane.doesystem_batch_user | |||
| Fizetési határidő PaymentDueDate | 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 dátuma és az ügyféllel egyeztetett fizetési feltételek alapján számítható ki. Ez jelöli a fizetés beérkezésének határidejét. Ez az attribútum szükséges a „Határidőre beérkezett fizetések aránya” KPI kiszámításához. A fizetési határidőt a tényleges beérkezési dátummal összevetve megállapítható, hogy az ügyfél időben vagy késve fizetett-e. Ez segít nyomon követni a vevőkövetelések alakulását és kezelni a pénzforgalmat. Miért fontos? Ez a határidő alapul szolgál a határidőre beérkezett fizetések arányának kiszámításához, amely a pénzforgalom hatékonyságának fontos mutatója. Hol szerezhető be? Az Oracle Fusion vevőkövetelési vagy számlatábláiban található, például az AR_PAYMENT_SCHEDULES_ALL táblában. Példák 2023-06-192023-07-012023-06-25 | |||
| Kért kézbesítési dátum RequestedDeliveryDate | Az a kézbesítési dátum, amelyet az ügyfél a rendeléshez kért. | ||
| Leírás Ez az attribútum rögzíti azt a dátumot, amikor az ügyfél szeretné megkapni az árut. Az Order to Cash folyamat teljesítési szakaszának egyik fontos célértéke. Ez a dátum szükséges a „Határidőre kézbesített rendelések aránya” KPI kiszámításához és a „Kézbesítési szolgáltatási szint (SLA)” dashboard használatához. A tényleges kézbesítési dátummal összevetve mérhető, hogy a szervezet mennyire teljesíti az ügyfélelvárásokat, és feltárhatók a késések kiváltó okai. Miért fontos? Alapul szolgál a határidőre történő kézbesítés és az ügyféllel kötött szolgáltatási szintű megállapodás (SLA) betartásának méréséhez. Hol szerezhető be? Általában az Oracle Fusion értékesítésirendelés-sorokat tartalmazó tábláiban található. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák 2023-05-202023-06-012023-05-25 | |||
| Tényleges kézbesítési dátum ActualDeliveryDate | Az a dátum, amikor az árut ténylegesen kézbesítették az ügyfélnek. | ||
| Leírás Ez az attribútum rögzíti a végső kézbesítés dátumát, amely a folyamat teljesítési szakaszának végét jelzi. Ez a tényleges eredmény, amelyhez a tervezett vagy kért dátumokat viszonyítják. A dátumot a kért kézbesítési dátummal összevetve számítható ki a határidőre történő kézbesítés aránya. Fontos adat a „Határidőre kézbesített rendelések aránya” KPI-hoz és a „Kézbesítési SLA” dashboardhoz, mert egyértelműen mutatja a logisztika és az ellátási lánc teljesítményét. Miért fontos? Ez a tényleges kézbesítési dátum, amelyből kiszámítható a határidőre kézbesített rendelések aránya, és mérhető, hogy a teljesítés megfelelt-e az ügyfél kérésének. Hol szerezhető be? Az Oracle Fusion szállítási és kézbesítési tranzakciós tábláiból származik. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák 2023-05-202023-06-032023-05-25 | |||
| Ügyfél neve CustomerName | Az értékesítési rendelést leadó ügyfél neve. | ||
| Leírás Ez az attribútum azonosítja az értékesítési rendeléshez tartozó ügyfélszámla hivatalos nevét. Az ügyfélközpontú folyamatelemzés egyik fontos dimenziója. Az ügyfél szerinti elemzés megmutatja, ha egyes ügyfelek rendeléseinek hosszabb az átfutási ideje, több újramunkálást igényelnek, vagy eltérnek a megszokott folyamattól. Az eredmények felhasználhatók az ügyfélkiszolgálás javítására, a kiemelt ügyfelek igényeihez igazított folyamatok kialakítására és az ügyfél-elégedettséget rontó problémák feltárására. Miért fontos? Ügyfélközpontú elemzést tesz lehetővé, amely feltárja az egyes ügyfeleket érintő folyamati problémákat, és segít javítani az ügyfél-elégedettséget. Hol szerezhető be? Az ügyféltörzs adatait tartalmazó táblákból, például a HZ_PARTIES táblából származik, és ügyfélazonosító kapcsolja az értékesítési rendeléshez. Példák Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Fizetési feltételek PaymentTerms | Az ügyféllel egyeztetett fizetési feltételek. | ||
| Leírás Ez az attribútum határozza meg, milyen feltételekkel kell az ügyfélnek kifizetnie a számlát, például „30 napos fizetési határidővel” vagy „60 napos fizetési határidővel”. Ezek alapján számítható ki a fizetési határidő. A fizetési feltételek szerinti bontás segíthet megmagyarázni a fizetési ciklusok eltéréseit. Kontextust ad a „Határidőre fizetett számlák aránya” KPI értelmezéséhez, mivel a különböző feltételek eltérő fizetési szokásokkal járnak. Az elemzés a hitelpolitika és a pénzforgalmi előrejelzés kialakítását is segítheti. Miért fontos? Fontos támpontot ad a fizetési szokások elemzéséhez, és segít megmagyarázni a számlázás és a fizetés közötti idő eltéréseit. Hol szerezhető be? Az Oracle Fusion rendszerben az értékesítési rendelés vagy az ügyfélszámla szintjén érhető el. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák 30 napos fizetési határidő60 napos fizetési határidőFizetés átvételkor | |||
| Forrásrendszer SourceSystemIdentifier | Megadja, melyik forrásrendszerből származnak az eseményadatok. | ||
| Leírás Ez az attribútum jelzi az adatok forrását. Különösen hasznos, ha az Order to Cash folyamat több rendszeren fut. A rendelési adatok például származhatnak az Oracle Fusion rendszerből, a szállítási adatok pedig egy külső logisztikai rendszerből. Az elemzés során segít megérteni az adatok eredetét, és lehetővé teszi, hogy a folyamatnézetet egy adott rendszer eseményeire szűrje. Több rendszer használatakor az adatok ellenőrzéséhez és az IT-környezetek közötti folyamattöredezettség feltárásához is fontos. Miért fontos? Megmutatja az adatok eredetét, ami több rendszert használó környezetben fontos az adatirányításhoz és a hibakereséshez. Hol szerezhető be? Általában az adatkinyerés és -átalakítás során hozzáadott, rögzített érték, amely azonosítja az adathalmaz forrását. Példák Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Határidőre kézbesítve IsOnTimeDelivery | Számított jelző, amelynek értéke true, ha a tényleges kézbesítés a kért dátumon vagy az előtt történt. | ||
| Leírás Ez a logikai attribútum a tényleges és a kért kézbesítési dátum összehasonlításából származik. Esetenként egyszerűen jelzi a kézbesítés teljesítményét. Ez a jelző szolgál alapul a „Határidőre kézbesített rendelések aránya” KPI kiszámításához. Egyszerűbbé teszi a szűrést és az elemzést: gyorsan kiválaszthatók a késve kézbesített rendelések, és feltárhatók a késésekhez vezető okok. Miért fontos? Közvetlenül méri, hogy a teljesítés megfelelt-e az ügyfélelvárásoknak, és egyszerűbbé teszi a késve kézbesített rendelések elemzését. Hol szerezhető be? Számított mező. A logika: ActualDeliveryDate <= RequestedDeliveryDate. Példák truefalse | |||
| Javított számla IsInvoiceCorrected | Jelzi, hogy a számlát az első létrehozása után javították vagy módosították-e. | ||
| Leírás Ez a logikai attribútum akkor igaz, ha a számla javítási folyamaton ment keresztül, amit a „Számla javítva” tevékenység jelenléte jelez. Megmutatja, mely esetekben kellett újramunkát végezni a számlázás során. Ez az „Számlapontosság és újramunka elemzése” dashboard és a „Számla-újramunkálási arány” KPI egyik fontos bemeneti adata. Segítségével számszerűsíthetők a számlázási hibák, és feltárhatók azok kiváltó okai. Így csökkenthető a kézi munka és a fizetési késedelem. Miért fontos? Azonosítja a számlák újramunkálását, amely a folyamat hatékonyságának, az adatminőségnek és a fizetési késedelmek kockázatának fontos mutatója. Hol szerezhető be? Ez egy számított mező, amely általában akkor kap igaz értéket egy esetnél, ha az eseménynapló tartalmaz „Számla javítva” tevékenységet. Példák falsetrue | |||
| Késedelmes fizetés IsLatePayment | Számított jelző, amelynek értéke true, ha a fizetés a fizetési határidő után érkezett be. | ||
| Leírás Ez a logikai attribútum a tényleges fizetési dátum és a fizetési határidő összehasonlításából származik. Egyértelműen jelzi, hogy a számlát időben fizették-e ki. Ezt az attribútumot a „Határidőre fizetett számlák aránya” KPI kiszámításához használják. Segítségével elkülöníthetők a határidőre és késve fizetett számlák, így elemezhetők a késve fizető ügyfelek jellemzői, a késések gyakori okai és a forgótőkére gyakorolt pénzügyi hatás. Miért fontos? Közvetlenül méri a fizetések beszedésének hatékonyságát, és egyszerűbbé teszi a késedelmes fizetések elemzését. Hol szerezhető be? Ez egy számított mező. A logika: PaymentReceivedDate > PaymentDueDate. Példák falsetrue | |||
| Rendelés típusa OrderType | Az értékesítési rendelés besorolása, például „Normál rendelés” vagy „Visszáru-rendelés”. | ||
| Leírás A rendelés típusa alapján üzleti céljuk szerint csoportosíthatók az értékesítési rendelések. Gyakori típus a normál értékesítési rendelés, a szolgáltatási rendelés, az áru-visszavételi engedély (RMA) és a belső rendelés. A rendeléstípus szerinti elemzés azért fontos, mert az egyes típusok folyamata és teljesítménycéljai eltérhetnek. A bontás segít felismerni a szándékos és elvárt folyamatváltozatokat, így ezek nem minősülnek tévesen eltérésnek. Miért fontos? Lehetővé teszi a különböző, szabályos folyamatok, például a normál rendelések és a visszáruk elkülönítését, így az elemzés pontos és méltányos marad. Hol szerezhető be? Általában az Oracle Fusion értékesítésirendelés-fejlécének egyik mezőjeként érhető el. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák Normál értékesítési rendelésVisszáru-engedélySzolgáltatási rendelés | |||
| Szállítási mód ShippingMethod | Az áru ügyfélhez szállításához használt mód vagy fuvarozó. | ||
| Leírás Ez az attribútum a kézbesítéshez használt fuvarozót vagy szolgáltatási szintet jelöli, például „Közúti áruszállítás”, „Expressz légi szállítás” vagy „Helyi futárszolgálat”. Ez az adat szükséges a „Szállítási módok határidős teljesítése” dashboardhoz. Segítségével összehasonlíthatók a különböző szállítási módok és fuvarozók határidős kézbesítési mutatói és költségei, ami támogatja a logisztikai stratégia és a beszállítók kiválasztásának optimalizálását. Miért fontos? Közvetlenül támogatja a logisztikai elemzést, mert összehasonlíthatóvá teszi a különböző fuvarozók és szállítási módok teljesítményét. Hol szerezhető be? Az Oracle Fusion szállítási és teljesítési tábláiban található. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák FedEx GroundUPS Next Day AirDHL International | |||
| Számlaszám InvoiceNumber | Az ügyfélszámla egyedi azonosítója. | ||
| Leírás Ez az attribútum az értékesítési rendelés alapján kiállított számla egyedi száma. Összekapcsolja az értékesítési és teljesítési tevékenységeket a folyamat pénzügyi elszámolási szakaszával. Az értékesítési rendelés az elsődleges esetazonosító, a számlaszám viszont elengedhetetlen a számlázási és fizetési részfolyamatok elemzéséhez. Segítségével nyomon követhetők a számlakorrekciók, a vitás ügyek és a fizetési státusz. A „Számlapontosság és újramunkálás elemzése” dashboard is erre épül. Miért fontos? Összekapcsolja az adatokat a vevőkövetelési folyamattal, és szükséges a számlák újramunkálásának és a fizetési ciklusoknak az elemzéséhez. Hol szerezhető be? Az Oracle Fusion vevőkövetelési tranzakciós tábláiban található, például a RA_CUSTOMER_TRX_ALL táblában. Példák INV-93485INV-93486INV-93487 | |||
| Termék neve ProductName | Az értékesített termék vagy szolgáltatás neve. | ||
| Leírás Ez az attribútum az értékesítési rendelés sorában szereplő tételt jelöli. Több soros rendelés esetén az eset elemezhető tételsoronként, vagy az attribútum a rendelés fejlécének szintjén összesíthető. A termék szerinti elemzés megmutatja, hogy egyes termékekhez bonyolultabb vagy problémásabb folyamatok kapcsolódnak-e, például gyakori kézbesítési késések vagy fizetési problémák. Az eredmények a termékmenedzsment és az ellátásilánc-stratégia kialakítását is segíthetik. Miért fontos? Lehetővé teszi a különböző termékekhez kapcsolódó folyamatok teljesítményének elemzését, és kiemeli azokat a tételeket, amelyek teljesítése vagy számlázása bonyolultabb folyamatot igényelhet. Hol szerezhető be? Az értékesítésirendelés-sorokat tartalmazó táblákból származik, és a terméktörzs táblájával kapcsolható össze. További információért tekintse meg az Oracle Fusion Financials dokumentációját. Példák Standard Widget X1Prémium szolgáltatáscsomagComponent Y2-B | |||
| Ügyfél országa CustomerCountry | Az ország, ahol az ügyfél található. | ||
| Leírás Ez az attribútum az ügyfél szállítási vagy számlázási címéből származó országot adja meg. A földrajzi elemzés egyik fontos dimenziója. Az ország szerinti bontás feltárhatja a folyamat teljesítményének, átfutási idejének vagy fizetési szokásainak regionális eltéréseit. Segít megérteni, hogyan hatnak a helyi szabályozások, logisztikai nehézségek és piaci körülmények az Order to Cash folyamatra. Miért fontos? Földrajzi elemzést tesz lehetővé, amely feltárja a folyamat hatékonyságának, a megfelelésnek és az ügyfélviselkedésnek a regionális eltéréseit. Hol szerezhető be? Az ügyféltörzs adatait tartalmazó táblákból, például a HZ_LOCATIONS és a HZ_PARTY_SITES táblából származik, amelyek az értékesítési rendeléshez kapcsolódnak. Példák USANémetországJapán | |||
| Utolsó adatfrissítés LastUpdateDate | Az az időbélyeg, amely megadja, mikor frissültek utoljára az esemény adatai a forrásrendszerből. | ||
| Leírás Ez az attribútum rögzíti, mikor nyerték ki vagy frissítették utoljára az adatokat a process mining adathalmazban. Így látható, mennyire frissek az elemzett adatok. Ez az információ segít a felhasználóknak megítélni, mennyire aktuális a folyamatelemzés. Tisztázza az adatok időszerűségével kapcsolatos elvárásokat, és fontos az adatfrissítések ütemezéséhez és nyomon követéséhez. Miért fontos? Jelzi az adatok frissességét, így a felhasználók tudják, mennyire naprakész a folyamatelemzés. Hol szerezhető be? Az érték minden adatkinyerési és -átalakítási ciklus során jön létre, és ekkor kerül az adathalmazba. Példák 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Üzleti egység BusinessUnitName | Az értékesítési rendelésért felelős belső üzleti egység neve. | ||
| Leírás Ez az attribútum a vállalat azon részlegét vagy működési egységét jelöli, amelyhez a tranzakció tartozik. Lehetővé teszi a szervezet különböző részeinek teljesítmény-összehasonlítását. Az üzleti egység szerinti bontás feltárja a hatékonyság, a költségek és a megfelelés eltéréseit. Az elemzés megmutathatja a jól teljesítő egységek átvehető gyakorlatait, illetve azokat, amelyeknél célzott folyamatfejlesztésre van szükség. Miért fontos? Lehetővé teszi a teljesítmény összehasonlítását és a folyamatok egységességének vizsgálatát a szervezet különböző egységei között. Hol szerezhető be? Általában az értékesítési rendelés fejlécében található, és az Oracle Fusion rendszerben meghatározott szervezeti struktúrához kapcsolódik. Példák BU-North AmericaBU-EMEAGlobal Services | |||
A rendeléstől a pénz beérkezéséig tartó értékesítésirendelés-feldolgozás tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Fizetés beérkezett | Ez a tevékenység azt jelzi, hogy az ügyfél befizetése beérkezett, és a vevőkövetelések között hozzárendelték a számlához. Az esemény akkor rögzül, amikor könyvelik a pénzbevétel számlához rendelését. | ||
| Miért fontos? Ez fontos mérföldkő a „Teljes rendeléstől a pénz beérkezéséig tartó idő” és a „Határidőre fizetett számlák aránya” mérésében. Azt jelzi, hogy az értékesítésből pénzbevétel lett. Hol szerezhető be? Ez kifejezett esemény az Oracle Accounts Receivable rendszerben. A pénzbevételi táblák, például az AR_RECEIVABLE_APPLICATIONS_ALL rögzítik, amikor egy befizetést hozzárendelnek egy számlához. Rögzítés Az AR rendszerben a pénzbevétel számlához rendelését rögzítő rekord „apply date” időbélyegéből származik. Eseménytípus explicit | |||
| Rendelés lezárva | A folyamat utolsó tevékenysége. Azt jelzi, hogy az értékesítési rendelés minden sora teljesült, számlázása megtörtént és lezárult. A rendelés fejlécének állapota „Closed” értékre vált. | ||
| Miért fontos? Ez a tevékenység jelzi az értékesítési rendelés életciklusának sikeres végét. Segítségével kiszámítható a folyamat teljes időtartama, és azonosíthatók azok a beragadt rendelések, amelyek soha nem zárulnak le. Hol szerezhető be? Az esemény a DOO_HEADERS_ALL táblában szereplő értékesítési rendelés fejlécének „Closed” állapotba váltásából következtethető ki. A végső állapotváltozás időbélyege jelöli az esemény időpontját. Rögzítés Az értékesítési rendelés fejlécének „Closed” állapotba váltásakor rögzített időbélyegből származik. Eseménytípus inferred | |||
| Rendelés visszaigazolva | Ez a fontos mérföldkő azt jelzi, hogy a vevői rendelés minden kezdeti ellenőrzésen, köztük a hiteljóváhagyáson is átesett, és teljesítésre vár. Az eseményre általában abból lehet következtetni, hogy a rendelés állapota például „Szállításra vár” vagy „Ütemezve” értékre változik. | ||
| Miért fontos? Ez a tevékenység fontos mérföldkő az „Átlagos rendelés-visszaigazolási idő” kiszámításához, és a rendelésrögzítés, valamint a teljesítés közötti átadást jelöli. Hol szerezhető be? A vevői rendelés fejlécének vagy tételének olyan állapotváltozásából következtethető ki, amely azt jelzi, hogy a rendelés készen áll a teljesítésre, például „Szállításra vár” állapotból. Ellenőrizze a DOO_HEADERS_ALL vagy a DOO_FULFILL_LINES_ALL tábla állapotoszlopait. Rögzítés A rendelés állapotának visszaigazolt vagy ütemezett állapotra váltásakor rögzített időbélyegből származtatható. Eseménytípus inferred | |||
| Számla létrehozva | Ez a tevékenység az ügyfél számlájának létrehozását jelöli a követeléskezelési modulban. A számlázást általában a szállítás visszaigazolása indítja el. A rendszer egyedi számlaszámmal és létrehozási dátummal hozza létre a számlarekordot. | ||
| Miért fontos? Ez jelöli a követelésbeszedési folyamat hivatalos kezdetét. Az „A számla kiállításától a fizetésig eltelt idő” és a teljes pénzforgalmi hatékonyság mérésének alapja. Hol szerezhető be? Az Oracle Accounts Receivable (AR) rendszerben külön eseményként rögzítik. A számlarekord a RA_CUSTOMER_TRX_ALL táblában jön létre, a tranzakció dátumával. Rögzítés Az AR-modulban rögzített számlatranzakció létrehozási dátumából nyerhető ki. Eseménytípus explicit | |||
| Termékek feladva | Ez a tevékenység azt jelöli, hogy a termékek elhagyták a raktárt, és úton vannak az ügyfélhez. Az esemény akkor kerül rögzítésre, amikor az Oracle Shipping rendszerben feldolgozzák a szállítás visszaigazolását. | ||
| Miért fontos? Ez fontos mérföldkő: a folyamat teljesítési szakaszának végét jelzi, és elindítja a számlázást. A határidőre történő feladás és a kézbesítési idő méréséhez is szükséges. Hol szerezhető be? Az Oracle Shipping Execution rendszerben külön eseményként rögzítik. A szállítás visszaigazolásakor a rendszer rekordot hoz létre a szállítási táblákban, például a WSH_DELIVERY_DETAILS táblában, a feladás dátumával. Rögzítés A rendelési tételhez tartozó szállítási részletek rekordjában szereplő „tényleges feladási dátum” időbélyegéből nyerhető ki. Eseménytípus explicit | |||
| Vevői rendelés létrehozva | Ez a tevékenység jelöli a vevői rendelési folyamat kezdetét, vagyis azt a pillanatot, amikor az új rendelést rögzítik az Oracle Fusion rendszerben. Az esemény rendszerint akkor kerül be a naplóba, amikor a felhasználó elmenti az új rendelést az Order Management modulban. | ||
| Miért fontos? A folyamat kezdőpontjaként ez a tevékenység elengedhetetlen az Order to Cash teljes átfutási idejének méréséhez és a beérkező rendelések számának elemzéséhez. Hol szerezhető be? Az esemény rögzítése a vevői rendelés létrehozásakor történik az Order Management Cloud rendszerben. A DOO_HEADERS_ALL táblában keresse a létrehozási időbélyegeket. Rögzítés A vevői rendelés fejlécrekordjának létrehozási időbélyegéből nyerhető ki. Eseménytípus explicit | |||
| Hitelvizsgálat elvégezve | A tevékenység azt jelzi, hogy ellenőrizték az ügyfél hitelképességét. Ez a rendelésfeldolgozási munkafolyamat automatizált vagy manuális lépése lehet. A befejezését általában állapotfrissítés vagy lezárt feladat rögzíti. | ||
| Miért fontos? A hitelvizsgálat idejének elemzésével azonosíthatók a rendelésjóváhagyás szűk keresztmetszetei. Ez a „Hitelvizsgálattól a visszaigazolásig eltelt idő” KPI méréséhez is szükséges. Hol szerezhető be? A vevői rendelés állapotváltozásaiból következtethető ki, például abból, ha a rendelés „Hiteljóváhagyásra vár” állapotba kerül. A hitelkezelési funkció eseménynaplójában külön eseményként is szerepelhet. Rögzítés A rendelés állapotváltozásaiból vagy a hitelvizsgálati feladatokhoz tartozó időbélyegekből következtethető ki. Eseménytípus inferred | |||
| Hitelzárolás beállítva | Ez a tevékenység akkor történik, amikor sikertelen hitelvizsgálat vagy más, hitellel kapcsolatos probléma miatt a vevői rendelést automatikusan vagy manuálisan zárolják. A rendszer ezt általában a rendelés zárolási állapotának változásával rögzíti. | ||
| Miért fontos? A hitelzárolások nyomon követése segít feltárni a rendelésfeldolgozási késedelmek okait, és mérni a zárolásfeloldási folyamat hatékonyságát. Hol szerezhető be? A vevői rendelés zárolásának rögzítéséből következtethető ki. Az eseményt általában a zárolásokhoz kapcsolódó táblák, például a DOO_HOLDS_ALL tartalmazzák, a vevői rendeléshez kapcsolva. Rögzítés A rendelészárolási táblában „Credit” típusú zárolással létrehozott rekordból következtethető ki. Eseménytípus inferred | |||
| Készlet lefoglalva | Ez a tevékenység a vevői rendelés tételének teljesítéséhez szükséges fizikai készlet hozzárendelését vagy lefoglalását jelöli. A rendszer meghatározott készletet rendel a rendeléshez, így az rendelkezésre áll, amikor megkezdődik a komissiózás. | ||
| Miért fontos? A tevékenység nyomon követésével elemezhető a „Készletallokáció átfutási ideje” KPI, és azonosíthatók a rendelés visszaigazolása, valamint a termékek biztosítása közötti késedelmek. Hol szerezhető be? Az eseményt gyakran a készletkezelési vagy ellátásilánc-végrehajtási modulok rögzítik. A teljesítési sor állapotfrissítéséből is következtetni lehet rá, ha az jelzi, hogy a készletet meghatározták vagy lefoglalták. Rögzítés A készlet lefoglalásához vagy ütemezéséhez kapcsolódó teljesítési sor állapotváltozásaiból következtethető ki. Eseménytípus inferred | |||
| Rendelés törölve | Azt jelzi, hogy az értékesítési rendelést a teljes kiszállítás előtt törölték. Erre többféle okból kerülhet sor, a rendelés végső állapota pedig „Cancelled” lesz. | ||
| Miért fontos? Ez egy fontos kivételes folyamatág. A törölt rendelések elemzése segít feltárni a kiváltó okokat, például a készlethiányt, az árazási problémákat vagy azt, ha az ügyfél meggondolta magát. Az eredmények a folyamat fejlesztését is segíthetik. Hol szerezhető be? Az esemény az értékesítési rendelés fejlécének vagy sorának „Cancelled” állapotba váltásából következtethető ki. Az esemény rögzítéséhez az állapotváltozás időbélyegét használja a rendszer. Rögzítés A rendelés fejlécének vagy sorának „Cancelled” állapotba váltásakor rögzített időbélyegből származik. Eseménytípus inferred | |||
| Rendeléssor lezárva | Egy értékesítési rendelés adott sorának végleges lezárását jelzi. A sor teljesítése és számlázása befejeződött, további tranzakció nem várható. A rendszer a sor állapotát „Closed” értékre állítja. | ||
| Miért fontos? A rendelési sor lezárása azt jelzi, hogy az adott tételhez kapcsolódó szerződéses kötelezettségek teljesültek. Az elemzés segít megtalálni azokat a rendeléseket, amelyek a teljesítés és a fizetés után is sokáig nyitva maradnak. Hol szerezhető be? Az esemény a DOO_FULFILL_LINES_ALL táblában szereplő teljesítési sor „Closed” állapotba váltásából következtethető ki. Az állapotváltozás időbélyege jelöli az esemény időpontját. Rögzítés A teljesítési sor „Closed” állapotba váltásának időbélyegéből származik. Eseménytípus inferred | |||
| Számla javítva | Akkor fordul elő, ha egy korábban kiállított számlát hiba vagy ügyfélpanasz miatt módosítanak, újra kiállítanak vagy jóváírnak. Ezt általában jóváíró számla kiállítása vagy a számla új verziójának létrehozása jelzi. | ||
| Miért fontos? A számlakorrekciók nyomon követése alapvető az „Újramunkált számlák aránya” KPI méréséhez. Ez a mutató rávilágít a számlázási folyamat hibáira, amelyek késleltethetik a fizetést és növelhetik az adminisztrációs költségeket. Hol szerezhető be? Az esemény a RA_CUSTOMER_TRX_ALL táblában szereplő, eredeti számlához kapcsolódó jóváíró számla vagy ugyanazon számla későbbi verziója alapján azonosítható. Rögzítés Az esemény olyan jóváíró számlák vagy számlák azonosításával határozható meg, amelyek egy korábbi számlatranzakcióra hivatkoznak. Eseménytípus inferred | |||
| Termékek kézbesítve | Azt jelzi, hogy az ügyfél átvette a küldeményt. Az adat gyakran a külső fuvarozótól érkezik, és az Oracle Fusion rendszerben frissül. Az esemény a feladás dátumától számított szokásos szállítási idő alapján is kikövetkeztethető. | ||
| Miért fontos? Ez a tevékenység elengedhetetlen a „Határidőre történő kézbesítések aránya” KPI kiszámításához és az ügyfélkiszolgálás színvonalának pontos méréséhez. Hol szerezhető be? Ez az esemény gyakran nem része az Oracle alapfunkcióinak. Fuvarozói integráció esetén rögzíthető, vagy a „Termékek feladva” dátumához hozzáadott szokásos szállítási idő alapján számítható ki. A meghatározásához elemezni kell a rendszert. Rögzítés A fuvarozótól érkező adatfolyamokból következtethető ki, vagy a feladás dátuma és az átlagos szállítási idő alapján számítható ki. Eseménytípus inferred | |||
| Termékek komissiózva | A tevékenység a rendelés teljesítéséhez szükséges termékek raktári összegyűjtését jelöli. Ez a logisztikai folyamat fontos lépése, amelyet általában a raktárkezelési vagy szállítási modulban rögzítenek. | ||
| Miért fontos? Ez a tevékenység betekintést ad a raktár működésébe. A készlet lefoglalása és a komissiózás közötti késedelem a raktári erőforrások vagy folyamatok szűk keresztmetszetére utalhat. Hol szerezhető be? Az Oracle Fusion Cloud SCM (Supply Chain Management) moduljaiban rögzítik. A vevői rendelés tételéhez kapcsolódó komissiózási hullám vagy komissiózási jegy állapotváltozásából következtethető ki. Rögzítés Az SCM-modulokban rögzített komissiózási tranzakció befejezési időbélyegéből következtethető ki. Eseménytípus inferred | |||
Adatkinyerési útmutatók
Lépések
- Nyissa meg az Oracle BI Publisher alkalmazást: Jelentkezzen be az Oracle Fusion-környezetbe olyan felhasználóként, aki BI Administrator vagy BI Author jogosultsággal rendelkezik. A Navigator menüben válassza a Tools > Reports and Analytics lehetőséget. A Business Intelligence Catalog megnyitásához kattintson a „Browse Catalog” gombra.
- Hozzon létre új adatmodellt: A BI Catalogban nyissa meg a megfelelő mappát, például Shared Folders > Custom. Kattintson a „New” legördülő menüre, majd válassza a „Data Model” lehetőséget.
- Állítsa be az SQL-lekérdezés adatkészletét: Az adatmodell-szerkesztőben kattintson a „+” ikonra új adatkészlet létrehozásához, majd válassza az „SQL Query” lehetőséget. Megjelenik egy párbeszédpanel. Adjon nevet az adatkészletnek, például „OrderToCash_EventLog”, válassza az „Oracle BI EE” adatforrást, majd az SQL típusánál a „Standard SQL” lehetőséget.
- Adja meg az SQL-lekérdezést: Másolja ki a dokumentum „query” részében található teljes SQL-lekérdezést, és illessze be az SQL Query szövegmezőbe. A lekérdezés tartalmazza a kezdő és záró dátum paramétereit (:p_start_date és :p_end_date), amelyeket a BI Publisher automatikusan felismer.
- Állítsa be az adatmodell tulajdonságait: A lekérdezés beillesztése után kattintson az „OK” gombra. Az adatmodell-szerkesztő bal oldali paneljén nyissa meg a „Properties” részt. Ellenőrizze, hogy az „Include Parameter Tags” be van-e jelölve. Igény szerint a dátumparaméterekhez alapértelmezett értékeket is megadhat.
- Tekintse meg és mentse az adatmodellt: Kattintson a „Data” fülre. Előfordulhat, hogy meg kell adnia a dátumparaméterek értékeit. Teszteléshez válasszon rövid dátumtartományt. Kattintson a „View” gombra az adatok mintájának megtekintéséhez. Ha az adatok megfelelően jelennek meg, mentse az adatmodellt a mentés ikonra kattintva, és adjon neki beszédes nevet, például „OrderToCash_EventLog_DM”.
- Készítsen jelentést az adatmodellből: Az adatmodell mentése után kattintson a jobb felső sarokban található „Create Report” gombra. Ezzel megnyílik a jelentéskészítő varázsló.
- Állítsa be a jelentést: A varázslóban válassza a „Use Data Model” lehetőséget. A varázsló végigvezeti az elrendezés beállításán. Egyszerű CSV-exporthoz válassza a „Table” elrendezést. Húzza az összes oszlopot a táblázatba. Kattintson a „Next” gombra, majd törölje a „Show Grand Totals Row” jelölését. A jelentés mentéséhez kattintson a „Finish” gombra. Adjon neki nevet, például „OrderToCash_EventLog_Report”.
- Futtassa a jelentést: Nyissa meg az újonnan létrehozott jelentést. Adja meg az adatkinyerés kezdő és záró dátumát, vagyis a kívánt dátumtartományt.
- Exportálja az adatokat: A jelentés futása után kattintson a „View” legördülő menüre, és válasszon másik nézetet, például a „View Report” lehetőséget. Keresse meg az „Export” hivatkozást vagy ikont, majd exportformátumként válassza a „CSV” lehetőséget. Ezzel letölti az eseménynapló fájlját.
- Készítse elő a feltöltést: Nyissa meg a letöltött CSV-fájlt. Ellenőrizze, hogy az oszlopfejlécek megfelelnek-e a szükséges attribútumoknak: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate és IsAutomated. A fájl ezután feltölthető a process mining eszközbe.
Konfiguráció
- Felhasználói jogosultságok: Olyan szerepkörrel kell rendelkeznie, amely lehetővé teszi BI Publisher-adatmodellek és jelentések létrehozását, például „BI Administrator” vagy „BI Author” szerepkörrel.
- Adatforrás: A lekérdezés a szabványos „Oracle BI EE” alkalmazás-adatforráshoz készült, amely a tranzakciós adatbázishoz (Fusion Apps) kapcsolódik. Általában nincs szükség külön beállításra.
- Dátumtartomány-paraméterek: A lekérdezés két paramétert használ az adatok szűréséhez: :p_start_date és :p_end_date. Javasoljuk, hogy kezelhető méretű, például 3–6 hónapos kötegekben nyerje ki az adatokat, így elkerülheti a jelentés időtúllépését és a teljesítményproblémákat.
- Szűrés üzleti egység szerint: Az adatkinyerés körének szűkítéséhez adjon meg egy WHERE feltételt a lekérdezés BaseOrders CTE-jében, és szűrjön egy adott Business Unit ID alapján, például: AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Rendeléstípus szerinti szűrés: A BaseOrders CTE-ben a dhead.SOURCE_ORDER_TYPE_CODE mezőre vonatkozó feltétellel meghatározott értékesítésirendelés-típusokra is szűrhet.
- Teljesítmény: Több évet felölelő, nagyon nagy adathalmazoknál ez az egyetlen lekérdezésre épülő megoldás lassú lehet. Futtassa csúcsidőn kívül, vagy bontsa az adatkinyerést kisebb, havi kötegekre. Győződjön meg arról, hogy az adatmodellben nincs bejelölve az „Enable SQL Pruning” tulajdonság, mert ez zavarhatja az összetett UNION-lekérdezések futását.
Példa-lekérdezés sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED' Lépések
- Nyissa meg a BICC konzolt: Jelentkezzen be az Oracle Fusion Applications-példányba olyan felhasználóként, aki rendelkezik a BICC_ADMINISTRATOR szerepkörrel. Nyissa meg a Tools menüt, majd válassza a Business Intelligence Cloud Connector lehetőséget.
- Hozzon létre új adatkinyerési konfigurációt: A BICC konzolon kattintson a Configure External Storage lehetőségre a célhely beállításához. Ez lehet Oracle Universal Content Management (UCM) vagy OCI Object Storage bucket. Ellenőrizze, hogy a kapcsolati adatok és a hitelesítő adatok helyesek-e.
- Indítson új adatkinyerési feladatot: Nyissa meg a Manage Extract Jobs részt. Új feladat létrehozásához kattintson a „+” ikonra. Adjon neki beszédes nevet, például ProcessMind_O2C_SalesOrder_Extract.
- Válassza ki az adattárolókat (PVO-kat): A feladat beállításainál keresse meg és adja hozzá az értékesítési rendelések életciklusának rögzítéséhez szükséges Public View Objects (PVO-kat). Több PVO-t is hozzá kell adnia, köztük ezeket: FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice és FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Állítsa be az egyes PVO-k oszlopait: Minden kiválasztott PVO-nál nyissa meg az Actions menüt, majd válassza a Select Columns lehetőséget. Gondosan válassza ki az eseménynapló létrehozásához szükséges oszlopokat, például a HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate mezőket és a felhasználóazonosítókat. A szükséges oszlopok részletes listáját a lekérdezés jegyzékében találja.
- Állítson be szűrőket a növekményes betöltéshez: Az adatmennyiség kezeléséhez minden PVO-nál szűrjön a LastUpdateDate oszlop alapján. Az első futtatásnál széles dátumtartományt is megadhat. A későbbi, ütemezett futtatásoknál úgy állítsa be a szűrőt, hogy csak az utolsó feladatfuttatás óta frissített rekordokat nyerje ki.
- Ütemezze az adatkinyerési feladatot: Nyissa meg a Manage Schedule részt, és hozzon létre új ütemezést a feladathoz. A rendszer teljesítményére gyakorolt hatás mérséklése érdekében érdemes csúcsidőn kívül, például éjszakánként futtatni a feladatot.
- Küldje be és kövesse nyomon a feladatot: A beállítás után küldje be a feladatot. A Manage Extract Jobs képernyőn követheti az előrehaladását. Sikeres futtatás után az adatfájlok tömörített CSV-formátumban lesznek elérhetők a beállított felhőtárhelyen.
- Alakítsa át a nyers adatokat eseménynaplóvá: Töltse le a kinyert CSV-fájlokat. A BICC nyers táblázatos adatokat ad, nem kész eseménynaplót. A fájlok feldolgozásához külső eszközre, például Pythonra, adatbázis-szkriptre vagy ETL-platformra lesz szüksége. A feldolgozás lépései:
- Egyesítse a különböző fájlok adatait, például kapcsolja össze a számlaadatokat az értékesítési rendelés fejlécével.
- Alakítsa az egyes dátumoszlopokat külön tevékenységsorokká. Például a FscmTopModelAM.DooTopAM.Header fájlból hozzon létre egy „Értékesítési rendelés létrehozva” sort a CreationDate, egy másikat pedig a „Rendelés lezárva” tevékenységhez a ClosedDate alapján.
- A státuszkódokat és jelzőket képezze le konkrét tevékenységekre, például „Rendelés visszaigazolva” vagy „Rendelés törölve”.
- Egyesítse az átalakított adatokat egyetlen, a szükséges oszlopokat tartalmazó fájlba: SalesOrder, ActivityName és EventTime.
- Formázza a feltöltéshez: A végső, átalakított fájl egyetlen CSV legyen, amelynek oszlopai megfelelnek a szükséges és ajánlott attribútumoknak. A fájl ezután feltölthető a ProcessMindbe.
Konfiguráció
- PVO-k kiválasztása: Az eseménynapló pontossága teljes mértékben a megfelelő PVO-k kiválasztásától függ. A fontos PVO-k közé tartozik a FscmTopModelAM.DooTopAM.Header (a rendelések létrehozásához és lezárásához), a FscmTopModelAM.ScmTopAM.ShipmentLine (a szállítási eseményekhez) és a FscmTopModelAM.ArTopAM.ReceivableInvoice (a számlázáshoz).
- Növekményes adatkinyerés: Ismétlődő adatkinyerésnél mindig használja a LastUpdateDate szűrőt. Ez a teljesítmény szempontjából elengedhetetlen, és megakadályozza, hogy újra és újra ugyanazt a több gigabájtos adathalmazt nyerje ki. Az első, teljes betöltés adja meg az alapot, a későbbi futtatások pedig csak a változásokat rögzítsék.
- Dátumtartomány: Az első, korábbi adatokat betöltő futtatásnál válasszon reprezentatív időszakot, például az elmúlt 3–6 hónapot. Így az adatok teljessége és kezelhető mérete egyensúlyban marad. A további futtatások növekményesek lesznek.
- Tárhely beállítása: A BICC Oracle UCM- vagy OCI Object Storage-tárhelyre exportálhat. Tömeges adatkezeléshez és a későbbi ETL-eszközökkel való egyszerűbb integrációhoz általában az OCI Object Storage ajánlott.
- Feladatok ütemezése: Az adatkinyerési feladatokat munkaidőn kívülre ütemezze, hogy ne rontsák az Oracle Fusion Financials tranzakciós rendszerének teljesítményét.
- Előfeltételek: A feladatot beállító felhasználóknak BICC_ADMINISTRATOR szerepkörrel kell rendelkezniük. Előre be kell állítani a felhőtárhely hitelesítő adatait, és ismerni kell az adatkinyerés utáni átalakítási logikát.
Példa-lekérdezés config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filtering Készen áll a kezdésre?
Használja ezt a sablont az adatgyűjtés egyszerűsítéséhez, és kezdje el a process mining használatát. Lássa neki még ma a rendeléstől a pénz beérkezéséig tartó értékesítésirendelés-feldolgozás optimalizálásának.
Optimalizálja még ma az értékesítésirendelés-feldolgozást a rendeléstől a pénz beérkezéséig tartó folyamatban
Azonosítsa a szűk keresztmetszeteket, és csökkentse egyszerűen 30%-kal a rendeléstől a pénz beérkezéséig tartó folyamat átfutási idejét.
Nincs szükség bankkártyára. A próbaverzió 14 napig ingyenes.