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 otros más complejos. El módulo es muy flexible y puede mapear el proceso de la forma 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 Anveo EDI Connect en Anveo EDI Connect. Luego está el concepto de una transacción de base de datos. En pocas palabras, una transacción de la 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 un commit de la base de datos. O bien, se pueden anular las modificaciones, es decir, todas las modificaciones realizadas durante la transacción se deshacen y no se graban. Cada ejecución de un mapeo 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 transacción se anula. De lo contrario, la operación está comprometida. (Esto es cierto para la mayoría de los mapeos. En Anveo EDI Connect hay desencadenantes de tabla que pueden ejecutar código arbitrario. Si ese código contiene un comando COMMIT, el módulo no puede anular los cambios. Esto puede conducir a un comportamiento no deseado).
Pedido de cliente XML entrante
Utilizamos tres mapeos en este ejemplo, para importar un archivo XML. Este es el mínimo recomendado. En el primer paso mapearemos la estructura de datos externos a tablas de buffer. La idea es importar los datos, aunque no todos los datos puedan ser procesados. Esto permitirá al usuario final corregir los errores en la transacción de EDI, sin el conocimiento del formato de datos externos. Por supuesto, esto sólo es posible si hay errores en los datos, no si la estructura del archivo no puede ser analizada.
El siguiente paso es verificar los datos. Aquí puede añadir cualquier verificación lógica de los datos comerciales. Recomendamos hacer esto en un paso separado antes del procesamiento para recoger múltiples mensajes de error y dar al usuario final un protocolo de error completo. Si necesita buscar datos de la tabla del sistema y quiere persistir en ellos, lo haríamos en un cuarto paso entre el mapeo externo y el de verificación.
El último paso es la creación del documento Microsoft Dynamics NAV 2009R2 RTC. Hacemos esto en un paso separado, para mantener los bloqueos de mesa en las mesas del sistema lo más corto posible.
Factura saliente de EDIFACT
En los documentos salientes, normalmente se tienen algunos valores que no se almacenan directamente en la tabla de origen Microsoft Dynamics NAV 2009R2 RTC. Para dar al usuario final la posibilidad de ver estos datos y para simplificar el mapeo del formato de los datos externos, recomendamos escribir primero los datos en una tabla de buffer. En este paso se pueden consultar los valores y hacer cálculos.
El mapeo 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. También puede utilizar condiciones y bifurcaciones condicionales, para ejecutar diferentes mapeos basados en los datos.
Cómo configurar el workflow
Entraremos en los detalles más tarde. Si desea avanzar, utilizamos dos técnicas para estructurar el flujo de trabajo del mapeo. Las operaciones comerciales y el tratamiento posterior.