> Mejora Continua de Procesos > Del Registro al Informe Asiento Contable > Microsoft Dynamics 365 > Plantilla de Datos

Su Plantilla de Datos del Registro al Informe - Asiento Contable

Microsoft Dynamics 365

Del Registro al Informe - Atributos de Asientos Contables (21) Del Registro al Informe - Actividades de Asientos Contables (12) Guías de Extracción (4)

Su Plantilla de Datos del Registro al Informe - Asiento Contable

Esta plantilla proporciona una guía completa sobre los puntos de datos esenciales requeridos para analizar su proceso del Registro al Informe - Asiento Contable. Describe los atributos cruciales a recopilar y las actividades clave a rastrear, asegurando que capture toda la información necesaria para una iniciativa de process mining efectiva. Además, encontrará orientación práctica sobre la extracción de estos datos de su sistema de origen.

Atributos recomendados para recopilar
Actividades clave para el seguimiento
Guía de extracción para Microsoft Dynamics 365

¿Nuevo en registros de eventos? Aprenda cómo crear un registro de eventos para Process Mining.

Descargar Plantilla

Del Registro al Informe - Atributos de Asientos Contables

Estos son los campos de datos recomendados para incluir en su registro de eventos para un análisis exhaustivo del proceso del Registro al Informe - Asiento Contable.

3 Requerido 7 Recomendado 11 Opcional

	Nombre	Descripción
	Hora del Evento EventTime	El `timestamp` preciso que indica cuándo ocurrió una actividad o `event`.
Descripción La Hora del Evento registra la fecha y hora en que tuvo lugar una actividad específica en el proceso de asientos contables. Estos datos cronológicos son esenciales para ordenar los eventos y calcular la duración entre ellos. En el análisis, esta marca de tiempo se utiliza para construir la línea de tiempo para cada caso, lo cual es crítico para calcular todas las métricas basadas en el tiempo, como los tiempos de ciclo, los tiempos de procesamiento y los tiempos de espera. Permite la identificación de retrasos entre pasos y soporta dashboards relacionados con cuellos de botella y el cumplimiento de SLA. Por qué es importante Esta marca de tiempo es esencial para ordenar los eventos correctamente y calcular todos los KPIs basados en duración, como el tiempo de ciclo y los retrasos de procesamiento. Dónde obtener Las marcas de `tiempo` de los `eventos` se encuentran típicamente en los registros del historial del `workflow`, tablas de seguimiento de auditoría (por ejemplo, `SysDatabaseLog`), o como marcas de `tiempo` de creación/modificación en registros relacionados como `LedgerJournalTable` y `LedgerJournalTrans`. Ejemplos 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:45:10Z
	ID de Asiento de Diario JournalEntryId	El identificador único para un asiento contable, sirviendo como el identificador principal del caso.
Descripción El ID de Asiento Contable vincula de forma única todas las actividades y puntos de datos relacionados con una única transacción de asiento contable. Permite el seguimiento completo de extremo a extremo del ciclo de vida de un asiento, desde su creación y revisión hasta su contabilización final en el libro mayor. En el análisis de process mining, este atributo es fundamental para reconstruir el flujo del proceso. Cada ID de Asiento Contable único representa una única instancia del proceso, lo que permite un examen detallado de las variantes del proceso, los tiempos de ciclo y el cumplimiento para transacciones financieras individuales. Por qué es importante Esta es la clave esencial para rastrear un asiento contable de principio a fin, haciendo posible analizar todo el flujo del proceso para cada caso. Dónde obtener Este identificador se encuentra típicamente en la tabla de encabezados de asientos, como LedgerJournalTable, a menudo en un campo llamado JournalNum. Ejemplos JRN-0012345JV-2023-08-156GENJ0000891
	Nombre de la Actividad ActivityName	El nombre del paso o evento específico del proceso de negocio que ocurrió.
Descripción Este atributo describe un único evento o tarea dentro del ciclo de vida del asiento contable, como 'Asiento Contable Creado', 'Asiento Enviado para Aprobación' o 'Asiento Contable Contabilizado'. Estas actividades forman los nodos del mapa de proceso descubierto. Analizar la secuencia y frecuencia de estas actividades es fundamental para el process mining. Revela el flujo real del proceso, ayuda a identificar desviaciones del procedimiento estándar y destaca los cuellos de botella donde las actividades tardan más de lo esperado o se repiten. Por qué es importante Este atributo define los pasos del proceso, formando la columna vertebral del mapa de proceso y permitiendo el análisis del flujo del proceso y sus variaciones. Dónde obtener Este es un atributo conceptual derivado de eventos del sistema, cambios de estado o registros de flujo de trabajo dentro de Microsoft Dynamics 365. Ejemplos Asiento Contable CreadoDiario Enviado para AprobaciónDiario AprobadoAsiento de Diario Contabilizado
	Entidad jurídica LegalEntity	La entidad legal o código de empresa para la cual se está registrando el asiento contable.
Descripción La Entidad Legal representa la empresa o unidad de negocio específica dentro de una organización para la cual se está registrando la transacción financiera. Esta es una dimensión organizacional fundamental en los sistemas financieros. En process mining, este atributo permite la comparación del proceso de asientos contables entre diferentes partes de la organización. Puede revelar si ciertas entidades legales tienen procesos más eficientes, tasas de rechazo más altas o tiempos de ciclo más largos, ayudando a identificar y compartir las mejores prácticas. Por qué es importante Permite la comparación del rendimiento del proceso entre diferentes empresas o unidades de negocio, destacando variaciones y oportunidades de mejora. Dónde obtener Este es un campo principal en Dynamics 365, a menudo disponible en tablas de transacciones como LedgerJournalTable, típicamente vinculado al DataAreaId. Ejemplos USMFDEMFGBSI
	Estado del Diario JournalStatus	El estado actual o final del asiento contable.
Descripción Este atributo indica el estado del asiento contable en un momento dado, como 'Borrador', 'En Revisión', 'Aprobado', 'Rechazado' o 'Contabilizado'. Proporciona una instantánea de dónde se encuentra el asiento en su ciclo de vida. Analizar el estado es útil para comprender los resultados de los casos. Se puede usar para filtrar todos los asientos rechazados o para rastrear el volumen de asientos en una etapa específica. Este atributo soporta múltiples dashboards al proporcionar contexto para el análisis del rendimiento y el estado. Por qué es importante Proporciona un resultado claro para cada asiento contable, permitiendo el análisis de las tasas de éxito, las tasas de rechazo y el volumen de trabajo en las diferentes etapas. Dónde obtener El estado se encuentra a menudo en la tabla de encabezados de asientos, LedgerJournalTable, o se deriva del estado del flujo de trabajo. Ejemplos BorradorEnviadoAprobadoContabilizadoRechazada
	Hora Fin del Evento EventEndTime	La marca de tiempo que indica cuándo se completó una actividad o evento.
Descripción La Hora de Fin del Evento marca la finalización de una actividad específica. Mientras que la Hora de Inicio indica cuándo comienza un evento, la Hora de Fin proporciona el otro límite, permitiendo el cálculo preciso de la duración de tareas individuales. En process mining, disponer tanto de una hora de inicio como de fin permite el cálculo del tiempo de procesamiento de la actividad, que es distinto del tiempo de espera. Esto es crucial para los dashboards que analizan el rendimiento del usuario e identifican qué tareas específicas, y no solo los espacios entre ellas, están consumiendo la mayor parte del tiempo. Por qué es importante Permite el cálculo preciso del `tiempo` que toma cada actividad, lo cual es vital para analizar el rendimiento del usuario e identificar tareas que consumen muchos recursos. Dónde obtener Estos datos pueden almacenarse explícitamente en los registros de flujo de trabajo o pueden necesitar ser derivados utilizando la Hora de Inicio de la actividad subsiguiente en la secuencia. Ejemplos 2023-10-26T10:05:15Z2023-10-26T11:45:00Z2023-10-27T15:00:00Z
	Importe Total del Diario JournalTotalAmount	El valor monetario total del asiento contable, típicamente la suma de los débitos.
Descripción Este atributo representa el valor financiero total del asiento contable. Se puede utilizar para categorizar los asientos en rangos de valor, como valor bajo, medio y alto. Analizar el proceso basándose en el valor financiero puede revelar patrones importantes. Por ejemplo, los asientos contables de alto valor pueden seguir un proceso de aprobación más riguroso con más pasos y tiempos de ciclo más largos. Este atributo es esencial para el análisis de materialidad y para comprender el impacto financiero de las ineficiencias del proceso. Por qué es importante Permite segmentar el proceso por valor financiero, lo que a menudo se correlaciona con la complejidad del proceso, el riesgo y los `workflows` de aprobación. Dónde obtener Este valor puede necesitar ser calculado sumando los importes de débito de la tabla de líneas de asiento, LedgerJournalTrans, para cada asiento contable. Ejemplos 1500.75125000.0050.25
	Motivo de rechazo RejectionReason	La razón proporcionada cuando un asiento contable es rechazado durante el proceso de aprobación.
Descripción Cuando se rechaza un asiento contable, el aprobador a menudo proporciona una razón para el rechazo. Este atributo captura esa información, que es invaluable para el análisis de causa raíz. Este es el atributo principal para el dashboard 'Análisis de Tasa de Rechazo de Asientos Contables'. Al categorizar y analizar las razones de rechazo, las organizaciones pueden identificar problemas comunes, como documentación incorrecta, violaciones de políticas o errores de entrada de datos, y luego implementar capacitación dirigida o mejoras de proceso. Por qué es importante Explica por qué ocurre la reelaboración, proporcionando la información directa necesaria para reducir las tasas de rechazo y mejorar las aprobaciones correctas a la primera. Dónde obtener Esta información se almacena típicamente en el historial de flujo de trabajo o en la sección de comentarios asociada con el paso de rechazo. Ejemplos Documentación de respaldo insuficienteCuenta incorrecta utilizadaSupera el umbral de aprobaciónEntrada duplicada
	Nombre de Usuario UserName	El nombre del `usuario` que realizó la `actividad`.
Descripción Este atributo identifica al empleado o usuario del sistema responsable de ejecutar una actividad específica, como crear, aprobar o contabilizar un asiento contable. Vincula los pasos del proceso con los recursos humanos. Analizar el rendimiento por usuario es una capacidad clave en process mining. Ayuda a construir el dashboard 'Rendimiento de Usuarios de Asientos Contables' para comparar las duraciones de las actividades y el rendimiento entre diferentes usuarios o equipos. Esto puede destacar a los de mejor desempeño, identificar necesidades de capacitación y ayudar en el equilibrio de la carga de trabajo. Por qué es importante Vincula las actividades del proceso a individuos específicos, permitiendo el análisis del rendimiento del usuario, la distribución de la carga de trabajo y la asignación de recursos. Dónde obtener La información del usuario se encuentra típicamente en los campos createdBy o modifiedBy de tablas como LedgerJournalTable o en los registros de historial de flujo de trabajo asociados. Ejemplos Alice SmithBob Johnsonsystem.batch
	Tipo de Asiento JournalType	La clasificación del asiento contable, como Asiento General o Devengo.
Descripción El Tipo de asiento categoriza los registros según su propósito comercial, por ejemplo, asientos diarios, provisiones, asignaciones o eliminaciones. Esta segmentación es crucial para comprender las distintas rutas y comportamientos del proceso. Este atributo permite filtrar y comparar el proceso entre los diferentes tipos de asientos. Es esencial para el dashboard 'Volumen de Asientos Contables Procesados por Tipo', ayudando a analizar si ciertos tipos de asientos son más propensos a retrasos, rechazos o retrabajos. Por qué es importante Permite segmentar el análisis para comparar procesos con diferentes propósitos comerciales, que pueden tener rutas, tiempos de ciclo y requisitos de aprobación distintos. Dónde obtener Esto se almacena típicamente en la tabla de encabezados de asientos, LedgerJournalTable, en un campo relacionado con nombres o tipos de asientos (ej., JournalName). Ejemplos Diario GeneralAjuste por DevengoTransferencia entre CompañíasNóminas
	¿Es Retrabajo? IsRework	Un indicador que identifica actividades que forman parte de un ciclo de reelaboración o corrección.
Descripción Este atributo booleano calculado se establece en verdadero para actividades que ocurren después de un rechazo, como 'Asiento Contable Corregido' o un 'Asiento Enviado para Aprobación' repetido. Ayuda a aislar y cuantificar el retrabajo. Este atributo es esencial para el dashboard 'Bucles de Retrabajo y Corrección de Asientos Contables' y el KPI 'Tasa de Retrabajo'. Al marcar el retrabajo, resulta fácil visualizar y medir la frecuencia y el impacto de los ciclos de corrección, que son una fuente principal de ineficiencia en el proceso. Por qué es importante Marca directamente los ciclos de reelaboración ineficientes, facilitando la cuantificación del impacto de los rechazos y correcciones en el `tiempo` de ciclo y el costo generales. Dónde obtener Este es un atributo calculado derivado durante la transformación de datos al analizar la secuencia de actividades dentro de un caso. Ejemplos truefalse
	Código de Moneda CurrencyCode	La moneda del importe del asiento contable.
Descripción Este atributo especifica la moneda en la que se denomina el asiento contable, como USD, EUR o GBP. Proporciona un contexto esencial para el Importe Total del Asiento. Si bien no siempre se utiliza para analizar el flujo del proceso en sí, la moneda es vital para cualquier informe o análisis financiero basado en los importes de los asientos. Permite la agregación y comparación correctas de valores, especialmente en organizaciones multinacionales. Por qué es importante Proporciona el contexto necesario para cualquier análisis financiero, asegurando que los valores monetarios se interpreten correctamente, especialmente en entornos multi-divisa. Dónde obtener El código de moneda suele estar disponible en la tabla de líneas de asiento, LedgerJournalTrans. Ejemplos USDEURGBPJPY
	Departamento DepartmentName	El departamento o centro de costos asociado al asiento contable.
Descripción El departamento o centro de costos identifica la unidad de negocio interna responsable o afectada por la transacción financiera. Esta es una dimensión clave para los informes de gestión interna. Este atributo permite analizar el proceso de asientos contables por departamento. Puede ayudar a responder preguntas como: ¿Qué departamentos envían más asientos? ¿Ciertos departamentos tienen tasas de rechazo más altas o tiempos de aprobación más largos? Esto es útil para los esfuerzos de mejora de procesos específicos. Por qué es importante Proporciona una forma de analizar el rendimiento del proceso por función comercial, ayudando a identificar cuellos de botella específicos del departamento o necesidades de capacitación. Dónde obtener Esta información se encuentra típicamente a nivel de línea de asiento (LedgerJournalTrans) como una dimensión financiera. Ejemplos VentasFinanzasMarketingOperaciones
	Es Contabilización Automática IsAutomatedPosting	Un indicador que señala si el asiento de diario fue creado o contabilizado automáticamente.
Descripción Este atributo booleano distingue entre asientos contables que son creados manualmente por un usuario y aquellos generados automáticamente por el sistema o un subsistema, como una integración de sistema o un proceso de asignación automatizado. Analizar este atributo ayuda a comparar la eficiencia y las tasas de error de los procesos automatizados frente a los manuales. Puede destacar oportunidades para una mayor automatización al mostrar si los asientos manuales son más propensos a errores, retrabajo o retrasos. Por qué es importante Separa los procesos manuales de los automatizados, permitiendo una comparación de su eficiencia, precisión y cumplimiento. Dónde obtener Esto puede indicarse por el usuario 'Creado por' (ej., un usuario del sistema o por lotes) o por un indicador específico en el encabezado del asiento o en la configuración del tipo. Ejemplos truefalse
	Es Correcto a la Primera IsFirstTimeRight	Un indicador que señala si el diario fue aprobado sin rechazos previos.
Descripción Este atributo booleano a nivel de caso es verdadero si un asiento contable procede de la presentación a la aprobación sin actividades intermedias de 'Asiento Rechazado' o 'Asiento Contable Corregido'. Es una medida clave de la calidad del proceso. El KPI 'Tasa de Aprobación Correcta a la Primera' se calcula directamente a partir de este atributo. Una tasa alta indica un proceso eficiente y de alta calidad, mientras que una tasa baja señala problemas sistémicos con la calidad inicial de los datos, la claridad de los requisitos o los procedimientos de envío. Por qué es importante Esta es una medida crítica de la calidad del proceso, destacando cuántos asientos fluyen a través del proceso de aprobación sin problemas y sin ningún retrabajo. Dónde obtener Este es un atributo calculado derivado a nivel de caso al analizar la secuencia de actividades para cada ID de Asiento Contable. Ejemplos truefalse
	Estado del SLA de Aprobación ApprovalSlaState	Indica si la aprobación del asiento de diario cumplió con su acuerdo de nivel de servicio.
Descripción Este atributo categoriza el ciclo de aprobación de cada asiento contable según si se completó dentro del tiempo objetivo definido por un Acuerdo de Nivel de Servicio (SLA). Los valores posibles suelen ser 'Cumplido' o 'Incumplido'. Esta es la métrica principal para el dashboard 'Cumplimiento de SLA de Aprobación de Asientos Contables'. Proporciona una visión clara y orientada al negocio del rendimiento frente a los objetivos, ayudando a monitorear y gestionar la puntualidad del proceso de aprobación e impulsar mejoras donde los SLA se incumplen con frecuencia. Por qué es importante Traduce los datos brutos del tiempo de ciclo en un resultado de negocio claro (cumplido o incumplido), facilitando el seguimiento del rendimiento frente a los objetivos clave. Dónde obtener Este es un atributo calculado. La lógica requiere comparar el KPI de Tiempo de Ciclo de Aprobación calculado con un objetivo de SLA predefinido. Ejemplos CumplidoIncumplido
	Fecha de Contabilización PostingDate	La fecha en que el asiento contable se contabiliza en el libro mayor.
Descripción La Fecha de Contabilización es la fecha oficial en la que la transacción afecta los saldos del libro mayor. Esta fecha es crítica para la presentación de informes financieros y los períodos de cierre. Este atributo se utiliza para analizar el retraso entre la aprobación y la contabilización, que es el foco del KPI 'Tiempo de Ciclo de Contabilización de Asientos Contables'. Reducir este retraso es a menudo un objetivo clave para acelerar el proceso de cierre financiero. También se puede utilizar para analizar los volúmenes de contabilización a lo largo del tiempo. Por qué es importante Crucial para calcular el `KPI` de tiempo de espera de contabilización y comprender los retrasos entre la aprobación y el momento en que una transacción se vuelve oficial en el libro mayor. Dónde obtener Esta fecha se almacena típicamente en la tabla de encabezados de asientos (LedgerJournalTable) o en tablas de transacciones contabilizadas relacionadas. Ejemplos 2023-10-282023-11-012023-10-31
	Nivel de Aprobación ApprovalLevel	Indica la etapa actual o completada en un `workflow` de aprobación multinivel.
Descripción Para los asientos de diario que requieren múltiples aprobaciones, este `atributo` rastrea el nivel de la jerarquía que ha alcanzado el asiento, por ejemplo, 'Aprobación del Gerente' o 'Aprobación del Director'. Este `atributo` es útil para analizar los cuellos de botella de aprobación con más detalle. Puede ayudar a identificar si los retrasos ocurren consistentemente en un nivel específico de la cadena de aprobación, sugiriendo la necesidad de un rediseño del proceso o una reasignación de recursos en esa etapa. Por qué es importante Proporciona visibilidad de los flujos de trabajo de aprobación multi-etapa, ayudando a identificar cuellos de botella en niveles de aprobación específicos. Dónde obtener Esta información se derivaría del registro de historial de flujo de trabajo, rastreando la finalización de los diferentes pasos de aprobación. Ejemplos Nivel 1: GerenteNivel 2: DirectorNivel 3: Vicepresidente de Finanzas
	Source System SourceSystem	El sistema de registro del que se extrajeron los `datos`.
Descripción Este atributo identifica la aplicación de origen donde se originan los datos del asiento contable. Para este proceso, el valor suele ser una constante, como 'Microsoft Dynamics 365'. En un contexto de análisis más amplio, especialmente en entornos con múltiples ERPs o sistemas integrados, este campo ayuda a diferenciar procesos y fuentes de datos. Asegura la claridad sobre la procedencia de los datos y es importante para la gobernanza y validación de datos. Por qué es importante Identifica el origen de los `datos`, lo cual es crucial para la gobernanza de `datos` y para análisis que puedan abarcar múltiples sistemas empresariales. Dónde obtener Este es un valor estático añadido durante el proceso de extracción, transformación y carga de datos (ETL) para etiquetar el origen del conjunto de datos. Ejemplos Microsoft Dynamics 365D365 F&O
	Tiempo de Procesamiento ProcessingTime	La duración del tiempo dedicado activamente a una actividad.
Descripción El Tiempo de Procesamiento mide el tiempo entre el inicio y el final de una actividad, representando la duración real del trabajo. Esto es distinto del tiempo de ciclo, que incluye el tiempo de espera entre actividades. Esta métrica calculada es vital para el dashboard 'Rendimiento de Usuarios en Asientos Contables'. Ayuda a comprender cuánto tiempo tardan los usuarios o equipos en completar tareas específicas, eliminando la influencia del tiempo en cola o de espera. Esto permite una evaluación más justa y precisa de la eficiencia de los recursos. Por qué es importante Mide el tiempo de trabajo activo para una actividad, permitiendo el análisis de la eficiencia del usuario y del equipo sin la interferencia de los períodos de espera. Dónde obtener Esto se calcula tomando la diferencia entre la Hora de Fin del Evento y la Hora del Evento (Hora de Inicio) para cada actividad. Ejemplos PT5M15SPT1H15MP1DT2H
	Última actualización de datos LastDataUpdate	El timestamp cuando los datos se actualizaron por última vez desde el sistema de origen.
Descripción Este atributo indica la fecha y hora de la extracción de datos más reciente del sistema de origen. Proporciona contexto para la actualización del análisis y los datos incluidos. Mostrar esta información en los dashboards asegura a los usuarios la puntualidad de los datos y les ayuda a comprender el marco de tiempo cubierto por el análisis de proceso actual. Es una pieza clave de metadatos para cualquier proyecto de process mining. Por qué es importante Proporciona un contexto crítico sobre la actualización de los datos, asegurando que los usuarios comprendan cuán actual es el análisis del proceso. Dónde obtener Esta marca de tiempo se genera y almacena durante el proceso de extracción, transformación y carga de datos (ETL). Ejemplos 2023-10-27T02:00:00Z

Requerido Recomendado Opcional

Del Registro al Informe - Actividades de Asientos Contables

Estos son los pasos clave del proceso y los hitos a capturar en su Registro de eventos para un descubrimiento y análisis precisos del proceso.

5 Recomendado 7 Opcional

	Actividad	Descripción
	Asiento Contable Creado	Esta actividad marca el inicio de un nuevo asiento contable. Se captura cuando un usuario crea un nuevo registro de encabezado de asiento en el sistema, estableciendo un ID de Asiento Contable único que sirve como identificador de caso para el análisis del proceso.
Por qué es importante Este es el evento de inicio principal para el proceso. Analizar el tiempo desde este punto hasta la contabilización es crucial para medir el tiempo de ciclo de extremo a extremo e identificar retrasos iniciales en la entrada de datos. Dónde obtener Este evento se captura de la marca de tiempo de creación del encabezado del asiento en la entidad GeneralJournalEntry o LedgerJournalTable. Típicamente es un evento explícito de creación de registro. Capturar Utilice el campo 'createdDateTime' en GeneralJournalEntry o LedgerJournalTable. Tipo de evento explicit
	Asiento de Diario Contabilizado	Esta actividad marca la contabilización exitosa del asiento contable en el libro mayor, convirtiéndolo en un registro financiero oficial. Este es un evento crítico, capturado cuando el estado del encabezado del asiento se actualiza a 'Contabilizado'.
Por qué es importante Este es el evento de fin exitoso principal para el proceso. Se utiliza para calcular el tiempo de ciclo de extremo a extremo y el tiempo de ciclo de contabilización, que son indicadores clave de la eficiencia del cierre financiero. Dónde obtener Capturado de un cambio de campo de estado (por ejemplo, `JournalStatus` cambiando a 'Posted') en la `LedgerJournalTable` y la creación de asientos correspondientes en la tabla `GeneralJournalAccountEntry`. Capturar Identificar la marca de `tiempo` cuando el estado del diario cambia a 'Posted'. Tipo de evento inferred
	Diario Aprobado	El asiento contable ha sido aprobado por la autoridad designada, completando el paso final en el flujo de trabajo de aprobación. Esto se captura típicamente de un cambio de estado en el encabezado del asiento, como pasar a 'Aprobado'.
Por qué es importante Este es un hito crítico que concluye el proceso de aprobación y permite la contabilización. Es esencial para calcular el tiempo de ciclo de aprobación, el tiempo de ciclo de contabilización y la tasa de aprobación correcta a la primera. Dónde obtener Inferido de un cambio de campo de estado (por ejemplo, `ApprovalStatus` cambiando a 'Approved') en la `LedgerJournalTable` o de la tabla de historial de `workflow` que indica un estado de aprobación final. Capturar Identificar la marca de `tiempo` cuando el estado del diario cambia a 'Approved'. Tipo de evento inferred
	Diario Enviado para Aprobación	Representa la presentación formal de un asiento contable completado en un flujo de trabajo de revisión y aprobación. Esto se infiere típicamente de un cambio de estado en el encabezado del asiento, como de 'Borrador' a 'En Revisión' o 'Enviado'.
Por qué es importante Este es un hito clave que inicia el ciclo de aprobación. Medir el tiempo desde la presentación hasta la aprobación final es crítico para identificar cuellos de botella en el proceso de revisión y monitorear el cumplimiento de SLA. Dónde obtener Inferido de un cambio de campo de estado (por ejemplo, `ApprovalStatus` cambiando a 'InReview') en la `LedgerJournalTable` o de los registros de historial de `workflow` asociados con el diario. Capturar Identificar la marca de `tiempo` cuando el estado del diario cambia a un estado 'submitted' o 'in review'. Tipo de evento inferred
	Diario Rechazado	El asiento contable ha sido rechazado por un revisor o aprobador y requiere corrección. Este evento se captura de un cambio de estado en el asiento, como pasar a un estado de 'Rechazado' o 'Necesita Corrección'.
Por qué es importante El seguimiento de los rechazos es fundamental para calcular la tasa de rechazo e identificar las causas raíz del retrabajo. Destaca problemas con la calidad de los datos, el cumplimiento o la capacitación del usuario. Dónde obtener Inferido de un cambio de campo de estado (por ejemplo, `ApprovalStatus` cambiando a 'Rejected') en la `LedgerJournalTable` o del registro de historial de `workflow`. Capturar Identificar la marca de `tiempo` cuando el estado del diario cambia a 'Rejected'. Tipo de evento inferred
	Asiento de Diario Corregido	Esta actividad indica que un asiento contable previamente rechazado ha sido modificado por un usuario. Esto se infiere típicamente al detectar una modificación en el encabezado del asiento o en sus líneas después de que se haya registrado un estado de 'Rechazado'.
Por qué es importante Esta actividad identifica explícitamente el retrabajo. Analizar la frecuencia y duración de los bucles de corrección ayuda a optimizar el proceso y reducir el esfuerzo manual. Dónde obtener Inferido al rastrear los campos 'modifiedDateTime' y 'modifiedBy' en las tablas `LedgerJournalTable` o `LedgerJournalTrans` después de que haya ocurrido un `evento` de 'Journal Rejected'. Capturar Compare la marca de `tiempo` de un estado 'Rejected' con las marcas de `tiempo` de modificación posteriores del creador. Tipo de evento inferred
	Asiento de Diario Revertido	Marca la finalización del proceso de reversión de asientos contables, donde un asiento de reversión se contabiliza con éxito. Esto sirve como un punto final alternativo para el ciclo de vida de un asiento incorrecto.
Por qué es importante Esta actividad proporciona cierre a los asientos corregidos y ayuda a analizar el esfuerzo total dedicado a los ajustes post-contabilización, lo que impacta la eficiencia general del proceso. Dónde obtener Capturado cuando el nuevo asiento de diario de reversión se mueve a un estado 'Posted'. El vínculo al diario original se mantiene a través de un campo de referencia. Capturar Identificar el `evento` de estado 'Posted' para el asiento de diario de reversión asociado. Tipo de evento inferred
	Contabilización del Diario Intentada	Esta actividad significa que un usuario ha iniciado el proceso de contabilización para un asiento aprobado. Esto puede capturarse explícitamente si el sistema registra el inicio de la tarea de contabilización.
Por qué es importante Distinguir entre el intento de contabilizar y la contabilización exitosa puede ayudar a diagnosticar problemas de rendimiento del sistema o retrasos en los trabajos por lotes que afectan el cierre financiero. Dónde obtener Esto puede ser un evento explícito registrado en una tabla de historial de trabajos por lotes o inferido de un cambio de estado a 'Contabilización en curso' en la LedgerJournalTable. Capturar Requiere el análisis de registros del sistema o trabajos por lotes relacionados con la rutina de contabilización del Libro Mayor. Tipo de evento explicit
	Diario Reenviado para Aprobación	Una entrada de diario corregida se envía de nuevo al `workflow` de aprobación para un nuevo ciclo de revisión. Esto se infiere de un cambio de estado de 'Rejected' o 'Draft' a 'In Review' o 'Submitted'.
Por qué es importante Esta actividad marca el inicio de un bucle de retrabajo. Contar estos eventos ayuda a cuantificar la tasa de retrabajo y el número promedio de bucles de aprobación por asiento contable. Dónde obtener Inferido del historial del `workflow` o mediante el seguimiento de cambios de estado en la `LedgerJournalTable` donde el estado pasa de un estado rechazado a un estado enviado. Capturar Identificar un `evento` de estado 'Submitted' que ocurre después de un `evento` de estado 'Rejected' para el mismo diario. Tipo de evento inferred
	Línea de Diario Agregada	Este evento significa que se ha añadido una línea de débito o crédito al asiento contable. Se captura cada vez que se crea una nueva línea de transacción y se asocia con el encabezado del asiento.
Por qué es importante El seguimiento de la creación de líneas de asiento ayuda a comprender la complejidad y el esfuerzo de entrada de datos para diferentes tipos de asientos. También puede resaltar retrasos entre la creación del encabezado y la finalización de la línea. Dónde obtener Capturado de la marca de `tiempo` de creación de registros en la entidad `LedgerJournalTrans`, vinculados de nuevo al encabezado del diario. Cada creación de línea es un `evento` discreto. Capturar Utilice el campo 'createdDateTime' para cada registro en la tabla LedgerJournalTrans. Tipo de evento explicit
	Reversión de Asiento de Diario Iniciada	Este evento representa el inicio de un proceso para revertir un asiento contable previamente contabilizado. Esto se captura cuando un usuario inicia la acción de reversión en el sistema.
Por qué es importante El seguimiento de las reversiones ayuda a identificar la frecuencia y las razones para corregir asientos contabilizados. Esto puede señalar problemas subyacentes en la entrada de datos inicial o en las etapas de aprobación. Dónde obtener Esta es típicamente una acción explícita del usuario que puede capturarse de las pistas de auditoría o identificando la creación de un nuevo asiento de reversión vinculado al original. Capturar Utilice el evento de creación de un nuevo asiento contable que esté marcado como una reversión de un asiento contabilizado. Tipo de evento explicit
	Revisión del Diario Iniciada	Esta actividad marca el momento en que un revisor comienza a trabajar activamente en un asiento enviado. Se puede inferir cuando el asiento se asigna a un revisor o cuando el revisor abre el registro por primera vez para su examen.
Por qué es importante Esta actividad ayuda a medir el tiempo de traspaso del revisor, que es el retraso entre la presentación y el inicio de la revisión. Puede exponer problemas de asignación de recursos o de notificación. Dónde obtener Esto a menudo no se registra explícitamente. Puede inferirse de los registros de asignación de flujo de trabajo o requiere comparar la marca de tiempo de envío con la primera marca de tiempo de modificación por parte de un usuario revisor. Capturar Requiere el análisis de registros de asignación de usuarios de flujo de trabajo o registros de actividad de usuarios, lo cual puede no ser estándar. Tipo de evento inferred

Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Microsoft Dynamics 365

Pasos

Navegue al espacio de trabajo de Gestión de Datos: Inicie sesión en su entorno de Microsoft Dynamics 365. Use la barra de búsqueda principal para encontrar y navegar al espacio de trabajo de 'Gestión de datos'.
Cree un nuevo proyecto de exportación: Dentro del espacio de trabajo de Gestión de Datos, seleccione el mosaico 'Exportar' para crear un nuevo proyecto de exportación de datos. Proporcione un nombre descriptivo para el proyecto, como 'ProcessMind_JournalEntry_Export'.
Seleccione el formato de datos: En los detalles del proyecto, especifique el formato de datos de destino. Para facilitar los pasos de transformación posteriores, seleccione 'CSV' o 'Excel'.
Agregue las entidades de datos requeridas: Este es el paso más crítico. Agregará varias entidades al proyecto para capturar todas las actividades y atributos requeridos. Para cada entidad, haga clic en 'Agregar entidad' y busque los siguientes nombres de entidad. Se recomienda agregarlas una por una.
- Ledger journal headers: Captura eventos de creación, contabilización y reversión.
- Ledger journal lines: Captura la adición de líneas individuales de débito/crédito.
- Workflow tracking status table: Captura todos los eventos relacionados con el workflow como envío, aprobación y rechazo.
Configure los filtros de entidad: Para cada entidad agregada, seleccione la opción 'Filtrar'. Aplique filtros para limitar el alcance de la exportación. Como mínimo, filtre por 'Entidad legal' (Compañía) y un rango de fechas específico en un campo de fecha relevante, como CREATEDDATETIME en Ledger journal headers, para mantener el volumen de datos manejable. Por ejemplo, exporte datos de los últimos 3 a 6 meses.
Mapee los campos de entidad: Revise los mapeos de campos para cada entidad. Asegúrese de que todos los campos necesarios para los atributos finales estén incluidos en el archivo de exportación. El sistema generalmente incluye todos los campos por defecto.
Ejecute el trabajo de exportación: Una vez configurado el proyecto, haga clic en 'Exportar' en el Panel de Acción. El sistema creará un paquete de datos que contiene archivos separados para cada entidad de datos.
Descargue los datos exportados: Una vez que el trabajo de exportación se complete con éxito, vaya al historial de trabajos y descargue el paquete de datos generado, que será un archivo zip.
Transforme los datos en un registro de eventos: Este paso debe realizarse fuera de Dynamics 365 utilizando un script (por ejemplo, Python, PowerShell) o una herramienta de preparación de datos. El objetivo es combinar y transformar los datos de los múltiples archivos exportados en un único archivo CSV de registro de eventos. Para cada archivo de origen, cree filas correspondientes a actividades específicas. Por ejemplo:
- Del archivo Ledger journal headers, cree eventos de 'Asiento de Diario Creado' utilizando la marca de tiempo de creación y eventos de 'Asiento de Diario Contabilizado' utilizando la marca de tiempo de contabilización.
- Del archivo Ledger journal lines, cree eventos de 'Línea de Diario Agregada'.
- Del archivo Workflow tracking status table, únase a los datos del encabezado y cree eventos para 'Diario Enviado para Aprobación', 'Diario Aprobado' y 'Diario Rechazado' basándose en el estado del workflow y las marcas de tiempo.
- Infiere eventos como 'Asiento de Diario Corregido' buscando una marca de tiempo modificada después de un evento de 'Diario Rechazado'.
Estructure el archivo CSV final: Asegúrese de que el archivo transformado final tenga las columnas requeridas: JournalEntryId, ActivityName y EventTime, junto con cualquier atributo recomendado. El archivo debe estar ordenado por JournalEntryId y luego por EventTime.
Cargue a ProcessMind: El registro de eventos CSV final y único está ahora listo para ser cargado a la plataforma ProcessMind para su análisis.

Configuración

Entidades de datos: El núcleo de la configuración es seleccionar las entidades correctas. Las principales son Ledger journal headers, Ledger journal lines y Workflow tracking status table. Es posible que necesite entidades adicionales dependiendo de su configuración de workflow específica.
Formato de exportación: Se recomienda CSV, ya que es un formato universal fácilmente manejable por lenguajes de scripting y herramientas de datos para el paso de transformación requerido.
Filtrado: Filtrar por Entidad Legal (Compañía) es esencial para evitar exportar datos de unidades de negocio irrelevantes. Aplicar un filtro de rango de fechas (por ejemplo, en CREATEDDATETIME) es crítico para gestionar el rendimiento y el tamaño del archivo. Un rango de 3 a 6 meses es típico para un análisis inicial.
Exportaciones incrementales: Para una supervisión continua, configure el proyecto de exportación para realizar exportaciones incrementales. Esto solo extraerá los registros que hayan cambiado desde la última ejecución, lo que es mucho más eficiente que una exportación completa cada vez.
Permisos: La cuenta de usuario que configura y ejecuta el trabajo de exportación debe tener el rol de 'administrador de gestión de datos' o permisos equivalentes para acceder al espacio de trabajo de Gestión de Datos y a las entidades de datos subyacentes.

a Consulta de ejemplo config

/*
This is not a single executable query. Instead, it defines the configuration of a Data Management Framework export project. The following entities and fields must be selected and then combined using an external script to build the final event log.
*/

-- Configuration for Entity 1: Ledger journal headers
-- Purpose: Extracts core journal header data for Created, Posted, and Reversal events.
-- Source Entity: Ledger journal headers
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Entry Created')
--   CREATEDBY -> UserName (for 'Journal Entry Created')
--   LedgerJournalWFApprovalStatus -> JournalStatus (for workflow context)
--   JournalType -> JournalType
--   company -> LegalEntity
--   PostedDateTime -> EventTime (for 'Journal Entry Posted')
--   PostedBy -> UserName (for 'Journal Entry Posted')
--   ReverseDate -> EventTime (for 'Journal Entry Reversal Initiated')
--   MODIFIEDDATETIME -> Used to infer 'Journal Entry Corrected'
--   MODIFIEDBY -> UserName

-- Configuration for Entity 2: Ledger journal lines
-- Purpose: Extracts individual transaction lines to create 'Journal Line Added' events.
-- Source Entity: Ledger journal lines
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Line Added')
--   CREATEDBY -> UserName (for 'Journal Line Added')
--   AmountInTransactionCurrency -> JournalTotalAmount (Note: Must be aggregated per JournalEntryId)
--   company -> LegalEntity

-- Configuration for Entity 3: Workflow tracking status table
-- Purpose: Extracts detailed workflow history for approval and rejection events.
-- Source Entity: Workflow tracking status table
-- Key Fields to Map:
--   ContextRecId -> (This needs to be joined back to the RecId of the LedgerJournalTable to get the JournalBatchNumber)
--   ContextTableId -> (Used to filter for Journal related workflows)
--   CREATEDDATETIME -> EventTime
--   User -> UserName
--   TrackingStatus -> Used to derive ActivityName ('Submitted For Approval', 'Journal Approved', 'Journal Rejected')
--   Comment -> RejectionReason

-- **Post-Processing Transformation Logic (to be implemented in an external script)**

-- 1. For each row in 'Ledger journal headers' export:
--    - Create one row with ActivityName = 'Journal Entry Created', EventTime = CREATEDDATETIME.
--    - If PostedDateTime is not null, create one row with ActivityName = 'Journal Entry Posted', EventTime = PostedDateTime.
--    - If ReverseDate is not null, create one row with ActivityName = 'Journal Entry Reversal Initiated', EventTime = ReverseDate. (A separate 'Journal Entry Reversed' event may need to be derived from the creation of the reversing journal).

-- 2. For each row in 'Ledger journal lines' export:
--    - Create one row with ActivityName = 'Journal Line Added', EventTime = CREATEDDATETIME.

-- 3. For each row in 'Workflow tracking status table' export (after joining to get JournalBatchNumber):
--    - IF TrackingStatus indicates submission, create ActivityName = 'Journal Submitted For Approval'.
--    - IF TrackingStatus indicates approval, create ActivityName = 'Journal Approved'.
--    - IF TrackingStatus indicates rejection, create ActivityName = 'Journal Rejected'.
--    - Other activities like 'Journal Review Started', 'Journal Entry Corrected', 'Journal Resubmitted For Approval', and 'Journal Posting Attempted' are often not explicitly logged. They must be inferred from status changes, user actions within a timeframe, or modification timestamps on the journal header after a rejection event.

Pasos

Configure la exportación de D365 a Azure Data Lake: Antes de ejecutar cualquier consulta, asegúrese de que la función nativa 'Exportar a Azure Data Lake' de Microsoft Dynamics 365 esté configurada y activa. Seleccione las entidades de datos necesarias para el proceso de asientos de diario, incluyendo como mínimo: LedgerJournalTable, LedgerJournalTrans, GeneralJournalEntry, GeneralJournalAccountEntry y WorkflowTrackingStatusTable. Deje tiempo para que se complete la sincronización inicial de datos.
Navegue a Azure Synapse Analytics: Abra su Azure Portal y navegue al espacio de trabajo de Synapse Analytics que está conectado a la cuenta de Azure Data Lake Storage que contiene sus datos de Dynamics 365.
Acceda a la base de datos SQL: Dentro de Synapse Studio, vaya al centro de 'Datos'. Localice la base de datos SQL sin servidor que se ha creado sobre sus archivos de data lake. Las entidades D365 estarán disponibles como tablas o vistas consultables.
Cree un nuevo script SQL: Abra el centro de 'Desarrollo' y cree un nuevo script SQL en blanco. Aquí es donde construirá la consulta del registro de eventos.
Copie y adapte la consulta: Copie la consulta SQL completa proporcionada en la sección 'query' de este documento en el nuevo editor de scripts en Synapse Studio.
Actualice los marcadores de posición: Revise cuidadosamente la consulta y reemplace todos los valores de los marcadores de posición. Debe actualizar el nombre de la base de datos y el esquema, por ejemplo [YourD365DB].[dbo], y establecer los parámetros StartDate y EndDate deseados para su período de análisis.
Ejecute la consulta: Ejecute el script usando el pool de SQL sin servidor. El tiempo de ejecución variará según el rango de fechas y el volumen de datos en su sistema.
Revise los resultados: Una vez que la consulta se complete, el panel de resultados mostrará el registro de eventos generado. Realice una revisión rápida para asegurarse de que las columnas (JournalEntryId, ActivityName, EventTime, etc.) y los datos se vean correctos.
Exporte el registro de eventos: Use la funcionalidad de exportación disponible en su herramienta de consulta o Synapse Studio para guardar el conjunto de resultados como un archivo CSV. Haga clic derecho en los resultados y seleccione una opción como 'Guardar como CSV'.
Prepare para la carga: Asegúrese de que el archivo CSV exportado esté codificado en UTF-8 y que los encabezados de las columnas coincidan con los requisitos de ProcessMind. No debería ser necesaria ninguna transformación de datos adicional.

Configuración

Prerrequisitos: Este método requiere una integración funcional entre Microsoft Dynamics 365 Finance y una cuenta de Azure Data Lake Storage Gen2. Debe configurarse un espacio de trabajo de Azure Synapse Analytics para consultar estos datos. Los usuarios requieren permisos de lectura adecuados tanto en Azure Synapse como en el data lake.
Entidades de datos: Asegúrese de que las siguientes entidades de D365 estén incluidas en la exportación al data lake: LedgerJournalTable, LedgerJournalTrans, WorkflowTrackingStatusTable, GeneralJournalEntry y UserInfo.
Filtrado por rango de fechas: La consulta proporcionada incluye los parámetros @StartDate y @EndDate. Es muy recomendable comenzar con un rango de fechas limitado, como de 3 a 6 meses, para gestionar el rendimiento y el costo de la consulta. Analice un período representativo de actividad empresarial.
Filtrado de entidad legal: La consulta debe filtrarse por la DataAreaId (Entidad Legal) para enfocar el análisis en una compañía específica. Este es un filtro crítico para el rendimiento en grandes entornos de D365. El marcador de posición [YourLegalEntity] debe ser reemplazado.
Configuración del Workflow: La lógica de la consulta para los eventos de aprobación y rechazo asume el uso del motor de workflow estándar de D365, que registra los datos en la WorkflowTrackingStatusTable. Si su organización utiliza un mecanismo de aprobación diferente o personalizado, la consulta deberá adaptarse.

a Consulta de ejemplo sql

DECLARE @StartDate DATETIME = '2023-01-01';
DECLARE @EndDate DATETIME = '2023-12-31';

WITH JournalHeaders AS (
    SELECT 
        JOURNALBATCHNUMBER AS JournalEntryId,
        JOURNALTYPE AS JournalType,
        DOCUMENTSTATUS AS JournalStatus, -- Captures Posted, etc.
        APPROVALSTATUS AS ApprovalStatus, -- Captures Draft, InReview, Approved, Rejected
        LOG AS RejectionReason, -- Often contains rejection comments
        POSTEDDATETIME, 
        CREATEDDATETIME,
        CREATEDBY,
        MODIFIEDDATETIME,
        MODIFIEDBY,
        DATA indignationId
    FROM 
        [YourD365DB].[dbo].LedgerJournalTable
    WHERE 
        CREATEDDATETIME BETWEEN @StartDate AND @EndDate
        AND DATA indignationId = '[YourLegalEntity]'
),
WorkflowEvents AS (
    SELECT 
        wtst.CONTEXTRECID,
        wtst.CONTEXTTABLEID,
        wtst.USERID,
        wtst.CREATEDDATETIME,
        wtst.TRACKINGSTATUS, -- Submitted, Approved, Rejected
        wtsi.INSTANCENUMBER
    FROM 
        [YourD365DB].[dbo].WorkflowTrackingStatusTable wtst
    JOIN 
        [YourD365DB].[dbo].WorkflowTrackingTable wtsi ON wtst.WORKFLOWTRACKINGTABLEINSTANCENUMBER = wtsi.RECID
    WHERE 
        wtst.CONTEXTTABLEID = (SELECT TABLEID FROM [YourD365DB].[dbo].SysTableIdTable WHERE NAME = 'LedgerJournalTable')
)

-- 1. Journal Entry Created
SELECT 
    jh.JournalEntryId AS JournalEntryId,
    'Journal Entry Created' AS ActivityName,
    jh.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    CAST(jh.ApprovalStatus AS VARCHAR) AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    (SELECT SUM(ABS(jlt.AMOUNTCREDIT)) FROM [YourD365DB].[dbo].LedgerJournalTrans jlt WHERE jlt.JOURNALBATCHNUMBER = jh.JournalEntryId) AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.CREATEDBY = u.ID

UNION ALL

-- 2. Journal Line Added
SELECT 
    jlt.JOURNALBATCHNUMBER AS JournalEntryId,
    'Journal Line Added' AS ActivityName,
    jlt.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    CAST(jh.ApprovalStatus AS VARCHAR) AS JournalStatus,
    NULL AS RejectionReason,
    jlt.DATA indignationId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    [YourD365DB].[dbo].LedgerJournalTrans jlt
JOIN 
    JournalHeaders jh ON jlt.JOURNALBATCHNUMBER = jh.JournalEntryId AND jlt.DATA indignationId = jh.DataAreaId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jlt.CREATEDBY = u.ID

UNION ALL

-- 3. Journal Submitted For Approval
SELECT 
    jh.JournalEntryId,
    'Journal Submitted For Approval' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 1 -- Submitted

UNION ALL

-- 4. Journal Review Started (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Review Started' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGTYPE = 5 -- Work item creation

UNION ALL

-- 5. Journal Approved
SELECT 
    jh.JournalEntryId,
    'Journal Approved' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Approved' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 5 -- Completion

UNION ALL

-- 6. Journal Rejected
SELECT 
    jh.JournalEntryId,
    'Journal Rejected' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Rejected' AS JournalStatus,
    jh.RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 3 -- Rejection

UNION ALL

-- 7. Journal Entry Corrected (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Entry Corrected' AS ActivityName,
    jh.MODIFIEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Corrected' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID
WHERE 
    jh.MODIFIEDDATETIME > jh.CREATEDDATETIME AND
    EXISTS (
        SELECT 1 FROM WorkflowEvents we 
        WHERE we.CONTEXTRECID = jh.RecId AND we.TRACKINGSTATUS = 3 -- Rejection
        AND jh.MODIFIEDDATETIME > we.CREATEDDATETIME
    )

UNION ALL

-- 8. Journal Resubmitted For Approval
SELECT 
    jh.JournalEntryId,
    'Journal Resubmitted For Approval' AS ActivityName,
    we.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'InReview' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
JOIN 
    WorkflowEvents we ON jh.RecId = we.CONTEXTRECID
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON we.USERID = u.ID
WHERE 
    we.TRACKINGSTATUS = 1 -- Submitted
    AND EXISTS (
        SELECT 1 FROM WorkflowEvents rej_we 
        WHERE rej_we.CONTEXTRECID = jh.RecId AND rej_we.TRACKINGSTATUS = 3 -- Rejection
        AND we.CREATEDDATETIME > rej_we.CREATEDDATETIME
    )

UNION ALL

-- 9. Journal Posting Attempted (Approximation)
SELECT 
    jh.JournalEntryId,
    'Journal Posting Attempted' AS ActivityName,
    DATEADD(second, -5, jh.POSTEDDATETIME) AS EventTime, -- Approximated as just before posting
    jh.POSTEDDATETIME AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Posting' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID -- Often posted by the last modifier or a system account
WHERE 
    jh.POSTEDDATETIME IS NOT NULL

UNION ALL

-- 10. Journal Entry Posted
SELECT 
    jh.JournalEntryId,
    'Journal Entry Posted' AS ActivityName,
    jh.POSTEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Posted' AS JournalStatus,
    NULL AS RejectionReason,
    jh.DataAreaId AS LegalEntity,
    NULL AS JournalTotalAmount
FROM 
    JournalHeaders jh
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON jh.MODIFIEDBY = u.ID
WHERE 
    jh.POSTEDDATETIME IS NOT NULL

UNION ALL

-- 11. Journal Entry Reversal Initiated
SELECT 
    gje.JOURNALNUMBER AS JournalEntryId,
    'Journal Entry Reversal Initiated' AS ActivityName,
    gje_rev.CREATEDDATETIME AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Reversing' AS JournalStatus,
    NULL AS RejectionReason,
    gje.LEDGER AS LegalEntity,
    NULL AS JournalTotalAmount
FROM
    [YourD365DB].[dbo].GeneralJournalEntry gje
JOIN
    [YourD365DB].[dbo].GeneralJournalEntry gje_rev ON gje.JOURNALNUMBER = gje_rev.OriginalJournalNumber
JOIN
    JournalHeaders jh ON gje.JOURNALNUMBER = jh.JournalEntryId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON gje_rev.CREATEDBY = u.ID
WHERE
    gje.REVERSED = 'Yes'

UNION ALL

-- 12. Journal Entry Reversed
SELECT 
    gje.JOURNALNUMBER AS JournalEntryId,
    'Journal Entry Reversed' AS ActivityName,
    gje.REVERSEDDATE AS EventTime,
    NULL AS EventEndTime,
    u.NAME AS UserName,
    jh.JournalType,
    'Reversed' AS JournalStatus,
    NULL AS RejectionReason,
    gje.LEDGER AS LegalEntity,
    NULL AS JournalTotalAmount
FROM
    [YourD365DB].[dbo].GeneralJournalEntry gje
JOIN
    JournalHeaders jh ON gje.JOURNALNUMBER = jh.JournalEntryId
LEFT JOIN 
    [YourD365DB].[dbo].UserInfo u ON gje.MODIFIEDBY = u.ID
WHERE
    gje.REVERSED = 'Yes' AND gje.REVERSEDDATE IS NOT NULL;

Pasos

Prerrequisitos y configuración del entorno: Instale Python 3.x en su máquina. Instale las bibliotecas de Python necesarias usando pip: pip install pandas requests adal. La biblioteca adal se utiliza para la autenticación de Azure Active Directory, que es requerida para Dynamics 365.
Registre una aplicación en Azure AD: Para acceder a la API de Dynamics 365, debe registrar una aplicación en su Azure Active Directory. Anote el ID de la aplicación (cliente), el ID del directorio (inquilino) y cree un secreto de cliente. Conceda a esta aplicación permisos delegados para acceder a Dynamics 365 Finance & Operations, como Financials.Read.
Configure el script de Python: Copie el script de Python proporcionado en un archivo, por ejemplo extract_journals.py. Rellene las variables de marcador de posición en la parte superior del script con su información de Azure AD y Dynamics 365: TENANT_ID, CLIENT_ID, CLIENT_SECRET y D365_URL.
Establezca los parámetros de extracción: Ajuste las variables START_DATE y END_DATE en el script para definir la ventana de tiempo para la extracción de datos. También puede personalizar la lista LEGAL_ENTITIES para filtrar por códigos de empresa específicos.
Ejecute el script de extracción: Ejecute el script desde su línea de comandos usando python extract_journals.py. El script se autenticará con Azure AD, obtendrá un token de acceso y comenzará a consultar la API OData de Dynamics 365 para obtener datos de encabezados y líneas de diario dentro del rango de fechas especificado.
Supervise la ejecución del script: El script imprimirá mensajes de progreso en la consola a medida que obtiene páginas de datos de la API. Esto puede tomar una cantidad significativa de tiempo dependiendo del volumen de datos. El script maneja la paginación de la API automáticamente para recuperar todos los registros relevantes.
Revise los datos sin procesar (Opcional): El script primero guarda los datos consultados sin procesar en raw_journal_headers.csv y raw_journal_lines.csv. Puede inspeccionar estos archivos para asegurarse de que la extracción inicial de datos fue exitosa antes de aplicar la lógica de transformación.
Comprenda la inferencia de eventos: El script procesa los datos sin procesar para inferir las 12 actividades de proceso requeridas. Por ejemplo, 'Journal Submitted For Approval' se infiere cuando el campo WorkflowApprovalStatus cambia de 'Draft' a 'Submitted'. La marca de tiempo para tales eventos se toma del campo ModifiedDateTime del registro.
Genere el registro de eventos final: Después del procesamiento, el script combina todos los eventos inferidos en un único registro de eventos estructurado. Crea las columnas requeridas: JournalEntryId, ActivityName, EventTime y otros atributos recomendados.
Exporte y verifique el archivo CSV: El registro de eventos final se guarda como journal_entry_event_log.csv. Abra este archivo para verificar su estructura y contenido. Asegúrese de que contenga las columnas esperadas y que se hayan generado datos para varias actividades.
Prepare para la carga en ProcessMind: El archivo CSV generado está en un formato adecuado para la carga. Asegúrese de que el archivo se guarde con codificación UTF-8. Ahora puede usar este archivo como fuente de datos en ProcessMind para analizar su proceso de Registro a Informe de asientos de diario.

Configuración

URL del endpoint de la API: La URL base para su API OData de Dynamics 365 Finance & Operations. Esta debe configurarse en la variable D365_URL del script, por ejemplo, https://your-org.operations.dynamics.com.
Credenciales de Azure AD: El script requiere un registro de aplicación de Azure AD. Debe proporcionar el TENANT_ID, CLIENT_ID y CLIENT_SECRET para la autenticación.
Permisos de API requeridos: La aplicación de Azure AD necesita permisos delegados para leer datos de Dynamics 365. El permiso Financials.Read suele ser suficiente para acceder a los datos del diario.
Rango de fechas: Las variables START_DATE y END_DATE del script controlan el período de extracción. Para un análisis inicial, se recomienda un período de 3 a 6 meses para equilibrar el volumen de datos y los insights del proceso.
Filtro de entidad legal: La lista LEGAL_ENTITIES del script le permite especificar qué códigos de empresa (dataAreaId) incluir en la extracción. Esto es fundamental para enfocar el análisis en las partes relevantes del negocio.
Entidades de datos: El script consulta principalmente las entidades OData LedgerJournalHeaders y LedgerJournalLines. Estas son entidades estándar para los datos de asientos contables en Dynamics 365.
Mapeo de campo de estado: La lógica del script para inferir actividades se basa en el campo estándar WorkflowApprovalStatus. Si su implementación utiliza un campo personalizado para rastrear el estado del diario, deberá actualizar el nombre del campo en el script.

a Consulta de ejemplo python

import adal
import requests
import pandas as pd
from datetime import datetime

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Azure AD Application Details
TENANT_ID = class="hl-string">'[Your Tenant ID]'
CLIENT_ID = class="hl-string">'[Your Application Client ID]'
CLIENT_SECRET = class="hl-string">'[Your Client Secret]'

class=class="hl-string">"hl-comment"># Dynamics 365 F&O Environment Details
D365_URL = class="hl-string">'https://[your-d365-url].operations.dynamics.com'
RESOURCE = D365_URL
AUTHORITY_URL = fclass="hl-string">'https://login.microsoftonline.com/{TENANT_ID}'

class=class="hl-string">"hl-comment"># Extraction Parameters
START_DATE = class="hl-string">'2023-01-01T00:00:00Z'
END_DATE = class="hl-string">'2023-12-31T23:59:59Z'
LEGAL_ENTITIES = [class="hl-string">'[YourLegalEntity1]', class="hl-string">'[YourLegalEntity2]'] class=class="hl-string">"hl-comment"># e.g., [class="hl-string">'USMF']

class=class="hl-string">"hl-comment"># --- OData Helper Functions ---

def get_access_token():
    class="hl-string">"""Authenticates with Azure AD to get an access token."""
    context = adal.AuthenticationContext(AUTHORITY_URL)
    token = context.acquire_token_with_client_credentials(RESOURCE, CLIENT_ID, CLIENT_SECRET)
    if class="hl-string">'accessToken' not in token:
        raise Exception(fclass="hl-string">"Failed to get access token: {token.get('error_description')}")
    return token[class="hl-string">'accessToken']

def execute_odata_query(entity_url, headers):
    class="hl-string">"""Executes a paginated OData query and returns a list of records."""
    all_records = []
    next_link = entity_url
    page_num = 1
    while next_link:
        print(fclass="hl-string">"Fetching page {page_num} for entity: {entity_url.split('/')[-1].split('?')[0]}...")
        response = requests.get(next_link, headers=headers)
        if response.status_code != 200:
            raise Exception(fclass="hl-string">"Query failed with status {response.status_code}: {response.text}")
        data = response.json()
        all_records.extend(data[class="hl-string">'value'])
        next_link = data.get(class="hl-string">'@odata.nextLink')
        page_num += 1
    return all_records

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Journal Entry data extraction...")
    
    class=class="hl-string">"hl-comment"># 1. Get Access Token
    access_token = get_access_token()
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'Content-Type': class="hl-string">'application/json',
        class="hl-string">'OData-MaxVersion': class="hl-string">'4.0',
        class="hl-string">'OData-Version': class="hl-string">'4.0',
        class="hl-string">'Accept': class="hl-string">'application/json'
    }

    class=class="hl-string">"hl-comment"># 2. Build and Execute Queries
    legal_entity_filter = class="hl-string">" or ".join([fclass="hl-string">"dataAreaId eq '{le}'" for le in LEGAL_ENTITIES])
    date_filter = fclass="hl-string">"CreatedDateTime ge {START_DATE} and CreatedDateTime le {END_DATE}"

    class=class="hl-string">"hl-comment"># Query LedgerJournalHeaders
    headers_fields = [
        class="hl-string">'JournalBatchNumber', class="hl-string">'dataAreaId', class="hl-string">'LedgerJournalType', class="hl-string">'WorkflowApprovalStatus',
        class="hl-string">'CreatedBy', class="hl-string">'CreatedDateTime', class="hl-string">'ModifiedBy', class="hl-string">'ModifiedDateTime', class="hl-string">'PostedDateTime',
        class="hl-string">'JournalTotalDebit', class="hl-string">'Reversed', class="hl-string">'ReversedDate', class="hl-string">'RejectionReasonComment' class=class="hl-string">"hl-comment"># Assuming a field for rejection reason
    ]
    headers_select = fclass="hl-string">"$select={','.join(headers_fields)}"
    headers_filter = fclass="hl-string">"$filter=({legal_entity_filter}) and ({date_filter})"
    headers_url = fclass="hl-string">"{D365_URL}/data/LedgerJournalHeaders?{headers_select}&{headers_filter}&cross-company=true"
    
    journal_headers_raw = execute_odata_query(headers_url, headers)
    if not journal_headers_raw:
        print(class="hl-string">"No journal headers found for the specified criteria. Exiting.")
        exit()

    df_headers = pd.DataFrame(journal_headers_raw)
    df_headers.to_csv(class="hl-string">'raw_journal_headers.csv', index=False)
    print(fclass="hl-string">"Fetched and saved {len(df_headers)} journal headers.")

    class=class="hl-string">"hl-comment"># Query LedgerJournalLines for class="hl-string">'Line Added' activity
    journal_batch_numbers = df_headers[class="hl-string">'JournalBatchNumber'].unique().tolist()
    journal_batch_filter = class="hl-string">" or ".join([fclass="hl-string">"JournalBatchNumber eq '{jbn}'" for jbn in journal_batch_numbers])
    
    lines_fields = [class="hl-string">'JournalBatchNumber', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']
    lines_select = fclass="hl-string">"$select={','.join(lines_fields)}"
    lines_filter = fclass="hl-string">"$filter=({legal_entity_filter}) and ({journal_batch_filter})"
    lines_url = fclass="hl-string">"{D365_URL}/data/LedgerJournalLines?{lines_select}&{lines_filter}&cross-company=true"

    journal_lines_raw = execute_odata_query(lines_url, headers)
    df_lines = pd.DataFrame(journal_lines_raw)
    df_lines.to_csv(class="hl-string">'raw_journal_lines.csv', index=False)
    print(fclass="hl-string">"Fetched and saved {len(df_lines)} journal lines.")

    class=class="hl-string">"hl-comment"># 3. Transform Data into Event Log Format
    print(class="hl-string">"Transforming raw data into event log...")
    event_log_frames = []

    class=class="hl-string">"hl-comment"># Rename columns for consistency
    df_headers.rename(columns={
        class="hl-string">'JournalBatchNumber': class="hl-string">'JournalEntryId',
        class="hl-string">'dataAreaId': class="hl-string">'LegalEntity',
        class="hl-string">'LedgerJournalType': class="hl-string">'JournalType',
        class="hl-string">'JournalTotalDebit': class="hl-string">'JournalTotalAmount',
        class="hl-string">'WorkflowApprovalStatus': class="hl-string">'JournalStatus',
        class="hl-string">'RejectionReasonComment': class="hl-string">'RejectionReason'
    }, inplace=True)
    df_lines.rename(columns={class="hl-string">'JournalBatchNumber': class="hl-string">'JournalEntryId'}, inplace=True)

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Created
    df_created = df_headers[[class="hl-string">'JournalEntryId', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']].copy()
    df_created[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Created'
    df_created.rename(columns={class="hl-string">'CreatedDateTime': class="hl-string">'EventTime', class="hl-string">'CreatedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(df_created)

    class=class="hl-string">"hl-comment"># Activity: Journal Line Added
    df_line_added = df_lines[[class="hl-string">'JournalEntryId', class="hl-string">'CreatedDateTime', class="hl-string">'CreatedBy']].copy()
    df_line_added[class="hl-string">'ActivityName'] = class="hl-string">'Journal Line Added'
    df_line_added.rename(columns={class="hl-string">'CreatedDateTime': class="hl-string">'EventTime', class="hl-string">'CreatedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(df_line_added)

    class=class="hl-string">"hl-comment"># Activities inferred from status changes and modifications
    class=class="hl-string">"hl-comment"># This part requires a more stateful analysis if audit trails are not directly available
    class=class="hl-string">"hl-comment"># We use ModifiedDateTime as a proxy for the event time of status changes.
    
    class=class="hl-string">"hl-comment"># NOTE: The logic below is a simplified inference. A real implementation might require parsing audit trail logs for precise timestamps.
    status_events_map = {
        class="hl-string">'Submitted': class="hl-string">'Journal Submitted For Approval',
        class="hl-string">'InProgress': class="hl-string">'Journal Review Started', class=class="hl-string">"hl-comment"># Approximation
        class="hl-string">'Approved': class="hl-string">'Journal Approved',
        class="hl-string">'Rejected': class="hl-string">'Journal Rejected',
        class="hl-string">'ChangeRequested': class="hl-string">'Journal Rejected', class=class="hl-string">"hl-comment"># Map another status to Rejected
        class="hl-string">'Canceled': class="hl-string">'Journal Rejected' class=class="hl-string">"hl-comment"># Map another status to Rejected
    }

    status_change_df = df_headers[df_headers[class="hl-string">'JournalStatus'].isin(status_events_map.keys())].copy()
    status_change_df[class="hl-string">'ActivityName'] = status_change_df[class="hl-string">'JournalStatus'].map(status_events_map)
    status_change_df.rename(columns={class="hl-string">'ModifiedDateTime': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
    event_log_frames.append(status_change_df[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName', class="hl-string">'RejectionReason']])

    class=class="hl-string">"hl-comment"># Activity: Journal Resubmitted For Approval & Journal Entry Corrected
    class=class="hl-string">"hl-comment"># Infer this by finding a class="hl-string">'Submitted' status that occurred after a class="hl-string">'Rejected' status for the same journal.
    class=class="hl-string">"hl-comment"># For simplicity, we assume any modification after rejection is a correction.
    df_rejected = status_change_df[status_change_df[class="hl-string">'ActivityName'] == class="hl-string">'Journal Rejected']
    for index, row in df_rejected.iterrows():
        class=class="hl-string">"hl-comment"># Check for modifications on the header after rejection
        header_row = df_headers[df_headers[class="hl-string">'JournalEntryId'] == row[class="hl-string">'JournalEntryId']].iloc[0]
        if pd.to_datetime(header_row[class="hl-string">'ModifiedDateTime']) > pd.to_datetime(row[class="hl-string">'EventTime']):
            class=class="hl-string">"hl-comment"># Add Corrected Event
            corrected_event = row.copy()
            corrected_event[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Corrected'
            corrected_event[class="hl-string">'EventTime'] = header_row[class="hl-string">'ModifiedDateTime']
            corrected_event[class="hl-string">'UserName'] = header_row[class="hl-string">'ModifiedBy']
            event_log_frames.append(pd.DataFrame([corrected_event]))
            
            class=class="hl-string">"hl-comment"># If status went back to submitted, it's a resubmission
            if header_row[class="hl-string">'JournalStatus'] == class="hl-string">'Submitted':
                resubmitted_event = row.copy()
                resubmitted_event[class="hl-string">'ActivityName'] = class="hl-string">'Journal Resubmitted For Approval'
                resubmitted_event[class="hl-string">'EventTime'] = header_row[class="hl-string">'ModifiedDateTime']
                resubmitted_event[class="hl-string">'UserName'] = header_row[class="hl-string">'ModifiedBy']
                event_log_frames.append(pd.DataFrame([resubmitted_event]))

    class=class="hl-string">"hl-comment"># Activity: Journal Posting Attempted (Approximation)
    class=class="hl-string">"hl-comment"># This is difficult to capture. We'll use the approval time as a proxy.
    df_approved_for_posting = status_change_df[status_change_df[class="hl-string">'ActivityName'] == class="hl-string">'Journal Approved'].copy()
    df_approved_for_posting[class="hl-string">'ActivityName'] = class="hl-string">'Journal Posting Attempted'
    event_log_frames.append(df_approved_for_posting[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Posted
    df_posted = df_headers[df_headers[class="hl-string">'PostedDateTime'].notna()].copy()
    if not df_posted.empty:
        df_posted[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Posted'
        class=class="hl-string">"hl-comment"># Use PostedDateTime if available, otherwise fallback to ModifiedDateTime
        df_posted[class="hl-string">'EventTime'] = df_posted[class="hl-string">'PostedDateTime'].fillna(df_posted[class="hl-string">'ModifiedDateTime'])
        df_posted.rename(columns={class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_posted[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># Activity: Journal Entry Reversal Initiated & Reversed
    df_reversed = df_headers[df_headers[class="hl-string">'Reversed'] == True].copy()
    if not df_reversed.empty:
        class=class="hl-string">"hl-comment"># Reversal Initiated (approximated by modification date when Reversed flag is set)
        df_reversal_initiated = df_reversed.copy()
        df_reversal_initiated[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversal Initiated'
        df_reversal_initiated.rename(columns={class="hl-string">'ModifiedDateTime': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_reversal_initiated[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])
        class=class="hl-string">"hl-comment"># Reversed (using the specific ReversedDate)
        df_reversed_final = df_reversed[df_reversed[class="hl-string">'ReversedDate'].notna()].copy()
        df_reversed_final[class="hl-string">'ActivityName'] = class="hl-string">'Journal Entry Reversed'
        df_reversed_final.rename(columns={class="hl-string">'ReversedDate': class="hl-string">'EventTime', class="hl-string">'ModifiedBy': class="hl-string">'UserName'}, inplace=True)
        event_log_frames.append(df_reversed_final[[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName']])

    class=class="hl-string">"hl-comment"># 4. Assemble Final Event Log
    print(class="hl-string">"Assembling the final event log...")
    final_event_log = pd.concat(event_log_frames, ignore_index=True)

    class=class="hl-string">"hl-comment"># Merge attributes from the header file
    attributes_to_merge = df_headers[[class="hl-string">'JournalEntryId', class="hl-string">'LegalEntity', class="hl-string">'JournalType', class="hl-string">'JournalStatus', class="hl-string">'JournalTotalAmount', class="hl-string">'RejectionReason']].drop_duplicates()
    final_event_log = pd.merge(final_event_log, attributes_to_merge, on=class="hl-string">'JournalEntryId', how=class="hl-string">'left')

    class=class="hl-string">"hl-comment"># Clean up and order columns
    final_event_log[class="hl-string">'EventTime'] = pd.to_datetime(final_event_log[class="hl-string">'EventTime'])
    final_event_log.sort_values(by=[class="hl-string">'JournalEntryId', class="hl-string">'EventTime'], inplace=True)
    final_event_log.drop_duplicates(subset=[class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime'], inplace=True)
    
    class=class="hl-string">"hl-comment"># Define column order
    final_columns = [
        class="hl-string">'JournalEntryId', class="hl-string">'ActivityName', class="hl-string">'EventTime', class="hl-string">'UserName', class="hl-string">'LegalEntity',
        class="hl-string">'JournalType', class="hl-string">'JournalStatus', class="hl-string">'JournalTotalAmount', class="hl-string">'RejectionReason'
    ]
    class=class="hl-string">"hl-comment"># Add missing columns with None
    for col in final_columns:
        if col not in final_event_log.columns:
            final_event_log[col] = None
    final_event_log = final_event_log[final_columns]
    
    class=class="hl-string">"hl-comment"># Add EventEndTime (optional, can be populated if duration is known)
    final_event_log[class="hl-string">'EventEndTime'] = None
    
    class=class="hl-string">"hl-comment"># 5. Export to CSV
    final_event_log.to_csv(class="hl-string">'journal_entry_event_log.csv', index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Extraction complete. Event log with {len(final_event_log)} events saved to journal_entry_event_log.csv")

Pasos

Navegue al espacio de trabajo de Gestión de Datos: Inicie sesión en su entorno de Microsoft Dynamics 365. Use la barra de búsqueda principal para encontrar y navegar al espacio de trabajo de 'Gestión de datos'.
Cree un nuevo proyecto de exportación: Dentro del espacio de trabajo de Gestión de Datos, seleccione el mosaico 'Exportar' para crear un nuevo proyecto de exportación de datos. Proporcione un nombre descriptivo para el proyecto, como 'ProcessMind_JournalEntry_Export'.
Seleccione el formato de datos: En los detalles del proyecto, especifique el formato de datos de destino. Para facilitar los pasos de transformación posteriores, seleccione 'CSV' o 'Excel'.
Agregue las entidades de datos requeridas: Este es el paso más crítico. Agregará varias entidades al proyecto para capturar todas las actividades y atributos requeridos. Para cada entidad, haga clic en 'Agregar entidad' y busque los siguientes nombres de entidad. Se recomienda agregarlas una por una.
- Ledger journal headers: Captura eventos de creación, contabilización y reversión.
- Ledger journal lines: Captura la adición de líneas individuales de débito/crédito.
- Workflow tracking status table: Captura todos los eventos relacionados con el workflow como envío, aprobación y rechazo.
Configure los filtros de entidad: Para cada entidad agregada, seleccione la opción 'Filtrar'. Aplique filtros para limitar el alcance de la exportación. Como mínimo, filtre por 'Entidad legal' (Compañía) y un rango de fechas específico en un campo de fecha relevante, como CREATEDDATETIME en Ledger journal headers, para mantener el volumen de datos manejable. Por ejemplo, exporte datos de los últimos 3 a 6 meses.
Mapee los campos de entidad: Revise los mapeos de campos para cada entidad. Asegúrese de que todos los campos necesarios para los atributos finales estén incluidos en el archivo de exportación. El sistema generalmente incluye todos los campos por defecto.
Ejecute el trabajo de exportación: Una vez configurado el proyecto, haga clic en 'Exportar' en el Panel de Acción. El sistema creará un paquete de datos que contiene archivos separados para cada entidad de datos.
Descargue los datos exportados: Una vez que el trabajo de exportación se complete con éxito, vaya al historial de trabajos y descargue el paquete de datos generado, que será un archivo zip.
Transforme los datos en un registro de eventos: Este paso debe realizarse fuera de Dynamics 365 utilizando un script (por ejemplo, Python, PowerShell) o una herramienta de preparación de datos. El objetivo es combinar y transformar los datos de los múltiples archivos exportados en un único archivo CSV de registro de eventos. Para cada archivo de origen, cree filas correspondientes a actividades específicas. Por ejemplo:
- Del archivo Ledger journal headers, cree eventos de 'Asiento de Diario Creado' utilizando la marca de tiempo de creación y eventos de 'Asiento de Diario Contabilizado' utilizando la marca de tiempo de contabilización.
- Del archivo Ledger journal lines, cree eventos de 'Línea de Diario Agregada'.
- Del archivo Workflow tracking status table, únase a los datos del encabezado y cree eventos para 'Diario Enviado para Aprobación', 'Diario Aprobado' y 'Diario Rechazado' basándose en el estado del workflow y las marcas de tiempo.
- Infiere eventos como 'Asiento de Diario Corregido' buscando una marca de tiempo modificada después de un evento de 'Diario Rechazado'.
Estructure el archivo CSV final: Asegúrese de que el archivo transformado final tenga las columnas requeridas: JournalEntryId, ActivityName y EventTime, junto con cualquier atributo recomendado. El archivo debe estar ordenado por JournalEntryId y luego por EventTime.
Cargue a ProcessMind: El registro de eventos CSV final y único está ahora listo para ser cargado a la plataforma ProcessMind para su análisis.

Configuración

Entidades de datos: El núcleo de la configuración es seleccionar las entidades correctas. Las principales son Ledger journal headers, Ledger journal lines y Workflow tracking status table. Es posible que necesite entidades adicionales dependiendo de su configuración de workflow específica.
Formato de exportación: Se recomienda CSV, ya que es un formato universal fácilmente manejable por lenguajes de scripting y herramientas de datos para el paso de transformación requerido.
Filtrado: Filtrar por Entidad Legal (Compañía) es esencial para evitar exportar datos de unidades de negocio irrelevantes. Aplicar un filtro de rango de fechas (por ejemplo, en CREATEDDATETIME) es crítico para gestionar el rendimiento y el tamaño del archivo. Un rango de 3 a 6 meses es típico para un análisis inicial.
Exportaciones incrementales: Para una supervisión continua, configure el proyecto de exportación para realizar exportaciones incrementales. Esto solo extraerá los registros que hayan cambiado desde la última ejecución, lo que es mucho más eficiente que una exportación completa cada vez.
Permisos: La cuenta de usuario que configura y ejecuta el trabajo de exportación debe tener el rol de 'administrador de gestión de datos' o permisos equivalentes para acceder al espacio de trabajo de Gestión de Datos y a las entidades de datos subyacentes.

a Consulta de ejemplo config

/*
This is not a single executable query. Instead, it defines the configuration of a Data Management Framework export project. The following entities and fields must be selected and then combined using an external script to build the final event log.
*/

-- Configuration for Entity 1: Ledger journal headers
-- Purpose: Extracts core journal header data for Created, Posted, and Reversal events.
-- Source Entity: Ledger journal headers
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Entry Created')
--   CREATEDBY -> UserName (for 'Journal Entry Created')
--   LedgerJournalWFApprovalStatus -> JournalStatus (for workflow context)
--   JournalType -> JournalType
--   company -> LegalEntity
--   PostedDateTime -> EventTime (for 'Journal Entry Posted')
--   PostedBy -> UserName (for 'Journal Entry Posted')
--   ReverseDate -> EventTime (for 'Journal Entry Reversal Initiated')
--   MODIFIEDDATETIME -> Used to infer 'Journal Entry Corrected'
--   MODIFIEDBY -> UserName

-- Configuration for Entity 2: Ledger journal lines
-- Purpose: Extracts individual transaction lines to create 'Journal Line Added' events.
-- Source Entity: Ledger journal lines
-- Key Fields to Map:
--   JournalBatchNumber -> JournalEntryId
--   CREATEDDATETIME -> EventTime (for 'Journal Line Added')
--   CREATEDBY -> UserName (for 'Journal Line Added')
--   AmountInTransactionCurrency -> JournalTotalAmount (Note: Must be aggregated per JournalEntryId)
--   company -> LegalEntity

-- Configuration for Entity 3: Workflow tracking status table
-- Purpose: Extracts detailed workflow history for approval and rejection events.
-- Source Entity: Workflow tracking status table
-- Key Fields to Map:
--   ContextRecId -> (This needs to be joined back to the RecId of the LedgerJournalTable to get the JournalBatchNumber)
--   ContextTableId -> (Used to filter for Journal related workflows)
--   CREATEDDATETIME -> EventTime
--   User -> UserName
--   TrackingStatus -> Used to derive ActivityName ('Submitted For Approval', 'Journal Approved', 'Journal Rejected')
--   Comment -> RejectionReason

-- **Post-Processing Transformation Logic (to be implemented in an external script)**

-- 1. For each row in 'Ledger journal headers' export:
--    - Create one row with ActivityName = 'Journal Entry Created', EventTime = CREATEDDATETIME.
--    - If PostedDateTime is not null, create one row with ActivityName = 'Journal Entry Posted', EventTime = PostedDateTime.
--    - If ReverseDate is not null, create one row with ActivityName = 'Journal Entry Reversal Initiated', EventTime = ReverseDate. (A separate 'Journal Entry Reversed' event may need to be derived from the creation of the reversing journal).

-- 2. For each row in 'Ledger journal lines' export:
--    - Create one row with ActivityName = 'Journal Line Added', EventTime = CREATEDDATETIME.

-- 3. For each row in 'Workflow tracking status table' export (after joining to get JournalBatchNumber):
--    - IF TrackingStatus indicates submission, create ActivityName = 'Journal Submitted For Approval'.
--    - IF TrackingStatus indicates approval, create ActivityName = 'Journal Approved'.
--    - IF TrackingStatus indicates rejection, create ActivityName = 'Journal Rejected'.
--    - Other activities like 'Journal Review Started', 'Journal Entry Corrected', 'Journal Resubmitted For Approval', and 'Journal Posting Attempted' are often not explicitly logged. They must be inferred from status changes, user actions within a timeframe, or modification timestamps on the journal header after a rejection event.

Su Plantilla de Datos del Registro al Informe - Asiento Contable

Su Plantilla de Datos del Registro al Informe - Asiento Contable

Del Registro al Informe - Atributos de Asientos Contables

Del Registro al Informe - Actividades de Asientos Contables

Guías de Extracción

Exportación con Microsoft Dynamics 365 Data Management Framework

Pasos

Configuración

a Consulta de ejemplo config

Consulta de Azure Data Lake vía Synapse para Dynamics 365

Pasos

Configuración

a Consulta de ejemplo sql

Extracción por Script de Python a través de la API OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

Extracción de Dataflows de Power Platform desde Dynamics 365

Pasos

Configuración

a Consulta de ejemplo config

¿Listo para comenzar?

Impulse los Asientos de Diario en Dynamics 365, Reporte Más Rápido Ahora

Su Plantilla de Datos del Registro al Informe - Asiento Contable

Su Plantilla de Datos del Registro al Informe - Asiento Contable

Del Registro al Informe - Atributos de Asientos Contables

Del Registro al Informe - Actividades de Asientos Contables

Guías de Extracción

Exportación con Microsoft Dynamics 365 Data Management Framework

Pasos

Configuración

a Consulta de ejemplo config

Consulta de Azure Data Lake vía Synapse para Dynamics 365

Pasos

Configuración

a Consulta de ejemplo sql

Extracción por Script de Python a través de la API OData de Dynamics 365

Pasos

Configuración

a Consulta de ejemplo python

Extracción de Dataflows de Power Platform desde Dynamics 365

Pasos

Configuración

a Consulta de ejemplo config

Valoramos su privacidad

¿Listo para comenzar?

Impulse los Asientos de Diario en Dynamics 365, Reporte Más Rápido Ahora