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
Purchase to Pay - Attributi dell’elaborazione delle fatture
| Nome | Descrizione | ||
|---|---|---|---|
| Numero fattura InvoiceNumber | L'identificativo univoco del documento di fattura del fornitore, che funge da identificativo principale della pratica nel processo. | ||
| Descrizione Il numero fattura è l'identificativo univoco assegnato a ciascuna fattura del fornitore in SAP S/4HANA. Collega tutte le attività correlate, come creazione, parcheggio, approvazione e pagamento, in un'unica istanza di processo coerente. Nel Process Mining, questo attributo è fondamentale per monitorare il percorso end-to-end di ogni fattura. Consente di ricostruire l'intero flusso di processo, dalla ricezione al pagamento finale, permettendo di analizzare i tempi di ciclo, i colli di bottiglia e le variazioni del processo a livello di singola fattura. Perché è importante È la chiave essenziale per collegare tutti gli eventi correlati e ottenere una traccia completa del ciclo di vita della fattura nel sistema. Dove reperirlo Si tratta del numero del documento contabile, disponibile nella tabella BKPF, campo BELNR. Esempi 190000000119000000451900000132 | |||
| Nome attività ActivityName | Il nome dell'attività aziendale o dell'evento che si è verificato in un momento specifico per una fattura. | ||
| Descrizione Il nome attività descrive un passaggio specifico o una modifica di stato nel ciclo di elaborazione della fattura. Tra gli esempi figurano 'Documento fattura creato', 'Fattura inviata per approvazione', 'Blocco del pagamento impostato' e 'Pagamento eseguito'. Questo attributo è fondamentale per costruire la mappa del processo, che rappresenta visivamente il flusso delle attività. L'analisi della sequenza, della frequenza e della durata tra queste attività aiuta a identificare colli di bottiglia, cicli di rilavorazione e variazioni del processo non conformi. Costituisce la base di qualsiasi analisi di Process Mining. Perché è importante Definisce i passaggi del processo, consentendo di visualizzare le mappe di processo e analizzare i flussi e le variazioni del processo. Dove reperirlo Derivato dalla combinazione dei codici transazione SAP (SY-TCODE), degli stati degli oggetti dei documenti di modifica (CDHDR/CDPOS) e di specifici valori dei campi che indicano modifiche di stato. Esempi Fattura parcheggiataFattura approvataPagamento eseguito | |||
| Ora dell'evento EventTime | La data e l'ora precise in cui si è verificata l'attività. | ||
| Descrizione L'ora dell'evento è il timestamp che registra con precisione il momento in cui si è verificata una specifica attività. Questi dati sono essenziali per calcolare durate, tempi di ciclo e tempi di attesa tra le diverse fasi del processo. Nell'analisi di Process Mining, timestamp accurati vengono utilizzati per misurare KPI di performance come 'Tempo medio del ciclo della fattura' e 'Tempo del ciclo di approvazione della fattura'. Analizzando il tempo trascorso tra le attività, le organizzazioni possono individuare i colli di bottiglia in cui le fatture subiscono ritardi e identificare opportunità per accelerare il processo. Perché è importante Questo timestamp costituisce la base di tutte le analisi basate sul tempo, inclusi il monitoraggio delle performance, l'identificazione dei colli di bottiglia e il monitoraggio degli SLA. Dove reperirlo Proviene generalmente dalle tabelle dei documenti di modifica CDHDR (intestazione) e CDPOS (posizione), utilizzando i campi UDATE e UTIME. Per alcuni eventi può provenire 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 la quale la fattura deve essere pagata per evitare che il pagamento risulti in ritardo. | ||
| Descrizione La data di scadenza del pagamento è la data calcolata entro la quale deve essere effettuato 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 il KPI 'Tasso di puntualità dei pagamenti' e per il Dashboard 'Performance dei pagamenti ai fornitori'. Confrontando la data effettiva del pagamento con la data 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 riferimento per misurare la puntualità dei pagamenti, un aspetto fondamentale per mantenere buoni rapporti con i fornitori ed evitare penali per ritardi. Dove reperirlo Questa data è spesso disponibile direttamente nella posizione del fornitore nella tabella BSEG, campo ZFBDT (data di riferimento per il calcolo della scadenza). La data di scadenza netta viene calcolata a partire da questa data di riferimento e dai termini di pagamento. Esempi 2023-05-302023-06-152023-07-01 | |||
| Importo fattura AmountInCompanyCodeCurrency | L'importo lordo totale della fattura nella valuta locale della società. | ||
| Descrizione Questo attributo rappresenta il valore totale della fattura. È una metrica fondamentale per comprendere l'impatto finanziario e la portata delle attività di elaborazione delle fatture. L'analisi degli importi delle fatture aiuta a dare priorità alle fatture di valore elevato per un'elaborazione più rapida, identificare le tendenze di spesa e correlare i problemi di processo al valore finanziario. Ad esempio, può essere utilizzata per verificare se le fatture di importo elevato hanno maggiori probabilità di essere bloccate o di richiedere tempi di approvazione più lunghi. Perché è importante Fornisce un contesto finanziario al processo, consentendo analisi basate sul valore monetario, ad esempio per identificare se le fatture di importo elevato vengono elaborate in modo diverso. Dove reperirlo Questo valore deriva generalmente dalla somma delle posizioni pertinenti nella tabella BSEG, campo WRBTR (importo nella valuta locale). Esempi 1500.75125000.00850.20 | |||
| Motivo del blocco del pagamento PaymentBlockReason | Un codice che indica il motivo per cui una fattura è bloccata e non può essere pagata. | ||
| Descrizione Quando una fattura viene bloccata per il pagamento, questo attributo indica il motivo specifico del blocco, ad esempio 'Discrepanza nella quantità' o 'Prezzo non corrispondente'. Questi motivi sono configurati in SAP per standardizzare la gestione delle eccezioni. Questo attributo è fondamentale per il Dashboard 'Frequenza e durata dei blocchi di pagamento'. L'analisi della frequenza dei diversi motivi di blocco aiuta a identificare le cause principali dei ritardi nei pagamenti, come problemi legati a specifici fornitori, materiali o processi interni, consentendo di adottare azioni correttive mirate. Perché è importante Fornisce la causa principale specifica dei blocchi di pagamento, consentendo analisi mirate per ridurre i ritardi e migliorare l'elaborazione corretta al primo tentativo. Dove reperirlo Si trova nella posizione del fornitore della tabella BSEG, campo ZLSPR (Payment Block Key). 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ò trattarsi dell'ID utente di una persona o dell'ID di sistema utilizzato per i processi batch automatizzati. L'analisi per utente aiuta a comprendere la distribuzione del carico di lavoro, individuare le esigenze formative e rilevare comportamenti anomali. Ad esempio, può evidenziare quali utenti gestiscono più frequentemente le eccezioni o quali fatture vengono elaborate automaticamente, come quelle gestite dall'utente 'BATCHUSER', un elemento fondamentale per calcolare il KPI 'Tasso di automazione delle fatture'. Perché è importante Attribuisce le attività del processo a utenti o account di sistema specifici, consentendo di analizzare il carico di lavoro e le performance e di rilevare le attività automatizzate. Dove reperirlo Proviene da campi come BKPF-USNAM (Inserito da) o CDHDR-USERNAME (Modificato da). Esempi SMITHJMUELLERTWF-BATCH | |||
| Numero fornitore VendorNumber | L'identificativo univoco del fornitore che ha emesso la fattura. | ||
| Descrizione Il numero fornitore identifica il fornitore o creditore associato alla fattura. Collega la transazione della fattura ai dati anagrafici del fornitore. Questo attributo è fondamentale per le analisi incentrate sui fornitori, ad esempio per valutare le 'Performance dei pagamenti ai fornitori' o identificare i fornitori che inviano frequentemente fatture problematiche, causa di eccezioni o blocchi dei pagamenti. Aiuta a gestire i rapporti con i fornitori e a valutarne l'affidabilità. Perché è importante Consente di analizzare le performance del processo per fornitore, aiutando a identificare schemi ricorrenti, gestire i rapporti e valutare i problemi legati ai fornitori. Dove reperirlo Si trova generalmente nella tabella delle posizioni del documento contabile BSEG, campo LIFNR. Esempi 100345700012V9832 | |||
| Ordine di acquisto PurchasingDocument | Il 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 processo di three-way match, che verifica la fattura rispetto all'ordine di acquisto e alla ricezione della merce. L'analisi per questo attributo aiuta a comprendere i problemi relativi alle fatture associate a un ordine di acquisto rispetto a quelle non associate. È fondamentale per analizzare le discrepanze di matching e comprendere l'efficienza della componente di approvvigionamento del processo. Perché è importante Collega la fattura al processo di approvvigionamento, essenziale per analizzare le discrepanze di matching e la conformità agli ordini di acquisto. Dove reperirlo Questa informazione si trova generalmente nella tabella delle posizioni del documento BSEG, campo EBELN (numero del documento di acquisto). Esempi 450000123445000056784500009012 | |||
| Società CompanyCode | L'unità organizzativa che rappresenta una società legalmente indipendente per la quale vengono redatti i bilanci. | ||
| 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 performance del processo tra diverse unità aziendali, entità giuridiche o Paesi. Aiuta a identificare differenze regionali in termini di efficienza, conformità e livelli di automazione, supportando iniziative di miglioramento mirate. Perché è importante Consente di segmentare e confrontare le performance dell'elaborazione delle fatture tra diverse entità giuridiche o aree geografiche dell'organizzazione. Dove reperirlo È un campo standard nella tabella di intestazione dei documenti BKPF, campo BUKRS. Esempi 1000US01DE01 | |||
| Tipo di documento DocumentType | Un codice che classifica diversi tipi di documenti contabili, come fatture dei fornitori o note di credito. | ||
| Descrizione Il tipo di documento viene utilizzato in SAP per distinguere tra diverse transazioni aziendali. Ad esempio, 'KR' rappresenta generalmente una fattura standard del fornitore, mentre 'KG' può indicare una nota di credito del fornitore. L'analisi per tipo di documento consente di segmentare il processo per comprendere come vengono gestiti i diversi tipi di transazione. Ad esempio, il processo relativo a una nota di credito può differire significativamente da quello di una fattura standard. Questa segmentazione fornisce insight di processo più accurati e pertinenti. Perché è importante Aiuta a distinguere tra diversi tipi di transazioni finanziarie, come fatture standard e note di credito, che spesso seguono percorsi di processo differenti. Dove reperirlo Si trova nella tabella di intestazione dei documenti BKPF, campo BLART. Esempi KRREKG | |||
| Data fattura InvoiceDate | La data in cui il fornitore ha emesso il documento di fattura. | ||
| Descrizione La data fattura, nota anche come data del 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 di pagamento 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 input essenziale per il KPI 'Tasso di acquisizione degli sconti per pagamento anticipato'. Perché è importante Funge da riferimento per il calcolo dei termini di pagamento e delle date di scadenza, essenziale per la gestione del capitale circolante e l'acquisizione degli sconti. Dove reperirlo Si trova nella tabella di intestazione dei documenti BKPF, campo BLDAT (data del documento). Esempi 2023-04-122023-05-152023-06-20 | |||
| È automatizzata IsAutomated | Un indicatore che segnala se un'attività è stata eseguita da un utente di sistema automatizzato. | ||
| Descrizione Questo attributo booleano è impostato su true se l'utente associato a un'attività è un account di sistema o batch noto, come 'WF-BATCH' o 'SAP_SYSTEM'. Aiuta a distinguere tra fasi del processo manuali e automatizzate. Questo attributo è essenziale per calcolare il KPI 'Tasso di automazione delle fatture'. Analizzando quali parti del processo sono automatizzate, le organizzazioni possono misurare il successo delle iniziative di automazione e identificare ulteriori opportunità per ridurre il lavoro manuale e migliorare l'efficienza. Perché è importante Distingue tra attività manuali e attività gestite dal sistema, un elemento fondamentale per misurare i tassi di automazione e identificare ulteriori opportunità di automazione. Dove reperirlo Derivato dall'attributo UserName. Viene creata una mappatura o una regola per classificare specifici ID utente come 'automatizzati'. Esempi truefalse | |||
| È rilavorata IsRework | Un indicatore che segnala se una fattura è stata sottoposta ad attività di rilavorazione, come un'approvazione rifiutata o la rimozione di un blocco del pagamento. | ||
| Descrizione Questo attributo contrassegna le fatture che hanno attraversato uno o più cicli di rilavorazione. La rilavorazione viene identificata da specifiche sequenze di attività, ad esempio 'Fattura approvata' dopo 'Fattura rifiutata' oppure 'Blocco del pagamento rimosso' dopo 'Blocco del pagamento impostato'. Questo attributo semplifica il calcolo del KPI 'Tasso di rilavorazione delle fatture'. Consente agli analisti di isolare e analizzare facilmente i casi con rilavorazione, per comprenderne le cause principali di inefficienza e il ripetersi delle attività manuali. Perché è importante Identifica i flussi di processo inefficienti in cui il lavoro deve essere ripetuto, aiutando a quantificare gli sprechi e individuare le cause principali delle eccezioni di processo. Dove reperirlo Calcolato in base alla sequenza delle attività nell'event log. Ad esempio, se nel trace di una fattura compare 'Fattura rifiutata', questo indicatore viene impostato su true. Esempi truefalse | |||
| ID del sistema di origine SourceSystemId | L'identificativo del sistema SAP S/4HANA di origine dal quale 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. Ai fini dell'analisi, consente di confrontare le performance dei processi tra sistemi o regioni diversi. Garantisce la provenienza dei dati ed è fondamentale per la governance dei dati e la risoluzione dei problemi quando i dati provenienti da più fonti vengono combinati in una piattaforma centrale di Process Mining. Perché è importante Fornisce il contesto sull'origine dei dati, essenziale per la governance dei dati e per confrontare i processi tra sistemi o sedi aziendali diversi. Dove reperirlo Questo valore deriva generalmente dall'ID del sistema SAP (sy-sysid) durante l'estrazione dei dati oppure viene configurato come valore statico nella pipeline ETL. Esempi S4PS4H_PROD_100ECC_EU | |||
| Motivo dello storno ReversalReason | Un codice che indica il motivo per cui un documento di 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 'Data di registrazione errata' o 'Errore di inserimento dati'. L'analisi dei motivi degli storni aiuta a identificare gli schemi ricorrenti di errore nel processo di registrazione delle fatture. Questi insight possono essere utilizzati per migliorare la formazione, potenziare i controlli di sistema o affrontare i problemi ricorrenti che generano rilavorazioni finanziarie e oneri amministrativi. Perché è importante Spiega perché le fatture sono state annullate, fornendo insight diretti sulle fonti di errore e rilavorazione nel processo di registrazione. Dove reperirlo Si trova nell'intestazione del documento originale nella tabella BKPF, campo STGRD (motivo dello storno). Esempi 010205 | |||
| N. documento di compensazione. ClearingDocumentNumber | Il numero del documento che compensa la fattura, generalmente il documento di pagamento. | ||
| Descrizione Il numero del documento di compensazione collega una posizione di fattura aperta alla transazione che la compensa, quasi sempre il documento di pagamento. Ciò conferma che la fattura è stata pagata. Questo attributo costituisce il collegamento definitivo tra una fattura e il relativo pagamento. Viene utilizzato per identificare l'attività 'Pagamento eseguito' e il relativo timestamp, essenziali per calcolare il tempo di ciclo end-to-end e il tasso di puntualità dei pagamenti. Perché è importante Conferma che una fattura è stata pagata e la collega alla specifica transazione di pagamento, un elemento fondamentale per l'analisi dei tempi di ciclo e delle performance dei pagamenti. Dove reperirlo Si trova nella tabella delle posizioni del documento BSEG, campo AUGBL (numero del documento di compensazione). Esempi 150000000115000000231500000088 | |||
| Numero di cicli di approvazione ApprovalCycleCount | Il numero di volte in cui una fattura è stata inviata per l'approvazione. | ||
| Descrizione Questa metrica conta il numero di volte in cui l'attività 'Fattura inviata per approvazione' si verifica per una singola fattura. Un valore superiore a uno indica che la fattura è stata rifiutata o restituita almeno una volta, rendendo necessario un nuovo ciclo di approvazione. Questo attributo supporta direttamente il KPI 'Tasso di approvazione al primo passaggio'. Analizzando le fatture con un numero elevato di cicli di approvazione, le organizzazioni possono identificare le cause delle approvazioni non riuscite, come informazioni insufficienti o codifiche errate, e adottare misure per migliorare il processo. Perché è importante Quantifica la rilavorazione nel sottoprocesso di approvazione, aiutando a misurare il tasso di correttezza al primo tentativo e identificare i motivi dei rifiuti in fase di approvazione. Dove reperirlo Calcolato contando le occorrenze dell'attività 'Fattura inviata per approvazione' per ogni InvoiceNumber univoco. Esempi 123 | |||
| Pagata puntualmente IsPaidOnTime | Un indicatore impostato su true se la fattura è stata pagata entro o prima della data di scadenza del pagamento. | ||
| Descrizione Questo attributo booleano deriva dal confronto tra la data effettiva del pagamento, ovvero il timestamp dell'attività 'Pagamento eseguito', e la 'Data di scadenza del pagamento'. Fornisce un risultato chiaro e binario per lo stato del pagamento di ogni fattura. Costituisce il calcolo principale del KPI 'Tasso di puntualità dei pagamenti'. Consente di filtrare e analizzare facilmente le caratteristiche dei pagamenti in ritardo, come i fornitori, le società o gli importi delle fatture più frequentemente associati ai ritardi. Perché è importante Misura direttamente il rispetto dei termini di pagamento, un KPI fondamentale per la gestione dei rapporti con i fornitori e delle attività finanziarie. Dove reperirlo Calcolato confrontando l'EventTime dell'attività 'Pagamento eseguito' con l'attributo PaymentDueDate. (Payment Date <= PaymentDueDate). Esempi truefalse | |||
| Termini di pagamento PaymentTerms | Il codice che definisce le condizioni di pagamento concordate con il fornitore, come date di scadenza e periodi di sconto. | ||
| Descrizione I termini di pagamento definiscono le regole per il pagamento di una fattura, inclusi eventuali sconti disponibili per il pagamento anticipato. Ad esempio, 'Z030' può significare 'Pagabile 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, supportando direttamente il KPI 'Tasso di acquisizione degli sconti per pagamento anticipato'. Perché è importante Definisce le regole per le date di scadenza dei pagamenti e gli sconti, influenzando direttamente i KPI sulla puntualità dei pagamenti e la gestione del capitale circolante. Dove reperirlo Si trova nella posizione del fornitore nella tabella BSEG, campo ZTERM (chiave dei termini di pagamento). Esempi 0001Z030NT60 | |||
| Timestamp di estrazione ExtractionTimestamp | La data e l'ora in cui i dati sono stati estratti dal sistema di origine. | ||
| Descrizione Questo attributo registra il timestamp dell'estrazione dei dati. Riflette l'aggiornamento dei dati analizzati nello strumento di Process Mining. Nell'analisi, viene utilizzato per comprendere quanto siano recenti gli insight generati. È fondamentale per i Dashboard di monitoraggio operativo, così da garantire che le decisioni si basino su informazioni aggiornate e gestire in modo efficace i cicli di aggiornamento dei dati. Perché è importante Indica l'aggiornamento dei dati, garantendo che analisi e report si basino sulle informazioni più recenti disponibili. Dove reperirlo Non si tratta di 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 | |||
Purchase to Pay - Attività di elaborazione delle fatture
| Attività | Descrizione | ||
|---|---|---|---|
| Documento di fattura creato | Questo è il primo evento e indica la creazione di un documento di fattura in SAP. Può essere acquisito quando un utente salva un nuovo documento di fattura, che potrebbe trovarsi nello stato parcheggiato o pre-registrato. | ||
| 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 altri è fondamentale per misurare il tempo di attraversamento complessivo dell’elaborazione. Dove reperirlo Questo evento viene acquisito dalla data e dall’ora di creazione (CPUDT, CPUTM) nella tabella di testata del documento, generalmente BKPF o RBKP per le fatture logistiche. Il codice transazione (BKPF-TCODE), ad esempio FB60, MIRO o MIR7, indica il metodo di creazione. Acquisizione Utilizzi il timestamp di creazione BKPF-CPUDT e BKPF-CPUTM per il documento di fattura. Tipo di evento explicit | |||
| Fattura approvata | Questa attività indica che la fattura è stata approvata dall’autorità designata. Viene acquisita quando il Workflow di approvazione si conclude correttamente o quando viene impostato un indicatore di rilascio. | ||
| Perché è importante Si tratta di una milestone fondamentale, che sblocca la fattura per il pagamento. I ritardi nelle approvazioni sono un collo di bottiglia frequente e il monitoraggio di questa attività aiuta a individuare gli approvatori o i passaggi più lenti. Dove reperirlo Può essere dedotto dal passaggio finale di rilascio in un Workflow SAP oppure monitorando le modifiche ai campi dello stato di rilascio nelle tabelle associate alla fattura o al relativo documento di acquisto. Acquisizione Lo deduca dagli eventi di completamento del Workflow o dalle modifiche al campo dello stato di rilascio del documento. Tipo di evento inferred | |||
| Fattura registrata | Si tratta di un evento finanziario fondamentale, durante il quale la fattura parcheggiata o approvata viene registrata formalmente nella contabilità generale. Questa operazione rileva la passività nei confronti del fornitore. | ||
| Perché è importante La registrazione costituisce una tappa fondamentale, che separa l'inserimento e l'approvazione dei dati dalla fase di regolamento finanziario. Il tempo che intercorre tra la creazione della fattura e la registrazione è un indicatore essenziale dell'efficienza di elaborazione interna. Dove reperirlo Questo evento viene identificato dalla data di registrazione (BKPF-BUDAT) nell'intestazione del documento. Per i documenti parcheggiati inizialmente, il passaggio allo stato registrato fornisce il timestamp dell'evento. Acquisizione Utilizzare la data di registrazione (BKPF-BUDAT) come timestamp dell'evento. Tipo di evento explicit | |||
| Fattura stornata | Attività che rappresenta lo storno di un documento di fattura registrato in precedenza. Si tratta di un evento terminale per una fattura errata, che viene spesso reinserita correttamente. | ||
| Perché è importante Gli storni indicano errori critici che non sono stati rilevati nelle fasi precedenti del processo. Monitorarne la frequenza e le cause principali è essenziale per migliorare il processo e ridurre le inesattezze finanziarie. Dove reperirlo Uno storno viene identificato quando viene creato un documento di storno. L'intestazione del documento originale (BKPF) conterrà il numero del documento di storno (BKPF-STBLG) e viceversa. La data di registrazione del documento di storno rappresenta l'ora dell'evento. Acquisizione Identificare i documenti che contengono un valore nel campo BKPF-STBLG e utilizzare la data di registrazione del documento di storno. Tipo di evento explicit | |||
| Pagamento eseguito | Questa è l'attività finale del processo standard, durante la quale il pagamento viene effettuato e la fattura viene compensata. Ciò indica che i fondi sono stati trasferiti al fornitore. | ||
| Perché è importante Questo evento segna la conclusione del ciclo di vita della fattura P2P. È essenziale per calcolare il tempo totale del ciclo end-to-end e misurare la puntualità dei pagamenti rispetto alla data di scadenza. Dove reperirlo Questo evento viene acquisito dalle informazioni sul documento di compensazione nella posizione del fornitore. La Clearing Date (BSEG-AUGDT) e il Clearing Document (BSEG-AUGBL) indicano che il pagamento è stato effettuato. Acquisizione Utilizzare la data di compensazione (BSEG-AUGDT) della posizione del fornitore compensata. Tipo di evento explicit | |||
| Blocco di pagamento impostato | Un’attività con cui viene applicato intenzionalmente un blocco a una fattura per impedirne il pagamento. Spesso ciò avviene a causa di discrepanze nel prezzo o nella quantità oppure in attesa di una nota di credito. | ||
| Perché è importante I blocchi di pagamento sono una delle principali cause di pagamenti tardivi e controversie con i fornitori. Analizzare frequenza, durata e cause dei blocchi è fondamentale per migliorare il tasso di pagamenti puntuali. Dove reperirlo Questo evento viene acquisito monitorando le modifiche al campo Payment Block Key (BSEG-ZLSPR) nella posizione della fattura. I log delle modifiche in CDHDR e CDPOS forniscono il timestamp e l’utente relativi al momento in cui il blocco è stato impostato. Acquisizione Individui il momento in cui il campo BSEG-ZLSPR viene valorizzato tramite i documenti di modifica (CDHDR/CDPOS). Tipo di evento explicit | |||
| Blocco di pagamento rimosso | Rappresenta la risoluzione di un problema: un blocco di pagamento precedentemente impostato viene rimosso. In questo modo, la fattura torna a essere idonea al pagamento. | ||
| Perché è importante Il tempo che intercorre tra l'impostazione e la rimozione di un blocco rappresenta il tempo di risoluzione di un'eccezione di processo. Ridurre questa durata è fondamentale per migliorare l'efficienza e i rapporti con i fornitori. Dove reperirlo Questo evento viene acquisito quando il campo Payment Block Key (BSEG-ZLSPR) viene cancellato. La modifica viene registrata nelle tabelle CDHDR e CDPOS, che forniscono un timestamp per la rimozione. Acquisizione Identificare il momento in cui il campo BSEG-ZLSPR viene cancellato tramite i documenti di modifica (CDHDR/CDPOS). Tipo di evento explicit | |||
| Dati della fattura aggiornati | Questa attività riflette una modifica apportata al documento di fattura dopo la sua creazione iniziale. È frequente durante i cicli di rilavorazione successivi a un rifiuto o per correggere errori. | ||
| Perché è importante Aggiornamenti frequenti segnalano rilavorazioni e possibili problemi di qualità dei dati al momento dell’inserimento. Monitorare queste modifiche aiuta a quantificare l’impegno dedicato alle correzioni e a individuare gli errori ricorrenti. Dove reperirlo Le modifiche ai campi principali vengono registrate nelle tabelle SAP dei documenti di modifica, CDHDR, la testata, e CDPOS, la posizione. Gli eventi possono essere generati filtrando le modifiche relative all’oggetto fattura. Acquisizione Estragga gli eventi di modifica dalle tabelle CDHDR e CDPOS per l’oggetto fattura. Tipo di evento explicit | |||
| Fattura inviata per l’approvazione | Questa attività indica l’avvio di un Workflow formale di approvazione della fattura. Spesso viene dedotta quando lo stato della fattura passa a “in attesa di approvazione” o quando viene generato un elemento di Workflow. | ||
| Perché è importante Questo è il punto di partenza per misurare il tempo di ciclo dell’approvazione. Comprendere quando iniziano le approvazioni è essenziale per individuare i colli di bottiglia all’interno del Workflow di approvazione. Dove reperirlo In genere viene dedotto dall’avvio di un SAP Business Workflow, nella tabella SWW_WI2OBJ, collegato all’oggetto fattura, ad esempio BUS2081, oppure da una modifica a un campo di stato personalizzato nella testata del documento. Acquisizione Lo deduca dalla creazione di un elemento di Workflow relativo al documento di fattura. Tipo di evento inferred | |||
| Fattura parcheggiata | Rappresenta una fattura inserita nel sistema ma non ancora registrata nella contabilità generale. Il parcheggio viene utilizzato per salvare fatture incomplete o sottoporle a una revisione successiva prima della registrazione. | ||
| Perché è importante Il parcheggio indica una pausa deliberata nel processo. Monitorare la durata e la frequenza delle fatture parcheggiate aiuta a individuare le cause dei ritardi prima dell’avvio del ciclo formale di registrazione e approvazione. Dove reperirlo Può essere identificato tramite documenti creati con transazioni di parcheggio, ad esempio MIR7 o FV60, oppure verificando specifici campi di stato nella tabella BKPF o in tabelle dedicate ai documenti parcheggiati, come VBKPF. Acquisizione Individui i documenti creati tramite transazioni di parcheggio oppure verifichi la presenza dello stato di documento parcheggiato. Tipo di evento explicit | |||
| Fattura rifiutata | Rappresenta il rifiuto di una fattura durante il processo di approvazione. Questo evento attiva una rilavorazione, che richiede la correzione e il nuovo invio della fattura. | ||
| Perché è importante I rifiuti delle fatture sono un indicatore importante di inefficienza del processo e di problemi nella qualità dei dati. Analizzare la frequenza e le cause dei rifiuti aiuta a individuare opportunità di miglioramento e formazione. Dove reperirlo Viene dedotto da specifici aggiornamenti di stato in un Workflow SAP, come lo stato “rifiutata”, oppure da eventi che annullano il Workflow di approvazione corrente e lo rimandano al responsabile dell’elaborazione. Acquisizione Lo deduca dalle modifiche dello stato del Workflow che indicano un rifiuto. Tipo di evento inferred | |||
| Pagamento eseguito in ritardo | Si tratta di un evento calcolato che si verifica quando il pagamento di una fattura viene eseguito dopo la relativa data di scadenza calcolata. L'evento deriva dal confronto tra due campi data. | ||
| Perché è importante Questa attività supporta direttamente i KPI relativi alla puntualità dei pagamenti e aiuta a identificare i fornitori o le unità aziendali caratterizzati da frequenti ritardi, che possono compromettere i rapporti con i fornitori e comportare penali. Dove reperirlo Il calcolo viene effettuato confrontando la data di compensazione (BSEG-AUGDT) con la data di scadenza netta. La data di scadenza viene a sua volta calcolata a partire dalla data di riferimento (BSEG-ZFBDT) e dalle condizioni di pagamento (BSEG-ZTERM). Acquisizione Derivare 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 payment run. Questo è 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 definitiva del pagamento possono evidenziare problemi nel processo di payment run, nelle approvazioni o nelle comunicazioni con la banca. Dove reperirlo Questa informazione è disponibile nelle tabelle del payment run, in particolare nella tabella REGUP, che contiene gli elementi inclusi in una proposta di pagamento. La data del run nella tabella REGUH corrispondente fornisce il timestamp. Acquisizione Identificare il momento in cui una fattura compare nella tabella REGUP a seguito di un payment proposal run. 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 CDS View richieste. Le View principali includono
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. - Individui il metodo di connessione: stabilisca come collegarsi al sistema SAP S/4HANA per eseguire la query SQL. I metodi più comuni includono 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 policy di sicurezza della Sua organizzazione.
- Definisca i parametri di estrazione: prima di eseguire la query, definisca i parametri principali. Specifichi l'intervallo di date per l'estrazione, ad esempio
CreationDatecompreso 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. Verifichi attentamente i segnaposto, come
'{StartDate}','{EndDate}'e('{CompanyCode1}', '{CompanyCode2}'). Sostituisca questi segnaposto con i valori effettivi definiti nel passaggio precedente. Potrebbe inoltre essere necessario modificare i nomi dei campi relativi allo stato del Workflow 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 essere completa e, a seconda del volume dei dati e dell'intervallo selezionato, potrebbe richiedere tempi significativi. Monitori l'esecuzione per individuare eventuali errori o timeout.
- Esamini i risultati iniziali: al termine della query, esegua una rapida verifica dell'output. Controlli che le colonne
InvoiceNumber,ActivityNameedEventTimesiano valorizzate. Verifichi inoltre che nella colonnaActivityNamesiano presenti diverse attività, non soltanto 'Invoice Document Created'. - Gestisca la trasformazione dei dati: la query è strutturata per produrre un formato Event Log pulito. Verifichi tuttavia che la colonna
EventTimeutilizzi un formato timestamp coerente, ad esempioYYYY-MM-DDTHH:MM:SS. Quando necessario, la query fornita combina i campi data e ora in un unico timestamp. - Esporti i dati: esporti il set di risultati finale dallo strumento in un file CSV (Comma-Separated Values). Questo formato è universalmente compatibile con gli strumenti di Process Mining, incluso ProcessMind.
- Prepari il caricamento: prima del caricamento, confermi che il file CSV utilizzi la codifica UTF-8, per evitare problemi con i caratteri. Verifichi che le intestazioni delle colonne corrispondano esattamente agli attributi richiesti:
InvoiceNumber,ActivityName,EventTime,UserName,CompanyCodeecc. - Carichi i dati in ProcessMind: carichi il file CSV preparato nel Suo progetto di Process Mining. Mappi le colonne del file ai campi corrispondenti per l'ID caso, il nome dell'attività e il timestamp nella configurazione del modello dati dello strumento.
Configurazione
- CDS View utilizzate: le principali fonti dati sono CDS View SAP standard. Le View principali sono
I_InvoiceDocumentper i dati di testata,I_OperationalAcctgDocItemper i dettagli di registrazione contabile e compensazione eI_ChangeDocumentconI_ChangeDocumentItemper monitorare le modifiche storiche agli attributi delle fatture, come i blocchi di pagamento e lo stato del Workflow. - Filtro per intervallo di date: per gestire le prestazioni è fondamentale filtrare i dati in base a un intervallo di date specifico. La query fornita utilizza un segnaposto per
CreationDatenella ViewI_InvoiceDocument. Come punto di partenza si consiglia un periodo di dati compreso tra 3 e 6 mesi. - Filtro per codice società: per garantire che l'estrazione sia pertinente e gestibile, applichi sempre un filtro su uno o più
CompanyCode. La query include a questo scopo il segnapostoWHERE inv.CompanyCode IN ('{CompanyCode1}', '{CompanyCode2}'). - Filtro per tipo di documento: può affinare ulteriormente l'estrazione filtrando per
InvoiceDocumentType. Ad esempio, potrebbe voler includere le fatture standard dei fornitori (RE) ed escludere le note di credito. Questo 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 speciali.
- Considerazioni sulle prestazioni: l'estrazione dei dati dalle tabelle dei documenti di modifica (
I_ChangeDocument,I_ChangeDocumentItem) può richiedere molte risorse. È essenziale applicare filtri rigorosi su data, codice società e classe oggetto (INCOMINGINVOICE) per evitare tempi di esecuzione eccessivi.
a 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
- Confermi che l'accesso diretto in lettura al tenant SAP HANA o allo schema del database sia approvato e ottenga un utente database in sola lettura, autorizzato ad accedere alle tabelle SAP richieste e alle eventuali tabelle approvate per lo storico delle modifiche o il Workflow. Utilizzi SAP HANA Database Explorer, SAP HANA Studio o un client SQL approvato. Non utilizzi l'accesso in scrittura all'ambiente di produzione.
- Confermi i nomi fisici delle tabelle e delle colonne nel sistema S/4HANA di destinazione. ACDOCA, BKPF e RBKP sono punti di partenza standard, ma gli oggetti relativi a Workflow, parcheggio, proposte di pagamento, esecuzione dei pagamenti, storico delle modifiche e storico dei blocchi di pagamento possono variare in base alla release o alle personalizzazioni 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 di inizio] e [Timestamp di fine]. Estragga un periodo sufficientemente ampio per documenti ed eventi, normalmente da tre a sei mesi, e lo estenda quando le date di scadenza o i pagamenti in ritardo possono ricadere al di fuori del periodo di creazione delle fatture.
- Identifichi i casi fattura utilizzando la chiave fattura configurata. La query usa InvoiceNumber come identificativo del caso e, quando necessario, lo combina internamente con il codice società e l'anno fiscale per evitare collisioni. Confermi se la definizione aziendale richiede di includere l'anno fiscale o il codice società nell'identificativo del caso di 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 del documento contabile e ACDOCA per fornitore, importo, documento di acquisto, compensazione e informazioni contabili relative al pagamento, ove disponibili. Non presuma che ogni campo sia valorizzato in ogni scenario di registrazione.
- Mappi gli eventi di parcheggio, approvazione, rifiuto, aggiornamento, blocco del pagamento, storno, proposta ed esecuzione del pagamento dalle fonti specifiche del sistema verificate. Sostituisca le View sorgente segnaposto con View o tabelle approvate che espongano timestamp degli eventi, riferimenti alle fatture, utenti, stati e valori precedenti e nuovi. Ogni attività deve essere prodotta 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. Esamini i piani di esecuzione e limiti la query per codice società, tipo di documento, anno fiscale e timestamp dell'evento, ove appropriato. Eviti join non limitati tra tabelle di grandi dimensioni relative a registri e storico.
- Convalidi il risultato utilizzando i controlli descritti di seguito. Confermi che ogni colonna richiesta sia presente, che
EventTimesia valorizzato per ogni evento, cheInvoiceNumbersia valorizzato per ogni caso e che tutti i 13 nomi di attività compaiano quando esistono dati sorgente 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 caso aggiuntive, utilizzi la stessa politica di chiave composta applicata durante l'estrazione.
Configurazione
- Intervallo di date: utilizzi un periodo mobile iniziale di tre-sei mesi. Includa ulteriore storico quando gli eventi di approvazione, pagamento, compensazione, storno o pagamento in ritardo possono verificarsi dopo il periodo di creazione della fattura.
- Ambito societario: applichi il filtro [Filtro codice società] e convalidi che i codici società selezionati siano autorizzati per l'estrazione.
- Ambito documentale: applichi il filtro [Filtro tipo documento] e includa i tipi di documento che rappresentano fatture dei fornitori, note di credito, fatture parcheggiate e storni nel processo di destinazione.
- Identificativo del caso: utilizzi InvoiceNumber come richiesto dalla definizione del processo. Quando i numeri delle fatture non sono univoci a livello globale, conservi il codice società e l'anno fiscale nel risultato sorgente oppure configuri una chiave caso composta secondo il modello ProcessMind.
- Fonti degli eventi: verifichi le fonti fisiche per le modifiche dello stato del Workflow, le decisioni di approvazione, il parcheggio, lo storico delle modifiche, i blocchi di pagamento, le proposte di pagamento e l'esecuzione dei pagamenti. Queste fonti variano in base alla release S/4HANA, all'ambito attivato, alla progettazione del Workflow e alle estensioni del cliente.
- Politica dei timestamp: selezioni il timestamp dell'evento aziendale, non quello di estrazione. Documenti il fuso orario e converta tutti i timestamp degli eventi in modo coerente prima del caricamento.
- Politica degli importi: utilizzi l'importo nella valuta della società e confermi che la fonte selezionata memorizzi in modo coerente i segni di dare e avere. Eviti di sommare le righe contabili, a meno che la regola di aggregazione non sia stata convalidata per il caso fattura.
- Politica dei pagamenti: definisca se Payment Executed indica la compensazione, la registrazione del documento di pagamento, l'esecuzione bancaria o un'altra milestone aziendale. Utilizzi la fonte coerente con la definizione di processo concordata.
- Pagamento in ritardo: produca Late Payment Executed solo quando Payment Executed si verifica dopo PaymentDueDate. La query calcola esplicitamente questo evento e non si basa su deduzioni di ProcessMind.
- Prestazioni: limiti le letture delle fonti per data, codice società, tipo di documento e anno fiscale pertinente. Selezioni solo le colonne necessarie, esamini i piani di query e materializzi le View intermedie approvate se lo storico sorgente è di grandi dimensioni.
- 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, Workflow e pagamenti. Confermi che siano in vigore le eventuali licenze SAP richieste, le policy di accesso al database e le approvazioni in materia di protezione dei dati.
- Sicurezza: utilizzi un utente tecnico in sola lettura, protegga i dati dei fornitori e dei pagamenti e segua le policy dell'organizzazione relative a trasporti, audit, mascheramento e gestione delle credenziali.
a 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 faccia clic sul 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 dell'Event Log finale. Crei quindi una schermata di selezione che consenta agli utenti di inserire parametri quali l'intervallo di date per la data 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 SQL ABAP 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 posizione: per gli eventi fondamentali come 'Invoice Document Created' e 'Invoice Posted', selezioni i dati da tabelle principali quali
RBKP(testata fattura logistica) eBKPF(testata documento contabile). - Estragga i dati dei documenti di modifica: per attività come 'Payment Block Set' e 'Payment Block Removed', interroghi le tabelle dei documenti di modifica
CDHDR(testata del documento di modifica) eCDPOS(posizioni del documento di modifica). Dovrà identificare le modifiche a campi specifici, ad esempioZLSPRnella tabellaBSEG. - Estragga i dati dei pagamenti: per acquisire le attività relative ai pagamenti, interroghi tabelle come
REGUP(posizioni elaborate dal programma di pagamento) per le proposte di pagamento eBSAK(posizioni fornitore compensate) per i pagamenti eseguiti. Distingua 'Late Payment Executed' confrontando la data di compensazione (AUGDT) con la data di scadenza netta (ZFBDT). - Estragga i dati del Workflow: per le attività di approvazione, interroghi le tabelle SAP Business Workflow, come
SWW_WI2OBJ, per collegare gli elementi di Workflow agli oggetti fattura. Questa parte dipende in larga misura dalla configurazione specifica del Workflow e potrebbe richiedere un adattamento significativo. - Unifichi i dati nel formato Event Log: per ogni attività selezionata, formatti i dati in una struttura di tabella interna comune. Ogni riga di questa 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 flat sul server applicativo SAP. Si consiglia il formato CSV. - Pianifichi ed esegua: esegua il programma in primo piano per i test (utilizzando
F8). Per le esecuzioni in produzione, lo pianifichi come job in background tramite la transazioneSM36, in orari di bassa attività, per evitare di incidere sulle prestazioni del sistema. - Recuperi e carichi il file: utilizzi la transazione
AL11per accedere alla directory del server applicativo in cui è stato salvato il file. Scarichi il file nel sistema locale. Verifichi che il file sia codificato in UTF-8 e formattato correttamente prima di caricarlo nello strumento di Process Mining.
Configurazione
- Intervallo di date: definisca un intervallo di date specifico per l'estrazione in base alla data di inserimento della fattura (
RBKP-CPUDT) o alla 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à. L'estrazione dei dati di tutti i codici società di una grande organizzazione può comportare tempi di esecuzione estremamente lunghi e file di grandi dimensioni.
- Tipo di documento (BLART): applichi un filtro sui tipi di documento pertinenti per isolare le fatture dei fornitori. I tipi comuni includono 'RE' (Fattura - lordo) e 'KR' (Fattura fornitore). In questo modo è possibile escludere i documenti non pertinenti dall'analisi.
- Conto fornitore (LIFNR): il programma può includere un filtro facoltativo per numeri di fornitore specifici, utile per analisi mirate o attività di 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 questo programma deve disporre dell'accesso da sviluppatore per creare ed eseguire programmi ABAP tramite
SE38, nonché di ampie autorizzazioni di lettura per le tabelle FI, MM e Basis, incluseBKPF,BSEG,RBKP,RSEG,CDHDR,CDPOSe le tabelle del Workflow.
a 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 per iniziare?
Inizi oggi stesso a ottimizzare l'elaborazione delle Sue fatture. Questo Template rappresenta il primo passo verso miglioramenti operativi significativi e una maggiore efficienza.
Ottimizzi ora l'elaborazione delle fatture P2P in SAP S/4HANA
Individui i colli di bottiglia e riduca del 30% o più il tempo del ciclo di elaborazione delle fatture.
Non è richiesta alcuna carta di credito. Configurazione in pochi minuti.