In questo paragrafo verrà illustrato il processo di caricamento sul cubo di pianificazione delle variabili relative ai costi per veicolo; il focus è dunque posto sulla parte sinistra del modello dati rappresentato in figura 4.1.
Prima della realizzazione dell’applicazione i dati relativi alle componenti che vanno a formare le variabili di pianificazione relative ai costi per veicolo venivano reperiti tramite delle query Bex costruite su strutture dati già presenti sul sistema Sap Business Warehouse aziendale.
I dati recuperati dalle query venivano in seguito armonizzati ed elaborati manualmente dagli utenti al fine di ottenere le variabili utilizzate per la redazione dei piani di budget e di forecast. Per ragioni di semplicità, rapidità d’implementazione e per avere una più agevole confrontabilità con il contesto preesistente, è stata concordata con l’azienda committente l’adozione di una strategia che sfruttasse le query già presenti a sistema per l’estrazione delle variabili di partenza. L’output delle query viene scritto all’interno delle strutture di staging che fanno da base dati all’applicazione utilizzando lo strumento dell’Analysis Process designer, descritto nel paragrafo precedente.
37
Come è possibile vedere in figura 4.1, nel modello dati implementato le query di partenza distinte sono quattro ma, utilizzando parametrizzazioni differenti applicate utilizzando delle varianti Bex, esse vanno ad alimentare sette flussi diversi.
Le query esistenti vanno a recuperare i dati dai provider che contengono le informazioni relative alle garanzie filtrando i valori su dei parametri prevalentemente temporali. I dati vengono filtrati per degli intervalli di date che possono essere:
• Date di delibera: relative all’emissione dell’ordine dei veicoli.
• Date di vendita: relative alla data di effettiva vendita del veicolo al cliente finale. • Date di esecuzione: relative all’effettiva esecuzione di un intervento di riparazione
di un veicolo in garanzia.
Si può inoltre osservare come nella parte del modello dati relativa ai C/V siano compresi 14 DSO. I vari DSO non contengono un singolo costo ma le diverse componenti a partire dalle quali, tramite gli opportuni calcoli ed aggregazioni, è possibile ricavare gli indicatori di interesse.
I DSO sono divisi su 2 livelli. Il livello inferiore è costituito da DSO a scrittura diretta che vengono cancellati prima di ogni caricamento: queste strutture contengono l’output delle query eseguite degli APD, ovvero le componenti dei costi relativi alla versione ed al ciclo di pianificazione correnti.
Nella transformation che va dal primo al secondo livello di staging, i dati vengono corredati delle informazioni relative al ciclo di pianificazione ed alla versione attivi al momento del caricamento; in questo modo sul secondo livello di staging è possibile memorizzare lo storico dei dati relativi alle versioni e ai cicli di pianificazione passati. Prima di illustrare la modalità di caricamento dati in maniera più dettagliata verranno elencati i DSO presenti sul secondo livello di staging e verrà data una breve descrizione dei dati contenuti al loro interno.
• ZO_WAP01 (Costi per data di delibera Y+1): Contiene le componenti dei costi per veicolo estratte per data di delibera, relative all’anno di pianificazione corrente.
38
• ZO_WAP21 (Costi per data di vendita Y+1): Contiene le componenti dei costi per veicolo, estratte per data di vendita, relative all’anno di pianificazione corrente.
• ZO_WAP22 (Costi per data di vendita Y): Contiene le componenti dei costi per veicolo, estratte per data di vendita, relative all’anno solare corrente.
• ZO_WAP23 (Costi per data di vendita Y-1): Contiene le componenti dei costi per veicolo estratte per data di delibera, relative all’anno solare precedente a quello attuale.
• ZO_WAP31 (Costi per data effettuazione %net): Contiene le componenti che vanno a determinare la percentuale del costo netto della garanzia rispetto al suo costo totale.
• ZO_WAP32 (Costi per data effettuazione %spare): Contiene le informazioni relative alla percentuale del costo della garanzia riferita ai pezzi di ricambio utilizzati.
• ZO_WAP04 (Distribuzione costi per periodo): Contiene le componenti che vanno a determinare la frazione del costo di una garanzia riferita ad ognuno degli anni di validità della stessa.
L’intero processo di caricamento sul cubo dei dati è gestito da un particolare tipo di programma detto “Badi”. Per Badi, acronimo di Business Add-In, si intende una estensione del codice standard SAP che può essere definita al fine di gestire dei requisiti di business troppo specifici per essere gestiti con gli strumenti standard messi a disposizione dal sistema. Ciò viene fatto inserendo delle istruzioni in linguaggio ABAP che vanno a gestire le specificità richieste.
Il programma viene richiamato dall’utente utilizzando una funzionalità dell’applicativo di front-end illustrata nel capitolo successivo e una volta eseguito esegue i macro-step indicati nella tabella 4.1:
39 Step Descrizione
1 Estrazione dati tramite query
2 Caricamento dei dati fino all’ultimo livello di staging 3 Calcolo ed aggregazione delle informazioni di interesse 4 Caricamento dei dati elaborati sul cubo di pianificazione
Tabella 4. 1: Fasi di caricamento dei dati sul cubo di planning
Da qui alla fine del paragrafo verranno descritte le operazioni effettuate all’interno della Badi al fine di portare a compimento gli step appena elencati.
L’esecuzione dei primi due step indicati nella tabella 4.1 viene effettuata richiamando all’interno della badi l’esecuzione di una process chain. Di seguito un estratto del codice ABAP contenente il trigger d’esecuzione e la gestione dello status della catena. Viene inizialmente richiamata la funzione standard SAP “RSSM_EVENT_RAISE” che consente di iniziare l’esecuzione della catena identificata per mezzo del parametro “WA_EVENTID, definito in fase di dichiarazione delle variabili tramite il nome tecnico dell’oggetto richiamato a sistema. La funzione in questione permette anche di gestire una serie di eccezioni standard.
Successivamente un ciclo while richiama l’esecuzione di una funzione standard SAP che restituisce lo stato di esecuzione della catena fino a quando essa non termina. Quando l’esecuzione è terminata, nel caso di errori viene gestita l’eccezione e mostrato un messaggio di errore.
CALL FUNCTION 'RSSM_EVENT_RAISE'
EXPORTING I_EVENTID = WA_EVENTID I_EVENTPARM = WA_EVENTPARM EXCEPTIONS BAD_EVENTID = 1 EVENTID_DOES_NOT_EXIST = 2
40 EVENTID_MISSING = 3
RAISE_FAILED = 4
OTHERS = 5.
IF SY-SUBRC <> 0.
MESSAGE E398(00) WITH 'Error Trigger subrc:' SY-SUBRC.
ENDIF.
W_FLAG = 'Y'.
WHILE W_FLAG = 'Y'.
WAIT UP TO 2 SECONDS.
CLEAR: WA_STATUS, W_FLAG.
CALL FUNCTION 'RSPC_API_CHAIN_GET_STATUS'
EXPORTING
I_CHAIN = WA_PC-CHAIN_ID I_LOGID = WA_PC-LOG_ID IMPORTING
E_STATUS = WA_STATUS.
CASE WA_STATUS.
WHEN 'G' OR 'F'. "esecuzione terminata correttamente W_FLAG = 'G'.
WHEN 'R' OR 'X' OR 'U'. "esecuzione terminata con errori W_FLAG = 'R'.
WHEN OTHERS. "catena in esecuzione W_FLAG = 'Y'.
ENDCASE.
ENDWHILE.
IF W_FLAG = 'R'.
L_LOG = 'An error occured during process chain execution'.
CL_UJK_LOGGER=>LOG( I_OBJECT = L_LOG ).
RAISE EXCEPTION TYPE CX_UJ_CUSTOM_LOGIC.
EXIT.
41
La catena richiamata dalla Badi presenta la seguente struttura:
Figura 4. 2: Vista strutturale della process chain
In cima alla catena è possibile osservare il processo di start, azionato tramite il comando presente nell’estratto di codice appena mostrato.
Una volta iniziata l’esecuzione della catena vengono richiamati sette programmi ABAP, relativi ai sette diversi DSO dei costi. Essi vanno a parametrizzare le rispettive query di estrazione dei dati utilizzando delle varianti associate ad ognuna delle query. Le varianti vengono valorizzate per mezzo di alcuni range temporali definiti dall’utente tramite una funzionalità dell’applicativo di front-end descritta nel capitolo successivo.
Una volta parametrizzate le query inizia l’operazione di estrazione dei dati vera e propria, effettuata tramite l’esecuzione dei sette APD che vanno a valorizzare i rispettivi DSO di destinazione.
Nell’esempio rappresentato in figura 4.3 è riportato l’APD realizzato per l’alimentazione del DSO ZO_WA21A (Costi per data di vendita Y+1).
42
Figura 4. 3: Esempio di implementazione di un APD
Si può osservare come la struttura sia estremamente semplice con la query sorgente, opportunamente parametrizzata con le date di estrazione indicate dall’utente, che va a scrivere i dati estratti sui campi corrispondenti della struttura di staging identificata come destinazione.
A questo punto della catena è stato inserito un processo che permette di proseguire con l’esecuzione solamente se tutte le estrazioni sono terminate con successo e senza errori. Una volta completate tutte le estrazioni viene eseguita una cancellazione dei dati dei DSO di secondo livello. La cancellazione è di tipo selettivo e vengono eliminati solamente i dati relativi al ciclo di pianificazione ed alla versione attivi al momento dell’esecuzione. A questo punto vengono eseguiti i DTP che trasferiscono i dati dal primo al secondo livello di staging.
La struttura del DSO di destinazione e quella del DSO sorgente sono identiche salvo per il fatto che il primo contiene due campi relativi al ciclo di pianificazione ed alla versione. La definizione di questi campi all’interno della transformation viene implementata tramite una selezione dalla tabella presente a sistema contenente il ciclo di pianificazione e la versione attivi al momento dell’esecuzione.
Una volta completati i trasferimenti dati da un livello all’altro di staging vengono eseguiti i comandi di attivazione dei dati dei DSO di secondo livello.
43
Terminata l’attivazione dei dati, l’esecuzione della catena termina e le strutture sono popolate con i dati attualizzati.
A questo punto la Badi procede, a partire dagli indicatori presenti nelle strutture di staging, al calcolo ed alla scrittura delle variabili di pianificazione sul cubo. Come riportato nel capitolo 3, nella versione 7.5 di BPC tutte le tipologie di indicatori vengono scritti su un’unica misura chiamata “Signed Data”: ciò che permette di distinguere cosa rappresenta un determinato valore numerico è dato dalla dimensione “Account”: i vari elementi presenti all’interno della sua anagrafica consentono di distinguere tra costi a 6 mesi, costi a 24 mesi, percentuali di costo netto e le altre variabili di interesse indicate nel capitolo 2.
Al fine di velocizzare l’esecuzione, a runtime viene caricato il contenuto dei DSO in delle tabelle temporanee, dette tabelle interne o locali, come mostrato nelle seguenti query contenute nella Badi:
***ESTRAZIONE DSO ZO_WAP01 SELECT * FROM /BIC/AZO_WAP0100
INTO CORRESPONDING FIELDS OF TABLE LT_WAP01 WHERE PLAN_CYCLE = PC_ACTIVE AND
VERSION = VER_ACTIVE.
***ESTRAZIONE DSO ZO_WAP21
SELECT * FROM /BIC/AZO_WAP2100
INTO CORRESPONDING FIELDS OF TABLE LT_WAP21 WHERE PLAN_CYCLE = PC_ACTIVE AND
VERSION = VER_ACTIVE.
***ESTRAZIONE DSO ZO_WAP22
SELECT * FROM /BIC/AZO_WAP2200
INTO CORRESPONDING FIELDS OF TABLE LT_WAP22 WHERE PLAN_CYCLE = PC_ACTIVE AND
VERSION = VER_ACTIVE..
***ESTRAZIONE DSO ZO_WAP23
SELECT * FROM /BIC/AZO_WAP2300
INTO CORRESPONDING FIELDS OF TABLE LT_WAP23 WHERE PLAN_CYCLE = PC_ACTIVE AND
VERSION = VER_ACTIVE.
***ESTRAZIONE DSO ZO_WAP31
SELECT * FROM /BIC/AZO_WAP3100
44 WHERE PLAN_CYCLE = PC_ACTIVE AND VERSION = VER_ACTIVE.
***ESTRAZIONE DSO ZO_WAP32
SELECT * FROM /BIC/AZO_WAP3200
INTO CORRESPONDING FIELDS OF TABLE LT_WAP32 WHERE PLAN_CYCLE = PC_ACTIVE AND
VERSION = VER_ACTIVE.
***ESTRAZIONE DSO ZO_WAP04
SELECT * FROM /BIC/AZO_WAP0400
INTO CORRESPONDING FIELDS OF TABLE LT_WAP04 WHERE PLAN_CYCLE = PC_ACTIVE AND
VERSION = VER_ACTIVE.
Osservando la clausola Where presente nelle select si può notare come i dati caricati nelle local tables siano solamente quelli relativi al ciclo di pianificazione ed alla versione correnti.
I dati contenuti nei DSO, e dunque nelle tabelle interne, contengono il dettaglio del prodotto al livello 7 (Scolorato) della gerarchia dei veicoli presentata nel capitolo precedente. Il processo di pianificazione avviene invece a livello 3 (Segmento) e livello 5 (Modello). Possono però essere presenti delle eccezioni, specificabili dall’utente tramite gli strumenti offerti dall’applicativo di front end, che vanno gestite all’interno della fase di caricamento dati presa in esame in questo paragrafo.
Può accadere infatti che, per esigenze legate alla pianificazione, gli utenti abbiano la necessità di trattare dei segmenti o dei mercati in maniera aggregata. È allora possibile, mediante il client di amministrazione, definire delle regole di confluenza che fanno sì che, durante il processo di pianificazione, i veicoli facenti parte di segmenti o mercati diversi siano trattati come un segmento o un mercato unico. L’esempio appena descritto è valido in maniera analoga anche per una ipotetica aggregazione di mercati.
È inoltre possibile trattare un particolare modello in maniera separata dal resto del suo segmento di appartenenza. Ciò può essere utile ad esempio in corrispondenza di un modello di recente uscita sul mercato di cui si vuole analizzare in maniera più mirata il comportamento in termini di costi legati all’assistenza tecnica.
Ciò si traduce formalmente nella creazione di una regola di confluenza che va a gerarchizzare il modello in oggetto al di sotto di un segmento fittizio, diverso da quello a cui apparterrebbe secondo la gerarchia standard. Nella figura seguente si può osservare,
45
a livello ideale, l’effetto della regola di confluenza appena descritta. Prima dell’applicazione della regola il segmento 1 conteneva due modelli: A e B; dopo l’applicazione di una regola di confluenza, il modello A viene incluso in un segmento indipendente creato ad hoc e i suoi dati non vengono più considerati nel computo dei totali relativi al segmento 1.
Segmento 1 – 1S1 Modello A 1S1MA Modello B 1S1MB Segmento 1 – 1S1 Modello A 1S1MA Modello B 1S1MB Confluence rule Segmento A – 1SA Modello A 1S1MA
Figura 4. 4: Effetto della regola di confluenza
Proseguendo nel flusso di istruzioni contenute all’interno della Badi, vengono ora illustrate le operazioni eseguite sul primo dei DSO relativi ai costi, contenente le componenti dei costi per veicolo estratte per data di delibera, relative all’anno di pianificazione corrente.
Per questa e per le altre tabelle interne contenenti i dati dei DSO, caricate tramite le select mostrate in precedenza, viene eseguito un ciclo in modo da elaborare ogni singolo record e gestire le eventuali eccezioni.
In ABAP, all’interno di un loop, il record viene scritto in una struttura avente lo stesso formato della tabella interna, come nell’istruzione seguente:
46
All’interno del ciclo, per prima cosa vengono recuperate le informazioni gerarchiche del prodotto accedendo all’anagrafica dei materiali presente a sistema con una read utilizzando il codice del veicolo a livello scolorato :
CLEAR: LL_MATERIAL.
"verifico il MATERIALE
READ TABLE IT_MATERIAL INTO LL_MATERIAL
WITH KEY MATERIAL = LL_WAP01-MATERIAL.
Una volta recuperati il segmento ed il modello del veicolo preso in esame, si controlla la presenza di eccezioni di confluenza a livello 3 o a livello 5 della gerarchia. Se il segmento o il modello sono oggetto di confluenza allora il codice destinatario della confluenza stessa viene scritto al posto di quello originario nella riga che verrà poi inserita nella tabella interna contenente i risultati delle elaborazioni. Ciò viene fatto nella seguente porzione di codice in cui si effettua una lettura sulla tabella contenente le regole di confluenza mediante l’istruzione “READ TABLE”. Se il livello 5 della gerarchia legata al prodotto analizzato è presente tra i codici di origine delle regole contenute nella tabella, allora il campo SEGMENT viene valorizzato col codice di destinazione della confluenza. Se non viene trovata alcuna corrispondenza col livello 5, si prova a ripetere l’operazione col livello 3 legato al prodotto trattato e se anche in questo caso non è presente alcuna eccezione di confluenza si scrive sul campo SEGMENT il livello 3 corrispondente della gerarchia del prodotto.
** CONTROLLO SE IL PRODOTTO HA UNA ECCEZIONE A LIVELLO 5
READ TABLE LT_EXCEPTION_SEG INTO LL_EXCEPTION_SEG
WITH KEY SOURCE_CONFL = LL_MATERIAL-ZPRODH5
BINARY SEARCH.
IF SY-SUBRC = 0.
LL_DATA_COSTS-SEGMENT = LL_EXCEPTION_SEG-DESTINATION_CONFL.
ELSE.
** CONTROLLO SE IL PRODOTTO HA UNA ECCEZIONE A LIVELLO 3
READ TABLE LT_EXCEPTION_SEG INTO LL_EXCEPTION_SEG
WITH KEY SOURCE_CONF = LL_MATERIAL-ZPRODH3
BINARY SEARCH.
IF SY-SUBRC = 0.
47
ELSE.
LL_DATA_COSTS-SEGMENT = LL_MATERIAL-ZPRODH3.
ENDIF.
ENDIF.
Si controlla poi se anche il mercato preso in esame è oggetto di una regola di confluenza ed eventualmente, anche in questo caso, si procede con la sostituzione del mercato originario con quello oggetto di confluenza:
** CONTROLLO SE IL MERCATO HA UNA ECCEZIONE DI CONFLUENZA
READ TABLE LT_EXCEPTION_MAR INTO LL_EXCEPTION_MAR
WITH KEY SOURCE_COUNTRY = LL_WAP01-COUNTRY BINARY SEARCH.
IF SY-SUBRC = 0.
LL_DATA_COSTS-MARKET = LL_EXCEPTION_MAR-DESTINATION_COUNTRY.
ELSE.
LL_DATA_COSTS-MARKET = LL_WAP01-COUNTRY.
ENDIF.
A questo punto il record viene corredato con le altre informazioni del perimetro dimensionale da scrivere sulla tabella dei risultati. Siccome i valori relativi allo stesso perimetro d’analisi verranno aggregati per somma sulla tabella interna, è necessario inserire anche un contatore degli stessi in modo che poi sia possibile effettuare una media del costo sostenuto dividendo il costo totale aggregato per il numero di attivazioni di garanzia.
Per far ciò viene utilizzato l’indicatore “ZK_CONTSO”, contenente un valore pari a 1 su ognuno dei record del DSO, come contatore delle attivazioni di garanzia, che verrà scritto nel campo signed data del record da inserire nella tabella finale. Nell’estratto di codice seguente è presente il resto delle valorizzazioni dei campi relativi al perimetro dimensionale. Al campo Account è stato assegnato il codice “WARR_ACT_YP1” che identifica il contatore di attivazioni di garanzia sul primo anno di pianificazione. Il valore assegnato al campo Currency ed anche al campo Type currency è di tipo “DUMMY”, ovvero fittizio, visto che, trattandosi di un contatore, non c’è alcuna valuta associata ad esso. Il campo data source viene valorizzato come “UPLOAD”, trattandosi di un caricamento da back-end e non di un input eseguito da un utente. Il ciclo di pianificazione e la versione vengono valorizzati con le variabili contenenti il ciclo e la versione attivi. Nel
48
campo time viene concatenato l’anno legato al ciclo di pianificazione attivo con la stringa DUMMY, per indicare un periodo di riferimento che abbraccia l’intero anno di pianificazione. L’istruzione finale di COLLECT inserisce il record all’interno della tabella locale che verrà rielaborata in seguito.
LL_DATA_COSTS-ACCOUNT = 'WARR_ACT_YP1'. LL_DATA_COSTS-CURRENCY = 'CURRENCY_DUMMY'. LL_DATA_COSTS-DATASRC = 'UPLOAD'. LL_DATA_COSTS-PCYCLE = PC_ACTIVE. LL_DATA_COSTS-TCURRENCY = 'TCURRENCY_DUMMY'. LL_DATA_COSTS-VERSION = VER_ACTIVE.
CONCATENATE PC_ACTIVE(4) '.DUMMY' INTO LL_DATA_COSTS-TIME.
LL_DATA_COSTS-SIGNEDDATA = LL_WAP01-ZK_CONTSO.
COLLECT LL_DATA_COSTS INTO LT_DATA_COSTS.
Nell’estratto di codice seguente viene invece scritto nella tabella interna il costo totale di garanzia relativo al periodo di riferimento, identificato da un diverso Account:
LL_DATA_COSTS-ACCOUNT = 'CV_6M_G_YP1'. LL_DATA_COSTS-CURRENCY = 'CURRENCY_DUMMY'. LL_DATA_COSTS-DATASRC = 'UPLOAD'. LL_DATA_COSTS-PCYCLE = PC_ACTIVE. LL_DATA_COSTS-TCURRENCY = 'TCURRENCY_DUMMY'. LL_DATA_COSTS-VERSION = VER_ACTIVE.
CONCATENATE PC_ACTIVE(4) '.DUMMY' INTO LL_DATA_COSTS-TIME.
LL_DATA_COSTS-SIGNEDDATA = LL_WAP01-ZK_TOTALE.
COLLECT LL_DATA_COSTS INTO LT_DATA_COSTS.
Le operazioni appena descritte vengono effettuate, con le dovute differenze legate al tipo di dato trattato, su tutte le tabelle interne contenenti i dati delle strutture di staging. Terminata l’elaborazione dei record di tutti i DSO, viene effettuato un nuovo ciclo sulla tabella contenente i costi estratti in precedenza e vengono eseguite le ultime operazioni, differenziate a seconda dell’account analizzato.
Nell’esempio seguente viene elaborato il valore medio del costo per veicolo a 6 mesi dividendo il costo totale aggregato per il contatore relativo al numero di attivazioni di garanzia:
49
LOOP AT LT_DATA_COSTS INTO LL_DATA_COSTS.
MOVE-CORRESPONDING LL_DATA_COSTS TO LL_DATA_COSTS_FIN.
CASE LL_DATA_COSTS-ACCOUNT.
WHEN 'CV_6M_G_YP1' OR 'CV_6M_G_Y' OR 'CV_6M_G_YM1'.
READ TABLE LT_DATA_COUNT INTO LL_DATA_COUNT
WITH KEY ACCOUNT = LL_DATA_COSTS-ACCOUNT BRAND = LL_DATA_COSTS-BRAND
SEGMENT = LL_DATA_COSTS-SEGMENT