Beszerzéstől a fizetésig tartó folyamat: beszerzési igények adatainak sablonja
Beszerzéstől a fizetésig tartó folyamat: beszerzési igények adatainak sablonja
- Javasolt attribútumok a részletes elemzéshez
- A folyamat feltárásához követendő fő tevékenységek
- Útmutató az SAP S/4HANA rendszerből történő adatkinyeréshez
Beszerzéstől a fizetésig tartó folyamat: a beszerzési igények attribútumai
| Név | Leírás | ||
|---|---|---|---|
| Beszerzési igénylés azonosítója PurchaseRequisitionId | A beszerzési igénylés dokumentumának egyedi azonosítója. | ||
| Leírás A beszerzési igénylés azonosítója az SAP S/4HANA rendszerben az árukra vagy szolgáltatásokra vonatkozó egyes igények elsődleges kulcsa. Ezzel az azonosítóval kapcsolható össze az adott igényléshez tartozó összes tevékenység és módosítás a létrehozástól a végső állapotig, például a jóváhagyásig, az elutasításig vagy a beszerzési megrendeléssé alakításig. A process mining során ez az attribútum alapvető az egyes igénylések teljes életciklusának rekonstruálásához. Ha az elemzők minden kapcsolódó eseményt egyetlen beszerzési igénylésazonosító alá rendeznek, pontosan mérhetik az átfutási időt, követhetik az állapotváltozásokat, és elemezhetik az igénylés jóváhagyási folyamatának különböző útvonalait. Miért fontos? Ez az alapvető ügyazonosító kapcsolja össze a folyamat összes kapcsolódó lépését, így az igénylés teljes életciklusa egységesen áttekinthető. Hol szerezhető be? Ez az attribútum a beszerzési igénylés száma, amely az EBAN tábla BANFN mezőjében található. Példák 100178901001789110017892 | |||
| Esemény időpontja EventTime | Az adott tevékenység pontos dátuma és időpontja. | ||
| Leírás Az esemény időpontja az a dátum és idő, amely rögzíti, mikor történt egy tevékenység. Ez az adat szükséges az ügyön belüli események időrendi sorrendjének meghatározásához, és a process mining során minden időtartam- és teljesítményszámítás alapja. Például az „Igénylés jóváhagyásra benyújtva” és az „Igénylés jóváhagyva” esemény közötti idő adja a jóváhagyási átfutási időt. A pontos időbélyegek nélkülözhetetlenek a folyamat teljesítményének elemzéséhez, a késedelmek feltárásához és a szolgáltatási szintre vonatkozó megállapodások betartásának nyomon követéséhez. Ezzel az attribútummal olyan dashboardok készíthetők, amelyek megjelenítik az átfutási időket, követik az elakadt igényléseket, és összehasonlítják a különböző időszakok teljesítményét. Miért fontos? Ez az időbélyeg szükséges az események sorrendjének meghatározásához, az átfutási idők kiszámításához, valamint a folyamat teljesítményének és szűk keresztmetszeteinek elemzéséhez. Hol szerezhető be? Az időbélyegek jellemzően a módosítási dokumentumok fejléceiből (CDHDR-UDATE, CDHDR-UTIME) vagy a munkafolyamat eseménynaplóiból származnak. Példák 2023-04-15T10:05:30Z2023-04-15T14:22:01Z2023-04-16T09:00:15Z | |||
| Tevékenység neve ActivityName | Az igénylési folyamat egy adott pontján végrehajtott üzleti tevékenység neve. | ||
| Leírás A tevékenység neve a beszerzési igénylés életciklusa során bekövetkezett eseményt vagy végrehajtott feladatot jelöli. Ezek a tevékenységek rendszerint a rendszernaplókból, például a módosítási dokumentumokból és a munkafolyamatok előzményeiből származnak. Olyan fontos mérföldköveket jelölnek, mint az „Igénylés létrehozva”, a „Jóváhagyási lépés elindult” vagy a „Beszerzési megrendelés létrehozva”. A tevékenységek elemzésével megjeleníthető a folyamat menete, feltárhatók a szűk keresztmetszetek, és mérhető az egyes szakaszok időtartama. Az olyan tevékenységek sorrendjének és gyakoriságának megértése, mint az „Igénylés módosítva” vagy az „Igénylés elutasítva”, segít feltárni a folyamat hatékonysági problémáit és a fejlesztési lehetőségeket. Miért fontos? Meghatározza a folyamat lépéseit, ezek adják a folyamattérkép alapját, és lehetővé teszik a folyamat menetének, eltéréseinek és szűk keresztmetszeteinek elemzését. Hol szerezhető be? Származtatott attribútum, amelyet jellemzően a módosítási dokumentumok (CDHDR, CDPOS) és a munkafolyamat-naplók (például SWWLOGHIST) értelmezésével állítanak elő. Példák Igénylés létrehozvaJóváhagyási lépés befejeződöttIgénylés jóváhagyvaBeszerzési megrendelés létrehozva | |||
| Felhasználói azonosító UserId | Az igénylést létrehozó vagy egy adott tevékenységet végrehajtó felhasználó azonosítója. | ||
| Leírás A felhasználói azonosító megmutatja, melyik munkatárs vagy rendszerfelhasználó felelős az igénylés életciklusának egy adott eseményéért. Ez lehet az igénylést létrehozó személy, a jóváhagyó vezető vagy a módosítást végző ügyintéző. Automatizált lépéseknél rendszer- vagy kötegelt feldolgozást végző felhasználó azonosítója is szerepelhet. A felhasználói azonosító szerinti elemzés segít megérteni az egyéni munkavégzést, a munkaterhelés eloszlását és a teljesítményt. Segítségével feltárhatók a képzési igények, azonosíthatók a kiemelkedően teljesítő munkatársak, és biztosítható az elszámoltathatóság. A felhasználói törzsadatokkal kombinálva a részlegek teljesítménye is elemezhető. Miért fontos? Lehetővé teszi a felhasználói teljesítmény, a munkaterhelés eloszlása és a folyamat szabályoknak való megfelelésének elemzését. Segít feltárni a képzési lehetőségeket és az erőforrások szűk keresztmetszeteit. Hol szerezhető be? A létrehozó azonosítója az EBAN-ERNAM mezőben található. A későbbi módosításoknál a CDHDR-USERNAME mezőben, a jóváhagyásoknál pedig a munkafolyamat-naplókban szerepel. Példák JSMITHRROEWF-BATCH | |||
| Igénylés állapota RequisitionStatus | A beszerzési igénylés aktuális feldolgozási vagy jóváhagyási állapota. | ||
| Leírás Az igénylés állapota megmutatja, hol tart az igénylés az életciklusában. Az SAP-ban ezt gyakran a jóváhagyási jelző képviseli, amely jelzi, hogy az igénylés zárolt, jóváhagyás alatt áll, részben vagy teljesen jóváhagyott. Az állapot a munkafolyamat előrehaladtával változik. Az állapot időbeli követése alapvető a folyamat menetének megértéséhez. Segít feltárni, hol és mennyi időre akadnak el az igénylések. Az állapotváltozások elemzésével részletesen áttekinthető a jóváhagyási folyamat és annak különböző változatai. Miért fontos? Megmutatja az igénylés aktuális állapotát, ami nélkülözhetetlen az előrehaladás követéséhez, a szűk keresztmetszetek feltárásához és a folyamat menetének elemzéséhez. Hol szerezhető be? A jóváhagyási állapotot gyakran az EBAN tábla FRGZU mezőjében található jóváhagyási jelző határozza meg. Példák B1S | |||
| Igénylés összege RequisitionAmount | A beszerzési igénylés teljes pénzértéke. | ||
| Leírás Az igénylés összege a kért áruk vagy szolgáltatások becsült teljes költségét jelöli. Ez az érték gyakran meghatározza a jóváhagyási munkafolyamat összetettségét és hosszát. A nagyobb értékű igénylésekhez jellemzően több jóváhagyási szint szükséges. Az attribútum alapján az igénylések érték szerint csoportosíthatók. Segítségével megválaszolhatók például ezek a kérdések: „A nagy értékű igénylések jóváhagyása tovább tart?” vagy „Mekkora az értéke a gyakran elutasított igényléseknek?” Ez fontos szempont a folyamat hatékonysági problémáinak pénzügyi hatásának megértéséhez. Miért fontos? Segít a folyamat pénzügyi hatás szerinti csoportosításában, amely gyakran összefügg a jóváhagyás összetettségével és az átfutási idővel. Nélkülözhetetlen az érték szerinti folyamatelemzéshez. Hol szerezhető be? A teljes érték az EBAN tábla GFWERT mezőjében található. A tételszintű érték az EBAN-PREIS mezőben szerepel. Példák 1500.0075000.50250.75 | |||
| Igénylés típusa RequisitionType | A beszerzési igénylést besoroló kód, például normál tételek, szolgáltatások vagy beruházások esetén. | ||
| Leírás Az igénylés típusa, amelyet az SAP dokumentumtípusnak is nevez, a beszerzési igényléseket kategorizáló fontos beállítási mező. A különböző típusokhoz eltérő jóváhagyási munkafolyamatok és mezőbeállítások tartozhatnak. A típusok különböző üzleti célokat szolgálnak, például készleten tartott áruk, külső szolgáltatások vagy eszközbeszerzések igénylését. Az igénylés típusa szerinti elemzéssel megérthető, hogyan kezelik a különböző igényeket. Összehasonlíthatók a kategóriák teljesítménye, átfutási ideje és jóváhagyási útvonalai. Így kiderülhet, hogy egyes igényléstípusok hatékonyabban működnek-e, és a folyamatfejlesztés is az adott típushoz igazítható. Miért fontos? Kategóriákba sorolja az igényléseket, így összehasonlítható, hogy az egyes igénytípusokhoz eltérő folyamatmenet, szűk keresztmetszet vagy átfutási idő tartozik-e. Hol szerezhető be? Ez a dokumentumtípus mező, amely az EBAN tábla BSART mezőjében található. Példák NBFORV | |||
| Jóváhagyó azonosítója ApproverId | A jóváhagyási vagy elutasítási lépést végrehajtó felhasználó azonosítója. | ||
| Leírás A jóváhagyó azonosítója annak a felhasználónak az azonosítója, aki jóváhagyási vagy elutasítási tevékenységet végzett. Az általános felhasználói azonosítótól eltérően kizárólag a jóváhagyási munkafolyamat döntéshozóit jelöli. Ez az adat nélkülözhetetlen a jóváhagyási folyamat részletes elemzéséhez. Az attribútum alapján elemezhető a jóváhagyók munkája, például azonosíthatók a lassan döntő vezetők vagy azok, akik gyakran utasítanak el igényléseket. A jóváhagyási lépések átfutási idejét és a munkafolyamat szűk keresztmetszeteit bemutató dashboardok alapadata. Segít feltárni, hogy mely személyek vagy szerepkörök okozhatnak késedelmet. Miért fontos? Megmutatja, ki hozta meg a döntést az adott jóváhagyási lépésben, így személyenként vagy szerepkörönként elemezhetők a jóváhagyási átfutási idők és a szűk keresztmetszetek. Hol szerezhető be? Az adat jellemzően az SAP Business Workflow tábláiból, például az SWW_WI2OBJ és az SWWLOGHIST táblákból nyerhető ki. Ezek a munkaelemeket összekapcsolják az azokat lezáró felhasználóval. Példák MJOHNSONCWILLIAMSLBLACK | |||
| Részleg Department | Az a részleg vagy költséghely, amelyre az igénylés költségeit terhelik. | ||
| Leírás A részleg attribútum, amelyet az SAP-ban gyakran a költséghely képvisel, azonosítja a kért beszerzésért felelős üzleti egységet. Fontos pénzügyi és szervezeti adat, amelyet az igénylés tételszintjén rendelnek hozzá. A process mining során ez az attribútum nélkülözhetetlen a részlegek teljesítményének elemzéséhez. Olyan dashboardok készíthetők vele, amelyek összehasonlítják a fő mutatókat, például az átfutási időt, a módosítások és az elutasítások arányát a különböző részlegek között. Így azonosíthatók azok a részlegek, amelyek bevált gyakorlata máshol is alkalmazható, valamint azok, amelyeknek további képzésre vagy folyamattámogatásra lehet szükségük. Miért fontos? Lehetővé teszi az üzleti egységek teljesítményének összehasonlítását. Az átfutási idők vagy az elutasítások arányának eltérései alapján feltárhatók a bevált gyakorlatok és a fejlesztendő területek. Hol szerezhető be? Ez a költséghely, amely jellemzően a számlakijelölési EBKN tábla KOSTL mezőjében található. Példák FIN-1001IT-2005MKT-3010 | |||
| Átdolgozás jelzője IsRework | Jelzi, hogy egy tevékenység átdolgozásnak számít-e, például a benyújtás utáni módosítás. | ||
| Leírás Az Is Rework egy számított logikai jelző, amely azonosítja a hozzáadott értéket nem teremtő vagy ismétlődő munkát jelentő tevékenységeket. Gyakori példa erre a „Beszerzési igény módosítva” tevékenység, amely az igény jóváhagyásra történő benyújtása után következik be, és emiatt újra kell indítani a jóváhagyást. Ez az attribútum szükséges a folyamatban végzett átdolgozás mennyiségének és az átfutási időre gyakorolt hatásának méréséhez. A Beszerzési igény módosítása és az átdolgozási arány dashboard ezt a jelzőt használja a folyamat hatékonysági problémáinak feltárására. A folyamatfejlesztési kezdeményezések egyik gyakori célja az átdolgozás csökkentése, mert ezzel közvetlenül időt és energiát lehet megtakarítani. Miért fontos? Jelzi az elvesztegetett munkát vagy ismétlést jelentő tevékenységeket, így közvetlenül mérhető az átdolgozás mértéke és annak hatása a folyamat hatékonyságára. Hol szerezhető be? Számított attribútum. A logika általában minden olyan „Beszerzési igény módosítva” tevékenységet átdolgozásként jelöl, amely az első „Beszerzési igény jóváhagyásra benyújtva” tevékenység után történik. Példák truefalse | |||
| Automatizált IsAutomated | Jelző, amely megmutatja, hogy a tevékenységet rendszerfelhasználó vagy személy hajtotta-e végre. | ||
| Leírás Az Is Automated attribútum logikai értékű jelző. Akkor igaz, ha egy tevékenységet rendszerfelhasználó vagy kötegelt felhasználó hajtott végre, például a workflow-műveleteknél használt „WF-BATCH”. Segítségével megkülönböztethetők a folyamat manuális és automatizált lépései. Ez az attribútum elengedhetetlen a beszerzési igénylési folyamat automatizáltságának méréséhez és az „Automatizált jóváhagyási arány” KPI kiszámításához. Az automatizált és manuális lépések szűrésével az elemzők összehasonlíthatják a hatékonyságukat, és azonosíthatják, hol érdemes tovább automatizálni a feldolgozási idő és a manuális munka csökkentése érdekében. Miért fontos? Megkülönbözteti az emberi és a rendszer által végzett tevékenységeket. Ez fontos az automatizáltság méréséhez és a manuális feladatok automatizálási lehetőségeinek feltárásához. Hol szerezhető be? Származtatott attribútum, amely általában egy olyan szabályon alapul, amely ellenőrzi, hogy az esemény User ID értéke szerepel-e az ismert rendszer- vagy kötegelt felhasználók listáján. Példák truefalse | |||
| Befejezés időpontja EndTime | Az a pontos dátum és időpont, amikor egy adott tevékenység befejeződött. | ||
| Leírás Az EndTime időbélyeg rögzíti, mikor fejeződött be egy tevékenység. Sok rendszer által generált esemény azonnali, vagyis a StartTime és az EndTime megegyezik. Az emberi feladatok, például a jóváhagyások esetében viszont eltérhet a kezdési és a befejezési időpont. Ez az időbélyeg jelöli a munka végét. A külön EndTime segítségével pontosabban mérhető az aktív feldolgozási idő és a tétlen várakozási idő. A ProcessingTime mutató kiszámításához a StartTime értékkel együtt használható. Ez a részletesség javítja a manuális feladatok erőforrás-felhasználásának és hatékonyságának elemzését. Miért fontos? Jelzi a tevékenység befejezését, így kiszámítható az aktív feldolgozási idő, és részletesebben elemezhető a feladat időtartama. Hol szerezhető be? Workflow-naplókból származik, amelyek rögzíthetik a munkaelem létrehozásának (StartTime) és befejezésének (EndTime) időpontját. Példák 2023-04-15T10:20:30Z2023-04-15T14:25:01Z2023-04-16T11:00:45Z | |||
| Beszerzési megrendelés száma PurchaseOrderNumber | Az igénylésből létrehozott beszerzési megrendelés száma. | ||
| Leírás A beszerzési megrendelés száma az a hivatalos beszerzési dokumentumot azonosítja, amelyet egy jóváhagyott igénylés alapján hoztak létre. A beszerzési megrendelés létrehozása gyakran az igénylés sikeres lezárását jelenti: a kérést hivatalos, szállítónak szóló megrendeléssé alakították. Ez az attribútum nélkülözhetetlen az igényléstől a beszerzési megrendelésig tartó átfutási idő KPI-jának és az átalakítási aránynak a méréséhez. Összekapcsolja az igénylési folyamatot a további beszerzési folyamattal, így a teljes beszerzéstől a fizetésig tartó folyamat is áttekinthető. Miért fontos? Összekapcsolja az igénylést a következő beszerzési dokumentummal, így mérhető az igénylésből megrendeléssé alakítás aránya és átfutási ideje. Hol szerezhető be? Az EBAN tábla EBELN mezőjében található, miután az igénylési tételből beszerzési megrendelés jött létre. Példák 450001789045000178914500017892 | |||
| Elutasítás oka RejectionReason | A beszerzési igénylés elutasításakor megadott indok. | ||
| Leírás Az elutasítás oka megmagyarázza, miért utasította el a jóváhagyó a beszerzési igénylést. Ilyen ok lehet például a költségkeret túllépése, a hibás adat, a szabályzatnak való meg nem felelés vagy egy másik igényléssel való átfedés. Ez az adat segít megérteni, miért nem sikerült a folyamat. Az elutasítási okok elemzésével feltárhatók a folyamat hatékonysági problémáinak és az újramunkálásnak a kiváltó okai. Ha például gyakori indok a „Hibás költséghely”, az további felhasználói képzés vagy rendszeres ellenőrzés szükségességére utal. Ez az attribútum a beszerzési igénylések elutasítását elemző dashboard alapja, és célzott folyamatfejlesztéshez is nélkülözhetetlen. Miért fontos? Feltárja a folyamat sikertelenségének kiváltó okát, így célzott fejlesztésekkel csökkenthető az újramunkálás, és növelhető az elsőre helyesen benyújtott igénylések aránya. Hol szerezhető be? Ez gyakran nem szabványos mező. Az adat a munkafolyamat konténerelemeiben, az igényléshez kapcsolódó hosszú szövegben vagy egyéni mezőkben szerepelhet. Példák Költségkeret túllépéseHibás szállítóDuplikált igénylés | |||
| Forrásrendszer SourceSystem | Azonosítja azt az SAP S/4HANA-példányt, amelyből az adatokat kinyerték. | ||
| Leírás A forrásrendszer attribútum azt a rendszert jelöli, amelyben a folyamatadatok keletkeztek. Ha egy szervezet több SAP-példányt használ, például fejlesztési, minőségbiztosítási és éles rendszereket, vagy külön rendszereket az egyes régiókban, ez a mező fontos az adatok kezeléséhez és értelmezéséhez. Segítségével megkülönböztethetők a különböző forrásokból származó adatok, így elkerülhető a hibás összesítés, és rendszerenként is elvégezhető az elemzés. Az adatútvonal nyomon követéséhez és a folyamatadatok eredetének visszakövethetőségéhez kötelező attribútum. Miért fontos? Megadja az adatok eredetének és kezelésének értelmezéséhez szükséges hátteret. Több rendszer használatakor az adatok visszakövethetőségét is biztosítja. Hol szerezhető be? Ez jellemzően az SAP rendszerazonosítója (SID), amely rendszer-változókból vagy konfigurációs táblákból kérdezhető le. Példák S4PECCS4H_PROD_01 | |||
| Jóváhagyási lépés neve ApprovalStepName | A workflow egy adott jóváhagyási lépésének neve vagy leírása. | ||
| Leírás A Jóváhagyási lépés neve közérthetően megnevezi a jóváhagyási workflow egy adott szakaszát, például „Vezetői jóváhagyás” vagy „Pénzügyi alelnöki jóváhagyás”. Ez pontosabb leírás, mint az általános „Jóváhagyási lépés befejezve” tevékenység. Ez az attribútum szükséges a Jóváhagyási lépés átfutási ideje és a Workflow szűk keresztmetszeteinek elemzése dashboardokhoz. Részletes képet ad a jóváhagyási folyamatról, így pontosan megállapítható, mely szakaszok okozzák a legnagyobb késedelmet, és hol torlódik fel a munka. Ez a részletesség teszi lehetővé, hogy célzottan lehessen beavatkozni és egyszerűsíteni a jóváhagyási láncot. Miért fontos? Részletesen bemutatja a jóváhagyási szakaszokat, így pontosan azonosíthatók a többszintű jóváhagyási workflow szűk keresztmetszetei. Hol szerezhető be? Az adat a workflow-feladat leírásából származik. Ez a workflow-napló és a feladatdefiníciós táblák, például a T528T összekapcsolásával érhető el. Példák Vezetői jóváhagyásIgazgatói jóváhagyásPénzügyi alelnöki jóváhagyás | |||
| Kért teljesítési dátum RequiredByDate | Az a dátum, ameddig az igénylőnek szüksége van a kért árukra vagy szolgáltatásokra. | ||
| Leírás A kért teljesítési dátum, amelyet az SAP-ban szállítási dátumnak neveznek, megadja, mikorra van szükség az igénylési tételben szereplő árukra vagy szolgáltatásokra. Ezt a dátumot az igénylő határozza meg, és a teljes beszerzési folyamat célidőpontjaként szolgál. Ez az attribútum szükséges a határidőre teljesített igénylések arányát mérő KPI kiszámításához. A kért teljesítési dátum és a végső jóváhagyás vagy a beszerzési megrendelés létrehozásának dátuma összevetésével mérhető, hogy a szervezet mennyire tudja teljesíteni a belső szolgáltatási szinteket és az üzleti igényeket. A dátumot elmulasztó igénylések elemzése feltárhatja a beszerzési folyamat rendszeres késedelmeit. Miért fontos? Meghatározza az igénylés teljesítésének célidőpontját, így mérhető a határidőre történő teljesítés és a belső szolgáltatási szintek betartása. Hol szerezhető be? Ez a szállítási dátum, amely az EBAN tábla tételszintű LFDAT mezőjében található. Példák 2023-11-152023-12-012024-01-20 | |||
| Pénznem Currency | Az igénylés összegének pénznemkódja. | ||
| Leírás Ez az attribútum adja meg, milyen pénznemben szerepel az igénylés összege, például USD, EUR vagy JPY. Az igénylés összegének értelmezéséhez szükséges, különösen a több pénznemet használó nemzetközi szervezeteknél. A pontos pénzügyi elemzéshez és jelentéskészítéshez figyelembe kell venni a pénznemet. Az igénylések értékének összesítésekor vagy összehasonlításakor minden összeget közös pénznemre kell átváltani, hogy az eredmények összevethetők legyenek. Ehhez szükség van erre az attribútumra. Miért fontos? Értelmezhetővé teszi az igénylés összegét, és lehetővé teszi a pontos pénzügyi elemzést, valamint az összehasonlítást több pénznem használata esetén. Hol szerezhető be? Az EBAN tábla WAERS mezőjében található. Példák USDEURGBP | |||
| Sürgősségi szint UrgencyLevel | A beszerzési igény sürgősségének besorolása, amely befolyásolhatja a feldolgozás prioritását. | ||
| Leírás A Sürgősségi szint a beszerzési igény prioritását jelzi. Bár erre nincs külön szabványos mező, egyes szervezetek például a Requirement Tracking Number mezőt használják az adat rögzítésére. Így az igénylők jelezhetik, ha egy kritikus igény gyorsított feldolgozást kíván. A sürgősség hatásának elemzésével ellenőrizhető, hogy a folyamat valóban előnyben részesíti-e a kritikus igényeket. A Sürgősségi szint hatáselemzése dashboard ezt az attribútumot használja a sürgős és a normál igények átfutási idejének és jóváhagyási arányának összehasonlítására. Az eredményekből kiderül, hogy a prioritásos kezelés a kívánt módon működik-e. Miért fontos? Megmutatja, hogyan tér el a folyamat teljesítménye a magas prioritású igényeknél, így ellenőrizhető, hogy a sürgős tételek valóban gyorsabban haladnak-e. Hol szerezhető be? Nincs szabványos sürgősségi mező. Egyes vállalatok erre a célra a Requirement Tracking Number (EBAN-BEDAR) mezőt használják. Egyedi mező is szolgálhat erre. Példák MagasKözepesAlacsony | |||
| Utolsó adatfrissítés LastDataUpdate | Az időbélyeg azt mutatja, mikor frissítették utoljára a rekord adatait a forrásrendszerből. | ||
| Leírás Ez az attribútum rögzíti a forrásrendszerből végzett legutóbbi adatkinyerés vagy frissítés dátumát és időpontját. Fontos metaadat, mert megmutatja, mennyire frissek az elemzett adatok. Az elemzők és az üzleti felhasználók ebből látják, hogy a folyamatadatok a működés legfrissebb állapotát tükrözik-e. A megalapozott döntésekhez tudni kell, mennyire aktuálisak az adatok. Ez az attribútum segít kezelni a felhasználói elvárásokat, és biztosítja, hogy az elemzés következtetései az adott célhoz kellően friss adatokon alapuljanak. Miért fontos? Jelzi az adatok frissességét, ami szükséges az elemzés megbízhatóságához és az időben meghozott üzleti döntésekhez. Hol szerezhető be? Ezt az időbélyeget az adatkinyerés, -átalakítás és -betöltés (ETL) során állítják elő és adják hozzá az adatokhoz. Példák 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
Beszerzéstől a fizetésig tartó folyamat: a beszerzési igények tevékenységei
| Tevékenység | Leírás | ||
|---|---|---|---|
| Beszerzési megrendelés létrehozva | Azt jelzi, hogy az igénylési tételre hivatkozó beszerzési megrendelés jött létre. Ezt a rendszer közvetlenül rögzíti, és az esemény összekapcsolja az igénylést a következő beszerzési dokumentummal. | ||
| Miért fontos? Ez fontos mérföldkő és az igénylési folyamat sikeres eredménye. Az igénylés jóváhagyása és a beszerzési megrendelés létrehozása közötti idő fontos KPI a beszerzés hatékonyságának mérésére. Hol szerezhető be? Az esemény közvetlenül rögzül a beszerzési megrendelés tételének létrehozásakor. A kapcsolatot az EKPO tábla (beszerzési megrendelés tétele) tárolja, amely tartalmazza a forrásigénylés számát (BANFN) és tételszámát (BNFPO). Rögzítés Kapcsolja össze az EKPO táblát az EBAN táblával az igénylés száma és tétele alapján. Az esemény időpontját a megrendeléstétel létrehozási dátuma adja. Eseménytípus explicit | |||
| Igénylés elutasítva | A beszerzési igénylés jóváhagyó általi végleges elutasítását jelzi, amely leállítja a folyamatot. Az eseményt egy elutasítást jelző állapotváltozás rögzíti. | ||
| Miért fontos? Ez a folyamat sikertelen lezárását jelzi. Az elutasítások gyakoriságának, okainak és folyamatbeli helyének elemzésével feltárhatók a szabályzatnak való megfeleléssel, a költségkerettel vagy az igénylés minőségével kapcsolatos problémák. Hol szerezhető be? Az EBAN táblában bekövetkező állapotváltozásból következtethető ki. A feldolgozási állapot (PROCSTAT) vagy egy jóváhagyási jelző olyan értéket kap, amely egyértelműen az „Elutasítva” állapotot jelenti. Rögzítés A módosítási dokumentumok alapján azonosítsa azt az időpontot, amikor az EBAN tábla általános állapota „Elutasítva” értékre változik. Eseménytípus inferred | |||
| Igénylés jóváhagyva | A beszerzési igénylés végleges és teljes jóváhagyását jelzi. Ettől kezdve az igénylés beszerzési megrendeléssé alakítható. Ez a mérföldkő akkor állapítható meg, amikor az általános jóváhagyási állapot eléri a végleges, jóváhagyott értéket. | ||
| Miért fontos? Ez fontos sikermérföldkő, és az átfutásiidő-elemzés gyakori végpontja. Azt jelzi, hogy az igénylés minden ellenőrzésen átment, és a beszerzési részleg feldolgozhatja. Hol szerezhető be? Az EBAN táblában bekövetkező állapotváltozásból következtethető ki, különösen akkor, ha az általános jóváhagyási jelző (FRGZU) vagy a feldolgozási állapot (PROCSTAT) végleges, „Jóváhagyva” értékre változik. Rögzítés Azonosítsa azt az időpontot, amikor beállítják az utolsó jóváhagyási kódot, vagy az igénylés általános állapota „Jóváhagyva” értékre változik. Eseménytípus inferred | |||
| Igénylés létrehozva | A beszerzési igénylés dokumentumának első létrehozását jelzi a rendszerben. Az esemény akkor rögzül, amikor a felhasználó először menti az új igénylést, a létrehozás időpontjával együtt. | ||
| Miért fontos? Ez a tevékenység az igénylés életciklusának elemzési kezdőpontja. Segítségével mérhető a teljes átfutási idő az igény felmerülésétől a végső jóváhagyásig vagy a beszerzési megrendeléssé alakításig. Hol szerezhető be? Ez az esemény közvetlenül az EBAN táblából származik. Az adott beszerzési igénylés számához (BANFN) tartozó létrehozási dátum (ERDAT) és időpont (ERZEIT) rögzíti. Rögzítés Minden igénylésnél (BANFN) használja az EBAN tábla létrehozási időpontot tartalmazó mezőit (ERDAT, ERZEIT). Eseménytípus explicit | |||
| Igénylés lezárva | Azt jelzi, hogy az igénylési tétel feldolgozása befejeződött, és abból már nem hozható létre további beszerzési megrendelés. Az állapot általában automatikusan beáll, amikor a teljes mennyiséget megrendelték. | ||
| Miért fontos? Ez a tevékenység az igénylési tétel életciklusának sikeres lezárását jelzi. Megerősíti, hogy az üzleti igény teljes egészében beszerzési megrendeléssé alakult. Hol szerezhető be? Az EBAN táblából következtethető ki. Akkor történik, amikor beállítják a lezárás jelzőjét (EBAKZ), jellemzően akkor, ha a beszerzési megrendelésekben szereplő mennyiség eléri az igénylés mennyiségét. Rögzítés A módosítási dokumentumok alapján keresse meg azt az eseményt, amikor az EBAN táblában beállítják a lezárás jelzőjét (EBAKZ). Eseménytípus inferred | |||
| Jóváhagyási lépés befejeződött | Akkor történik, amikor a jóváhagyó pozitív döntést hoz az igénylésről, és ezzel lezárja a többszintű jóváhagyási munkafolyamat egyik lépését. Ez az igénylés jóváhagyási állapotának változásából következtethető ki. | ||
| Miért fontos? Ez a tevékenység lehetővé teszi a jóváhagyási munkafolyamat részletes elemzését, és az egyes lépések időtartamának mérését. Segít megkülönböztetni a gyors jóváhagyókat a folyamat szűk keresztmetszeteitől. Hol szerezhető be? Az EBAN táblához tartozó módosítási dokumentumokból (CDHDR/CDPOS) következtethető ki. Az eseményt az jelzi, ha egy adott jóváhagyási kód állapota a mezőben (például FRGZU) nem jóváhagyottról jóváhagyottra változik. Rögzítés Kövesse az EBAN tábla jóváhagyási állapotot tartalmazó mezőinek változásait a stratégiában meghatározott minden jóváhagyási kódnál. Eseménytípus inferred | |||
| Beszerzési forrás hozzárendelve | Azt jelzi, amikor a beszerző konkrét szállítót, szerződést vagy információs rekordot rendel egy jóváhagyott igénylési tételhez. Ez fontos lépés az igénylés beszerzési megrendeléssé alakítása előtt. | ||
| Miért fontos? Ez a tevékenység köti össze a jóváhagyást a megrendeléssel. A beszerzési forrás hozzárendeléséhez szükséges idő mérése segít feltárni a beszerzői munkaterhelésből és a beszerzési forrás kiválasztásából eredő késedelmeket. Hol szerezhető be? Az EBAN tábla beszerzési forráshoz kapcsolódó mezőinek kitöltéséből következtethető ki, például a rögzített szállító (LIFNR), az információs rekord (INFNR) vagy a szerződés (KONNR) megadásából. Rögzítés Kövesse az EBAN táblában az olyan mezők kitöltését, mint a LIFNR, az INFNR vagy a KONNR, a módosítási dokumentumok alapján. Eseménytípus inferred | |||
| Igénylés jóváhagyásra benyújtva | Azt az időpontot jelzi, amikor az igénylő hivatalosan benyújtja az igénylést, és ezzel elindítja a jóváhagyási munkafolyamatot. Ez általában abból állapítható meg, hogy meghatározzák az igénylés jóváhagyási stratégiáját, és az állapota „Jóváhagyás alatt” értékre változik. | ||
| Miért fontos? Ez a mérföldkő indítja el a jóváhagyási átfutási idő KPI-jának mérését. A létrehozás és a benyújtás közötti idő elemzésével feltárhatók az igénylés előkészítési szakaszának késedelmei. Hol szerezhető be? Az EBAN táblához tartozó módosítási dokumentumokból (CDHDR/CDPOS) következtethető ki, különösen akkor, ha kitöltik a jóváhagyási stratégia mezőit (például FRGST), vagy az általános állapot (PROCSTAT) jóváhagyás alatti állapotra változik. Rögzítés Keresse meg az első olyan módosítási dokumentumot, amely a jóváhagyási munkafolyamat kezdetét vagy az állapot „Jóváhagyás alatt” értékre változását jelzi. Eseménytípus inferred | |||
| Igénylés módosítva | Akkor történik, amikor a felhasználó az igénylés létrehozása után módosít egy fontos mezőt, például a mennyiséget, az árat vagy az anyagot. A műveletet az SAP módosítási dokumentumai rögzítik. | ||
| Miért fontos? A módosítások követése segít feltárni az újramunkálási köröket és azok hatását az átfutási időre. A gyakori módosítások adatminőségi problémákra vagy változó igényekre utalhatnak. Ezek a folyamatfejlesztés fontos területei. Hol szerezhető be? Az EBAN táblán végzett módosításokat az SAP módosítási dokumentumai (CDHDR és CDPOS) rögzítik. Minden követett mező módosítása külön bejegyzést hoz létre. Rögzítés Nyerje ki a CDHDR/CDPOS táblákból azokat a módosítási eseményeket, amelyeknél a beszerzési igénylések objektumosztálya BANF. Eseménytípus explicit | |||
| Igénylés visszavonva | Akkor történik, amikor az eredeti igénylő a teljes feldolgozás előtt visszavonja vagy törli az igénylést. Ez általában kifejezett művelet, amely törlési jelzőt állít be az igénylés tételénél. | ||
| Miért fontos? A visszavonások követése segít megérteni az igények változását és a lemondások okait. Az igénylés ezzel végleges állapotba kerül, és nem dolgozható fel tovább. Hol szerezhető be? Az esemény közvetlenül rögzül, amikor az EBAN tábla igénylési tételénél beállítják a törlési jelzőt (LOEKZ). A módosítást a CDHDR/CDPOS naplózza. Rögzítés Keresse meg azt az eseményt, amikor az EBAN tábla törlési jelzője (LOEKZ) „L” értékre változik. Eseménytípus explicit | |||
| Jóváhagyás visszaállítva | A teljes jóváhagyási munkafolyamat visszaállítását jelzi, ami gyakran az igénylés jelentős módosítása miatt történik. Ilyenkor a jóváhagyási folyamat az első szintről indul újra. | ||
| Miért fontos? Ez a tevékenység az átfutási időt jelentősen növelő újramunkálást jelzi. A jóváhagyás visszaállításának okai segítenek egyszerűsíteni a folyamatot és csökkenteni a késedelmeket. Hol szerezhető be? Az EBAN táblához tartozó módosítási dokumentumokból (CDHDR/CDPOS) következtethető ki. Az esemény akkor észlelhető, ha a jóváhagyási állapot mezőit (például FRGKZ vagy FRGZU) részleges vagy teljes beállítás után törlik. Rögzítés Keresse a módosítási naplókban azt az esetet, amikor a jóváhagyási állapot jóváhagyottról nem jóváhagyottra változik. Eseménytípus inferred | |||
| Jóváhagyási lépés elindult | Azt jelzi, hogy az igénylés egy adott jóváhagyóra vagy jóváhagyói csoportra vár. Ez abból következtethető ki, hogy az igénylés állapota egy adott jóváhagyási kódra várakozást jelez. | ||
| Miért fontos? Ez a tevékenység segít feltárni a jóváhagyási lánc szűk keresztmetszeteit. Az állapot időtartamának elemzésével azonosíthatók az elakadt igénylések és a túlterhelt jóváhagyók. Hol szerezhető be? Az EBAN tábla jóváhagyási állapotot tartalmazó mezőiből (például FRGZU) és a jóváhagyási stratégia beállításaiból következtethető ki. Az esemény akkor kezdődik, amikor egy adott jóváhagyási kód következik feldolgozásra. Rögzítés A munkafolyamat naplói vagy az állapotmezők alapján állapítsa meg, mikor kerül az igénylés olyan állapotba, amelyben egy adott jóváhagyási kód jóváhagyásra vár. Eseménytípus inferred | |||
Adatkinyerési útmutatók
Lépések
- Előfeltételek: Gondoskodjon róla, hogy rendelkezzen megfelelő jogosultságokkal az SAP S/4HANA rendszerben a szükséges CDS view-k eléréséhez. Ehhez általában olyan objektumokhoz kell jogosultság, mint az S_TABU_NAM, valamint hozzáférés az adatmegjelenítő eszközökhöz.
- A rendszerelérés módjának meghatározása: Döntse el, hogyan csatlakozik az SAP S/4HANA adatbázishoz az SQL-lekérdezések futtatásához. Használhatja például az SAP HANA Studio eszközt, az ADT-t (ABAP Development Tools) tartalmazó Eclipse IDE-t, vagy olyan külső SQL-klienst, mint a DBeaver, amely az SAP HANA adatbázis-kliensen keresztül csatlakozik.
- Az SQL-lekérdezés áttekintése: Ismerkedjen meg a mellékelt SQL-szkripttel. Common Table Expressions (CTE) segítségével gyűjti össze a különböző tevékenységek adatait, majd egyesíti őket egy egységes eseménynaplóvá.
- Helyőrzők testreszabása: Keresse meg és cserélje le a lekérdezésben szereplő helyőrzőket. Adja meg az adatkinyerés időszakát (
[YYYY-MM-DD]formátumban), valamint a szervezetére vonatkozó vállalatkódokat ([Your Company Code]). - A lekérdezés futtatása: Futtassa a teljes, testreszabott SQL-lekérdezést az SAP S/4HANA adatbázison. Az adatmennyiségtől és a kiválasztott időszaktól függően a lekérdezés futtatása eltarthat egy ideig.
- Az adatok első ellenőrzése: A lekérdezés lefutása után tekintse át az eredmény első néhány sorát. Ellenőrizze, hogy minden oszlop, például a PurchaseRequisitionId, az ActivityName és az EventTime a várt módon ki van-e töltve, és megfelelő-e az adatok formátuma.
- Adatátalakítás ellenőrzése: A lekérdezés a process mininghez szükséges formátumban adja vissza az adatokat. A
CASTés aCONCATfüggvények gondoskodnak az adattípusok egységességéről. A futtatás után várhatóan nincs szükség jelentős átalakításra. - Az eseménynapló exportálása: Exportálja az SQL-kliensből a teljes eredményhalmazt CSV-fájlba. A karakterkódolást állítsa UTF-8-ra, hogy elkerülje a karakterek megjelenítésével kapcsolatos problémákat.
- Feltöltés előtti előkészítés: Process mining eszközbe való feltöltés előtt ellenőrizze, hogy a CSV-fájl fejlécei megfelelőek-e (
PurchaseRequisitionId,ActivityName,EventTimestb.), és azEventTimedátum- és időformátuma egységes, valamint a célplatform által támogatott-e. - Feltöltés a ProcessMindba: Töltse fel a végleges CSV-fájlt a ProcessMind-projektjébe. A projekt beállításakor rendelje a
PurchaseRequisitionIdmezőt az esetazonosítóhoz, azActivityNamemezőt a tevékenységhez, azEventTimemezőt pedig az időbélyeghez.
Konfiguráció
- Alapvető CDS view-k: Az adatkinyerés főként az
I_PurchaseRequisitionAPI01view-t használja az alapvető beszerzésiigény-adatokhoz, azI_ChangeDocumentés azI_ChangeDocumentItemview-kat a módosítások és állapotfrissítések követéséhez, valamint azI_PurchaseOrderItemAPI01view-t a megrendelések összekapcsolásához. - Jogosultságok: A lekérdezést futtató felhasználónak olvasási jogosultságra van szüksége a fent említett CDS view-khoz. A szükséges szerepkörökről és jogosultságokról érdeklődjön az SAP biztonsági csapatánál.
- Időszak szerinti szűrés: Az adatmennyiség korlátozásához feltétlenül szűrjön a beszerzési igény létrehozási dátumára (
CreationDate). Első elemzéshez 3–6 hónapnyi adat javasolt. - Szervezeti szűrés: Szűrjön a
CompanyCodemezőre, hogy a megfelelő gazdálkodó egység folyamatát elemezze. APurchaseRequisitionTypemezőre is szűrhet, ha egy adott beszerzési folyamatra, például normál árubeszerzésre vagy szolgáltatásbeszerzésre kíván összpontosítani. - Módosítási dokumentumok beállítása: Az olyan tevékenységek rögzítése, mint a „Beszerzési igény módosítva” és a különböző jóváhagyási lépések, attól függ, hogy az SAP-rendszerben aktív-e a módosítási dokumentumok naplózása az érintett mezőknél. Ha ezek az események hiányoznak, ellenőrizze az EBAN tábla rendszerbeállításait.
- Teljesítmény: Több millió beszerzési igényt kezelő nagy rendszerekben a hosszú időszakra futtatott lekérdezés ronthatja a rendszer teljesítményét. Futtassa csúcsidőn kívül, vagy nem éles környezetben, frissen frissített adatokkal.
Példa-lekérdezés sql
WITH REQUISITIONS AS (
SELECT
PurchaseRequisition,
PurchaseRequisitionType,
PurReqnDescription,
CreatedByUser,
CreationDate,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS CreationTimestamp,
SourceOfSupplyIsAssigned
FROM I_PurchaseRequisitionAPI01
WHERE CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
AND CompanyCode IN ('[Your Company Code]')
),
CHANGE_DOCS AS (
SELECT
ObjectValue AS PurchaseRequisition,
UserName,
CAST(CONCAT(CreationDate, 'T', LPAD(CreationTime, 6, '0')) AS TIMESTAMP) AS ChangeTimestamp,
FieldName,
ValueNew,
ValueOld
FROM I_ChangeDocument AS H
JOIN I_ChangeDocumentItem AS I
ON H.ChangeDocument = I.ChangeDocument
WHERE H.Objectclass = 'EINKBELEG'
AND H.CreationDate BETWEEN '[YYYY-MM-DD]' AND '[YYYY-MM-DD]'
)
-- 1. Requisition Created
SELECT
R.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Created' AS "ActivityName",
R.CreationTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM REQUISITIONS AS R
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON R.PurchaseRequisition = I.PurchaseRequisition
UNION ALL
-- 2. Requisition Submitted For Approval & 5. Approval Step Started
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
CASE
WHEN C.ValueOld = ''
THEN 'Requisition Submitted For Approval'
ELSE 'Approval Step Started'
END AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
R.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R
ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I
ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew != ''
UNION ALL
-- 3. Requisition Amended
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Amended' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('MENGE', 'PREIS', 'MATNR', 'LIFNR', 'INFNR')
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 4. Approval Reset
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Reset' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueOld != '' AND C.ValueNew = ''
UNION ALL
-- 6. Approval Step Completed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Approval Step Completed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew IN ('1', '2', '3', '4', '5', '6', '7') -- Adjust release codes as per your config
UNION ALL
-- 7. Requisition Approved
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Approved' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGKE' AND C.ValueNew = '2' -- Final release indicator '2' is common for approved
UNION ALL
-- 8. Requisition Rejected
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Rejected' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
NULL AS "UserId",
C.UserName AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'FRGZU' AND C.ValueNew = 'B' -- 'B' for Blocked/Rejected is a common setting
UNION ALL
-- 9. Requisition Withdrawn
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Withdrawn' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'LOEKZ' AND C.ValueNew = 'X'
UNION ALL
-- 10. Source of Supply Assigned
SELECT DISTINCT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Source of Supply Assigned' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName IN ('LIFNR', 'INFNR') AND C.ValueNew != ''
AND C.ChangeTimestamp > R.CreationTimestamp
UNION ALL
-- 11. Purchase Order Created
SELECT DISTINCT
I.PurchaseRequisition AS "PurchaseRequisitionId",
'Purchase Order Created' AS "ActivityName",
CAST(CONCAT(H.PurchaseOrderDate, 'T', LPAD(H.CreationTime, 6, '0')) AS TIMESTAMP) AS "EventTime",
H.CreatedByUser AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.OrderPriceUnit * I.OrderQuantity AS "RequisitionAmount",
'PO Created' AS "RequisitionStatus"
FROM I_PurchaseOrderItemAPI01 AS I
JOIN I_PurchaseOrderAPI01 AS H
ON I.PurchaseOrder = H.PurchaseOrder
JOIN REQUISITIONS AS R
ON I.PurchaseRequisition = R.PurchaseRequisition
WHERE I.PurchaseRequisition IS NOT NULL AND I.PurchaseRequisition != ''
UNION ALL
-- 12. Requisition Closed
SELECT
C.PurchaseRequisition AS "PurchaseRequisitionId",
'Requisition Closed' AS "ActivityName",
C.ChangeTimestamp AS "EventTime",
C.UserName AS "UserId",
NULL AS "ApproverId",
R.PurchaseRequisitionType AS "RequisitionType",
I.CostCenter AS "Department",
I.RequisitionPrice * I.RequestedQuantity AS "RequisitionAmount",
I.PurReqnProcessingStatus AS "RequisitionStatus"
FROM CHANGE_DOCS AS C
JOIN REQUISITIONS AS R ON C.PurchaseRequisition = R.PurchaseRequisition
JOIN I_PurchaseRequisitionItemAPI01 AS I ON C.PurchaseRequisition = I.PurchaseRequisition
WHERE C.FieldName = 'EBAKZ' AND C.ValueNew = 'X' Lépések
- Ellenőrizze, hogy rendelkezésre áll-e közvetlen olvasási hozzáférés az EBAN és az EBKN táblát tartalmazó SAP HANA-sémához. Azonosítsa továbbá azokat a módosítási dokumentumokat és beszerzési dokumentumokat kezelő objektumokat, amelyeket a rendszer a beszerzési igények módosításához, a jóváhagyási folyamathoz, a forrás-hozzárendeléshez, a megrendelések hivatkozásaihoz és a lezáráshoz használ. Ezek az objektumok és mezők kiadásonként és beállításonként eltérhetnek, ezért a lekérdezés minden szögletes zárójelben megadott helyőrzőjét cserélje le a rendszerében használt megfelelő objektumra vagy mezőre.
- Az SAP GUI-ban az SE16H tranzakcióval vagy jóváhagyott adatbázis-kezelő eszközzel vizsgálja meg az EBAN és az EBKN táblát. Ellenőrizze a beszerzési igény kulcsmezőit, valamint a rendelkezésre álló dátum-, idő-, felhasználó-, állapot-, törlési, jóváhagyási, kontírozási és beszerzési dokumentumhivatkozási mezőket. A mezők definícióját az SE11-ben vagy az SAP adatszótárában ellenőrizze. Tesztelés közben ne tegye hozzáférhetővé az éles adatokat.
- Azonosítsa a beszerzési igények módosításaihoz és a jóváhagyási változásokhoz beállított módosításidokumentum-forrást. A lekérdezés egy [Your requisition change document source] nevű, egységesített módosítási forrást vár, amely a beszerzési igény számát, a tételszámot, a módosított mezőt, a régi és az új értéket, a módosítás dátumát és időpontját, valamint a felhasználót tartalmazza. Futtatás előtt rendelje hozzá ezt a forrást a rendszerben használt megfelelő SAP-módosításidokumentum-táblákhoz vagy CDS view-hoz.
- Azonosítsa a benyújtás, a jóváhagyás visszaállítása, a jóváhagyási lépés kezdete és befejezése, a végső jóváhagyás, valamint az elutasítás workflow- vagy jóváhagyási forrását. A lekérdezés egy [Your requisition approval event source] nevű forrást vár, amely minden állapot- vagy jóváhagyási átmenethez egy sort tartalmaz, a beszerzési igény számával, a tételszámmal, az eseménytípussal, a jóváhagyási kóddal vagy csoporttal, a jóváhagyóval, az esemény dátumával és időpontjával, valamint az állapottal. Rendelje hozzá a helyőrzőt az S/4HANA-konfigurációban használt jóváhagyási vagy workflow-adattárolóhoz.
- Azonosítsa a forrás-hozzárendelés, a megrendelés-hivatkozás és a lezárás adatforrását. A lekérdezés a [Your requisition source assignment source], a [Your requisition purchase order reference source] és a [Your requisition closure source] helyőrzőket várja. Rendelje hozzá ezeket a rendszerben jóváhagyott táblákhoz vagy view-khoz. A megrendelés létrehozását a megrendelési tétel és a beszerzési igény tétele közötti kifejezett hivatkozásnak kell jeleznie, nem szabad más, oda nem tartozó beszerzési tevékenységből kikövetkeztetni.
- Állítsa be az adatkinyerés időszakát a [Start date] és az [End date] értékével. Első futtatáshoz 3–6 hónap javasolt. Csak az adatbázis teljesítményének és az eseménymennyiségnek az ellenőrzése után válasszon hosszabb időszakot. A lekérdezés a létrehozási és eseménydátumokra szűr, a beszerzési igény azonosítóját pedig esetazonosítóként tartja meg.
- Futtassa a lekérdezést az SAP HANA rendszerhez csatlakozó, jóváhagyott SQL-kliensben. Csak a kapcsolódási adatokat a lekérdezésen kívül, a dátumparamétereket, a vállalatspecifikus szűrőket, valamint a dokumentált forrás- és mezőhelyőrzőket módosítsa. A kimeneti oszlopok nevét pontosan így őrizze meg: PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount és RequisitionStatus.
- Ellenőrizze a duplikált eseményeket, az időbélyegek pontosságát, az időzóna kezelését, valamint a tétel- és dokumentumszintű részletezettséget. A lekérdezés dokumentumszintű esetazonosítókat ad vissza, a tétel adatait pedig belsőleg használja. Ha több tételhez ugyanaz a tevékenység és időbélyeg tartozik, tartsa meg a külön sorokat, kivéve, ha a ProcessMind-beállítás kifejezetten megköveteli az összevonást.
- Ellenőrizze, hogy minden szükséges tevékenység megjelenik-e ActivityName értékként, az EventTime ki van-e töltve és időrendileg hihető-e, valamint a szükséges esetazonosító nem üres-e. Az azonos időszakra vonatkozó darabszámokat vesse össze az SAP-jelentésekkel vagy a jóváhagyott működési adatkinyerésekkel.
- Exportálja az eredményt UTF-8 kódolású CSV-fájlba vagy más, ProcessMind által támogatott táblázatos formátumba. Hagyja meg a fejlécsort, őrizze meg az ISO-kompatibilis időbélyegeket, a hiányzó értékeket pedig üresen rögzítse. Feltöltéskor a PurchaseRequisitionId legyen az esetazonosító, az ActivityName a tevékenység oszlopa, az EventTime pedig az időbélyeg oszlopa.
Konfiguráció
- Esetazonosító: Az EBAN táblából származó beszerzésidokumentum-számot használja, PurchaseRequisitionId néven. Ha a folyamat tételszinten van beállítva, használjon dokumentált összetett kulcsot, például a beszerzési igény számát és a tételszámot, és minden eseménynél ugyanazt a kulcsot alkalmazza.
- Elsődleges adatforrás: Az EBAN a beszerzési igény tételeinek adatait tartalmazza. Az EBKN a kontírozási adatok, például a részleg vagy a költséghely kiegészítésére szolgál. Futtatás előtt ellenőrizze a pontos mezőneveket és adattípusokat az SAP adatszótárában.
- Eseményforrások: A lekérdezés szándékosan használ általános helyőrzőket a módosítási, jóváhagyási, forrás-hozzárendelési, megrendelés-hivatkozási és lezárási forrásokhoz. Ezek a források az S/4HANA-kiadástól, a workflow kialakításától, a jóváhagyási eljárástól, az aktivált üzleti funkcióktól és az ügyfélspecifikus bővítésektől függenek.
- Időszak: Kezdje 3–6 hónappal. Ha lehetséges, az időszakot indexelt vagy partíciószűrést lehetővé tevő dátummezőkkel határolja be. Növekményes betöltésnél az adatkinyerési időszakok fedjék át egymást annyira, hogy a késve érkező módosítások is bekerüljenek. Ezután az eset, a tevékenység, az időbélyeg, a tétel és a forrásesemény kulcsa alapján távolítsa el a duplikátumokat.
- Üzleti szűrők: A [Company code filter], [Document type filter], [Purchasing group filter] és [Plant filter] szűrőket csak akkor állítsa be, ha a mezők rendelkezésre állnak, és üzleti jelentésük egyértelmű. Ha a teljes életciklust kívánja rögzíteni, ne szűrjön állapot alapján.
- Állapotok hozzárendelése: A célrendszer jóváhagyási stratégiája vagy workflow-beállítása alapján határozza meg az In Approval, final approved, rejected, reset, pending release code és closed értékeknek megfelelő állapotokat. Ne feltételezze, hogy minden SAP-rendszerben ugyanazok az állapotkódok érvényesek.
- Módosítások hozzárendelése: Vegye fel a mennyiség, az ár, az anyag, a szállítási dátum, a kontírozás és a folyamat szempontjából fontos egyéb mezők módosításait. A lekérdezés külön feltételeket tartalmaz a felsorolt fontos mezőkre, és megköveteli, hogy a forrás megadja a módosított mező nevét.
- Időbélyegek kezelése: Az esemény dátumát és időpontját az adatbázis időzónájában egyesítse, majd dokumentálja az esetleges UTC-re váltást. Ha egy forrás csak dátumot tárol, éjfélt csak akkor használjon időpontként, ha nincs pontosabb időbélyeg, és rögzítse ezt a korlátozást.
- Teljesítmény: Az első adatkinyerést korlátozza dátum és üzleti hatókör szerint, csak a szükséges oszlopokat válassza ki, kerülje a nagy módosítási vagy workflow-előzmények korlátozás nélküli összekapcsolását, és ellenőrizze a HANA végrehajtási tervét. Ha rendszeresen kell adatot kinyernie, készítsen elő egységesített eseményforrásokat.
- Jogosultságok és előfeltételek: Kérjen olvasási jogosultságot az EBAN és az EBKN táblához, a beállított módosítási és workflow-forrásokhoz, a forrás-hozzárendelési adatokhoz, a megrendelés-hivatkozási adatokhoz és a lezárási adatokhoz. Ellenőrizze, hogy a közvetlen adatbázis-hozzáférés engedélyezett-e, aktív-e a szükséges beszerzési és workflow-funkció, valamint rendelkezésre áll-e a szükséges SAP HANA-adatbázislicenc vagy adminisztrációs eszköz.
- Biztonság: Alkalmazza a legkisebb jogosultság elvét, védje a felhasználói és jóváhagyói azonosítókat, és tartsa be a beszerzési és pénzügyi adatok kinyerésére vonatkozó szervezeti szabályokat.
Példa-lekérdezés sql
WITH
base_items AS (
SELECT
eban.[Purchase requisition number field] AS PurchaseRequisitionId,
eban.[Purchase requisition item field] AS RequisitionItem,
eban.[Creation date field] AS CreationDate,
eban.[Creation time field] AS CreationTime,
eban.[Created by field] AS CreatedBy,
eban.[Requisition type field] AS RequisitionType,
eban.[Company code field] AS CompanyCode,
eban.[Plant field] AS Plant,
eban.[Purchasing group field] AS PurchasingGroup,
eban.[Quantity field] AS Quantity,
eban.[Net price field] AS NetPrice,
eban.[Currency field] AS Currency,
eban.[Material field] AS Material,
eban.[Deletion indicator field] AS DeletionIndicator,
eban.[Overall release status field] AS OverallReleaseStatus,
eban.[Item processing status field] AS ItemProcessingStatus,
ebkn.[Cost center field] AS CostCenter,
ebkn.[Department field] AS Department,
CAST(eban.[Quantity field] * eban.[Net price field] AS DECIMAL(19,4)) AS RequisitionAmount
FROM [Your SAP schema].EBAN eban
LEFT JOIN [Your SAP schema].EBKN ebkn
ON ebkn.[Purchase requisition number field] = eban.[Purchase requisition number field]
AND ebkn.[Purchase requisition item field] = eban.[Purchase requisition item field]
WHERE eban.[Creation date field] BETWEEN '[Start date]' AND '[End date]'
AND ('[Company code filter]' = '' OR eban.[Company code field] = '[Company code filter]')
AND ('[Document type filter]' = '' OR eban.[Requisition type field] = '[Document type filter]')
AND ('[Purchasing group filter]' = '' OR eban.[Purchasing group field] = '[Purchasing group filter]')
AND ('[Plant filter]' = '' OR eban.[Plant field] = '[Plant filter]')
),
created_events AS (
SELECT
PurchaseRequisitionId,
'Requisition Created' AS ActivityName,
TO_TIMESTAMP(CAST(CreationDate AS NVARCHAR(8)) || LPAD(COALESCE(CAST(CreationTime AS NVARCHAR(6)), '000000'), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CreatedBy AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
RequisitionType,
Department,
RequisitionAmount,
'Created' AS RequisitionStatus
FROM base_items
),
submitted_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Submitted For Approval' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Requester or submitter field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'SUBMITTED'
OR a.[Status field] = 'In Approval'
),
amended_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Amended' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Amended' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] IN ('QUANTITY', 'PRICE', 'MATERIAL', 'DELIVERY_DATE', 'ACCOUNT_ASSIGNMENT')
),
reset_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Reset' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
a.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'RESET'
OR a.[Status field] = 'Approval Reset'
),
step_started_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Started' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_STARTED'
OR a.[Status field] = 'Pending Release'
),
step_completed_events AS (
SELECT
b.PurchaseRequisitionId,
'Approval Step Completed' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'STEP_COMPLETED'
OR a.[Status field] = 'Step Approved'
),
approved_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Approved' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'FINAL_APPROVED'
OR a.[Status field] = 'Approved'
),
rejected_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Rejected' AS ActivityName,
TO_TIMESTAMP(CAST(a.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(a.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
CAST(NULL AS NVARCHAR(80)) AS UserId,
a.[Approver or approval group field] AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
a.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition approval event source] a
ON a.[Purchase requisition number field] = b.PurchaseRequisitionId
AND a.[Purchase requisition item field] = b.RequisitionItem
WHERE a.[Event type field] = 'REJECTED'
OR a.[Status field] = 'Rejected'
),
withdrawn_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Withdrawn' AS ActivityName,
TO_TIMESTAMP(CAST(c.[Change date field] AS NVARCHAR(8)) || LPAD(CAST(c.[Change time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
c.[Change user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Withdrawn' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition change document source] c
ON c.[Purchase requisition number field] = b.PurchaseRequisitionId
AND c.[Purchase requisition item field] = b.RequisitionItem
WHERE c.[Changed field field] = 'DELETION_INDICATOR'
AND c.[New value field] IS NOT NULL
AND c.[New value field] <> ''
),
source_assigned_events AS (
SELECT
b.PurchaseRequisitionId,
'Source of Supply Assigned' AS ActivityName,
TO_TIMESTAMP(CAST(s.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(s.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
s.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Source Assigned' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition source assignment source] s
ON s.[Purchase requisition number field] = b.PurchaseRequisitionId
AND s.[Purchase requisition item field] = b.RequisitionItem
WHERE s.[Source identifier field] IS NOT NULL
AND s.[Source identifier field] <> ''
),
purchase_order_events AS (
SELECT
b.PurchaseRequisitionId,
'Purchase Order Created' AS ActivityName,
TO_TIMESTAMP(CAST(p.[Purchase order creation date field] AS NVARCHAR(8)) || LPAD(CAST(p.[Purchase order creation time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
p.[Purchase order creator field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
'Purchase Order Created' AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition purchase order reference source] p
ON p.[Purchase requisition number field] = b.PurchaseRequisitionId
AND p.[Purchase requisition item field] = b.RequisitionItem
WHERE p.[Purchase order number field] IS NOT NULL
AND p.[Purchase order number field] <> ''
),
closed_events AS (
SELECT
b.PurchaseRequisitionId,
'Requisition Closed' AS ActivityName,
TO_TIMESTAMP(CAST(cl.[Event date field] AS NVARCHAR(8)) || LPAD(CAST(cl.[Event time field] AS NVARCHAR(6)), 6, '0'), 'YYYYMMDDHH24MISS') AS EventTime,
cl.[Event user field] AS UserId,
CAST(NULL AS NVARCHAR(80)) AS ApproverId,
b.RequisitionType,
b.Department,
b.RequisitionAmount,
cl.[Status field] AS RequisitionStatus
FROM base_items b
INNER JOIN [Your requisition closure source] cl
ON cl.[Purchase requisition number field] = b.PurchaseRequisitionId
AND cl.[Purchase requisition item field] = b.RequisitionItem
WHERE cl.[Event type field] = 'CLOSED'
OR cl.[Status field] = 'Closed'
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM created_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM submitted_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM amended_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM reset_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_started_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM step_completed_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM approved_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM rejected_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM withdrawn_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM source_assigned_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM purchase_order_events
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, UserId, ApproverId, RequisitionType, Department, RequisitionAmount, RequisitionStatus FROM closed_events
ORDER BY PurchaseRequisitionId, EventTime, ActivityName; Kezdheti?
Használja ezt a sablont az adatok előkészítéséhez, és aknázza ki a process mining lehetőségeit a beszerzéstől a fizetésig tartó folyamat beszerzési igénylési szakaszának elemzésében. Kezdje el még ma a hatékonyság javítását!
Szüntesse meg a P2P beszerzési igények késedelmét, optimalizálja munkafolyamatát még ma!
Egyszerűsítse a folyamatokat, rövidítse az átfutási időt, és csökkentse 30%-kal a ciklusidőt.
Nincs szükség bankkártyára, a beállítás 5 perc.