Il documento tratta del mini corso sull'adozione di ebiz, esplorando i profili d'uso e le mappature necessarie per implementare specifiche nel contesto del business elettronico. Viene discusso come ridurre ambiguità e incertezze nell'implementazione, promuovendo l'interoperabilità attraverso l'adozione di standard e profili d'uso specifici per sottosettori. Infine, il documento fornisce linee guida qualitative per evitare errori comuni e migliorare l'efficacia della comunicazione elettronica tra le PMI.

1. Mini CORSO adozione di eBIZ
Gennaio 2017
percorso di adozione
Profilo d’uso, percorso e mappatura
Piero De Sabbata, piero.desabbata@enea.it
Arianna Brutti, arianna.brutti@enea.it

2. Workshop sulle
attese delle PMI
dal Contratto di
Sommario
1. La terminologia
2. eBIZ
3. Il dominio applicativo di eBIZ
4. La lente su…
5. Il percorso di adozione
6. Le risorse e la documentazione
7. Validazione e controllo

3. Interoperabilità Plug-and-play?
plug-and-play:
Aggiunta di un nuovo partner (o tipo
di transazione) in una rete ed
immediatamente iniziare la
collaborazione

4. GRADI di LIBERTA’ che ostacolano scambi dati plug-&-play:
- Elementi opzionali (possibili ma non obbligatori), sono da gestire e
se sono TANTI non tutte le implementazioni li supportano per contenere i
costi
p.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 possibili
p.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

5. 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 di
implementazione
per migliorare
interoperabilità
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,…)

6. 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…

7. 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 originale
CP copia
RT ritrasmissione per errore di comunicazione
RC ritrasmissione dati errati
CA 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 finissaggio
FINRC Rilavorazione finissaggio a carico del cliente
FINRS 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
@numberi
ngOrg
Ente Codificatore (NT6) Opzionale
Valori ammessi
“MF” (Ministero Finanze)
In rosso le restrizioni del
Profilo d’Uso

8. 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

9. 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à

10. How to build a Use Profile
a 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:

11. Caso reale, passi successivi
− 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
− Modifico cardinalità
− Limito valori predefiniti, fornisco istruzioni di compilazione
Approccio scenario driven

12. Caso reale: Step 2
− 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
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

13. Caso reale: Step 3
Standard: Profilo d’uso:
− Step 3. Analisi dei documenti per transazione (profilo d’uso parte 2)
− Mappatura delle informazioni di ogni transazione sul relativo template di documento
− Modifico cardinalità
− Limito valori predefiniti, fornisco istruzioni di compilazione
TEXOrder
@TOtype [Optional] [Default= STD]
@msgfunction [Optional] [Default= OR]
@useProfile [Optional]
| TOheader 1-1
| | msgN 1-1
- scegli -
| | msgID 0-1
- oppure -
| | docID 0-1
| | @numberingOrg [Optional]
- fine scelta -
| | msgDate 1-1
| | @dateForm [Optional]
| | validityEnd 0-1
| | @dateForm [Optional]
| | msgCurrency 0-1
| | otherCurrency 0-9
| | @currencyUseQualifier [Required]
| | refDoc 0-9
| | @docType [Required]
TEXOrder
@TOtype OBBLIGATORIO, «STD»
@msgfunction [Optional] [Default= OR]
@useProfile [Optional] OBBLIGATORIO «pippo»
| TOheader 1-1
| | msgN 1-1
- scegli -
| | msgID 1-1 OBBLIGATORIO
- oppure -
| | docID 0-1
| | @numberingOrg [Optional] sottinteso «CL»
- fine scelta -
| | msgDate 1-1
| | @dateForm [Optional]
| | validityEnd 0-1
| | @dateForm [Optional]
| | msgCurrency 1-1 OBBLIGATORIO, «EUR»
| | otherCurrency 0-9
| | @currencyUseQualifier [Required]
| | refDoc 2-2 Massimo 2
| | @docType [Required] ammessi solo «ORD» e «OFF»
Vedi profili
di esempio:
A order
B invoice

14. 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 INKJET
Se 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

15. 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

16. 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)

17. 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

18. Fine parte su adozione eBIZ
Abbiamo parlato di
Gradi libertà nelle specifiche e Profili d’uso
Criteri per valutare l’utilità di soluzioni basate su std
Approccio ‘Scenario driven’ in fasi:
a) dominio/processo/profilo
b) analisi transazioni/mappatura
c) accordo tra le parti/implementazione/protocolli trasporto
Approccio ‘Entity driven’: un tema aperto
La creazione del profilo del processo
La creazione del profilo del modello di documento
un esempio concreto di profilo e documento XML corrispondente
alcune linee guida qualitative: campi opzionali, uso delle note
strutturate e dei testi liberi, altre..
DOMANDE e DUBBI?