Corso eBIZ -Modulo 05 - Profilo e adozione (CW513-010)

Mini CORSO adozione di eBIZ

Gennaio 2017

percorso di adozioneProfilo d’uso, percorso e mappatura

Piero De Sabbata, [email protected] Brutti, [email protected]

Workshop sulle attese delle PMI dal Contratto di

Rete - 2

Sommario

1. La terminologia2. eBIZ3. Il dominio applicativo di eBIZ4. La lente su…5. Il percorso di adozione6. Le risorse e la documentazione7. Validazione e controllo

Interoperabilità Plug-and-play?

plug-and-play:Aggiunta di un nuovo partner (o tipo di transazione) in una rete ed immediatamente iniziare la collaborazione

GRADI di LIBERTA’ che ostacolano scambi dati plug-&-play:

- Elementi opzionali (possibili ma non obbligatori), sono da gestire ese sono TANTI non tutte le implementazioni li supportano per

contenere i costip.es. in UBL ci sono milioni di possibili XPATH per l’ordine, ma se ne

usano alcune decine (diversamente da eBIZ/Moda-ML)

- Più collocazioni di una informazione sono possibilip.es. refDoc inserito in header o in ogni item

- Codifiche libere: p.es. testo libero anziché valori tabellati (a volte consentiti entrambi)p.es. payTerm(tabella) e payTermText(testo libero) oppure uso di note

I gradi di libertà nelle specifiche

NOTA: Spesso codifiche libere sono preferite da programmatori anche se non necessarie

Una possibile risposta: il Profilo d’Uso

− Restringere l’utilizzazione delle specifiche a un (sotto) dominio ben definito ed effettivamente utilizzato

− Ridurre ambiguità e incertezze interpretative

− Coerenza degli aspetti organizzativi e contrattuali con il modello scelto

per abbassare costi diimplementazione

per migliorareinteroperabilità

Alcune ‘sfide’ nell’implementazione di specifiche standard per eBusiness:

PROFILO d’ USO è una formalizzazione di COME va implementata la specifica in un dominio e contesto specifico (in un sottosettore, in una community, tra i fornitori di una azienda capocommessa,…)

Contenuto del Profilo d’Uso

- è una restrizione conforme della specifica (quindi resta conforme) che si applica in un sottosettore, in una community, tra i fornitori di una azienda capocommessa,…

- riguarda, ad esempio, per quanto attiene ai documenti

- Transazioni da implementare- Obbligatorietà e cardinalità di elementi opzionali della struttura dati- Codifiche, unità di misura e range di valori ammessi- Regole e vincoli di contesto sui dati (derivanti da ruolo, altri dati o da

transazione nel workflow)

- può inoltre includere protocolli di trasmissione e sicurezza, aspetti contrattuali e procedurali (p.es. gestione dei resi, modalità fatturazione,..)

TREND: automatizzarne creazione, confronto, messa in opera…

Contenuto del Profilo d’Uso

- è una restrizione della specifica (quindi è conforme) che si applica in un sottosettore, in una community, tra i fornitori di una azienda capocommessa,…

- riguarda, ad esempio, per quanto attiene ai documenti

- Transazioni da implementare- Obbligatorietà e cardinalità di elementi opzionali struttura dati- Codifiche, unità di misura e range di valori ammessi- Regole e vincoli di contesto sui dati (derivanti da ruolo, altri dati o da

transazione nel workflow)

- può inoltre includere protocolli di trasmissione e sicurezza, aspetti contrattuali e procedurali (p.es. gestione dei resi, modalità fatturazione,..)

TREND: automatizzarne creazione, confronto, messa in opera…

TEXDyFinOrder Radice del documento XML

@msgfunction Funzione Messaggio (NT18) Opzionale Default = “OR”Valori ammessi:

OR originaleCP copiaRT ritrasmissione per errore di comunicazioneRC ritrasmissione dati erratiCA cancellazione precedente documento

Il campo MSG-ID deve essere identico a quello del messaggio, di cui il presente costituisce la copia, ritrasmissione o cancellazione

@useProfile Profilo utente. Opzionale ma fortemente raccomandato.Il valore può essere il nome dell’azienda (e.g “BIANCHI Tessuti”) o meglio un URI o un URL con link al profilo

@TFCOtype Tipo Disposizione (NT24) Valori ammessi:

FIN Lavorazione finissaggioFINRC Rilavorazione finissaggio a carico del clienteFINRS Rilavorazione finissaggio a carico del fornitore

TFCOheader 1-1 Header Messaggio

msgN 1-1 Numero identificativo del messaggio nel contesto della trasmissione (lo stesso documento inviato più volte, per es per mancata ricezione, ha msgN diverso) Esempio: timestamp preceduto dalla stringa ODL (ordine di lavoro)

msgID 1-1 Numero o codice univoco della disposizione da citare nei messaggi successivi. Assegnato da chi genera la disposizione.

msgDate 1-1 Data della disposizione formato AAAA-MM-GG

refDoc 0-0 Non presente nella disposizione

Buyer 1-1 Dati del committente

id 1-1 “IT”+PIVA committente

@numberingOrg

Ente Codificatore (NT6) OpzionaleValori ammessi

“MF” (Ministero Finanze)

In rosso le restrizioni delProfilo d’Uso

Approcci per l’adozione

• Guidati da uno scenario specifico (scenario driven)(gradualità e parzialità, passaggio da carta a XML, ampiamente sperimentato)

• Guidati da entità interne all’ERP (entity driven)(big-bang globale, disegnato a tavolino, applicazione ad eBIZ in via di sperimentazione)

v

Approccio scenario driven

− Step 1. Individuazione del perimetro del dominio e del processo di interesse (e dei partner industriali di interesse)

− Step 2. Analisi transazioni: come implemento il processo (profilo d’uso parte 1)− Quali transazioni voglio davvero implementare− Quale granularità: che cosa identificare e come (le pezze, le partite, le localizzazioni,

gli stati di avanzamento, le singole attività)− Per ogni transazione individuare le informazioni da trasferire ed il template da usare

− Step 3. Analisi dei documenti per transazione (profilo d’uso parte 2)− Mappatura delle informazioni di ogni transazione sul relativo template di documento

− Step 4. Scelta dei protocolli di trasmissione− Step 5. Verifica dell’accordo tra i partner− Step 6. Implementazione

− Strumenti di import/export del formato (test conformità e funzionali inclusi)− Protocolli di spedizione (test conformità e funzionali inclusi)

− Step 7. Sperimentazione con i partner− Sperimentazione e Test di interoperabilità

How to build a Use Profilea real case, step 1

Domain and process: average quality fabric supplying

Participants: Fabric Producer and Fabric buyer

Objective: to support order sending, logistic

Others requirements:- I do not care about serial number of pieces but simply lots- I do not allow Order Responses changing dates or quantities- I want a third party quality check- I do not want a separate quality report beyond despatch advice

Requisiti del caso:

Caso reale, passi successivi




− Modifico cardinalità − Limito valori predefiniti, fornisco istruzioni di compilazione

Approccio scenario driven

Caso reale: Step 2



Standard:− Processo 1 - Fornitura tessuti− Scelta tessuti− Acquisto tessuti

− Ordine Acquisto Tessuto − Risposta Ordine Acquisto Tessuto − Modifica Ordine Acquisto Tessuto − Avanzamento Ordine Tessuto

− a - Spedizione tessuti con certificazione di Terzi

− b - Spedizione tessuti con groupage− c - Spedizione tessuti senza

certificazione di Terzi− Fatturazione tessuti

Profilo d’uso:Processo 1 - Fornitura tessuti− Scelta tessuti− Acquisto tessuti

− Ordine Acquisto Tessuto − Risposta Ordine Acquisto Tessuto − Modifica Ordine Acquisto Tessuto − Avanzamento Ordine Tessuto

− a - Spedizione tessuti con certificazione di Terzi

− Avviso spedizione− b - Spedizione tessuti con groupage− c - Spedizione tessuti senza

certificazione di Terzi− Fatturazione tessuti

− FatturaPotrebbe anche accadere che si ‘COMPONGA’un processo nuovo con i documenti esistenti

Step 3: situazioni particolari

Alcune situazioni particolari:

fabMnfrOperation, indicazioni delle lavorazioni da effettuare. Nel caso della disposizione del “stampa” possono essere presenti fino a tre operazioni diverse

texJob, 1-1: Tipo Di Lavorazione Tessuto (tabella T202) valori ammessi: ”53” : stampare, ”54” : finire, ”81” : controllare

texJobTech 0-1: Tipo di Tecnologia di Lavorazione Tessuto (tabella T262) valori ammessi:Se texJob=”53” allora ammessi 73: stampa transfer, 80: stampa a cilindri, 81: stampa INKJETSe texJob=”54” o “81” allora campo assente

Vincoli di contesto incrociando i valori di più campi

Piece 0-n, indicazioni sui numeri seriali di pezze (ad esempio spedite per acquisto oppure per reso da controllo) in Avviso di Spedizione. Nel caso dell’invio per acquisto dopo controllo, potrei non essere interessato ai numeri di serie, mentre, nel caso di merce resa a fornitore da controllo, potrebbe essere obbligatorio riferire esattamente i numeri di serie

Vincoli derivanti da uso del medesimo documento in transazioni diverse

Step 3: situazioni particolari/2

Note 0-19, testo libero

@noteLabel [Optional]: label da attribuire alla nota per dare un senso concordato tra le parti al suo valore

@codeList [Optional]: indicazione della lista di valori ammessi (p.es. un URL da cui scaricare le decodifiche)

@numberingOrg [Optional]: organizzazione che ha attribuito significato al label se presente

Coppie attributo/valore per gestire campi non previsti dalla specifica

Uso delle ‘note’ strutturate:

Esempio:Testo strutturato relativo a difetti riscontrati sulla pezza Il corpo della nota è costituito dal numero di difetti e dal riferimento alla pezza sulla quale sono stati riscontrati. <note numberingOrg="CL" noteLabel="Buco">2/PZ003</note><note numberingOrg="CL" noteLabel="Buco">4/PZ004</note><note numberingOrg="CL" noteLabel="Macchia">11/PZ003</note>

CAUTELA:- siamo sintatticamente nello

standard ma al di fuori della sua semantica

- quindi questi campi sono incomprensibili senza il profilo d’uso

Alcune linee guida qualitative

evitare valori sottintesi, evitare formulazioni del tipo “se non indicato um sono CM” (esplicitare sempre um unità di misura)

non attribuire significati a posizione, p.es. “il primo codice è del cliente, il secondo del fornitore” (esplicitare sempre almeno numberingOrg, organizzazione che da il codice e la decodifica)

limitare testi liberi, soprattutto avendo valori da tabelle predefinite disponibili (evitare “franco fabbrica” in incoTermText avendo disponibile ‘EXW’ in incoTerm di uguale significato)

se indispensabile testo libero, cercare di disciplinarne uso e valori ammessi (ricordare non è trattabile automaticamente e dipende dalla lingua di chi legge)

limitare uso di note strutturate (anche se da preferire a testi liberi)

Errori ed imprecisioni comuni

Errori di sintassi (riscontrabili con XML Schema validation)• Errato riferimento a XML Schema in testa a documento XML• Sequenze di elementi errate o tag errati ….• Tipi di dati o date in formato errato, uso della virgola per decimali …

Errori semantici• Valori fuori dal set di valori ammessi nei campi con valori predefiniti• Incoerenza tra tag e suo contenuto • Incoerenza tra diversi elementi • Duplicazione/sovrapposizione tra campi codificati e campi testuali liberi

Fine parte su adozione eBIZ

Abbiamo parlato di Gradi libertà nelle specifiche e Profili d’usoCriteri per valutare l’utilità di soluzioni basate su stdApproccio ‘Scenario driven’ in fasi:

a) dominio/processo/profilob) analisi transazioni/mappaturac) accordo tra le parti/implementazione/protocolli

trasportoApproccio ‘Entity driven’: un tema apertoLa creazione del profilo del processoLa creazione del profilo del modello di documento

un esempio concreto di profilo e documento XML corrispondentealcune linee guida qualitative: campi opzionali, uso delle note strutturate e dei testi liberi, altre..DOMANDE e DUBBI?

Corso eBIZ -Modulo 05 - Profilo e adozione (CW513-010)

Internet

Transcript of Corso eBIZ -Modulo 05 - Profilo e adozione (CW513-010)