Anveo EDI Connect / Config / Mappings / Modellazione dei flussi di lavoro di mappatura
Questa è una traduzione automatica. Il messaggio originale è disponibile in Inglese.

Modellazione dei flussi di lavoro di mappatura

In Anveo EDI Connect, normalmente si usano mappature multiple per modellare un processo EDI. Qui di seguito daremo uno sguardo ad esempi molto semplici e ad un altro più complesso. Il modulo è molto flessibile ed è possibile mappare il processo nel modo desiderato, ma i seguenti esempi sono il nostro modo consigliato per modellare il processo.

Prima di entrare troppo nel dettaglio, chiariamo alcuni concetti. È possibile eseguire una mappatura in Anveo EDI Connect. Poi c’è il concetto di transazione in un database. In parole povere, una transazione del database raccoglie tutte le modifiche apportate al database durante una transazione. Alla fine della transazione, i dati possono essere memorizzati in modo permanente, che viene chiamato database commit. Oppure le modifiche possono essere reimpostate, cioè tutte le modifiche apportate durante la transazione vengono annullate e non salvate. Ogni esecuzione di una mappatura viene effettuata in una transazione di database separata. Se c’è un errore durante l’esecuzione della mappatura, la transazione è roll-back. In caso contrario la transazione è impegnata. (Questo vale per la maggior parte delle mappature. In Anveo EDI Connect ci sono dei trigger di tabella che possono eseguire codice arbitrario. Se quel codice contiene un comando COMMIT, il modulo non può annullare le modifiche. Questo può portare a comportamenti indesiderati).

Ordine di vendita XML in arrivo

In questo esempio utilizziamo tre mappature per importare un file XML. Questo è il minimo raccomandato. Nella prima fase mappiamo la struttura dei dati esterni in tabelle di buffer. L’idea è quella di importare i dati, anche se non tutti i dati possono essere elaborati. Questo permetterà all’utente finale di correggere gli errori nella transazione EDI, senza la conoscenza del formato dei dati esterni. Naturalmente questo è possibile solo se ci sono errori di dati, non se la struttura del file non può essere analizzata.

Il passo successivo è quello di controllare i dati. Qui è possibile aggiungere eventuali controlli logici sui dati aziendali. Si consiglia di farlo in una fase separata prima dell’elaborazione per raccogliere i messaggi di errore multipli e dare all’utente finale un protocollo di errore completo. Se avete bisogno di cercare i dati della tabella di sistema e volete persistere, lo faremo in un quarto passo tra la mappatura esterna e la mappatura dei controlli.

L’ultimo passo è la creazione del documento Microsoft Dynamics NAV 2016. Lo facciamo in una fase separata, per mantenere i blocchi dei tavoli da tavolo sui tavoli del sistema il più breve possibile.

Fattura EDIFACT in uscita

Nei documenti in uscita, si hanno di solito alcuni valori, che non sono memorizzati direttamente nella tabella dei sorgenti Microsoft Dynamics NAV 2016. Per dare all’utente finale la possibilità di vedere questi dati e per semplificare la mappatura esterna del formato dei dati, si consiglia di scrivere prima i dati in una tabella buffer. In questa fase è possibile cercare i valori ed eseguire i calcoli.

La mappatura delle esportazioni prende solo i dati bufferizzati e li scrive nel formato di destinazione.

Processo EDI con conferma

Il processo non deve essere necessariamente lineare. Se è necessario inviare conferme o se si desidera raggruppare i dati, è sempre possibile chiamare più mappature da una sola mappatura. È inoltre possibile utilizzare condizioni e ramificazioni condizionali, per eseguire diverse mappature in base ai dati.

Come impostare il flusso di lavoro

Entreremo nei dettagli più tardi. Se si vuole fare un salto in avanti, usiamo due tecniche per strutturare il flusso di lavoro di mappatura. Le transazioni commerciali e il post-processing.