Anveo EDI Connect / Config / Mappings / Modelado de flujos de trabajo de mapeo
This is an automatic translation. The original post is available in Inglés.

Modelado de flujos de trabajo de mapeo

En Anveo EDI Connect, normalmente se utilizan múltiples mapeos para modelar un proceso EDI. A continuación veremos ejemplos muy sencillos y otro más complejo. El módulo es muy flexible y usted puede mapear el proceso de la manera que desee, pero los siguientes ejemplos son nuestra forma recomendada de modelar el proceso.

Antes de entrar en demasiados detalles, aclaremos algunos conceptos. Se puede ejecutar un mapeo en Anveo EDI Connect. Luego está el concepto de una transacción de base de datos. En pocas palabras, una transacción de base de datos recoge todas las modificaciones de la base de datos durante una transacción. Al final de la transacción, los datos pueden almacenarse de forma permanente, lo que se denomina confirmación de la base de datos. O bien, se pueden anular las modificaciones, es decir, todas las modificaciones realizadas durante la operación se anulan y no se graban. Cada ejecución de una asignación se realiza en una transacción de base de datos separada. Si se produce un error durante la ejecución de la asignación, la operación se retrocede. De lo contrario, la operación se confirma. (Esto es cierto para la mayoría de los mapeos. En Anveo EDI Connect hay disparadores de tablas que pueden ejecutar código arbitrario. Si ese código contiene un comando COMMIT, el módulo no puede deshacer los cambios. Esto puede conducir a un comportamiento no deseado.)

Pedido de cliente XML entrante

En este ejemplo utilizamos tres mapeos para importar un archivo XML. Este es el mínimo recomendado. En el primer paso mapearemos la estructura de datos externos a las tablas de búfer. La idea es importar los datos, aunque no todos los datos puedan ser procesados. Esto permitirá al usuario final corregir errores en la transacción EDI, sin conocer el formato de datos externos. Por supuesto, esto sólo es posible si hay errores de datos, no si no se puede analizar la estructura del fichero.

El siguiente paso es verificar los datos. Aquí puede añadir cualquier verificación lógica sobre los datos comerciales. Recomendamos hacer esto en un paso separado antes del procesamiento para recopilar múltiples mensajes de error y proporcionar al usuario final un protocolo de error completo. Si necesita buscar datos de la tabla del sistema y desea que persistan, lo haremos en un cuarto paso entre la asignación externa y la de verificación.

El último paso es la creación del documento Microsoft Dynamics 365 Business Central. Hacemos esto en un paso separado, para mantener los bloqueos de las mesas del sistema tan cortos como sea posible.

Factura EDIFACT saliente

En los documentos salientes, normalmente tiene algunos valores, que no se almacenan directamente en la tabla de fuentes de Microsoft Dynamics 365 Business Central. Para dar al usuario final la posibilidad de ver estos datos y simplificar la asignación de formato de datos externos, recomendamos escribir los datos primero en una tabla de búfer. En este paso puede buscar valores y hacer cálculos.

La asignación de exportación sólo toma los datos almacenados en el búfer y los escribe en el formato de destino.

Proceso EDI con confirmación

El proceso no tiene que ser lineal. Si necesita enviar confirmaciones o si desea agrupar datos, siempre puede llamar varias asignaciones desde una sola asignación. También se pueden utilizar condiciones y ramificaciones condicionales para ejecutar diferentes asignaciones basadas en los datos.

Cómo configurar el flujo de trabajo

Hablaremos de los detalles más tarde. Si quieres dar un salto adelante, utilizamos dos técnicas para estructurar el flujo de trabajo de mapeo. Las operaciones y el tratamiento posterior.