La progettazione funzionale della soluzione

Il progetto di integrazione di Microsoft Dynamics 365 for Field Service e SAP ECC consiste nella progettazione e nella mappatura di quattro interfacce, ovvero quattro flussi di dati che dovranno essere scambiati tra l’applicazione Microsoft e l’applicazione SAP, come è rappresentato in figura 32:

81

Figura 32: Le interfacce

1. Interface Work order creation from CRM to ECC;

2. Sales order update; Purchase order update from ERP to CRM; 3. Equipment creation from ERP to CRM;

4. Product Master creation from ERP to CRM.

4.8.1 Interface work order creation from CRM to ECC

L’interfaccia tra Microsoft Dynamics 365 e SAP ECC avviene via il middleware SAP PI, come già anticipato. Il flusso di dati è outbound per CRM e inbound per SAP ECC. L’oggetto di business che è scambiato è il Work Order.

82

Figura 34: Gli oggetti di business scambiati nella prima interfaccia

L’interfaccia progettata si prende cura dei dati inerenti l’oggetto Work Order scambiati tra CRM e SAP ERP. In particolare, per ogni work order gestito in CRM da un dispatcher o da un meccanico, è necessario generare i documenti corrispondenti in ECC, per permettere l’avanzamento del flusso logistico:

• Qualsiasi componente di proprietà del cliente che necessita di essere trasferito dal proprio magazzino al sito dell’account1 per consentire l’installazione o la riparazione da parte del meccanico, deve essere tracciato all’interno del Sales Order Document. Da quest’ultimo verrà elaborata la consegna e le relative attrezzature serializzate verranno create per il cliente;

• Qualsiasi componente non prodotto dal cliente, per cui le informazioni del fornitore saranno mantenute in CRM, deve fluire all’interno del documento di acquisto, per consentire l’acquisto da un fornitore specifico; • Qualsiasi Bespoke Material (ovvero un materiale ad hoc richiesto da parte dell’account), che sarà prodotto su commessa da un fornitore specifico per essere venduto al cliente, deve fluire sia nel documento di vendita (Sales Order Document) che nel documento di acquisto;

• Qualsiasi Claim material (ovvero un materiale per cui vi è stato un reclamo) verrà gestito con modifiche dirette all’Equipment master, attraverso la creazione ed eliminazione di entità correlate.

1 _{Con “Account” ci si riferisce in questo caso a un qualsiasi cliente della società acquirente}

83

Solo quando un ordine è in stato submitted, questo può essere inviato a SAP ERP per l’elaborazione dei documenti corrispondenti.

Ogni work order item in CRM avrà informazioni specifiche sul relativo Sales Order Number/Purchase Requisition Number con lo stato del relativo documento e nel caso di Claim material avrà l’Equipment number e il Serial Number, che verranno utilizzati per tracciare successivamente i documenti corrispondenti e aggiornare lo stato degli stessi (maggiori dettagli verranno descritti nell’interfaccia specifica).

La stessa interfaccia si occuperà dei service item, che evidenziano, per ogni tipo di servizio eseguito, il numero di ore effettivamente spese dai meccanici. Queste informazioni verranno inviate a SAP ERP quando lo stato del work order è Completed, per attivare così il processo di acquisto presso lo specifico fornitore che fatturerà al cliente il servizio fornito.

L’entità principale dove le informazioni riguardanti il work order sono contenute è denominata msdyn_workorder, pertanto questa entità sarà estratta e scambiata. Microsoft Dynamics fornirà a SAP PI una struttura XML contenente gli attributi che riflettono la mappatura dei dati.

L’approccio per l’interfaccia outbound sarà quello di spingere i dati in XML sull’HTTP quando le condizioni di trigger sono soddisfatte in CRM. In SAP PI ci sarà la mappatura dei dati e le regole di conversione utilizzate per inviare correttamente i dati in SAP ECC.

In base alla logica di suddivisione che verrà implementata in PI, in ECC saranno inseriti 3 idoc per la Purchase Requisition, il Sales Order e l’Equipment.

Secondo la logica descritta di seguito in SAP ECC verranno creati 3 tipi di idoc. Gli scenari all’interno dei quali l’integrazione tra Microsoft Dynamics 365 for Field Service e SAP ECC ha luogo sono:

84

Figura 35: Integrazione nel processo “Installation” della prima interfaccia

Si tratta dell’installazione di un’attrezzatura presso un account.

Durante il processo di installazione sono due gli step principali in cui avviene l’integrazione:

• Il Back Office crea il work order aggiungendo tutti i dati di testa, imposta lo stato del work order come Open – Unscheduled Submitted e sottoscrive l’ordine. Ogni volta che il work order viene modificato e salvato e si trova ancora in questo stato, l’intero aggiornamento viene replicato a SAP: qualsiasi elemento in stato complete (in caso di vendita significa che il documento di consegna è stato creato, in caso di acquisto significa che l’ordine di acquisto è stato creato) non sarà preso in considerazione da SAP PI e i dati non saranno inviati a SAP ECC. Qualsiasi item avente il Sales order, il Purchase requisition o l’Equipment number popolati (che significa che il documento in ECC esiste già) sarà aggiornato in ECC. Qualsiasi elemento con stato rejected genererà la disattivazione del documento in ECC. Qualsiasi altro item senza tali informazioni sarà considerato come un nuovo documento da creare in ECC;

• Il tecnico esegue l’intervento, aggiorna il work order e imposta lo stato su Open – Completed.

85

2. End to End Scenario Repair and Maintenance

Figura 36: Integrazione nel processo “Repair” della prima interfaccia

Figura 37: Integrazione nel processo “Maintenance” della prima interfaccia

Si tratta dei processi di riparazione e di manutenzione di un’attrezzatura presso un account.

86

Durante il processo di riparazione e manutenzione sono due gli step principali in cui avviene l’integrazione:

• Il tecnico esegue l’intervento, aggiorna il work order e lo invia al team di Back Office per l’approvazione. L’addetto al Back Office esamina il work order e, se tutto è in regola, imposta lo stato del work order su Open – Scheduled Submit e sottoscrive l’ordine. Ogni volta che il work order viene modificato e salvato e si trova ancora in questo stato, l’intero aggiornamento viene replicato a SAP: qualsiasi item in stato complete (in caso di vendita significa che il documento di consegna è stato creato, in caso di acquisto significa che l’ordine di acquisto è stato creato) non sarà preso in considerazione da SAP PI e i dati non saranno inviati a SAP ECC. Qualsiasi item che ha il Sales order, il Purchase requisition o l’Equipment number popolati (che significa che il documento in ECC esiste già) verrà aggiornato in ECC. Qualsiasi item con stato rejected genererà la disattivazione del documento in ECC. Qualsiasi altro item senza tali informazioni sarà considerato come un nuovo documento da creare in ECC;

• Il Back Office dopo l’aggiornamento del work order chiude il work order impostando lo stato su Open – Completed.

87

3. End to End Scenario Call out – Repair

Figura 38: Integrazione nel processo “Mechanic Call Out” della prima interfaccia

Nel processo Call Out Repair è il meccanico sul campo a creare un work order durante una visita presso un account quando si vede necessaria l’installazione di un’attrezzatura o la riparazione di una già presente.

Durante il processo di Call Out Repair è uno il passaggio fondamentale in cui l’integrazione avviene: il tecnico crea il work order ed esegue l’intervento, invia il work order al team di Back Office per l’approvazione, l’addetto al Back Office esamina il work order e se tutto è in regola imposta lo stato del work order su Open – Unscheduled Submitted e sottoscrive l’ordine. Ogni volta che il work order viene modificato e salvato e si trova ancora in questo stato, l’intero aggiornamento viene replicato a SAP ECC: qualsiasi elemento in stato complete (in caso di vendita significa che il documento di consegna è stato creato, in caso di acquisto significa che l’ordine di acquisto è stato creato) non sarà preso in considerazione da SAP PI e i dati non saranno inviati a SAP ECC. Qualsiasi item avente il Sales order, il Purchase requisition o l’Equipment number popolati (che significa che il documento in ECC esiste già) verrà aggiornato in ECC. Qualsiasi elemento con stato rejected genererà la disattivazione del documento in ECC. Qualsiasi altro item senza tali informazioni sarà considerato come un nuovo documento da creare in ECC.

88

Figura 39: La mappatura dei sistemi sorgente e target

4.8.2 Sales order update, purchase order update from ERP to CRM

L’interfaccia tra Microsoft Dynamics 365 e SAP ECC avviene via il middleware SAP PI. Il flusso di dati è outbound per SAP ECC via proxy e inbound per Microsoft Dynamics 365 via web service. L’oggetto di business scambiato è il Work Order.

Figura 40: La direzione del flusso di dati nella seconda interfaccia

89

L’interfaccia progettata si prenderà cura dei dati del work order scambiati tra SAP ECC e CRM. Dopo che il work order è stato sottoscritto lato CRM, potenzialmente due documenti corrispondenti (Sales Order e Purchase Requisition) sono creati in SAP ECC. Quando gli oggetti vengono creati in sistemi back-end, la conferma deve essere inviata ai sistemi CRM secondo la seguente logica:

• L’ID del Sales Order generato deve essere replicato e immagazzinato a livello di item;

• L’ID del Purchase Requisition generato deve essere replicato e immagazzinato a livello di item;

• Lo stato del Purchase Requisition deve essere replicato e immagazzinato a livello di item;

• La data di consegna dell’item deve essere replicata in CRM e archiviata a livello di item;

• Lo stato del Sales Order item deve essere replicato in CRM e archiviato a livello di item.

Le interfacce da ECC devono essere generate quando gli oggetti vengono creati in ECC per inviare la conferma e quando ci sono aggiornamenti del sales order e del purchase requisition che modificano i campi necessari in CRM.

Le principali entità in cui sono archiviate le informazioni sono il Sales Order e il Purchase Requisition in ECC. Quando gli oggetti sono creati in ECC, le strutture (Idoc o Proxy) con le informazioni vengono inviate in PI. Dopodiché, PI mapperà i valori pertinenti nell’XML da inviare in CRM. Inoltre, i dati devono essere inviati quando il Sales Order e il Purchase Requisition sono aggiornati in ECC.

La struttura scambiata da ECC a PI contiene i campi contenenti l’ID del work order e il numero dell’item. Questi valori sono rilevanti per identificare il giusto Work Order e gli item da aggiornare.

90

Gli scenari all’interno dei quali l’integrazione tra Microsoft Dynamics 365 for Field Service e SAP ECC ha luogo sono:

1. End to End Scenario Installation

Figura 42: Integrazione nel processo “Installation” della seconda interfaccia

Durante il processo di installazione sono due i principali step in cui l’integrazione avviene:

• Una volta che il Sales Order e il Purchase Requisition sono stati creati in ECC, la conferma viene inviata al CRM per aggiornare i prodotti inseriti all’interno del work order con i rispettivi Sales order number e Purchase requisition number. Quando i documenti di acquisto e di consegna sono creati in ECC, l’aggiornamento dello stato degli item viene replicato in CRM insieme alla data di consegna in caso di sales order. Qualsiasi ulteriore aggiornamento di stato in ECC è sincronizzato con CRM;

• Quando il work order viene chiuso in CRM, i service item vengono inviati a ECC per creare il Purchase Requisition, dopodiché la conferma di avvenuta creazione viene inviata al CRM al fine di aggiornare i service item associati al work order.

91

2. End to End Scenario Repair and Maintenance

Figura 43: Integrazione nel processo “Repair” della seconda interfaccia

Figura 44: Integrazione nel processo “Maintenance” della seconda interfaccia

Durante il processo di riparazione e manutenzione sono due le fasi principali in cui avviene l’integrazione:

• Dopo che il Back Office riesamina il work order e lo replica a ECC, il Sales order number deve essere rispedito in CRM quando l’ordine viene creato

92

in ECC. Quando il documento di consegna viene creato, lo stato dell’ordine e la data di consegna vengono nuovamente inviati al CRM. Qualsiasi ulteriore aggiornamento di stato è sincronizzato con CRM; • Il Back-Office chiude il work order e lo invia a ECC per creare il Purchase

Requisition per i service item. Quando il Purchase Requisition viene creato in ECC la conferma deve essere inviata in CRM per aggiornare i service item.

3. End to End Scenario Call out – Repair

Figura 45: Integrazione nel processo “Mechanic Call Out - Repair” della seconda interfaccia

Durante il processo Call Out Repair, è uno il passaggio in cui avviene l’integrazione: il Back Office riesamina il Work Order e, se tutto è in regola, imposta lo stato del work order su Open – Unscheduled Submitted e sottoscrive l’ordine. Dopodiché in ECC viene creato il Purchase Requisition con i service item, la cui conferma di creazione avvenuta deve essere inviata per aggiornare i service item associati al work order.

93

4.8.3 Equipment creation from ERP to CRM

L’interfaccia tra Microsoft Dynamics 365 e SAP ECC avviene via il middleware SAP PI. Il flusso di dati è outbound per SAP ECC e inbound per Microsoft Dynamics 365. L’oggetto di business che sarà scambiato è l’Equipment. I dati saranno scambiati da ECC a PI attraverso la tecnologia Proxy e da PI a CRM attraverso la tecnologia webservice.

Figura 46: La direzione del flusso di dati nella terza interfaccia

Figura 47: Gli oggetti di business scambiati nella terza interfaccia

L’interfaccia progettata si prenderà cura dei dati sull’Equipment del cliente scambiati da SAP ECC e da CRM. Dopo che il Work Order viene inviato lato CRM, potenzialmente l’Equipment (valido solamente per gli asset serializzati) viene creato o aggiornato in SAP ECC. Dopo la creazione dell’oggetto di business nei sistemi back- end, la conferma di creazione avvenuta deve essere inviata al sistema CRM per allineare i dati del cliente secondo la seguente logica:

• Se il nuovo Equipment viene creato in ECC, la struttura proxy deve essere inviata a PI con le informazioni principali e da PI la struttura XML tramite

94

webservice viene inviata in CRM, il webservice elaborerà tale struttura e creerà il nuovo Equipment all’interno dei dati del cliente;

• Se l’Equipment viene aggiornato in ECC, il proxy deve essere inviato a PI con le informazioni principali e da PI la struttura XML tramite webservice viene replicata in CRM, il webservice elaborerà la struttura XML in base all’Equipment number fornito e applicherà gli aggiornamenti di conseguenza.

L’interfaccia da ECC deve essere generata quando l’oggetto è creato o aggiornato in ECC.

L’entità principale in cui sono archiviate le informazioni è l’Equipment in ECC. Quando l’oggetto è creato in ECC, la struttura proxy contenente le principali informazioni viene inviata a PI, dopodiché PI mapperà i pertinenti valori all’interno della struttura XML da inviare a CRM.

Il webservice verifica se l’Equipment esiste già a livello di master data del cliente (la logica verrà implementata utilizzando l’Equipment number), quindi in base all’Equipment number il webservice aggiorna o aggiunge le informazioni riguardanti l’Equipment.

Gli scenari all’interno dei quali l’integrazione tra Microsoft Dynamics 365 for Field Service e SAP ECC ha luogo sono:

1. End to End Scenario Installation

95

Durante il processo di installazione, quando il Work Order è Completed l’integrazione avviene per la richiesta di creazione o di aggiornamento dell’Equipment da CRM a ECC, dopodiché quando l’oggetto viene creato in ECC avviene l’integrazione secondo la seguente logica:

• Possono verificarsi due casi:

– È necessario creare un nuovo asset serializzato;

– È necessario aggiornare un asset serializzato esistente (questo scenario è chiamato Lost & Found)

2. End to End Scenario Repair and Maintenance

96

Figura 50: Integrazione nel processo “Maintenance” della terza interfaccia

Durante il processo di riparazione e manutenzione, quando il Work Order è Open Scheduled l’integrazione avviene per la richiesta di creazione o aggiornamento dell’Equipment da CRM a ECC, dopodiché quando l’oggetto viene creato in ECC l’integrazione avviene secondo la seguente logica:

• Possono verificarsi due casi:

– Avviene l’aggiornamento dell’Equipment Master per gli item di de-installation, lost e not used;

– Avviene la creazione dell’Equipment Master per gli item di installation e found.

97

3. End to End Scenario Call out – Repair

Figura 51: Integrazione nel processo “Mechanic Call Out - Repair” della terza interfaccia

Durante il processo Call Out – Repair quando il Work Order è Open Unscheduled l’integrazione avviene per la richiesta di creazione o aggiornamento dell’Equipment da CRM a ECC, dopodiché quando l’oggetto è creato in ECC l’integrazione avviene secondo la seguente logica:

• Possono verificarsi due casi:

– Viene aggiornato l’Equipment Master per gli item di de- installation, lost e not used;

– Viene creato l’Equipment Master per gli item di installation e found.

4.8.4 Product Master creation from ERP to CRM

L’interfaccia tra Microsoft Dynamics 365 e SAP ECC avviene via il middleware SAP PI. Il flusso di dati è outbound per SAP ECC e inbound per Microsoft Dynamics 365. L’oggetto di business che sarà scambiato è il Product Master. I dati saranno

98

scambiati da ECC a PI attraverso tecnologia IDOC e da PI a CRM attraverso tecnologia SFTP.

Figura 52: La direzione del flusso di dati nella quarta interfaccia

Figura 53: Gli oggetti di business scambiati nella quarta interfaccia

L’interfaccia progettata si prenderà cura dei master data Product scambiati da SAP ECC e da CRM. Il master data viene creato in SAP ECC e l’idoc MATMAS contenente le informazioni principali sul prodotto viene inviato a SAP PI. L’interfaccia da ECC sarà inviata tramite elaborazione batch. PI raccoglierà tutte le informazioni da diversi idoc, genererà un file CSV e lo inserirà all’interno di una specifica cartella del Web Application Server.

Il sistema CRM, tramite batch file eseguito su base giornaliera (durante il turno notturno), importa tutti i dati dal file csv pertinente spostandoli all’interno di una sottocartella specifica.

L’entità principale all’interno della quale sono contenute le informazioni è il Product in ECC. I dati verranno estratti tramite batch job relativo a un carico completo, che verrà eseguito su base giornaliera.

99

100

Con Equipment master e Product master si intendono oggetti aziendali contenenti le principali informazioni rispettivamente su attrezzature e prodotti. Se ne riporta un esempio in figura 55 e 56:

Figura 55: Equipment master

Figura 56: Product master