Il Suo template dei dati per Purchase to Pay - Elaborazione delle fatture
Il Suo template dei dati per Purchase to Pay - Elaborazione delle fatture
- Attributi consigliati da raccogliere
- Attività principali da monitorare
- Indicazioni per l’estrazione da SAP S/4HANA
Attributi di Purchase to Pay - Elaborazione delle fatture
| Nome | Descrizione | ||
|---|---|---|---|
| Numero fattura InvoiceNumber | Identificativo univoco del documento fattura del fornitore, utilizzato come identificativo principale del caso nel processo. | ||
| Descrizione Il numero fattura è l’identificativo univoco assegnato a ogni fattura fornitore in SAP S/4HANA. Collega tutte le attività correlate, come la creazione, il parcheggio, l’approvazione e il pagamento, in un’unica istanza di processo. Nel Process Mining, questo attributo è fondamentale per seguire l’intero percorso di ogni fattura. Consente di ricostruire il flusso di processo completo, dalla ricezione al pagamento finale, e di analizzare i tempi di ciclo, i colli di bottiglia e le variazioni del processo per ogni singola fattura. Perché è importante È la chiave essenziale per collegare tutti gli eventi correlati e ricostruire l’intero ciclo di vita della fattura nel sistema. Dove reperirli È il numero del documento contabile, disponibile nella tabella BKPF, campo BELNR. Esempi 190000000119000000451900000132 | |||
| Nome attività ActivityName | Nome dell’attività aziendale o dell’evento che si è verificato per una fattura in un momento specifico. | ||
| Descrizione Il nome dell’attività descrive un passaggio specifico o una modifica di stato nel ciclo di elaborazione della fattura. Alcuni esempi sono «Documento fattura creato», «Fattura inviata per approvazione», «Blocco pagamento impostato» e «Pagamento eseguito». Questo attributo è fondamentale per creare la mappa del processo, che ne rappresenta visivamente il flusso delle attività. Analizzando la sequenza, la frequenza e la durata delle attività è possibile individuare colli di bottiglia, cicli di rilavorazione e variazioni del processo non conformi. È un elemento centrale per qualsiasi analisi di Process Mining. Perché è importante Definisce i passaggi del processo e consente di visualizzare le mappe di processo e analizzare i flussi e le variazioni. Dove reperirli Derivato da una combinazione di codici transazione SAP (SY-TCODE), stati dei documenti di modifica (CDHDR/CDPOS) e valori specifici dei campi che indicano cambiamenti di stato. Esempi Fattura registrata provvisoriamenteFattura approvataPagamento eseguito | |||
| Ora dell’evento EventTime | La data e l’ora esatte in cui si è verificata l’attività. | ||
| Descrizione L’ora dell’evento è la data e l’ora che registrano il momento esatto in cui si è verificata una specifica attività. Questi dati sono essenziali per calcolare le durate, i tempi di ciclo e i tempi di attesa tra le diverse fasi del processo. Nelle analisi di Process Mining, le date e le ore precise consentono di misurare indicatori chiave di prestazione come «Tempo medio di ciclo della fattura» e «Tempo di ciclo dell’approvazione della fattura». Analizzando il tempo trascorso tra le attività, le organizzazioni possono individuare i colli di bottiglia che causano ritardi nelle fatture e le opportunità per accelerare il processo. Perché è importante Questa data e ora costituisce la base di tutte le analisi temporali, compresi il monitoraggio delle prestazioni, l’individuazione dei colli di bottiglia e il monitoraggio degli SLA. Dove reperirli In genere, il dato proviene dalle tabelle dei documenti di modifica CDHDR (intestazione) e CDPOS (partita), utilizzando i campi UDATE e UTIME. Per alcuni eventi può essere ricavato dalle date di creazione o inserimento nelle tabelle come BKPF (CPUDT, CPUTM). Esempi 2023-04-15T10:30:00Z2023-04-18T14:05:21Z2023-05-02T09:00:00Z | |||
| Data di scadenza del pagamento PaymentDueDate | La data entro cui la fattura deve essere pagata per evitare che il pagamento risulti in ritardo. | ||
| Descrizione La data di scadenza del pagamento è la data calcolata entro cui effettuare il pagamento al fornitore, sulla base della data della fattura e dei termini di pagamento concordati. Rappresenta una scadenza fondamentale del processo. Questo attributo è essenziale per l’indicatore chiave di prestazione «Tasso di pagamenti puntuali» e per la Dashboard «Prestazioni di pagamento ai fornitori». Confrontando la data effettiva del pagamento con quella di scadenza, un’azienda può misurare la propria capacità di rispettare gli obblighi di pagamento, con effetti sui rapporti con i fornitori e sulla reputazione finanziaria. Perché è importante È il principale valore di riferimento per misurare il rispetto delle scadenze di pagamento, un aspetto essenziale per mantenere buoni rapporti con i fornitori ed evitare penali per ritardi. Dove reperirli Spesso questa data è disponibile direttamente nella partita del fornitore nella tabella BSEG, campo ZFBDT (data base per il calcolo della scadenza). La data di scadenza netta si calcola a partire da questa data base e dai termini di pagamento. Esempi 2023-05-302023-06-152023-07-01 | |||
| Importo fattura AmountInCompanyCodeCurrency | Importo lordo totale della fattura nella valuta locale della società. | ||
| Descrizione Questo attributo rappresenta il valore totale della fattura. È una metrica chiave per comprendere l’impatto finanziario e la portata delle attività di elaborazione delle fatture. L’analisi degli importi aiuta a dare priorità alle fatture di valore elevato per velocizzarne l’elaborazione, individuare le tendenze di spesa e correlare i problemi del processo al valore finanziario. Ad esempio, consente di verificare se le fatture di importo elevato vengono bloccate più spesso o richiedono tempi di approvazione più lunghi. Perché è importante Fornisce un contesto finanziario al processo e consente di analizzarlo in base al valore monetario, ad esempio per verificare se le fatture di importo elevato vengono elaborate in modo diverso. Dove reperirli Questo valore si ricava in genere dalla somma delle partite pertinenti nella tabella BSEG, campo WRBTR (importo in valuta locale). Esempi 1500.75125000.00850.20 | |||
| Motivo del blocco pagamento PaymentBlockReason | Codice che indica il motivo per cui una fattura è bloccata per il pagamento. | ||
| Descrizione Quando una fattura è bloccata per il pagamento, questo attributo ne specifica il motivo, ad esempio «Differenza nella quantità» o «Prezzo non corrispondente». In SAP, questi motivi vengono configurati per uniformare la gestione delle eccezioni. Questo attributo è fondamentale per la Dashboard «Frequenza e durata dei blocchi di pagamento». Analizzare la frequenza dei diversi motivi di blocco aiuta a individuare le cause profonde dei ritardi di pagamento, ad esempio problemi legati a determinati fornitori, materiali o processi interni, e permette di adottare misure correttive mirate. Perché è importante Indica la causa profonda specifica dei blocchi di pagamento, consentendo di analizzare il problema in modo mirato per ridurre i ritardi e migliorare la correttezza al primo tentativo. Dove reperirli Si trova nella partita del fornitore della tabella BSEG, campo ZLSPR (chiave di blocco pagamento). Esempi RIA | |||
| Nome utente UserName | L’ID utente SAP della persona o del sistema che ha eseguito l’attività. | ||
| Descrizione Questo attributo identifica l’utente che ha eseguito una specifica transazione o creato un documento. Può corrispondere all’ID di una persona o a quello di un sistema che esegue processi batch automatizzati. L’analisi per utente aiuta a comprendere la distribuzione del carico di lavoro, individuare le esigenze di formazione e rilevare comportamenti insoliti. Ad esempio, può mostrare quali utenti gestiscono spesso le eccezioni o quali fatture vengono elaborate automaticamente, come quelle associate all’utente «BATCHUSER». È un dato fondamentale per calcolare l’indicatore chiave di prestazione «Tasso di automazione delle fatture». Perché è importante Associa le attività del processo a utenti specifici o ad account di sistema, consentendo di analizzare il carico di lavoro e confrontare le prestazioni, oltre a rilevare le attività automatizzate. Dove reperirli Ricavato da campi come BKPF-USNAM (inserito da) o CDHDR-USERNAME (modificato da). Esempi SMITHJMUELLERTWF-BATCH | |||
| Numero fornitore VendorNumber | Identificativo univoco del fornitore che ha inviato la fattura. | ||
| Descrizione Il numero fornitore identifica il fornitore o creditore associato alla fattura e collega la transazione ai dati anagrafici del fornitore. Questo attributo è fondamentale per le analisi incentrate sui fornitori, ad esempio per valutare le «Prestazioni di pagamento ai fornitori» o individuare quelli che inviano spesso fatture problematiche, che generano eccezioni o blocchi di pagamento. Aiuta a gestire i rapporti con i fornitori e a valutarne l’affidabilità. Perché è importante Consente di analizzare le prestazioni del processo per fornitore, individuare schemi ricorrenti, gestire i rapporti e valutare i problemi legati ai fornitori. Dove reperirli In genere, si trova nella tabella delle partite dei documenti contabili BSEG, campo LIFNR. Esempi 100345700012V9832 | |||
| Ordine di acquisto PurchasingDocument | Numero dell’ordine di acquisto a cui è associata la fattura. | ||
| Descrizione Il numero del documento di acquisto collega la fattura del fornitore all’ordine di acquisto originale (PO). Questo collegamento è fondamentale per il confronto a tre vie, che verifica la fattura rispetto all’ordine di acquisto e alla registrazione della ricezione della merce. L’analisi di questo attributo aiuta a comprendere le differenze tra le fatture associate a un ordine di acquisto e quelle che non lo sono. È essenziale per indagare le discrepanze nel confronto e valutare l’efficienza della parte del processo relativa agli acquisti. Perché è importante Collega la fattura al processo di approvvigionamento, un aspetto essenziale per analizzare le discrepanze nel confronto e la conformità agli ordini di acquisto. Dove reperirli Questa informazione si trova in genere nella tabella delle partite dei documenti BSEG, campo EBELN (numero del documento di acquisto). Esempi 450000123445000056784500009012 | |||
| Società CompanyCode | Unità organizzativa che rappresenta una società legalmente indipendente per la quale vengono redatti i rendiconti finanziari. | ||
| Descrizione La società è un’unità organizzativa fondamentale in SAP Finance. A ogni fattura viene assegnata una società specifica, che determina l’entità giuridica responsabile della transazione. Nel Process Mining, filtrare o confrontare i dati per società è essenziale per analizzare le prestazioni dei processi tra diverse unità aziendali, entità giuridiche o paesi. Aiuta a individuare differenze regionali in termini di efficienza, conformità e livelli di automazione, fornendo indicazioni per iniziative di miglioramento mirate. Perché è importante Consente di segmentare e confrontare le prestazioni dell’elaborazione delle fatture tra diverse entità giuridiche o aree geografiche dell’organizzazione. Dove reperirli È un campo standard della tabella di intestazione dei documenti BKPF, campo BUKRS. Esempi 1000US01DE01 | |||
| Tipo documento DocumentType | Codice che classifica i diversi tipi di documenti contabili, come le fatture dei fornitori o le note di credito. | ||
| Descrizione In SAP, il tipo documento serve a distinguere le diverse transazioni aziendali. Ad esempio, «KR» indica in genere una fattura standard di un fornitore, mentre «KG» può indicare una nota di credito di un fornitore. L’analisi per tipo documento consente di segmentare il processo e capire come vengono gestiti i diversi tipi di transazione. Il processo di una nota di credito, ad esempio, può differire notevolmente da quello di una fattura standard. Questa segmentazione offre informazioni più precise e pertinenti sul processo. Perché è importante Aiuta a distinguere i diversi tipi di transazioni finanziarie, come le fatture standard e le note di credito, che spesso seguono percorsi di processo diversi. Dove reperirli Si trova nella tabella di intestazione dei documenti BKPF, campo BLART. Esempi KRREKG | |||
| Data e ora di estrazione ExtractionTimestamp | La data e l’ora in cui i dati sono stati estratti dal sistema di origine. | ||
| Descrizione Questo attributo registra la data e l’ora dell’estrazione dei dati e ne indica l’aggiornamento nello strumento di Process Mining. Nell’analisi, consente di valutare quanto siano recenti le informazioni ottenute. È fondamentale per le Dashboard di monitoraggio operativo, perché assicura che le decisioni si basino su dati aggiornati e aiuta a gestire efficacemente i cicli di aggiornamento dei dati. Perché è importante Indica quanto sono aggiornati i dati, affinché l’analisi e i report si basino sulle informazioni più recenti disponibili. Dove reperirli Non è un campo SAP. Viene generato e aggiunto dallo strumento di estrazione dei dati o dal processo ETL al momento dell’estrazione. Esempi 2023-10-27T02:00:00Z2023-10-28T02:00:00Z2023-10-29T02:00:00Z | |||
| Data fattura InvoiceDate | La data in cui il fornitore ha emesso la fattura. | ||
| Descrizione La data fattura, detta anche data documento, è la data indicata dal fornitore sulla fattura. Viene utilizzata come punto di partenza per calcolare la data di scadenza del pagamento in base ai termini concordati. Nell’analisi, questa data è fondamentale per i calcoli finanziari, ad esempio per determinare l’anzianità delle fatture e l’idoneità agli sconti per pagamento anticipato. È un dato chiave per l’indicatore «Tasso di acquisizione degli sconti per pagamento anticipato». Perché è importante Costituisce la base per calcolare i termini di pagamento e le scadenze, un aspetto essenziale per gestire il capitale circolante e ottenere gli sconti. Dove reperirli Si trova nella tabella di intestazione dei documenti BKPF, campo BLDAT (data documento). Esempi 2023-04-122023-05-152023-06-20 | |||
| È automatizzata IsAutomated | Indicatore che segnala se un’attività è stata eseguita da un utente di sistema automatizzato. | ||
| Descrizione Questo attributo booleano è impostato su vero se l’utente associato a un’attività è un account di sistema o batch noto, come «WF-BATCH» o «SAP_SYSTEM». Aiuta a distinguere le fasi del processo manuali da quelle automatizzate. Questo attributo è essenziale per calcolare l’indicatore «Tasso di automazione delle fatture». Analizzando le parti automatizzate del processo, le organizzazioni possono valutare i risultati delle iniziative di automazione e individuare altre opportunità per ridurre il lavoro manuale e migliorare l’efficienza. Perché è importante Distingue le attività manuali da quelle eseguite dal sistema, un aspetto fondamentale per misurare i tassi di automazione e individuare ulteriori opportunità di automazione. Dove reperirli Derivato dall’attributo UserName. Si crea una mappatura o una regola per classificare determinati ID utente come «automatizzati». Esempi truefalse | |||
| È una rilavorazione IsRework | Indicatore che segnala se una fattura è stata sottoposta a rilavorazioni, ad esempio dopo il rifiuto di un’approvazione o la rimozione di un blocco di pagamento. | ||
| Descrizione Questo attributo segnala le fatture che hanno attraversato uno o più cicli di rilavorazione. Le rilavorazioni vengono individuate tramite sequenze specifiche di attività, ad esempio «Fattura approvata» dopo «Fattura rifiutata» oppure «Blocco pagamento rimosso» dopo «Blocco pagamento impostato». Questo attributo semplifica il calcolo dell’indicatore «Tasso di rilavorazione delle fatture». Consente agli analisti di isolare e approfondire facilmente i casi con rilavorazioni, per comprenderne le cause profonde e ridurre le inefficienze e il ripetersi del lavoro manuale. Perché è importante Individua i flussi di processo inefficienti in cui è necessario ripetere il lavoro, aiutando a quantificare gli sprechi e a individuare le cause profonde delle eccezioni. Dove reperirli Calcolato in base alla sequenza delle attività nell’Event Log. Ad esempio, se nella traccia di una fattura compare «Fattura rifiutata», l’indicatore viene impostato su vero. Esempi truefalse | |||
| ID del sistema di origine SourceSystemId | Identificativo del sistema SAP S/4HANA di origine da cui sono stati estratti i dati. | ||
| Descrizione Questo attributo specifica il sistema di origine, ad esempio «S4H_PROD» o «ERP_EU». È particolarmente importante negli ambienti con più istanze ERP o con una combinazione di sistemi legacy e moderni. L’analisi consente di confrontare le prestazioni dei processi tra sistemi o aree geografiche diverse. Inoltre, garantisce la tracciabilità dei dati ed è fondamentale per la governance dei dati e la risoluzione dei problemi quando si combinano dati provenienti da più fonti in una piattaforma centrale di Process Mining. Perché è importante Fornisce informazioni sull’origine dei dati, essenziali per la governance dei dati e per confrontare i processi tra sistemi o sedi aziendali diverse. Dove reperirli Questo valore viene in genere ricavato dall’ID del sistema SAP (sy-sysid) durante l’estrazione dei dati oppure configurato come valore statico nella pipeline ETL. Esempi S4PS4H_PROD_100ECC_EU | |||
| Motivo dello storno ReversalReason | Codice che indica il motivo per cui un documento fattura è stato stornato. | ||
| Descrizione Se una fattura viene registrata in modo errato, spesso viene stornata. Il codice del motivo dello storno spiega perché è stata eseguita questa operazione, ad esempio per una «Data di registrazione errata» o un «Errore di inserimento dei dati». Analizzare i motivi degli storni aiuta a individuare gli schemi ricorrenti di errore nel processo di registrazione delle fatture. Queste informazioni possono essere utilizzate per migliorare la formazione, rafforzare i controlli di sistema o risolvere problemi ricorrenti che comportano rilavorazioni finanziarie e maggiori oneri amministrativi. Perché è importante Spiega perché le fatture sono state annullate e offre indicazioni dirette sulle cause degli errori e delle rilavorazioni nel processo di registrazione. Dove reperirli Si trova nell’intestazione del documento originale nella tabella BKPF, campo STGRD (motivo dello storno). Esempi 010205 | |||
| N. documento di compensazione. ClearingDocumentNumber | Numero del documento che compensa la fattura, in genere il documento di pagamento. | ||
| Descrizione Il numero del documento di compensazione collega una partita aperta della fattura alla transazione che la compensa, quasi sempre il documento di pagamento. Conferma che la fattura è stata pagata. Questo attributo costituisce il collegamento definitivo tra una fattura e il relativo pagamento. Viene utilizzato per individuare l’attività «Pagamento eseguito» e la relativa data e ora, essenziali per calcolare il tempo totale di attraversamento e il tasso di pagamenti puntuali. Perché è importante Conferma che la fattura è stata pagata e la collega alla specifica transazione di pagamento, un dato fondamentale per analizzare i tempi di ciclo e le prestazioni dei pagamenti. Dove reperirli Si trova nella tabella delle partite dei documenti BSEG, campo AUGBL (numero del documento di compensazione). Esempi 150000000115000000231500000088 | |||
| Numero di cicli di approvazione ApprovalCycleCount | Numero di volte in cui una fattura è stata inviata per l’approvazione. | ||
| Descrizione Questa metrica conta il numero di volte in cui si verifica l’attività «Fattura inviata per approvazione» per una singola fattura. Un valore superiore a uno indica che la fattura è stata rifiutata o restituita almeno una volta e ha quindi richiesto un nuovo ciclo di approvazione. Questo attributo contribuisce direttamente all’indicatore «Tasso di approvazione al primo passaggio». Analizzando le fatture con un numero elevato di cicli di approvazione, le organizzazioni possono individuare i motivi delle approvazioni non riuscite, come informazioni insufficienti o codici errati, e intervenire per migliorare il processo. Perché è importante Quantifica le rilavorazioni nel sottoprocesso di approvazione, aiutando a misurare il tasso di correttezza al primo tentativo e a individuare i motivi dei rifiuti. Dove reperirli Calcolato contando le occorrenze dell’attività «Fattura inviata per approvazione» per ogni InvoiceNumber univoco. Esempi 123 | |||
| Pagata puntualmente IsPaidOnTime | Indicatore impostato su vero se la fattura è stata pagata entro la data di scadenza, inclusa. | ||
| Descrizione Questo attributo booleano si ottiene confrontando la data effettiva del pagamento, ovvero la data e l’ora dell’attività «Pagamento eseguito», con la «Data di scadenza del pagamento». Fornisce un esito chiaro, sì o no, sullo stato del pagamento di ogni fattura. È il calcolo alla base dell’indicatore «Tasso di pagamenti puntuali». Consente di filtrare e analizzare facilmente le caratteristiche dei pagamenti in ritardo, come i fornitori, le società o gli importi delle fatture più spesso associati ai ritardi. Perché è importante Misura direttamente il rispetto dei termini di pagamento, un indicatore chiave per la gestione dei rapporti con i fornitori e delle operazioni finanziarie. Dove reperirli Calcolato confrontando l’ora dell’evento dell’attività «Pagamento eseguito» con l’attributo PaymentDueDate. (Payment Date <= PaymentDueDate). Esempi truefalse | |||
| Termini di pagamento PaymentTerms | Codice che definisce le condizioni di pagamento concordate con il fornitore, come le scadenze e i periodi in cui è possibile ottenere sconti. | ||
| Descrizione I termini di pagamento definiscono le regole per pagare una fattura, compresi gli eventuali sconti disponibili per il pagamento anticipato. Ad esempio, «Z030» può indicare «pagamento entro 30 giorni netti». Questo attributo è essenziale per la pianificazione finanziaria e l’ottimizzazione del capitale circolante. Nel Process Mining, viene utilizzato per calcolare la data di scadenza del pagamento e determinare l’idoneità agli sconti per pagamento anticipato, contribuendo direttamente all’indicatore «Tasso di acquisizione degli sconti per pagamento anticipato». Perché è importante Definisce le regole per le scadenze e gli sconti di pagamento, incidendo direttamente sugli indicatori dei pagamenti puntuali e sulla gestione del capitale circolante. Dove reperirli Si trova nella partita del fornitore della tabella BSEG, campo ZTERM (chiave dei termini di pagamento). Esempi 0001Z030NT60 | |||
Attività di Purchase to Pay - Elaborazione delle fatture
| Attività | Descrizione | ||
|---|---|---|---|
| Documento della fattura creato | È il primo evento e indica la creazione di un documento di fattura in SAP. Può essere registrato quando un utente salva un nuovo documento, che può trovarsi nello stato di registrazione provvisoria o non ancora contabilizzato. | ||
| Perché è importante Questa attività segna l’inizio del ciclo di vita dell’elaborazione della fattura. Analizzare il tempo che intercorre tra questo evento e gli eventi successivi è fondamentale per misurare il tempo di attraversamento complessivo dell’elaborazione. Dove reperirli L’evento viene rilevato dalla data e dall’ora di creazione (CPUDT, CPUTM) nella tabella di testata del documento, in genere BKPF o RBKP per le fatture logistiche. Il codice transazione (BKPF-TCODE), ad esempio FB60, MIRO o MIR7, indica la modalità di creazione. Acquisizione Utilizzare la data e l’ora di creazione BKPF-CPUDT e BKPF-CPUTM del documento della fattura. Tipo di evento explicit | |||
| Fattura approvata | Questa attività indica che la fattura è stata approvata dall’autorità designata. L’evento viene registrato quando il flusso di lavoro di approvazione si conclude correttamente o viene impostato un indicatore di rilascio. | ||
| Perché è importante È una tappa fondamentale, perché rende la fattura disponibile per il pagamento. I ritardi nelle approvazioni sono un collo di bottiglia frequente; monitorare questa attività aiuta a individuare i responsabili delle approvazioni o i passaggi più lenti. Dove reperirli L’evento può essere dedotto dalla fase finale di rilascio in un flusso di lavoro SAP oppure monitorando le modifiche ai campi di stato del rilascio nelle tabelle associate alla fattura o al relativo documento di acquisto. Acquisizione Dedurre l’evento dagli eventi di completamento del flusso di lavoro o dalle modifiche al campo di stato del rilascio del documento. Tipo di evento inferred | |||
| Fattura contabilizzata | È un evento finanziario fondamentale, in cui la fattura registrata provvisoriamente o approvata viene contabilizzata ufficialmente nel libro mastro. Questa operazione rileva il debito nei confronti del fornitore. | ||
| Perché è importante La registrazione contabile è una tappa fondamentale che segna il passaggio dall’inserimento e dall’approvazione dei dati alla fase di regolamento finanziario. Il tempo che intercorre tra la creazione della fattura e la registrazione è un indicatore chiave dell’efficienza dei processi interni. Dove reperirli L’evento è identificato dalla data di registrazione (BKPF-BUDAT) nell’intestazione del documento. Per i documenti prima parcheggiati, il passaggio allo stato di registrato fornisce la data e l’ora dell’evento. Acquisizione Utilizzare la data di registrazione (BKPF-BUDAT) come data e ora dell’evento. Tipo di evento explicit | |||
| Fattura stornata | Attività che rappresenta lo storno di un documento fattura registrato in precedenza. Per una fattura errata, questo è un evento conclusivo; spesso la fattura viene poi inserita nuovamente in modo corretto. | ||
| Perché è importante Gli storni segnalano errori critici che non sono stati rilevati nelle fasi precedenti del processo. Monitorarne la frequenza e le cause profonde è essenziale per migliorare il processo e ridurre le inesattezze finanziarie. Dove reperirli Lo storno viene identificato quando viene creato un documento di storno. Nell’intestazione del documento originale (BKPF) è riportato il numero del documento di storno (BKPF-STBLG), e viceversa. La data di registrazione del documento di storno corrisponde all’ora dell’evento. Acquisizione Individuare i documenti con un valore nel campo BKPF-STBLG e utilizzare la data di registrazione del documento di storno. Tipo di evento explicit | |||
| Pagamento eseguito | È l’ultima attività del processo standard: il pagamento viene effettuato e la fattura viene compensata. Indica che i fondi sono stati versati al fornitore. | ||
| Perché è importante Segna la conclusione del ciclo di vita della fattura P2P. È essenziale per calcolare il tempo totale di attraversamento e misurare il rispetto delle scadenze di pagamento. Dove reperirli L’evento viene rilevato dalle informazioni sul documento di compensazione nella partita del fornitore. La data di compensazione (BSEG-AUGDT) e il documento di compensazione (BSEG-AUGBL) indicano che il pagamento è stato effettuato. Acquisizione Utilizzare la data di compensazione (BSEG-AUGDT) della partita del fornitore compensata. Tipo di evento explicit | |||
| Blocco di pagamento impostato | Attività con cui viene applicato intenzionalmente un blocco a una fattura per impedirne il pagamento. Spesso il blocco è dovuto a discrepanze di prezzo o quantità oppure a una nota di credito in sospeso. | ||
| Perché è importante I blocchi di pagamento sono una delle principali cause dei ritardi nei pagamenti e delle controversie con i fornitori. Analizzare la frequenza, la durata e le cause dei blocchi è fondamentale per aumentare la puntualità dei pagamenti. Dove reperirli L’evento viene rilevato monitorando le modifiche al campo chiave del blocco di pagamento (BSEG-ZLSPR) nella riga della fattura. I log delle modifiche nelle tabelle CDHDR e CDPOS indicano la data e l’ora e l’utente che ha impostato il blocco. Acquisizione Individuare i casi in cui il campo BSEG-ZLSPR viene valorizzato tramite i documenti di modifica (CDHDR/CDPOS). Tipo di evento explicit | |||
| Blocco di pagamento rimosso | Indica la risoluzione di un problema tramite la rimozione di un blocco di pagamento precedentemente impostato. La fattura torna così a essere idonea al pagamento. | ||
| Perché è importante Il tempo che intercorre tra l’impostazione e la rimozione di un blocco corrisponde al tempo necessario per risolvere un’eccezione del processo. Ridurre questa durata è fondamentale per migliorare l’efficienza e i rapporti con i fornitori. Dove reperirli L’evento viene registrato quando il campo chiave del blocco di pagamento (BSEG-ZLSPR) viene svuotato. La modifica viene registrata nelle tabelle CDHDR e CDPOS, che forniscono la data e l’ora della rimozione. Acquisizione Individuare i casi in cui il campo BSEG-ZLSPR viene svuotato tramite i documenti di modifica (CDHDR/CDPOS). Tipo di evento explicit | |||
| Dati della fattura aggiornati | Questa attività indica una modifica apportata al documento della fattura dopo la sua creazione iniziale. È frequente nei cicli di rilavorazione successivi a un rifiuto o per correggere errori. | ||
| Perché è importante Gli aggiornamenti frequenti indicano rilavorazioni e possibili problemi di qualità dei dati al momento dell’inserimento. Monitorare queste modifiche aiuta a quantificare il lavoro dedicato alle correzioni e a individuare gli errori più comuni. Dove reperirli Le modifiche ai campi principali vengono registrate nelle tabelle SAP dei documenti di modifica, CDHDR (testata) e CDPOS (riga). Gli eventi possono essere generati filtrando le modifiche relative all’oggetto della fattura. Acquisizione Estrarre dalle tabelle CDHDR e CDPOS gli eventi di modifica relativi all’oggetto della fattura. Tipo di evento explicit | |||
| Fattura inviata per l’approvazione | Questa attività segna l’avvio del flusso di lavoro formale di approvazione della fattura. Spesso si deduce dal passaggio della fattura allo stato di approvazione in sospeso o dalla creazione di un elemento del flusso di lavoro. | ||
| Perché è importante Questo è il punto di partenza per misurare il tempo di ciclo delle approvazioni. Sapere quando iniziano le approvazioni è essenziale per individuare i colli di bottiglia nel flusso di lavoro di approvazione. Dove reperirli In genere, l’evento si deduce dall’avvio di un SAP Business Workflow, registrato nella tabella SWW_WI2OBJ e collegato all’oggetto della fattura, ad esempio BUS2081, oppure dalla modifica di un campo di stato personalizzato nella testata del documento. Acquisizione Dedurre l’evento dalla creazione di un elemento del flusso di lavoro associato al documento della fattura. Tipo di evento inferred | |||
| Fattura registrata provvisoriamente | Indica una fattura inserita nel sistema ma non ancora contabilizzata nel libro mastro. La registrazione provvisoria consente di salvare fatture incomplete o di sottoporle a revisione prima della contabilizzazione. | ||
| Perché è importante La registrazione provvisoria indica una pausa intenzionale nel processo. Monitorare la durata e la frequenza delle fatture registrate provvisoriamente aiuta a individuare le cause dei ritardi prima dell’avvio del ciclo formale di contabilizzazione e approvazione. Dove reperirli È possibile identificare queste fatture tramite i documenti creati con transazioni di registrazione provvisoria, ad esempio MIR7 e FV60, oppure controllando specifici campi di stato nella tabella BKPF o nelle tabelle dedicate ai documenti registrati provvisoriamente, come VBKPF. Acquisizione Individuare i documenti creati con transazioni di registrazione provvisoria oppure verificare lo stato di registrazione provvisoria del documento. Tipo di evento explicit | |||
| Fattura rifiutata | Indica il rifiuto di una fattura durante il processo di approvazione. Questo evento avvia una rilavorazione, che richiede la correzione e il nuovo invio della fattura. | ||
| Perché è importante I rifiuti delle fatture sono un indicatore importante di inefficienze del processo e problemi di qualità dei dati. Analizzare la frequenza e le cause dei rifiuti aiuta a individuare opportunità di miglioramento e formazione. Dove reperirli L’evento si deduce da specifici aggiornamenti di stato in un flusso di lavoro SAP, ad esempio lo stato di rifiuto, oppure da eventi che annullano il flusso di lavoro di approvazione in corso e lo rinviano al responsabile dell’elaborazione. Acquisizione Dedurre l’evento dalle modifiche allo stato del flusso di lavoro che indicano un rifiuto. Tipo di evento inferred | |||
| Pagamento eseguito in ritardo | È un evento calcolato che si verifica quando il pagamento di una fattura viene eseguito dopo la relativa data di scadenza calcolata. Si ottiene confrontando due campi data. | ||
| Perché è importante Questa attività contribuisce direttamente agli indicatori chiave di prestazione relativi ai pagamenti puntuali e aiuta a individuare i fornitori o le unità aziendali che registrano frequenti ritardi, con possibili ripercussioni sui rapporti con i fornitori e il rischio di penali. Dove reperirli Si calcola confrontando la data di compensazione (BSEG-AUGDT) con la data di scadenza netta. Quest’ultima viene a sua volta calcolata a partire dalla data base (BSEG-ZFBDT) e dai termini di pagamento (BSEG-ZTERM). Acquisizione Determinare il ritardo confrontando BSEG-AUGDT > (BSEG-ZFBDT + giorni previsti dai termini di pagamento). Tipo di evento calculated | |||
| Proposta di pagamento creata | La fattura viene selezionata e inclusa in una proposta di pagamento nell’ambito di un’esecuzione dei pagamenti. È il primo passaggio del processo di pagamento automatizzato. | ||
| Perché è importante Questa attività indica l’intenzione di effettuare il pagamento. I ritardi tra questo passaggio e l’esecuzione del pagamento possono evidenziare problemi nell’esecuzione dei pagamenti, nelle approvazioni o nelle comunicazioni con la banca. Dove reperirli L’informazione è disponibile nelle tabelle delle esecuzioni dei pagamenti, in particolare in REGUP, che contiene le partite incluse in una proposta di pagamento. La data di esecuzione riportata nella tabella REGUH corrispondente fornisce la data e l’ora dell’evento. Acquisizione Individuare quando una fattura compare nella tabella REGUP in seguito all’esecuzione di una proposta di pagamento. Tipo di evento explicit | |||
Guide all’estrazione
Passaggi
- Prerequisiti e autorizzazioni: Verifichi che l’utente che esegue l’estrazione disponga delle autorizzazioni necessarie in SAP S/4HANA per accedere alle viste Core Data Services (CDS) richieste. Tra le viste principali figurano
I_InvoiceDocument,I_OperationalAcctgDocItem,I_ChangeDocument,I_ChangeDocumentItemeI_PaymentProposalItem. L’utente dovrà inoltre disporre delle autorizzazioni per eseguire query tramite l’interfaccia scelta, ad esempio un servizio OData o una connessione SQL diretta. - Scelga il metodo di connessione: Stabilisca come collegarsi al sistema SAP S/4HANA per eseguire la query SQL. Tra i metodi più comuni figurano SAP Data Services, SAP Data Intelligence, uno strumento ETL di terze parti con connettore SAP oppure una connessione SQL diretta al database SAP HANA, se consentita dalle politiche di sicurezza dell’organizzazione.
- Definisca i parametri di estrazione: Prima di eseguire la query, definisca i parametri principali. Specifichi l’intervallo di date da estrarre, ad esempio
CreationDatecompresa tra'YYYY-MM-DD'e'YYYY-MM-DD'. Individui inoltre i valori specifici diCompanyCodeda includere, così da limitare l’ambito dell’estrazione. - Personalizzi la query SQL: Copi la query SQL fornita nel client SQL o nello strumento di estrazione scelto. Controlli attentamente i segnaposto, come
'{StartDate}','{EndDate}'e('{CompanyCode1}', '{CompanyCode2}'). Li sostituisca con i valori effettivi definiti nel passaggio precedente. Potrebbe inoltre essere necessario adeguare i nomi dei campi relativi allo stato del flusso di lavoro in base alla configurazione SAP specifica. - Esegua la query: Esegua la query SQL completa sul database SAP S/4HANA o tramite il livello di servizio appropriato. La query è progettata per includere un insieme ampio di dati e, a seconda del volume e dell’intervallo di date selezionato, potrebbe richiedere molto tempo. Controlli l’esecuzione per individuare eventuali errori o timeout.
- Riveda i risultati iniziali: Al termine della query, controlli rapidamente i risultati. Verifichi che le colonne
InvoiceNumber,ActivityNameedEventTimecontengano dati. Controlli inoltre che nella colonnaActivityNamecompaiano attività diverse e non soltanto 'Invoice Document Created'. - Gestisca la trasformazione dei dati: La query è strutturata per produrre un Event Log pulito. Verifichi tuttavia che la colonna
EventTimeutilizzi un formato di data e ora coerente, ad esempioYYYY-MM-DDTHH:MM:SS. Quando necessario, la query fornita combina i campi di data e ora in un unico timestamp. - Esporti i dati: Esporti il risultato finale dallo strumento in un file CSV (Comma-Separated Values). Questo formato è compatibile con gli strumenti di Process Mining, incluso ProcessMind.
- Prepari il caricamento: Prima del caricamento, verifichi che il file CSV utilizzi la codifica UTF-8 per evitare problemi con i caratteri. Controlli che le intestazioni delle colonne corrispondano esattamente agli attributi richiesti:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCodee così via. - Carichi i dati in ProcessMind: Carichi il file CSV preparato nel progetto di Process Mining. Nella configurazione del modello dati dello strumento, associ le colonne del file ai campi corrispondenti per l’ID del caso, il nome dell’attività e il timestamp.
Configurazione
- Viste CDS utilizzate: Le principali origini dei dati sono le viste CDS standard di SAP. Le viste principali sono
I_InvoiceDocumentper i dati di testata,I_OperationalAcctgDocItemper i dettagli delle registrazioni finanziarie e delle compensazioni eI_ChangeDocumentconI_ChangeDocumentItemper monitorare le modifiche storiche agli attributi delle fatture, come i blocchi di pagamento e lo stato del flusso di lavoro. - Filtro per intervallo di date: È fondamentale filtrare i dati per un intervallo di date specifico, così da gestire le prestazioni. La query fornita utilizza un segnaposto per
CreationDatenella vistaI_InvoiceDocument. Come punto di partenza, si consiglia un periodo di dati compreso tra 3 e 6 mesi. - Filtro per codice società: Per mantenere l’estrazione pertinente e gestibile, applichi sempre un filtro su uno o più valori di
CompanyCode. A questo scopo, la query include il segnapostoWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}'). - Filtro per tipo di documento: Può affinare ulteriormente l’estrazione filtrando per
InvoiceDocumentType. Ad esempio, può includere le fatture standard dei fornitori (RE) ed escludere le note di credito. Il filtro può essere aggiunto alla clausolaWHEREdella CTE iniziale. - Prerequisiti: L’utente che esegue la query deve disporre delle autorizzazioni di visualizzazione appropriate per i documenti finanziari e di acquisto relativi ai codici società specificati. L’accesso al database HANA sottostante tramite un client SQL non è standard e richiede autorizzazioni specifiche.
- Considerazioni sulle prestazioni: L’estrazione dei dati dalle tabelle dei documenti di modifica (
I_ChangeDocument,I_ChangeDocumentItem) può richiedere molte risorse. Per evitare tempi di esecuzione lunghi, è essenziale applicare filtri rigorosi per data, codice società e classe oggetto (INCOMINGINVOICE).
Query di esempio sql
WITH InvoiceBase AS (
SELECT
inv.InvoiceDocument,
inv.FiscalYear,
inv.CompanyCode,
inv.Supplier AS VendorNumber,
inv.DocumentType,
inv.GrossInvoiceAmountInCoCoCrcy AS AmountInCompanyCodeCurrency,
inv.NetDueDate AS PaymentDueDate,
inv.PurchasingDocument,
inv.CreationDateTime,
inv.CreatedByUser,
accdoc.AccountingDocument,
accdoc.ClearingDate,
accdoc.ClearingJournalEntry,
accdoc.PaymentBlockReason,
accdoc.IsReversed
FROM I_InvoiceDocument AS inv
LEFT JOIN I_OperationalAcctgDocItem AS accdoc
ON inv.AccountingDocument = accdoc.AccountingDocument
AND inv.FiscalYear = accdoc.FiscalYear
AND inv.CompanyCode = accdoc.CompanyCode
WHERE
inv.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
)
-- 1. Invoice Document Created
SELECT
InvoiceDocument AS "InvoiceNumber",
'Invoice Document Created' AS "ActivityName",
CreationDateTime AS "EventTime",
CreatedByUser AS "UserName",
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
UNION ALL
-- 2. Invoice Parked
SELECT
i.InvoiceDocument AS "InvoiceNumber",
'Invoice Parked' AS "ActivityName",
i.CreationDateTime AS "EventTime",
i.CreatedByUser AS "UserName",
i.CompanyCode AS "CompanyCode",
i.Supplier AS "VendorNumber",
i.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
i.NetDueDate AS "PaymentDueDate",
i.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
i.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS i
WHERE
i.InvoiceDocumentIsParked = 'X'
AND i.CreationDate BETWEEN '{StartDate}' AND '{EndDate}'
AND i.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}')
UNION ALL
-- 3, 4, 5. Workflow activities (Sent for Approval, Approved, Rejected) from Change Docs
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew = '[StatusSentForApproval]' THEN 'Invoice Sent For Approval'
WHEN cdpos.ValueNew = '[StatusApproved]' THEN 'Invoice Approved'
WHEN cdpos.ValueNew = '[StatusRejected]' THEN 'Invoice Rejected'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName = '[WorkflowStatusFieldName]'
AND cdpos.ValueNew IN ('[StatusSentForApproval]', '[StatusApproved]', '[StatusRejected]')
UNION ALL
-- 6. Invoice Data Updated
SELECT
cdpos.ObjectValue AS "InvoiceNumber",
'Invoice Data Updated' AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.InvoiceDocument
WHERE
cdhdr.ObjectClassName = 'INCOMINGINVOICE'
AND cdpos.FieldName IN ('GrossInvoiceAmount', 'DocumentDate', 'PaymentTerms')
AND cdhdr.ChangeDate BETWEEN '{StartDate}' AND '{EndDate}'
UNION ALL
-- 7 & 8. Payment Block Set/Removed
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
CASE
WHEN cdpos.ValueNew <> '' AND cdpos.ValueOld = '' THEN 'Payment Block Set'
WHEN cdpos.ValueNew = '' AND cdpos.ValueOld <> '' THEN 'Payment Block Removed'
END AS "ActivityName",
CAST(cdhdr.ChangeDate AS TIMESTAMP) + CAST(cdhdr.ChangeTime AS TIME) AS "EventTime",
cdhdr.UserName AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
cdpos.ValueNew AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM I_ChangeDocument AS cdhdr
JOIN I_ChangeDocumentItem AS cdpos ON cdhdr.ChangeDocument = cdpos.ChangeDocument
JOIN InvoiceBase AS inv ON cdpos.ObjectValue = inv.AccountingDocument
WHERE
cdhdr.ObjectClassName = 'BELEG'
AND cdpos.TableName = 'BSEG'
AND cdpos.FieldName = 'ZLSPR'
AND ( (cdpos.ValueNew <> '' AND cdpos.ValueOld = '') OR (cdpos.ValueNew = '' AND cdpos.ValueOld <> '') )
UNION ALL
-- 9. Invoice Posted
SELECT
inv.InvoiceDocument AS "InvoiceNumber",
'Invoice Posted' AS "ActivityName",
CAST(accdoc.PostingDate AS TIMESTAMP) AS "EventTime",
accdoc.CreatedByUser AS "UserName",
inv.CompanyCode AS "CompanyCode",
inv.VendorNumber AS "VendorNumber",
inv.AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
inv.PaymentDueDate AS "PaymentDueDate",
inv.DocumentType AS "DocumentType",
accdoc.PaymentBlockReason AS "PaymentBlockReason",
inv.PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase AS inv
JOIN I_OperationalAcctgDocItem AS accdoc ON inv.AccountingDocument = accdoc.AccountingDocument
WHERE inv.AccountingDocument IS NOT NULL AND inv.IsReversed = FALSE
UNION ALL
-- 10. Payment Proposal Created
SELECT
item.InvoiceReference AS "InvoiceNumber",
'Payment Proposal Created' AS "ActivityName",
CAST(prun.PaymentRunDate AS TIMESTAMP) AS "EventTime",
prun.CreatedByUser AS "UserName",
item.CompanyCode AS "CompanyCode",
item.Supplier AS "VendorNumber",
item.AmountInTransactionCurrency AS "AmountInCompanyCodeCurrency",
item.NetDueDate AS "PaymentDueDate",
item.AccountingDocumentType AS "DocumentType",
item.PaymentBlockReason AS "PaymentBlockReason",
item.PurchasingDocument AS "PurchasingDocument"
FROM I_PaymentProposalItem as item
JOIN I_PaymentRun as prun ON item.PaymentRunName = prun.PaymentRunName
JOIN InvoiceBase AS inv ON item.InvoiceReference = inv.InvoiceDocument
UNION ALL
-- 11 & 12. Payment Executed / Late Payment Executed
SELECT
InvoiceDocument AS "InvoiceNumber",
CASE
WHEN ClearingDate > PaymentDueDate THEN 'Late Payment Executed'
ELSE 'Payment Executed'
END AS "ActivityName",
CAST(ClearingDate AS TIMESTAMP) AS "EventTime",
CAST(NULL AS VARCHAR(12)) AS "UserName", -- User for clearing is not always straightforward
CompanyCode AS "CompanyCode",
VendorNumber AS "VendorNumber",
AmountInCompanyCodeCurrency AS "AmountInCompanyCodeCurrency",
PaymentDueDate AS "PaymentDueDate",
DocumentType AS "DocumentType",
'' AS "PaymentBlockReason",
PurchasingDocument AS "PurchasingDocument"
FROM InvoiceBase
WHERE ClearingDate IS NOT NULL AND IsReversed = FALSE
UNION ALL
-- 13. Invoice Reversed
SELECT
rev.OriginalInvoiceDocument AS "InvoiceNumber",
'Invoice Reversed' AS "ActivityName",
rev.CreationDateTime AS "EventTime",
rev.CreatedByUser AS "UserName",
rev.CompanyCode AS "CompanyCode",
rev.Supplier AS "VendorNumber",
rev.GrossInvoiceAmountInCoCoCrcy AS "AmountInCompanyCodeCurrency",
CAST(NULL AS DATE) AS "PaymentDueDate",
rev.DocumentType AS "DocumentType",
CAST(NULL AS VARCHAR(1)) AS "PaymentBlockReason",
rev.PurchasingDocument AS "PurchasingDocument"
FROM I_InvoiceDocument AS rev
WHERE rev.OriginalInvoiceDocument IN (SELECT InvoiceDocument FROM InvoiceBase) AND rev.IsReversal = 'X' Passaggi
- Verifichi che l’accesso diretto in lettura al tenant SAP HANA o allo schema del database sia autorizzato e richieda un utente di database con accesso in sola lettura alle tabelle SAP necessarie e alle eventuali tabelle approvate per la cronologia delle modifiche o il flusso di lavoro. Utilizzi SAP HANA Database Explorer, SAP HANA Studio o un client SQL approvato. Non utilizzi l’accesso in scrittura all’ambiente di produzione.
- Verifichi i nomi fisici delle tabelle e delle colonne nel sistema S/4HANA di destinazione. ACDOCA, BKPF e RBKP sono punti di partenza standard, ma il flusso di lavoro, la registrazione provvisoria, le proposte di pagamento, l’esecuzione dei pagamenti, la cronologia delle modifiche e quella dei blocchi di pagamento possono utilizzare oggetti specifici della versione o del cliente. Sostituisca ogni segnaposto tra parentesi quadre nella query con oggetti verificati nel catalogo di sistema e coerenti con la semantica aziendale pertinente.
- Definisca il periodo di estrazione utilizzando [Timestamp iniziale] e [Timestamp finale]. Estragga un periodo sufficientemente ampio per i documenti e gli eventi, normalmente da tre a sei mesi, e lo estenda quando le scadenze dei pagamenti o i pagamenti in ritardo possono ricadere al di fuori del periodo di creazione delle fatture.
- Identifichi i casi fattura utilizzando la chiave configurata per le fatture. La query utilizza InvoiceNumber come identificativo del caso e, quando necessario, lo combina internamente con il codice società e l’anno fiscale per evitare duplicati. Verifichi se la definizione aziendale richiede di includere l’anno fiscale o il codice società nell’identificativo del caso in ProcessMind.
- Mappi i dati delle fatture registrate provenienti da RBKP, BKPF e ACDOCA. Utilizzi RBKP per le informazioni di testata della fattura, BKPF per i timestamp e gli utenti dei documenti contabili e ACDOCA per il fornitore, l’importo, il documento di acquisto, la compensazione e le informazioni contabili relative ai pagamenti, ove disponibili. Non presuma che tutti i campi siano valorizzati in ogni scenario di registrazione.
- Mappi gli eventi di registrazione provvisoria, approvazione, rifiuto, aggiornamento, blocco del pagamento, storno, proposta ed esecuzione del pagamento utilizzando le origini verificate e specifiche del sistema. Sostituisca le viste segnaposto con viste o tabelle approvate che espongano timestamp degli eventi, riferimenti alle fatture, utenti, stati e valori precedenti e nuovi. Ogni attività deve essere emessa come riga evento esplicita, poiché ProcessMind non deduce gli eventi.
- Esegua la query SQL completa in una sessione non di produzione o di sola lettura. Riveda i piani di esecuzione e limiti la query per codice società, tipo di documento, anno fiscale e timestamp dell’evento, ove opportuno. Eviti join senza restrizioni tra tabelle di registrazioni contabili e tabelle storiche di grandi dimensioni.
- Convalidi il risultato con i controlli descritti di seguito. Verifichi che siano presenti tutte le colonne richieste, che
EventTimesia valorizzato per ogni evento, cheInvoiceNumbersia valorizzato per ogni caso e che siano presenti tutti i 13 nomi di attività quando esistono i dati di origine corrispondenti. - Esporti il risultato in un file delimitato supportato da ProcessMind, preferibilmente in formato CSV UTF-8, con una riga per evento e le colonne InvoiceNumber, ActivityName, EventTime, UserName, CompanyCode, VendorNumber, AmountInCompanyCodeCurrency, PaymentDueDate, DocumentType, PaymentBlockReason e PurchasingDocument. Mantenga i timestamp in un fuso orario coerente e conservi gli zeri iniziali negli identificativi.
- Carichi l’Event Log in ProcessMind e configuri InvoiceNumber come identificativo del caso, ActivityName come colonna delle attività ed EventTime come colonna dei timestamp. Se la configurazione di ProcessMind supporta chiavi aggiuntive per i casi, utilizzi la stessa politica per le chiavi composte applicata durante l’estrazione.
Configurazione
- Intervallo di date: Per l’estrazione iniziale, utilizzi un periodo mobile da tre a sei mesi. Includa ulteriore cronologia quando gli eventi di approvazione, pagamento, compensazione, storno o pagamento in ritardo possono verificarsi dopo il periodo di creazione della fattura.
- Ambito delle società: Applichi il filtro [Filtro per codice società] e verifichi che i codici società selezionati siano autorizzati per l’estrazione.
- Ambito dei documenti: Applichi il filtro [Filtro per tipo di documento] e includa i tipi di documento che rappresentano fatture fornitori, note di credito, fatture registrate provvisoriamente e storni nel processo di destinazione.
- Identificativo del caso: Utilizzi InvoiceNumber come previsto dalla definizione del processo. Se i numeri delle fatture non sono univoci a livello globale, mantenga il codice società e l’anno fiscale nel risultato di origine oppure configuri una chiave composta in base al modello ProcessMind.
- Origini degli eventi: Verifichi le origini fisiche delle modifiche allo stato del flusso di lavoro, delle decisioni di approvazione, della registrazione provvisoria, della cronologia delle modifiche, dei blocchi di pagamento, delle proposte di pagamento e dell’esecuzione dei pagamenti. Queste origini variano in base alla versione di S/4HANA, all’ambito attivato, alla progettazione del flusso di lavoro e alle estensioni del cliente.
- Criteri per i timestamp: Selezioni il timestamp dell’evento aziendale, non quello dell’estrazione. Documenti il fuso orario e uniformi tutti i timestamp degli eventi prima del caricamento.
- Criteri per gli importi: Utilizzi l’importo nella valuta del codice società e verifichi che l’origine selezionata memorizzi in modo coerente i segni di dare e avere. Eviti di sommare le righe contabili senza aver convalidato la regola di aggregazione per il caso fattura.
- Criteri per i pagamenti: Definisca se «Pagamento eseguito» indica la compensazione, la registrazione del documento di pagamento, l’esecuzione bancaria o un’altra tappa aziendale. Utilizzi l’origine corrispondente alla definizione di processo concordata.
- Pagamento in ritardo: Generi l’evento «Pagamento in ritardo eseguito» solo quando «Pagamento eseguito» si verifica dopo PaymentDueDate. La query calcola esplicitamente questo evento e non si basa su deduzioni di ProcessMind.
- Prestazioni: Limiti la lettura delle origini per data, codice società, tipo di documento e anno fiscale pertinente. Selezioni solo le colonne necessarie, controlli i piani di esecuzione e, se la cronologia di origine è ampia, materializzi le viste intermedie approvate.
- Prerequisiti: Connettività diretta a SAP HANA, autorizzazioni di lettura per tutti gli oggetti selezionati, autorizzazione a esaminare i metadati e accesso ai dati pertinenti di contabilità fornitori, contabilità generale, acquisti, flusso di lavoro e pagamenti. Verifichi che siano disponibili le licenze SAP necessarie e che siano state approvate le politiche di accesso al database e di protezione dei dati.
- Sicurezza: Utilizzi un utente tecnico con accesso in sola lettura, protegga i dati dei fornitori e dei pagamenti e rispetti le politiche aziendali relative a trasporti, audit, mascheramento e gestione delle credenziali.
Query di esempio sql
WITH
invoice_base AS (
SELECT
r.INV_DOC_NO AS InvoiceNumber,
r.COMPANY_CODE AS CompanyCode,
r.FISCAL_YEAR AS FiscalYear,
r.DOCUMENT_TYPE AS DocumentType,
r.VENDOR_NO AS VendorNumber,
r.GROSS_AMOUNT_CC AS AmountInCompanyCodeCurrency,
r.PAYMENT_DUE_DATE AS PaymentDueDate,
r.PURCHASING_DOCUMENT AS PurchasingDocument,
r.CREATED_AT AS InvoiceCreatedAt,
r.CREATED_BY AS InvoiceCreatedBy
FROM [Your RBKP invoice header source] r
WHERE r.CREATED_AT >= '[Start timestamp]'
AND r.CREATED_AT < '[End timestamp]'
AND r.COMPANY_CODE IN ([Company code filter])
AND r.DOCUMENT_TYPE IN ([Document type filter])
),
posted_accounting AS (
SELECT
b.INV_DOC_NO AS InvoiceNumber,
b.COMPANY_CODE AS CompanyCode,
b.FISCAL_YEAR AS FiscalYear,
b.ACCOUNTING_DOCUMENT AS AccountingDocument,
b.POSTING_DATE AS PostingDate,
b.CREATED_AT AS PostedAt,
b.CREATED_BY AS PostedBy,
b.REVERSAL_DOCUMENT AS ReversalDocument,
b.REVERSED_DOCUMENT AS ReversedDocument
FROM [Your BKPF accounting document source] b
WHERE b.CREATED_AT >= '[Start timestamp]'
AND b.CREATED_AT < '[End timestamp]'
AND b.COMPANY_CODE IN ([Company code filter])
),
journal_attributes AS (
SELECT
a.COMPANY_CODE AS CompanyCode,
a.FISCAL_YEAR AS FiscalYear,
a.ACCOUNTING_DOCUMENT AS AccountingDocument,
MAX(a.VENDOR_NO) AS VendorNumber,
SUM(a.AMOUNT_IN_COMPANY_CODE_CURRENCY) AS AmountInCompanyCodeCurrency,
MAX(a.PURCHASING_DOCUMENT) AS PurchasingDocument,
MAX(a.CLEARING_DATE) AS ClearingDate,
MAX(a.CLEARING_DOCUMENT) AS ClearingDocument
FROM [Your ACDOCA universal journal source] a
WHERE a.COMPANY_CODE IN ([Company code filter])
AND a.POSTING_DATE >= '[Start date]'
AND a.POSTING_DATE < '[End date]'
GROUP BY
a.COMPANY_CODE,
a.FISCAL_YEAR,
a.ACCOUNTING_DOCUMENT
),
source_events AS (
SELECT
e.INV_DOC_NO AS InvoiceNumber,
e.COMPANY_CODE AS CompanyCode,
e.FISCAL_YEAR AS FiscalYear,
e.EVENT_TIMESTAMP AS EventTime,
e.EVENT_USER AS UserName,
e.PAYMENT_BLOCK_REASON AS PaymentBlockReason,
e.PURCHASING_DOCUMENT AS PurchasingDocument,
e.VENDOR_NO AS VendorNumber,
e.AMOUNT_IN_COMPANY_CODE_CURRENCY AS AmountInCompanyCodeCurrency,
e.PAYMENT_DUE_DATE AS PaymentDueDate,
e.DOCUMENT_TYPE AS DocumentType,
e.EVENT_TYPE AS SourceEventType
FROM [Your verified invoice event and workflow source] e
WHERE e.EVENT_TIMESTAMP >= '[Start timestamp]'
AND e.EVENT_TIMESTAMP < '[End timestamp]'
AND e.COMPANY_CODE IN ([Company code filter])
),
base_events AS (
SELECT
i.InvoiceNumber,
'Invoice Document Created' AS ActivityName,
i.InvoiceCreatedAt AS EventTime,
i.InvoiceCreatedBy AS UserName,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber) AS VendorNumber,
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)) AS PaymentBlockReason,
COALESCE(i.PurchasingDocument, j.PurchasingDocument) AS PurchasingDocument
FROM invoice_base i
LEFT JOIN posted_accounting p
ON p.InvoiceNumber = i.InvoiceNumber
AND p.CompanyCode = i.CompanyCode
AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j
ON j.CompanyCode = p.CompanyCode
AND j.FiscalYear = p.FiscalYear
AND j.AccountingDocument = p.AccountingDocument
WHERE i.InvoiceCreatedAt IS NOT NULL
UNION ALL
SELECT
s.InvoiceNumber,
'Invoice Parked' AS ActivityName,
s.EventTime,
s.UserName,
s.CompanyCode,
COALESCE(s.VendorNumber, i.VendorNumber) AS VendorNumber,
COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency) AS AmountInCompanyCodeCurrency,
COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS PaymentDueDate,
COALESCE(s.DocumentType, i.DocumentType) AS DocumentType,
s.PaymentBlockReason,
COALESCE(s.PurchasingDocument, i.PurchasingDocument) AS PurchasingDocument
FROM source_events s
LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PARKED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Sent For Approval', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'SENT_FOR_APPROVAL'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Approved', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'APPROVED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Rejected', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'REJECTED'
UNION ALL
SELECT s.InvoiceNumber, 'Invoice Data Updated', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'DATA_UPDATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Set', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_SET'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Block Removed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_BLOCK_REMOVED'
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Posted',
p.PostedAt,
p.PostedBy,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN posted_accounting p ON p.InvoiceNumber = i.InvoiceNumber AND p.CompanyCode = i.CompanyCode AND p.FiscalYear = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.CompanyCode AND j.FiscalYear = p.FiscalYear AND j.AccountingDocument = p.AccountingDocument
WHERE p.PostedAt IS NOT NULL
UNION ALL
SELECT s.InvoiceNumber, 'Payment Proposal Created', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_PROPOSAL_CREATED'
UNION ALL
SELECT s.InvoiceNumber, 'Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
UNION ALL
SELECT s.InvoiceNumber, 'Late Payment Executed', s.EventTime, s.UserName, s.CompanyCode, COALESCE(s.VendorNumber, i.VendorNumber), COALESCE(s.AmountInCompanyCodeCurrency, i.AmountInCompanyCodeCurrency), COALESCE(s.PaymentDueDate, i.PaymentDueDate), COALESCE(s.DocumentType, i.DocumentType), s.PaymentBlockReason, COALESCE(s.PurchasingDocument, i.PurchasingDocument)
FROM source_events s LEFT JOIN invoice_base i ON i.InvoiceNumber = s.InvoiceNumber AND i.CompanyCode = s.CompanyCode AND i.FiscalYear = s.FiscalYear
WHERE s.SourceEventType = 'PAYMENT_EXECUTED'
AND s.EventTime > CAST(COALESCE(s.PaymentDueDate, i.PaymentDueDate) AS TIMESTAMP)
UNION ALL
SELECT
i.InvoiceNumber,
'Invoice Reversed',
p.ReversalEventAt,
p.ReversalUser,
i.CompanyCode,
COALESCE(i.VendorNumber, j.VendorNumber),
COALESCE(i.AmountInCompanyCodeCurrency, j.AmountInCompanyCodeCurrency),
i.PaymentDueDate,
i.DocumentType,
CAST(NULL AS NVARCHAR(20)),
COALESCE(i.PurchasingDocument, j.PurchasingDocument)
FROM invoice_base i
INNER JOIN [Your verified reversal event source] p ON p.INV_DOC_NO = i.InvoiceNumber AND p.COMPANY_CODE = i.CompanyCode AND p.FISCAL_YEAR = i.FiscalYear
LEFT JOIN journal_attributes j ON j.CompanyCode = p.COMPANY_CODE AND j.FiscalYear = p.FISCAL_YEAR AND j.AccountingDocument = p.ACCOUNTING_DOCUMENT
WHERE p.ReversalEventAt IS NOT NULL
)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
CompanyCode,
VendorNumber,
AmountInCompanyCodeCurrency,
PaymentDueDate,
DocumentType,
PaymentBlockReason,
PurchasingDocument
FROM base_events
WHERE InvoiceNumber IS NOT NULL
AND EventTime IS NOT NULL
ORDER BY InvoiceNumber, EventTime, ActivityName; Passaggi
- Acceda all’editor ABAP: Acceda al sistema SAP S/4HANA. Apra la transazione
SE38(editor ABAP). - Crei il programma: Inserisca un nome per il nuovo programma nel campo Programma, ad esempio
Z_PM_INVOICE_EXTRACT, e selezioni il pulsante 'Crea'. Inserisca un titolo, imposti il tipo su 'Programma eseguibile' e salvi il programma in un package appropriato. - Definisca la struttura del programma e la schermata di selezione: Nell’editor, definisca le strutture dati per l’output finale dell’Event Log. Crei quindi una schermata di selezione che consenta agli utenti di inserire parametri come l’intervallo di date di registrazione della fattura, i codici società e i tipi di documento. In questo modo il programma sarà riutilizzabile e flessibile.
- Implementi la logica di selezione dei dati: Scriva le istruzioni ABAP SQL principali per selezionare i dati dalle diverse tabelle SAP. Il programma eseguirà query in sequenza per ciascuna delle 13 attività richieste.
- Estragga i dati di testata e di riga: Per gli eventi fondamentali, come 'Documento fattura creato' e 'Fattura registrata', selezioni i dati dalle tabelle principali, ad esempio
RBKP(testata fattura logistica) eBKPF(testata documento contabile). - Estragga i dati dei documenti di modifica: Per attività come 'Blocco del pagamento impostato' e 'Blocco del pagamento rimosso', interroghi le tabelle dei documenti di modifica
CDHDR(testata del documento di modifica) eCDPOS(righe del documento di modifica). Dovrà individuare le modifiche a campi specifici, ad esempioZLSPRnella tabellaBSEG. - Estragga i dati dei pagamenti: Per acquisire le attività relative ai pagamenti, interroghi tabelle come
REGUP(righe elaborate dal programma di pagamento) per le proposte di pagamento eBSAK(partite fornitore compensate) per i pagamenti eseguiti. Distingua l’attività 'Pagamento in ritardo eseguito' confrontando la data di compensazione (AUGDT) con la data di scadenza netta (ZFBDT). - Estragga i dati del flusso di lavoro: Per le attività di approvazione, interroghi le tabelle SAP Business Workflow, come
SWW_WI2OBJ, per collegare gli elementi del flusso di lavoro agli oggetti fattura. Questa parte dipende in larga misura dalla configurazione specifica del flusso di lavoro e potrebbe richiedere modifiche sostanziali. - Riunisca i dati nel formato Event Log: Per ogni attività selezionata, formatti i dati in una struttura di tabella interna comune. Ogni riga della tabella rappresenta un singolo evento e deve contenere l’identificativo del caso (
InvoiceNumber),ActivityNameedEventTime, oltre agli altri attributi consigliati. - Generi il file di output: Utilizzi le istruzioni ABAP
OPEN DATASET,TRANSFEReCLOSE DATASETper scrivere il contenuto della tabella interna finale in un file semplice sul server applicativo SAP. Si consiglia il formato CSV (valori separati da virgola). - Pianifichi ed esegua il programma: Per i test, esegua il programma in primo piano utilizzando
F8. Per le esecuzioni in produzione, lo pianifichi come job in background tramite la transazioneSM36, in orari di minore attività, così da non incidere sulle prestazioni del sistema. - Recuperi il file e lo carichi: Utilizzi la transazione
AL11per raggiungere la directory del server applicativo in cui è stato salvato il file. Scarichi il file nel sistema locale. Prima di caricarlo nello strumento di Process Mining, verifichi che sia codificato in UTF-8 e formattato correttamente.
Configurazione
- Intervallo di date: Definisca un intervallo di date specifico per l’estrazione, basato sulla data di inserimento della fattura (
RBKP-CPUDT) o sulla data di registrazione (BKPF-BUDAT). Per l’analisi iniziale si consiglia un periodo da 3 a 6 mesi, così da mantenere gestibile il volume dei dati. - Codice società (BUKRS): È fondamentale filtrare per uno o più codici società. Estrarre i dati di tutte le società di una grande organizzazione può comportare tempi di esecuzione molto lunghi e file di grandi dimensioni.
- Tipo di documento (BLART): Applichi un filtro sui tipi di documento pertinenti per isolare le fatture dei fornitori. Tra i tipi più comuni figurano 'RE' (fattura lorda) e 'KR' (fattura fornitore). In questo modo si escludono dall’analisi i documenti non pertinenti.
- Conto fornitore (LIFNR): Il programma può includere un filtro facoltativo per numeri di fornitore specifici, utile per analisi mirate o test.
- Configurazione del file di output: Il programma dovrebbe prevedere parametri per definire il percorso del file di output sul server applicativo e il delimitatore dei campi, ad esempio una virgola o un punto e virgola.
- Prerequisiti: L’utente o l’account di sistema che esegue il programma deve disporre dell’accesso da sviluppatore per creare ed eseguire programmi ABAP tramite
SE38e di ampie autorizzazioni di lettura per le tabelle FI, MM e Basis, incluseBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSe le tabelle del flusso di lavoro.
Query di esempio abap
REPORT Z_PM_INVOICE_EXTRACT.
* --- Internal table structure for the final event log
TYPES: BEGIN OF ty_s_event_log,
invoicenumber TYPE char25,
activityname TYPE char50,
eventtime TYPE char19, "YYYY-MM-DD HH:MM:SS
username TYPE sy-uname,
companycode TYPE bukrs,
vendornumber TYPE lifnr,
amountincompanycodecurrency TYPE wrbtr,
paymentduedate TYPE char10, "YYYY-MM-DD
documenttype TYPE blart,
paymentblockreason TYPE char1,
purchasingdocument TYPE ebeln,
END OF ty_s_event_log.
DATA: lt_event_log TYPE STANDARD TABLE OF ty_s_event_log.
DATA: ls_event_log TYPE ty_s_event_log.
* --- Selection Screen for user inputs
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/tmp/invoice_events.csv'.
SELECT-OPTIONS: s_erdat FOR sy-datum OBLIGATORY, " Entry Date
s_bukrs FOR bkpf-bukrs OBLIGATORY, " Company Code
s_blart FOR bkpf-blart. " Document Type
START-OF-SELECTION.
* --- 1. Invoice Document Created (from Logistics Invoice Verification)
SELECT CONCAT( rbkp~belnr, rbkp~gjahr ) AS invoicenumber,
'Invoice Document Created' AS activityname,
CONCAT( rbkp~cpudt, rbkp~cputm ) AS eventtime,
rbkp~usnam AS username,
rbkp~bukrs AS companycode,
rbkp~lifnr AS vendornumber,
rbkp~rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
rbkp~blart AS documenttype,
rbkp~zuonr AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_created)
WHERE rbkp~cpudt IN @s_erdat
AND rbkp~bukrs IN @s_bukrs
AND rbkp~blart IN @s_blart.
LOOP AT lt_created INTO DATA(ls_created).
ls_event_log-invoicenumber = ls_created-invoicenumber.
ls_event_log-activityname = ls_created-activityname.
ls_event_log-eventtime = |{ ls_created-eventtime(8) } { ls_created-eventtime+8(2) }:{ ls_created-eventtime+10(2) }:{ ls_created-eventtime+12(2) }|.
ls_event_log-username = ls_created-username.
ls_event_log-companycode = ls_created-companycode.
ls_event_log-vendornumber = ls_created-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_created-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_created-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ls_created-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 2. Invoice Parked (assuming status 'A' or 'B' in RBKP)
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
'Invoice Parked' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
lifnr AS vendornumber,
rmwwr AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM rbkp
INTO TABLE @DATA(lt_parked)
WHERE rbstat IN ('A', 'B')
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs
AND blart IN @s_blart.
LOOP AT lt_parked INTO DATA(ls_parked).
ls_event_log-invoicenumber = ls_parked-invoicenumber.
ls_event_log-activityname = ls_parked-activityname.
ls_event_log-eventtime = |{ ls_parked-eventtime(8) } { ls_parked-eventtime+8(2) }:{ ls_parked-eventtime+10(2) }:{ ls_parked-eventtime+12(2) }|.
ls_event_log-username = ls_parked-username.
ls_event_log-companycode = ls_parked-companycode.
ls_event_log-vendornumber = ls_parked-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_parked-amountincompanycodecurrency.
ls_event_log-paymentduedate = ''.
ls_event_log-documenttype = ls_parked-documenttype.
ls_event_log-paymentblockreason = ''.
ls_event_log-purchasingdocument = ''.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 3, 4, 5. Sent For Approval, Approved, Rejected (Placeholder logic, needs adaptation)
* --- This logic is a generic template for SAP Business Workflow.
* --- Your implementation will vary. You must identify the correct workflow tasks.
SELECT obj.instid, wi.wi_cd, wi.wi_ct, wi.wi_stat, wi.wi_aagent
FROM sww_wi2obj AS obj
JOIN swwlog AS wi ON obj~instid = wi~wi_id
INTO TABLE @DATA(lt_workflow)
WHERE obj~typeid = 'BUS2081' " Business Object for Incoming Invoice
AND obj~catid = 'BO'
AND wi~wi_cd IN s_erdat.
LOOP AT lt_workflow INTO DATA(ls_workflow).
* --- This is a placeholder, adapt task IDs and logic
CASE ls_workflow-wi_stat.
WHEN 'STARTED'.
ls_event_log-activityname = 'Invoice Sent For Approval'.
WHEN 'COMPLETED'.
ls_event_log-activityname = 'Invoice Approved'.
WHEN 'CANCELLED'.
ls_event_log-activityname = 'Invoice Rejected'.
WHEN OTHERS.
CONTINUE.
ENDCASE.
* --- Code to get invoice details based on ls_workflow-instid needed here
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 6, 7, 8. Payment Block Set/Removed, Data Updated (from Change Docs)
SELECT h~objectid, h~username, h~udate, h~utime, p~fname, p~value_new, p~value_old
FROM cdhdr AS h
JOIN cdpos AS p ON h~objectclas = p~objectclas AND h~objectid = p~objectid AND h~changenr = p~changenr
INTO TABLE @DATA(lt_changes)
WHERE h~objectclas = 'BELEGV'
AND h~udate IN s_erdat.
LOOP AT lt_changes INTO DATA(ls_change).
ls_event_log-invoicenumber = |{ ls_change-objectid+10(10) }{ ls_change-objectid(4) }|.
ls_event_log-username = ls_change-username.
ls_event_log-eventtime = |{ ls_change-udate } { ls_change-utime(2) }:{ ls_change-utime+2(2) }:{ ls_change-utime+4(2) }|.
IF ls_change-fname = 'ZLSPR'. " Payment Block
IF ls_change-value_old IS INITIAL AND ls_change-value_new IS NOT INITIAL.
ls_event_log-activityname = 'Payment Block Set'.
ls_event_log-paymentblockreason = ls_change-value_new.
ELSEIF ls_change-value_old IS NOT INITIAL AND ls_change-value_new IS INITIAL.
ls_event_log-activityname = 'Payment Block Removed'.
ls_event_log-paymentblockreason = ''.
ELSE.
CONTINUE.
ENDIF.
ELSE.
ls_event_log-activityname = 'Invoice Data Updated'.
ENDIF.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 9. Invoice Posted
SELECT CONCAT( bkpf~belnr, bkpf~gjahr ) AS invoicenumber,
'Invoice Posted' AS activityname,
CONCAT( bkpf~cpudt, bkpf~cputm ) AS eventtime,
bkpf~usnam AS username,
bkpf~bukrs AS companycode,
bseg~lifnr AS vendornumber,
bseg~wrbtr AS amountincompanycodecurrency,
bseg~zfBDT AS paymentduedate,
bkpf~blart AS documenttype,
bseg~zlspr AS paymentblockreason,
bseg~ebeln AS purchasingdocument
FROM bkpf
JOIN bseg ON bkpf~bukrs = bseg~bukrs AND bkpf~belnr = bseg~belnr AND bkpf~gjahr = bseg~gjahr
INTO TABLE @DATA(lt_posted)
WHERE bkpf~cpudt IN @s_erdat
AND bkpf~bukrs IN @s_bukrs
AND bkpf~blart IN @s_blart
AND bseg~koart = 'K'. " Vendor line
LOOP AT lt_posted INTO DATA(ls_posted).
ls_event_log-invoicenumber = ls_posted-invoicenumber.
ls_event_log-activityname = ls_posted-activityname.
ls_event_log-eventtime = |{ ls_posted-eventtime(8) } { ls_posted-eventtime+8(2) }:{ ls_posted-eventtime+10(2) }:{ ls_posted-eventtime+12(2) }|.
ls_event_log-username = ls_posted-username.
ls_event_log-companycode = ls_posted-companycode.
ls_event_log-vendornumber = ls_posted-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_posted-amountincompanycodecurrency.
ls_event_log-paymentduedate = ls_posted-paymentduedate.
ls_event_log-documenttype = ls_posted-documenttype.
ls_event_log-paymentblockreason = ls_posted-paymentblockreason.
ls_event_log-purchasingdocument = ls_posted-purchasingdocument.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 10. Payment Proposal Created
SELECT CONCAT( regup~belnr, regup~gjahr ) AS invoicenumber,
'Payment Proposal Created' AS activityname,
CONCAT( reguh~erfdt, reguh~erfzt ) AS eventtime,
reguh~erfbu AS username,
regup~bukrs AS companycode,
regup~lifnr AS vendornumber,
regup~wrbtr AS amountincompanycodecurrency,
'' AS paymentduedate,
regup~blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM regup
JOIN reguh ON regup~laufd = reguh~laufd AND regup~laufi = reguh~laufi
INTO TABLE @DATA(lt_proposal)
WHERE reguh~erfdt IN @s_erdat
AND regup~bukrs IN @s_bukrs.
LOOP AT lt_proposal INTO DATA(ls_proposal).
ls_event_log-invoicenumber = ls_proposal-invoicenumber.
ls_event_log-activityname = ls_proposal-activityname.
ls_event_log-eventtime = |{ ls_proposal-eventtime(8) } { ls_proposal-eventtime+8(2) }:{ ls_proposal-eventtime+10(2) }:{ ls_proposal-eventtime+12(2) }|.
ls_event_log-username = ls_proposal-username.
ls_event_log-companycode = ls_proposal-companycode.
ls_event_log-vendornumber = ls_proposal-vendornumber.
ls_event_log-amountincompanycodecurrency = ls_proposal-amountincompanycodecurrency.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- 11, 12. Payment Executed / Late Payment Executed
SELECT CONCAT( belnr, gjahr ) AS invoicenumber,
augdt,
zfBDT
FROM bsak
INTO TABLE @DATA(lt_cleared)
WHERE augdt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_cleared INTO DATA(ls_cleared).
IF ls_cleared-augdt > ls_cleared-zfbdt.
ls_event_log-activityname = 'Late Payment Executed'.
ELSE.
ls_event_log-activityname = 'Payment Executed'.
ENDIF.
ls_event_log-invoicenumber = ls_cleared-invoicenumber.
ls_event_log-eventtime = |{ ls_cleared-augdt } 00:00:00|.
* --- Need to select other attributes based on invoice number
* --- ... appending to lt_event_log ...
ENDLOOP.
* --- 13. Invoice Reversed
SELECT CONCAT( stblg, stjah ) AS invoicenumber,
'Invoice Reversed' AS activityname,
CONCAT( cpudt, cputm ) AS eventtime,
usnam AS username,
bukrs AS companycode,
'' AS vendornumber,
'' AS amountincompanycodecurrency,
'' AS paymentduedate,
blart AS documenttype,
'' AS paymentblockreason,
'' AS purchasingdocument
FROM bkpf
INTO TABLE @DATA(lt_reversed)
WHERE stblg IS NOT NULL
AND cpudt IN @s_erdat
AND bukrs IN @s_bukrs.
LOOP AT lt_reversed INTO DATA(ls_reversed).
ls_event_log-invoicenumber = ls_reversed-invoicenumber.
ls_event_log-activityname = ls_reversed-activityname.
ls_event_log-eventtime = |{ ls_reversed-eventtime(8) } { ls_reversed-eventtime+8(2) }:{ ls_reversed-eventtime+10(2) }:{ ls_reversed-eventtime+12(2) }|.
ls_event_log-username = ls_reversed-username.
ls_event_log-companycode = ls_reversed-companycode.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
* --- Write internal table to CSV file
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
DATA: lv_line TYPE string.
FIELD-SYMBOLS: <fs_any> TYPE any.
* --- Header row
lv_line = 'InvoiceNumber,ActivityName,EventTime,UserName,CompanyCode,VendorNumber,AmountInCompanyCodeCurrency,PaymentDueDate,DocumentType,PaymentBlockReason,PurchasingDocument'.
TRANSFER lv_line TO p_path.
LOOP AT lt_event_log INTO ls_event_log.
CLEAR lv_line.
DO.
ASSIGN COMPONENT sy-index OF STRUCTURE ls_event_log TO <fs_any>.
IF sy-subrc <> 0.
EXIT.
ENDIF.
IF sy-index = 1.
lv_line = <fs_any>.
ELSE.
CONCATENATE lv_line <fs_any> INTO lv_line SEPARATED BY ','.
ENDIF.
ENDDO.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: / 'Extraction complete. File saved to:', p_path. È pronto a iniziare?
Inizi oggi a ottimizzare l’elaborazione delle fatture. Questo template è il primo passo verso miglioramenti significativi delle attività operative e una maggiore efficienza.
Ottimizzi subito l’elaborazione delle fatture P2P in SAP S/4HANA
Individui i colli di bottiglia e riduca del 30% o più il tempo di ciclo delle fatture.
Non è richiesta la carta di credito. La configurazione richiede pochi minuti.