> Mejora continua de procesos > Registro a informe: asientos contables > Oracle Fusion Financials > Template de datos

Su Template de datos de Registro a informe: asiento contable

Oracle Fusion Financials

Atributos de Registro a informe: asiento contable(21) Actividades de Registro a informe: asiento contable(12) Guías de extracción(4)

Su Template de datos de Registro a informe: asiento contable

Este Template de datos ofrece una guía completa para extraer y estructurar los datos de asientos contables de Oracle Fusion Financials. Indica qué atributos esenciales recopilar y qué actividades clave seguir para obtener toda la información necesaria para un análisis exhaustivo del proceso. También incluye instrucciones prácticas para extraer los datos directamente de su sistema.

Atributos recomendados para recopilar
Actividades clave que debe seguir
Guías de extracción para Oracle Fusion Financials

¿Es nuevo en los registros de eventos? Aprenda a crear un Registro de eventos para Process Mining.

Descargar Template

Atributos de Registro a informe: asiento contable

Estos son los campos de datos recomendados para incluir en el Registro de eventos y analizar exhaustivamente el proceso de Registro a informe: asiento contable.

5 Obligatorio 6 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	Nombre del evento de negocio o la tarea específica que tuvo lugar en un momento determinado del proceso de asiento contable.
Descripción El nombre de la actividad describe un paso concreto del ciclo de vida del asiento contable, como «Journal Entry Created» o «Journal Entry Approved». Estos datos son fundamentales para crear el mapa del proceso y comprender la secuencia de eventos. El análisis de las actividades permite identificar el flujo del proceso, incluidas las rutas habituales, las desviaciones y los ciclos de retrabajo. Al hacer un seguimiento de las distintas actividades, se puede medir el tiempo dedicado a etapas específicas, como la aprobación, y detectar los pasos que más tiempo consumen o que presentan más errores. Por qué es importante Define los pasos del proceso, constituye la base del mapa del proceso y permite analizar el flujo, los cuellos de botella y las variaciones. Dónde obtenerlo Este atributo suele derivarse de cambios de estado, registros de eventos o tablas de auditoría asociados a los objetos de asiento contable del módulo del libro mayor. Ejemplos Asiento contable creadoAsiento contable enviado para aprobaciónAsiento contable aprobadoAsiento contable contabilizado
	Hora de inicio EventTime	Marca de tiempo que indica cuándo tuvo lugar una actividad o un evento específico.
Descripción Esta marca de tiempo indica la fecha y hora exactas en que se ejecutó una actividad. Es el principal dato temporal que se utiliza en Process Mining para determinar la secuencia de eventos y calcular el tiempo transcurrido entre ellos. La precisión de la hora del evento es fundamental para todos los análisis temporales, como el cálculo de los tiempos de ciclo, la identificación de cuellos de botella y el seguimiento del rendimiento frente a los acuerdos de nivel de servicio. Proporciona el orden cronológico necesario para reconstruir el flujo real del proceso. Por qué es importante Esta marca de tiempo es esencial para ordenar los eventos, calcular todas las duraciones del proceso y realizar cualquier análisis temporal. Dónde obtenerlo Esta información suele almacenarse en tablas de auditoría o en campos como «Last Update Date» o «Creation Date» de tablas de transacciones como GL_JE_HEADERS y GL_JE_LINES para eventos específicos. Ejemplos 2023-10-26T10:00:00Z2023-11-15T14:35:10Z2024-01-05T09:12:00Z
	ID del asiento contable JournalEntryId	Identificador único de un asiento contable que vincula todas las actividades relacionadas con la transacción financiera.
Descripción El ID del asiento contable es el identificador principal del caso y vincula de forma única todas las actividades relacionadas con un conjunto específico de transacciones financieras. Esto permite seguir el ciclo de vida completo de un asiento, desde su inicio hasta su contabilización final, y comprobar que se hayan registrado todos los débitos y créditos. En Process Mining, este ID es esencial para reconstruir el recorrido completo de cada asiento contable. Conecta eventos distintos, como «Journal Entry Created», «Journal Submitted For Approval» y «Journal Entry Posted», en un flujo de proceso coherente. Así se pueden analizar los tiempos de ciclo, los cuellos de botella y las variaciones del proceso. Por qué es importante Es la clave fundamental para seguir un asiento contable de principio a fin y analizar el flujo completo del proceso de cada caso. Dónde obtenerlo Es una clave principal que se encuentra en tablas centrales del libro mayor, como GL_JE_HEADERS y GL_JE_LINES. Ejemplos JE100523JE202311001882019
	Sistema de origen SourceSystem	Sistema o módulo del que proceden los datos.
Descripción Este atributo identifica el sistema de origen del que se extrajeron los datos del proceso. En un entorno de TI complejo, los datos pueden proceder de varios sistemas integrados; este campo permite distinguirlos. En el análisis de procesos, conocer el sistema de origen es fundamental para comprender las variaciones que pueden deberse al comportamiento de cada sistema. También facilita la validación de datos y la resolución de problemas, ya que permite rastrear los datos hasta su origen. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza de datos, la validación y la comprensión de las variaciones del proceso entre distintos sistemas. Dónde obtenerlo A menudo es un valor estático configurado durante la extracción de datos, aunque también puede ser un campo de las tablas de origen que identifica el sistema en el que se registró la transacción. Ejemplos Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Última actualización de datos LastDataUpdate	Marca de tiempo de la actualización o extracción más reciente de datos del sistema de origen.
Descripción Este atributo registra cuándo se actualizaron los datos por última vez. Indica qué tan recientes son los datos analizados, algo importante para valorar la vigencia de la información obtenida. En cualquier análisis, especialmente en los Dashboards operativos, conocer la hora de la última actualización de datos es fundamental para que las personas usuarias confíen en los datos y tomen decisiones fundamentadas. También indica con claridad hasta qué momento se incluyen datos en el modelo de Process Mining. Por qué es importante Indica qué tan recientes son los datos, para que las personas usuarias sepan hasta qué momento está actualizado el análisis del proceso y puedan confiar en la información obtenida. Dónde obtenerlo Este valor se genera y almacena durante la extracción y transformación de datos. Suele corresponder a la marca de tiempo en que finalizó el trabajo ETL/ELT. Ejemplos 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Categoría del asiento contable JournalCategory	Categoría del asiento contable, como «Provisión», «Ajuste» o «Reclasificación».
Descripción La categoría del asiento contable clasifica los asientos según su finalidad empresarial. Esta clasificación permite analizar el proceso con más detalle, ya que cada categoría puede tener flujos de proceso, reglas de aprobación o tiempos de ciclo distintos. Por ejemplo, los asientos de ajuste de fin de mes pueden seguir un proceso más complejo y urgente que las provisiones habituales. Analizar el proceso por categoría ayuda a descubrir estas variaciones y a adaptar las mejoras a cada tipo de asiento contable. Por qué es importante Permite segmentar el proceso según la finalidad empresarial del asiento y revela diferencias de comportamiento y rendimiento entre los distintos tipos de asientos. Dónde obtenerlo Está disponible en la tabla GL_JE_HEADERS, normalmente en un campo llamado JE_CATEGORY. Ejemplos ProvisiónManualAjusteRevalorización
	Departamento del usuario UserDepartment	Departamento o equipo al que pertenece el usuario que realizó la actividad.
Descripción Este atributo aporta contexto organizativo al vincular una actividad con un departamento específico, como «Finanzas», «Operaciones contables» o «Auditoría interna». Suele derivarse de los datos maestros de usuarios. El análisis por departamento del usuario ayuda a identificar cuellos de botella entre departamentos, comparar el rendimiento de los equipos y comprender cómo varía la ejecución del proceso en la organización. También resulta útil para asignar recursos y orientar las iniciativas de mejora de procesos. Por qué es importante Aporta contexto organizativo, permite analizar el rendimiento por equipo o departamento y pone de manifiesto las ineficiencias entre funciones. Dónde obtenerlo Por lo general, este dato no está en las tablas de transacciones. Debe obtenerse vinculando UserName con una tabla de datos maestros de usuarios o con los datos del sistema de RR. HH. Ejemplos Contabilidad generalInformes financierosCuentas por pagar
	Importe del asiento contable JournalAmount	Valor monetario total del asiento contable, que suele corresponder a la suma de los débitos.
Descripción Este atributo representa el valor financiero total de la transacción registrada en el asiento contable. El importe puede influir considerablemente en el proceso. Por ejemplo, los asientos de importe elevado pueden requerir pasos de aprobación adicionales o revisiones más exhaustivas. El análisis del importe del asiento contable permite segmentar los casos según su impacto financiero. Ayuda a responder preguntas como «¿Tardan más en aprobarse los asientos de importe elevado?» o «¿Se rechazan más los asientos que superan cierto umbral?». Así se aporta un contexto empresarial clave al flujo del proceso. Por qué es importante Aporta contexto empresarial clave, permite analizar el impacto financiero y ayuda a determinar si los asientos de importe elevado siguen un proceso distinto. Dónde obtenerlo Este valor suele calcularse como la suma de los débitos o créditos de la tabla GL_JE_LINES para un asiento contable determinado. Ejemplos 5000.00125000.75750.50
	Motivo del rechazo RejectionReason	Descripción o código que explica por qué se rechazó un asiento contable.
Descripción Cuando se rechaza un asiento contable durante el proceso de aprobación, este atributo registra el motivo. Puede ser un código predefinido o un comentario de texto libre de quien aprobó. Es uno de los atributos más importantes para analizar las causas raíz de las ineficiencias del proceso. Al analizar los motivos de rechazo más frecuentes, las organizaciones pueden detectar oportunidades de mejora, como ofrecer más formación a quienes preparan los asientos, aclarar las directrices o reforzar los controles del sistema. Este atributo facilita directamente el Dashboard «Análisis de la tasa de rechazo de asientos contables». Por qué es importante Aporta información directa sobre las causas raíz del retrabajo y las demoras del proceso, lo que permite aplicar mejoras específicas para reducir los rechazos. Dónde obtenerlo Esta información puede almacenarse en tablas del flujo de trabajo o de auditoría asociadas al proceso de aprobación, o en un campo de notas de la cabecera del asiento. Ejemplos Combinación de cuentas incorrectaDocumentación justificativa insuficienteSupera el presupuesto
	Origen del asiento contable JournalSource	Submayor o sistema de origen que generó el asiento contable, como «Cuentas por pagar», «Cuentas por cobrar» o «Manual».
Descripción Este atributo indica el origen del asiento contable dentro del sistema ERP. Los asientos pueden crearse manualmente en el libro mayor o generarse automáticamente desde submayores, como los de cuentas por pagar, cuentas por cobrar o activos fijos. El origen del asiento contable es un atributo clave para analizar la automatización. Permite distinguir entre asientos manuales y generados por el sistema, y facilita el cálculo del KPI «Porcentaje de asientos contables automatizados». Los procesos de asientos procedentes de distintas fuentes suelen diferir considerablemente en complejidad y eficiencia. Por qué es importante Distingue los asientos manuales de los automatizados, algo fundamental para medir los niveles de automatización y analizar las diferencias entre procesos. Dónde obtenerlo Está disponible en la tabla GL_JE_HEADERS, normalmente en un campo llamado JE_SOURCE. Ejemplos ManualCuentas por pagarActivosCuentas por cobrar
	Usuario UserName	Usuario que realizó la actividad, por ejemplo, al crear, aprobar o contabilizar el asiento contable.
Descripción Este atributo identifica a la persona empleada o al usuario del sistema responsable de ejecutar una actividad. Es fundamental para comprender la distribución de la carga de trabajo y el rendimiento, así como para detectar cuellos de botella individuales. El campo UserName permite filtrar los procesos por usuario, comparar la eficiencia entre usuarios e investigar las causas de las demoras o los errores. También facilita el análisis de Dashboards como «Carga de trabajo y eficiencia de usuarios por equipo» y de KPI como el «Índice de cuellos de botella de asientos por usuario». Por qué es importante Asigna la responsabilidad de los pasos del proceso y permite analizar la carga de trabajo, el rendimiento individual y las necesidades de formación. Dónde obtenerlo Se encuentra en tablas de transacciones como GL_JE_HEADERS (por ejemplo, en CREATED_BY y LAST_UPDATED_BY) y en las tablas de auditoría relacionadas. Ejemplos john.doesusan.smithautoprocess_user
	Contabilización puntual IsOnTimePosting	Indicador calculado que es verdadero si el asiento se contabilizó en la fecha prevista o antes.
Descripción Este atributo booleano se obtiene al comparar la marca de tiempo de la actividad «Journal Entry Posted» con la fecha prevista de contabilización. Si la contabilización se realiza en la fecha prevista o antes, el valor es «verdadero»; de lo contrario, es «falso». Este atributo facilita directamente el cálculo del KPI «Porcentaje de contabilizaciones puntuales de asientos contables». También permite filtrar y analizar fácilmente los asientos atrasados para identificar causas frecuentes de demora, como determinadas categorías de asientos o personas que aprueban. Por qué es importante Ofrece un resultado claro y binario sobre la puntualidad de la contabilización, lo que simplifica el análisis de las tasas de puntualidad y las causas raíz de las demoras. Dónde obtenerlo Este atributo lo calcula la herramienta de Process Mining. Requiere el atributo «TargetPostingDate» y la marca de tiempo de la actividad «Journal Entry Posted». Ejemplos truefalse
	Es retrabajo IsRework	Indicador calculado que es verdadero si el asiento contable pasó por un ciclo de rechazo y corrección.
Descripción Este atributo booleano se calcula para identificar los casos que han requerido retrabajo. Normalmente se marca como «verdadero» para cualquier actividad posterior a un evento «Journal Entry Rejected», como «Journal Corrected and Resubmitted». Es retrabajo es un atributo útil para el análisis, ya que permite cuantificar fácilmente el volumen y el impacto de los ciclos de retrabajo. Facilita directamente el KPI «Tasa media de retrabajo de asientos contables» y ayuda a comparar el flujo y la duración de los casos que requieren retrabajo con los que se procesan correctamente a la primera. Por qué es importante Identifica directamente los casos que han pasado por ciclos de retrabajo ineficientes y facilita la cuantificación de la frecuencia y el impacto de los fallos del proceso. Dónde obtenerlo Este dato no está disponible en el sistema de origen. Se calcula en la herramienta de Process Mining mediante el análisis de la secuencia de actividades de cada caso. Ejemplos truefalse
	Estado de contabilización PostingStatus	Estado actual de contabilización del asiento contable, por ejemplo, «Sin contabilizar» o «Contabilizado».
Descripción Este atributo refleja el estado actual del asiento contable con respecto a su contabilización en el libro mayor. Indica en qué punto del ciclo de vida se encuentra el asiento, especialmente si el proceso sigue en curso. El estado de contabilización es fundamental para el Dashboard «Seguimiento en tiempo real del estado de los asientos contables», que ofrece una vista de todos los asientos activos. Ayuda a supervisar los atrasos de asientos pendientes de contabilización e identificar demoras en las últimas etapas del proceso. Por qué es importante Indica el estado actual de un asiento, algo esencial para supervisar los atrasos y hacer seguimiento de los asientos en curso. Dónde obtenerlo Está disponible en la tabla GL_JE_HEADERS, normalmente en una columna como STATUS o POSTING_STATUS. Ejemplos ContabilizadoSin contabilizarError
	Fecha prevista de contabilización TargetPostingDate	Fecha límite prevista para contabilizar el asiento contable.
Descripción La fecha prevista de contabilización es la fecha límite para contabilizar un asiento en el libro mayor. Suele determinarse según los acuerdos de nivel de servicio (SLA) o los calendarios de cierre de fin de mes. Sirve como referencia para medir el rendimiento. Este atributo es esencial para calcular el KPI «Porcentaje de contabilizaciones puntuales de asientos contables». Al comparar la fecha real de contabilización con la prevista, el sistema puede marcar automáticamente los asientos como puntuales o atrasados y medir con claridad el cumplimiento del calendario del proceso. Por qué es importante Define el acuerdo de nivel de servicio o la fecha límite de contabilización y permite calcular los KPI de puntualidad. Dónde obtenerlo Puede que no sea un campo estándar. Es posible que se derive de reglas de negocio basadas en la fecha de creación, el período contable o la categoría del asiento. Ejemplos 2023-10-312023-11-302024-01-05
	Hora de finalización EndTime	Marca de tiempo que indica cuándo se completó una actividad específica.
Descripción La hora de finalización marca el momento en que concluye una actividad. Mientras que la hora de inicio registra cuándo comienza, la hora de finalización indica cuándo termina y permite calcular con precisión el tiempo de procesamiento de ese paso. Este dato es esencial para calcular los tiempos de procesamiento de las actividades, una métrica clave para identificar cuellos de botella y medir la eficiencia de los recursos. Por ejemplo, la diferencia entre la hora de finalización y la hora de inicio de la actividad «Journal Entry Reviewed» indica el tiempo real que una persona revisora dedicó a la tarea. Por qué es importante Permite calcular la duración real o el tiempo de procesamiento de cada actividad, un dato clave para identificar problemas de eficiencia. Dónde obtenerlo Al igual que la hora de inicio, suele encontrarse en tablas de auditoría o puede inferirse a partir de la hora de inicio de la actividad siguiente del proceso. Ejemplos 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Indicador de reversión ReversalIndicator	Indicador que señala si el asiento contable revierte otro asiento.
Descripción Este atributo booleano identifica los asientos contables creados para revertir un asiento contabilizado anteriormente. Las reversiones son un tipo específico de asiento que suele seguir un proceso distinto y, en ocasiones, problemático. Analizar este indicador es clave para el Dashboard «Rendimiento del proceso de reversión de asientos contables». Permite aislar los procesos de reversión y medir su frecuencia, sus causas y sus tiempos de ciclo. Así se pueden detectar problemas subyacentes en los asientos originales que hacen necesaria la reversión. Por qué es importante Permite aislar y analizar el proceso de reversión, que a menudo indica errores o problemas en la transacción original. Dónde obtenerlo Puede tratarse de un indicador específico de la tabla GL_JE_HEADERS, como ACCRUAL_REV_FLAG, o identificarse mediante vínculos con el asiento original que se revierte. Ejemplos truefalse
	Moneda CurrencyCode	Código de moneda del importe del asiento contable, como USD, EUR o GBP.
Descripción El código de moneda especifica la moneda de los importes financieros del asiento contable. Es esencial para las organizaciones multinacionales que realizan transacciones en varias monedas. Este atributo garantiza que los valores financieros se interpreten correctamente. Permite filtrar por moneda y es necesario para cualquier análisis que compare o agregue importes monetarios de distintas regiones. Por qué es importante Aporta el contexto necesario para interpretar correctamente los importes financieros y permite realizar análisis específicos por moneda. Dónde obtenerlo Está disponible en la tabla GL_JE_HEADERS, normalmente en un campo llamado CURRENCY_CODE. Ejemplos USDEURGBPJPY
	Nombre del libro mayor LedgerName	Nombre del libro mayor en el que se registra el asiento contable.
Descripción El nombre del libro mayor identifica el libro al que pertenece el asiento contable. En organizaciones con varias entidades jurídicas o requisitos de información, puede haber varios libros mayores, como uno principal para la contabilidad corporativa y otros secundarios para los informes legales locales. Este atributo es esencial para filtrar y comparar procesos entre distintas entidades jurídicas o unidades de negocio. Garantiza que los análisis se realicen en el contexto organizativo adecuado, algo especialmente importante para el cumplimiento financiero y la elaboración de informes. Por qué es importante Permite filtrar y comparar el análisis de procesos entre distintas entidades jurídicas o marcos contables, algo fundamental para las grandes organizaciones. Dónde obtenerlo Se encuentra en la tabla GL_JE_HEADERS, normalmente vinculado mediante LEDGER_ID, que puede relacionarse con GL_LEDGERS para obtener el nombre. Ejemplos Libro mayor principal de EE. UU.Libro mayor legal del Reino UnidoLibro mayor de consolidación global
	Período contable AccountingPeriod	Período fiscal en el que se contabiliza el asiento, como «Ene-24».
Descripción El período contable especifica el período financiero en que se reconoce la transacción. Es un dato fundamental para todos los informes y análisis financieros. En Process Mining, este atributo es clave para analizar tendencias. Permite comparar el rendimiento del proceso, por ejemplo, los tiempos de ciclo o las tasas de rechazo, entre distintos meses o trimestres. Esto ayuda a identificar efectos estacionales, como el aumento de la carga de trabajo durante el cierre de fin de mes, y a medir el impacto de las mejoras del proceso a lo largo del tiempo. Por qué es importante Permite analizar las tendencias de los KPI a lo largo del tiempo, medir las mejoras del proceso e identificar patrones estacionales, como la presión al cierre de mes. Dónde obtenerlo Está disponible en la tabla GL_JE_HEADERS, normalmente en un campo llamado PERIOD_NAME. Ejemplos Ene-24Feb-24Mar-24
	Tiempo de ciclo de principio a fin EndToEndCycleTime	Duración total calculada desde la creación del asiento contable hasta su conciliación final.
Descripción Esta métrica representa el tiempo total que un asiento contable permanece en el proceso, desde el primer evento «Journal Entry Created» hasta el evento final «Journal Entry Reconciled». Ofrece una visión integral del rendimiento del proceso. Es un KPI principal para medir la eficiencia general del proceso. Se utiliza en Dashboards de tendencias para hacer seguimiento del impacto de las iniciativas de mejora a lo largo del tiempo y sirve como referencia para medir todos los cambios del proceso. Por qué es importante Ofrece una medida general de la salud y la eficiencia del proceso completo, por lo que es una métrica clave para los informes ejecutivos. Dónde obtenerlo La plataforma de Process Mining calcula esta métrica como la diferencia entre las marcas de tiempo del primer y el último evento de cada caso. Ejemplos P10DT5HP4DT12HP22D

Obligatorio Recomendado Opcional

Actividades de Registro a informe: asiento contable

Estos son los pasos y los hitos clave que debe registrar en el Registro de eventos para descubrir con precisión el proceso de asientos contables.

5 Recomendado 7 Opcional

	Actividad	Descripción
	Asiento contable aprobado	La persona designada para aprobar ha dado su aprobación formal al asiento contable y ha confirmado su exactitud y validez. Este es el último paso del flujo de trabajo de aprobación y permite contabilizar el asiento.
Por qué es importante Este hito marca el final del proceso de aprobación. El tiempo transcurrido entre el envío y la aprobación es un KPI clave para medir la eficiencia del flujo de trabajo e identificar cuellos de botella en la aprobación. Dónde obtenerlo Este evento se infiere a partir de un cambio de estado en la tabla GL_JE_HEADERS, cuando el campo APPROVAL_STATUS_CODE se actualiza a «APPROVED». Las tablas del flujo de trabajo contienen la identidad de quien aprobó y la marca de tiempo. Capturar Registre la marca de tiempo en que APPROVAL_STATUS_CODE cambia a «APPROVED» en GL_JE_HEADERS. Tipo de evento inferred
	Asiento contable conciliado	El asiento contable se ha cotejado y saldado durante la conciliación de cuentas al cierre del período. Esto confirma que la transacción coincide con otros datos financieros, como los extractos bancarios.
Por qué es importante Esta actividad constituye el verdadero punto final del ciclo de vida del asiento. Medir el tiempo entre la contabilización y la conciliación es un KPI clave para evaluar la eficiencia del proceso de cierre financiero. Dónde obtenerlo Este evento suele registrarse en Oracle Financial Consolidation and Close Cloud Service (FCCS) o Account Reconciliation Cloud Service (ARCS), no en el libro mayor. Se infiere a partir de un cambio de estado en el registro de conciliación vinculado al asiento. Capturar Correlacione los datos del asiento con las actualizaciones del estado de conciliación en las tablas de ARCS o FCCS. Tipo de evento inferred
	Asiento contable contabilizado	Los datos financieros del asiento contable se han registrado correctamente en el libro mayor. Los débitos y créditos ya se reflejan en los saldos de las cuentas.
Por qué es importante Este es un hito clave: el asiento pasa a formar parte del registro financiero oficial. Es esencial para medir el porcentaje de contabilizaciones puntuales y el tiempo total desde la creación hasta la contabilización. Dónde obtenerlo Esto se infiere a partir de un cambio de estado en la tabla GL_JE_HEADERS, cuando el campo STATUS cambia a «P» (contabilizado). La tabla GL_JE_BATCHES también contiene un estado de contabilización. Capturar Registre la marca de tiempo en que STATUS cambia a «P» en GL_JE_HEADERS. Tipo de evento inferred
	Asiento contable creado	Esta actividad marca el inicio del proceso de asientos contables. Corresponde al momento en que un usuario crea una nueva cabecera de asiento y empieza a introducir datos, antes de enviarlo a revisión o aprobación.
Por qué es importante Este es el evento de inicio principal del proceso. Analizar el tiempo transcurrido desde esta actividad hasta los pasos siguientes permite medir la eficiencia de la introducción inicial de datos y el tiempo de ciclo total del proceso. Dónde obtenerlo Este evento suele inferirse a partir de la marca de tiempo de la fecha de creación de la tabla GL_JE_HEADERS para un ID del asiento contable específico. La tabla también indica quién creó el registro. Capturar Utilice CREATION_DATE de la tabla GL_JE_HEADERS. Tipo de evento inferred
	Asiento contable enviado para aprobación	Esta actividad se produce cuando el usuario envía formalmente el asiento contable completado al flujo de aprobación. El asiento pasa de un estado de borrador o incompleto a uno pendiente de aprobación.
Por qué es importante Este es un hito clave para empezar a medir los tiempos del ciclo de aprobación e identificar cuellos de botella. Marca el paso de la fase de introducción de datos a la de revisión y aprobación. Dónde obtenerlo Este evento se infiere a partir de un cambio de estado en la tabla GL_JE_HEADERS, concretamente cuando APPROVAL_STATUS_CODE cambia a un valor como 'REQUIRED' o 'INITIATED'. También puede registrarse la marca de tiempo de envío. Capturar Registre la marca de tiempo en que APPROVAL_STATUS_CODE de GL_JE_HEADERS cambia para indicar el envío. Tipo de evento inferred
	Asiento contable corregido y enviado de nuevo	Después de que se rechaza un asiento contable, quien lo creó realiza las correcciones necesarias y lo vuelve a enviar para su aprobación. Esta actividad marca el inicio de un nuevo ciclo de aprobación para el mismo asiento.
Por qué es importante El seguimiento del retrabajo es esencial para comprender las ineficiencias del proceso. Esta actividad, junto con «Asiento contable rechazado», permite medir la duración y la frecuencia del retrabajo. Dónde obtenerlo Este es un evento posterior de «Journal Submitted For Approval» para un asiento que antes estaba en estado «REJECTED». Se identifica analizando la secuencia de cambios de estado de un mismo ID de asiento. Capturar Identifique la marca de tiempo de un evento de envío que ocurra después de un evento de rechazo para el mismo ID de caso. Tipo de evento inferred
	Asiento contable rechazado	Un aprobador ha revisado el asiento contable y lo ha rechazado por errores, falta de documentación o incumplimiento de políticas. Esta acción lo devuelve a quien lo creó para que lo corrija.
Por qué es importante Esta actividad es fundamental para analizar los ciclos de retrabajo, las tasas de rechazo y las métricas de acierto a la primera. Una frecuencia elevada de rechazos apunta a problemas de calidad de los datos o de formación. Dónde obtenerlo Se infiere a partir de un cambio de estado en la tabla GL_JE_HEADERS cuando APPROVAL_STATUS_CODE se actualiza a 'REJECTED'. El historial del flujo de trabajo registra el usuario y la marca de tiempo de esta acción. Capturar Registre la marca de tiempo en que APPROVAL_STATUS_CODE de GL_JE_HEADERS se establece en 'REJECTED'. Tipo de evento inferred
	Asiento contable revisado	Paso de revisión que puede realizarse antes del proceso formal de aprobación o como parte de este. Corresponde a la comprobación de un colega o gerente para verificar la precisión y el cumplimiento antes de que el asiento pase al aprobador final.
Por qué es importante Aislar esta actividad permite distinguir el tiempo de revisión preliminar del tiempo de aprobación final. También puede revelar cuellos de botella ocultos cuando la revisión es informal, pero requiere mucho tiempo. Dónde obtenerlo Puede ser un paso explícito de un flujo de aprobación con varias etapas y quedar registrado en las tablas del historial del flujo de trabajo. Si la revisión es informal, no queda registrada. Puede inferirse si se registra la acción de un usuario específico antes de la decisión final de aprobación. Capturar Analice las tablas del historial del flujo de trabajo para encontrar pasos intermedios de aprobación o revisión anteriores al estado final 'Aprobado'. Tipo de evento inferred
	Contabilización verificada	Es un paso de verificación posterior a la contabilización en el que una persona o un sistema confirma que el asiento se contabilizó correctamente y que los saldos son los esperados. A menudo se trata de un control manual.
Por qué es importante Analizar esta actividad ayuda a conocer el tiempo dedicado a los controles manuales y al aseguramiento de la calidad después de la contabilización. También puede revelar oportunidades para automatizar los procesos de verificación. Dónde obtenerlo Es poco probable que Oracle Fusion registre este evento de forma explícita. Habría que inferirlo a partir de otras acciones, como la ejecución de un informe específico por parte de una persona o la actualización de un campo de estado personalizado, que no forma parte de la configuración estándar. Capturar Requiere lógica personalizada, como registrar la hora de ejecución de los informes de verificación o las actualizaciones de un campo flexfield descriptivo. Tipo de evento inferred
	Documentación de respaldo adjunta	Representa la acción de adjuntar documentos de respaldo, como facturas u hojas de cálculo, al asiento contable. A menudo se hace para proporcionar contexto y pruebas a auditores y aprobadores.
Por qué es importante El seguimiento de esta actividad ayuda a determinar si los retrasos se deben a la falta de documentación. También aporta información sobre el cumplimiento y la integridad de los asientos contables antes de que entren en el flujo de aprobación. Dónde obtenerlo Puede ser difícil registrar esta actividad como un evento independiente. Es posible inferirla a partir de las marcas de tiempo de tablas de adjuntos, como FND_ATTACHED_DOCUMENTS, vinculadas al registro del asiento contable en GL_JE_HEADERS. Capturar Infiera esta actividad a partir de la fecha de creación de los registros de FND_ATTACHED_DOCUMENTS vinculados al asiento contable. Tipo de evento inferred
	Inicio de la contabilización del asiento	Se ha iniciado el proceso para contabilizar el asiento aprobado en el libro mayor. Este paso puede ser automático o manual y pone el asiento en cola para que lo procese el programa de contabilización.
Por qué es importante Esta actividad separa la aprobación del proceso técnico de contabilización. Las demoras entre la aprobación y el inicio de la contabilización pueden indicar problemas de programación o limitaciones de recursos en el motor de contabilización. Dónde obtenerlo Esto puede inferirse a partir de los cambios de estado en la tabla GL_JE_BATCHES o de la hora de envío de la solicitud concurrente de contabilización asociada al lote de asientos. Capturar Identifique la hora de envío de la solicitud del programa de contabilización del libro mayor para el lote de asientos correspondiente. Tipo de evento inferred
	Reversión del asiento procesada	Se ha creado y contabilizado un asiento de reversión para anular el efecto financiero del asiento original en un período posterior. Es una práctica habitual con las provisiones.
Por qué es importante El seguimiento de las reversiones ayuda a identificar los tipos de asientos que se revierten con frecuencia y a analizar la eficiencia del propio proceso de reversión. Esto puede revelar problemas en la gestión de provisiones. Dónde obtenerlo Esto se infiere al identificar un nuevo asiento contable vinculado explícitamente al original como su reversión. La tabla GL_JE_HEADERS incluye campos como REVERSAL_PERIOD y REVERSAL_FLAG para identificar y vincular estos asientos. Capturar Identifique la fecha de creación y contabilización del nuevo asiento cuya cabecera indica que revierte el asiento original. Tipo de evento inferred

Recomendado Opcional

Guías de extracción

Cómo obtener sus datos de Oracle Fusion Financials

Pasos

Vaya al área de trabajo Reports and Analytics: Inicie sesión en Oracle Fusion Financials. En el menú Navigator, vaya a Tools y seleccione Reports and Analytics. Este es el espacio central para crear y gestionar análisis e informes.
Cree un modelo de datos de BI Publisher: En lugar de empezar con un análisis de OTBI, para extraer este tipo de Registro de eventos resulta más eficaz crear directamente un modelo de datos de BI Publisher. Así podrá usar una consulta SQL personalizada con instrucciones UNION ALL. Haga clic en el botón 'Browse Catalog', vaya a una carpeta adecuada y seleccione Create > Data Model.
Defina el conjunto de datos de la consulta SQL: En el editor del modelo de datos, haga clic en el icono '+' para añadir un conjunto de datos y seleccione 'SQL Query'. Asigne un nombre descriptivo, por ejemplo, 'JournalEventLog'.
Introduzca la consulta SQL: Seleccione 'Oracle BI EE' como fuente de datos. Copie el script SQL completo de la sección Query que aparece más abajo y péguelo en el área de texto SQL Query. La consulta reúne todas las actividades y los atributos necesarios en una estructura unificada.
Defina los parámetros: La consulta proporcionada usa parámetros como :start_date, :end_date y :ledger_name. La interfaz del modelo de datos los detectará automáticamente. Debe configurarlos como parámetros, asignarles los tipos de datos adecuados (Date o Text) y, si es necesario, valores predeterminados. Así podrá ejecutar el informe con flexibilidad.
Cree un informe a partir del modelo de datos: Después de guardar el modelo, vuelva al catálogo. Haga clic en Create > Report. En el asistente de creación, seleccione 'Use Existing Data Model' y localice el modelo que acaba de crear.
Configure la disposición del informe: En el editor de disposición, elija 'Table'. Arrastre todas las columnas del modelo de datos a la tabla para asegurarse de que se incluyan en la exportación. No hace falta aplicar un formato complejo.
Establezca CSV como formato de salida predeterminado: En el editor del informe, vaya al enlace 'View a List'. En la sección 'Output Formats', compruebe que esté seleccionado 'CSV'. Se recomienda desmarcar los demás formatos para simplificar la programación. Guarde el informe.
Programe el informe para la extracción automatizada: Busque el informe guardado en el catálogo y haga clic en 'More' y luego en 'Schedule'. Cree una nueva tarea programada y configure la frecuencia, por ejemplo, diaria o semanal.
Configure la exportación y la entrega: En la pestaña 'Output' de la tarea programada, especifique los detalles de salida. Seleccione el informe y elija 'CSV' como formato. En la pestaña 'Destination', puede configurar la entrega del archivo a una ubicación del servidor de contenido (UCM) o a un servidor SFTP externo para recuperarlo automáticamente.
Recupere y prepare los datos: Cuando se ejecute la tarea programada, recupere el archivo CSV generado desde el destino configurado. Compruebe que los encabezados de columna coincidan con los requisitos de ingesta de ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. El archivo estará listo para cargarse.

Configuración

Fuente de datos: Ejecute la consulta en la fuente de datos 'Oracle BI EE' de BI Publisher, que se conecta a las vistas de la base de datos transaccional que utiliza OTBI.
Áreas temáticas clave (como referencia): La lógica de la consulta se basa principalmente en datos del área temática 'General Ledger - Journals Real Time'. También combina lógicamente datos que se encontrarían en 'HCM - Workforce Management - Worker Assignment Real Time' para los detalles de usuario y, posiblemente, en áreas temáticas de flujos de trabajo para el historial de aprobaciones.
Filtrado por intervalo de fechas: Es fundamental limitar los datos a un período manejable. La consulta incluye los parámetros :start_date y :end_date. Para el análisis inicial, recomendamos extraer entre 3 y 6 meses de datos. El filtro se aplica a la fecha de creación del asiento.
Filtrado por libro mayor: Use el parámetro :ledger_name para limitar la extracción a un libro mayor principal específico. Extraer datos de todos los libros mayores a la vez puede generar archivos muy grandes y problemas de rendimiento.
Requisitos previos: La persona que cree y programe el informe debe tener los roles de BI adecuados, como 'BI Administrator' o 'BI Author'. Además, su perfil de seguridad de datos debe permitir el acceso a los libros mayores y las unidades de negocio consultados.
Programación: Para obtener un rendimiento óptimo y evitar afectar a quienes usan el sistema, programe la extracción fuera de las horas de mayor actividad, por ejemplo, durante la noche.

Consulta de ejemplo sql

WITH JournalHeaders AS (
    SELECT
        gjh.je_header_id,
        gjh.ledger_id,
        gl.name AS ledger_name,
        gjb.je_batch_id,
        gjh.doc_sequence_value,
        gjh.name AS journal_name,
        gjc.user_je_category_name AS journal_category,
        gjs.user_je_source_name AS journal_source,
        gjh.default_effective_date,
        gjh.creation_date,
        gjh.created_by,
        gjh.last_update_date,
        gjh.last_updated_by,
        gjh.posted_date,
        gjb.approval_status_code AS batch_approval_status,
        gjh.accrual_rev_period_name,
        gjh.accrual_rev_je_header_id,
        (SELECT SUM(accounted_dr) FROM gl_je_lines WHERE je_header_id = gjh.je_header_id) AS journal_amount
    FROM
        gl_je_headers gjh
    JOIN
        gl_je_batches gjb ON gjh.je_batch_id = gjb.je_batch_id
    JOIN
        gl_ledgers gl ON gjh.ledger_id = gl.ledger_id
    JOIN
        gl_je_categories_tl gjc ON gjh.je_category = gjc.je_category_name AND gjc.language = USERENV('LANG')
    JOIN
        gl_je_sources_tl gjs ON gjh.je_source = gjs.je_source_name AND gjs.language = USERENV('LANG')
    WHERE
        gjh.creation_date BETWEEN TO_DATE(:start_date, 'YYYY-MM-DD') AND TO_DATE(:end_date, 'YYYY-MM-DD')
        AND gl.name = :ledger_name
)
-- 1. Journal Entry Created
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment", -- Placeholder: Configure based on your department tracking
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(SYSDATE) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.creation_date AS "EventTime",
    u.username AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    fnd_attached_documents fad
JOIN
    JournalHeaders jh ON fad.pk1_value = TO_CHAR(jh.je_header_id) AND fad.entity_name = 'GL_JE_HEADERS'
LEFT JOIN
    per_users u ON fad.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(fad.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_transactions wft ON wft.transaction_id = jh.je_batch_id AND wft.application_id = 101 AND wft.transaction_class = 'Journal Batch'
JOIN
    fun_all_wf_approvals wfa ON wft.transaction_id = wfa.transaction_id AND wfa.response = 'SUBMITTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 4. Journal Entry Reviewed & 7. Journal Entry Approved
SELECT
    jh.je_header_id AS "JournalEntryId",
    CASE
        WHEN wfa.approval_level < (SELECT MAX(approval_level) FROM fun_all_wf_approvals WHERE transaction_id = wfa.transaction_id) THEN 'Journal Entry Reviewed'
        ELSE 'Journal Entry Approved'
    END AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'APPROVED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    wfa.created_date AS "EventTime",
    wfa.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    wfa.reason AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    fun_all_wf_approvals wfa ON wfa.transaction_id = jh.je_batch_id AND wfa.response = 'REJECTED'
LEFT JOIN
    per_users u ON wfa.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(wfa.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 6. Journal Corrected and Resubmitted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    resubmit_events.created_date AS "EventTime",
    resubmit_events.updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN (
    SELECT wfa.transaction_id, wfa.created_date, wfa.updated_by
    FROM fun_all_wf_approvals wfa
    WHERE wfa.response = 'SUBMITTED'
    AND EXISTS (
        SELECT 1
        FROM fun_all_wf_approvals prev_wfa
        WHERE prev_wfa.transaction_id = wfa.transaction_id
        AND prev_wfa.response = 'REJECTED'
        AND prev_wfa.created_date < wfa.created_date
    )
) resubmit_events ON jh.je_batch_id = resubmit_events.transaction_id
LEFT JOIN
    per_users u ON resubmit_events.updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(resubmit_events.created_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 8. Journal Posting Initiated
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    gjb.last_update_date AS "EventTime",
    gjb.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_batches gjb ON jh.je_batch_id = gjb.je_batch_id
WHERE
    gjb.status = 'I' -- 'I' typically means Selected for Posting
    AND jh.posted_date IS NOT NULL
LEFT JOIN
    per_users u ON gjb.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(gjb.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.posted_date AS "EventTime",
    jh.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
LEFT JOIN
    per_users u ON jh.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(jh.posted_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.posted_date IS NOT NULL

UNION ALL

-- 10. Posting Verified - This is a placeholder as it is typically a manual control step not logged in a standard table.
-- This part of the query will return no rows unless you have a custom solution, such as a Descriptive Flexfield (DFF), to track this.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Posting Verified' AS "ActivityName",
    jh.last_update_date AS "EventTime", -- Placeholder timestamp
    jh.last_updated_by AS "UserName", -- Placeholder user
    NULL AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
WHERE
    1 = 2 -- This condition ensures no rows are returned. Replace with logic for your custom DFF or tracking field.

UNION ALL

-- 11. Journal Entry Reconciled - This depends on integration with Oracle Account Reconciliation (ARCS).
-- This query assumes reconciliation status is written back to GL_RECONCILIATION_REFERENCES.
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Entry Reconciled' AS "ActivityName",
    grr.last_update_date AS "EventTime",
    grr.last_updated_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_lines gjl ON jh.je_header_id = gjl.je_header_id
JOIN
    gl_reconciliation_references grr ON gjl.je_header_id = grr.je_header_id AND gjl.je_line_num = grr.je_line_num
WHERE
    grr.status = 'R' -- Assuming 'R' means Reconciled. Verify based on your ARCS configuration.
LEFT JOIN
    per_users u ON grr.last_updated_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(grr.last_update_date) BETWEEN papf.effective_start_date AND papf.effective_end_date

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.je_header_id AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.creation_date AS "EventTime",
    rev_jh.created_by AS "UserName",
    papf.person_number AS "UserDepartment",
    jh.journal_category AS "JournalCategory",
    jh.journal_source AS "JournalSource",
    jh.journal_amount AS "JournalAmount",
    NULL AS "RejectionReason",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate"
FROM
    JournalHeaders jh
JOIN
    gl_je_headers rev_jh ON jh.je_header_id = rev_jh.accrual_rev_je_header_id
LEFT JOIN
    per_users u ON rev_jh.created_by = u.username
LEFT JOIN
    per_all_people_f papf ON u.person_id = papf.person_id AND TRUNC(rev_jh.creation_date) BETWEEN papf.effective_start_date AND papf.effective_end_date
WHERE
    jh.accrual_rev_je_header_id IS NOT NULL

Pasos

Vaya a BI Publisher: Inicie sesión en Oracle Fusion Financials. En el menú Navigator, vaya a Tools y seleccione Reports and Analytics. Se abrirá el catálogo de Business Intelligence.
Cree un modelo de datos: En el catálogo de BI, haga clic en Create y seleccione Data Model. Se abrirá el editor del modelo de datos.
Defina el conjunto de datos de la consulta SQL: En el editor, haga clic en el icono más de la pestaña Diagram y seleccione SQL Query. En el cuadro de diálogo, asigne un nombre al conjunto de datos, por ejemplo, ProcessMind_JE_EventLog. Seleccione la fuente de datos adecuada, que suele ser FUSIONDB. Pegue la consulta SQL completa en el área de texto SQL Query.
Defina los parámetros: La consulta usa parámetros para el intervalo de fechas (p_start_date y p_end_date). Oracle BI Publisher los detectará automáticamente. Configúrelos como parámetros de tipo Text y asígneles etiquetas claras, como 'Start Date (YYYY-MM-DD)' y 'End Date (YYYY-MM-DD)'.
Guarde el modelo de datos: Después de pegar la consulta y definir los parámetros, haga clic en OK y guarde el modelo en una carpeta adecuada, por ejemplo, Shared Folders/Custom/ProcessMining.
Cree el informe: Haga clic en el botón Create Report, en la esquina superior derecha del editor del modelo de datos. Se abrirá el asistente de creación del informe.
Configure la disposición del informe: En el asistente, seleccione la opción para usar el modelo de datos actual. Elija la disposición 'Table'. Arrastre todas las columnas de la fuente de datos al área de la tabla. Desmarque la opción 'Show Grand Totals Row'.
Guarde el informe: Guárdelo en la misma carpeta que el modelo de datos. Asígnele un nombre descriptivo, como 'Journal Entry Event Log Report'.
Establezca el formato de salida predeterminado: Edite el informe y vaya a la pestaña 'Viewing'. En 'Output Formats', compruebe que esté seleccionado CSV y, de ser posible, establézcalo como formato predeterminado. Así, el archivo podrá utilizarse directamente.
Ejecute y exporte: Abra el informe e introduzca los parámetros de fecha de inicio y fin cuando se le solicite. Indique el intervalo deseado y haga clic en Apply. Cuando se ejecute el informe, haga clic en Export y seleccione el formato CSV para descargar el Registro de eventos.
Prepare el archivo para cargarlo: Abra el archivo CSV descargado. Compruebe que los encabezados de columna coincidan con los nombres de atributos esperados (JournalEntryId, ActivityName, EventTime, etc.) y que los datos tengan el formato correcto antes de cargarlos en ProcessMind.

Configuración

Requisitos previos: Quien ejecute el informe debe tener un rol con los privilegios de seguridad de datos necesarios para acceder a los datos del libro mayor, como General Accountant o un rol de BI personalizado. También se requiere acceso a BI Publisher.
Fuente de datos: Configure el modelo de datos de BI Publisher para que use la conexión a la base de datos de la aplicación FUSIONDB.
Parámetros del intervalo de fechas: La consulta usa los parámetros p_start_date y p_end_date para controlar el período de extracción. Se recomienda empezar con entre 3 y 6 meses de datos para garantizar el rendimiento.
Filtros del informe: En organizaciones grandes, se recomienda encarecidamente añadir filtros directamente en la cláusula WHERE de la expresión de tabla común JournalHeaders de la consulta. Filtrar por LEDGER_ID o LEGAL_ENTITY_ID es esencial para controlar el volumen de datos.
Consideraciones de rendimiento: Ejecutar esta consulta en una base de datos de producción grande puede consumir muchos recursos. Programe el informe fuera de las horas de mayor actividad para reducir el impacto en el rendimiento del sistema.
Formato de salida: Configure el informe para generar un archivo CSV. Este formato estructurado facilita la ingesta en herramientas de Process Mining.

Consulta de ejemplo sql

WITH JournalHeaders AS (
    SELECT
        gjh.JE_HEADER_ID,
        gjh.NAME AS JOURNAL_NAME,
        gjh.LEDGER_ID,
        gjh.JE_CATEGORY,
        gjh.JE_SOURCE,
        gjh.STATUS,
        gjh.APPROVAL_STATUS_CODE,
        gjh.CREATED_BY,
        gjh.CREATION_DATE,
        gjh.LAST_UPDATED_BY,
        gjh.LAST_UPDATE_DATE,
        gjh.POSTED_DATE,
        gjh.ACCRUAL_REV_JE_HEADER_ID,
        gjh.ACCRUAL_REV_PERIOD_NAME,
        gjs.USER_JE_SOURCE_NAME,
        gjc.USER_JE_CATEGORY_NAME,
        (SELECT SUM(NVL(gjl.ACCOUNTED_DR, 0)) FROM GL_JE_LINES gjl WHERE gjl.JE_HEADER_ID = gjh.JE_HEADER_ID) AS JOURNAL_AMOUNT
    FROM
        GL_JE_HEADERS gjh
    JOIN
        GL_JE_SOURCES_TL gjs ON gjh.JE_SOURCE = gjs.JE_SOURCE_NAME AND gjs.LANGUAGE = USERENV('LANG')
    JOIN
        GL_JE_CATEGORIES_TL gjc ON gjh.JE_CATEGORY = gjc.JE_CATEGORY_NAME AND gjc.LANGUAGE = USERENV('LANG')
    WHERE
        gjh.CREATION_DATE BETWEEN TO_TIMESTAMP(:p_start_date || ' 00:00:00.000', 'YYYY-MM-DD HH24:MI:SS.FF') AND TO_TIMESTAMP(:p_end_date || ' 23:59:59.999', 'YYYY-MM-DD HH24:MI:SS.FF')
        AND gjh.ACTUAL_FLAG = 'A'
        -- Recommended: Add a filter for your specific ledger(s) to improve performance
        -- AND gjh.LEDGER_ID IN ([Your Ledger ID])
),
UserDepartment AS (
    -- This subquery is an example. The join logic to find a user's department may need to be adjusted
    -- based on your specific Oracle HCM configuration (e.g., using different assignment types or tables).
    SELECT 
        pu.USERNAME, 
        org.NAME as Department
    FROM PER_USERS pu
    LEFT JOIN PER_ALL_ASSIGNMENTS_F asg ON pu.PERSON_ID = asg.PERSON_ID 
        AND asg.ASSIGNMENT_TYPE IN ('E', 'C') 
        AND asg.PRIMARY_FLAG = 'Y'
        AND SYSDATE BETWEEN asg.EFFECTIVE_START_DATE AND asg.EFFECTIVE_END_DATE
    LEFT JOIN HR_ALL_ORGANIZATION_UNITS_F_VL org ON asg.ORGANIZATION_ID = org.ORGANIZATION_ID
        AND SYSDATE BETWEEN org.EFFECTIVE_START_DATE AND org.EFFECTIVE_END_DATE
    WHERE pu.USERNAME IS NOT NULL
)
-- 1. Journal Entry Created
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Created' AS "ActivityName",
    jh.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.CREATED_BY = ud.USERNAME

UNION ALL

-- 2. Supporting Documentation Attached
SELECT
    TO_NUMBER(fad.PK1_VALUE) AS "JournalEntryId",
    'Supporting Documentation Attached' AS "ActivityName",
    fad.CREATION_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    fad.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    FND_ATTACHED_DOCUMENTS fad
JOIN
    JournalHeaders jh ON fad.PK1_VALUE = TO_CHAR(jh.JE_HEADER_ID)
LEFT JOIN UserDepartment ud ON fad.CREATED_BY = ud.USERNAME
WHERE
    fad.ENTITY_NAME = 'GL_JE_HEADERS'

UNION ALL

-- 3. Journal Submitted For Approval
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Submitted For Approval' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE IN ('REQUIRED', 'INITIATED')

UNION ALL

-- 4. Journal Entry Reviewed (Placeholder)
-- This activity requires custom logic based on your approval workflow configuration.
-- The query below is a placeholder and may not return any data without customization.
-- It assumes a review happens if the approval status is updated but not yet approved or rejected.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 5. Journal Entry Rejected
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Rejected' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    -- Rejection Reason is not a standard field. This might be found in workflow tables.
    '[Configure based on your system]' AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE = 'REJECTED'

UNION ALL

-- 6. Journal Corrected and Resubmitted
-- This logic assumes a resubmission is an update that occurs after a rejection.
-- A more precise method would involve analyzing workflow history, which is complex.
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Corrected and Resubmitted' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE IN ('REQUIRED', 'INITIATED')
    AND jh.JE_HEADER_ID IN (SELECT h.JE_HEADER_ID FROM GL_JE_HEADERS h WHERE h.APPROVAL_STATUS_CODE = 'REJECTED')

UNION ALL

-- 7. Journal Entry Approved
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Approved' AS "ActivityName",
    jh.LAST_UPDATE_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.APPROVAL_STATUS_CODE = 'APPROVED'

UNION ALL

-- 8. Journal Posting Initiated
-- The exact initiation time is not stored. We infer it as 5 minutes before the final posted date.
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Posting Initiated' AS "ActivityName",
    (jh.POSTED_DATE - INTERVAL '5' MINUTE) AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    -- Posting is often a system process, so user might not be available.
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.STATUS = 'P' AND jh.POSTED_DATE IS NOT NULL

UNION ALL

-- 9. Journal Entry Posted
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Entry Posted' AS "ActivityName",
    jh.POSTED_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    jh.LAST_UPDATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
LEFT JOIN UserDepartment ud ON jh.LAST_UPDATED_BY = ud.USERNAME
WHERE
    jh.STATUS = 'P' AND jh.POSTED_DATE IS NOT NULL

UNION ALL

-- 10. Posting Verified (Placeholder)
-- This is a manual control activity not tracked by default. This query must be customized.
-- It assumes a descriptive flexfield named 'POSTING_VERIFIED_DATE' on GL_JE_HEADERS exists.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 11. Journal Entry Reconciled (Placeholder)
-- Reconciliation is typically done in other modules. This query must be customized.
-- It assumes a custom table or field indicates when a journal is reconciled.
SELECT
    NULL AS "JournalEntryId",
    NULL AS "ActivityName",
    NULL AS "EventTime",
    NULL AS "SourceSystem",
    NULL AS "LastDataUpdate",
    NULL AS "UserName",
    NULL AS "UserDepartment",
    NULL AS "JournalCategory",
    NULL AS "JournalSource",
    NULL AS "JournalAmount",
    NULL AS "RejectionReason"
FROM DUAL WHERE 1=0

UNION ALL

-- 12. Journal Reversal Processed
SELECT
    jh.JE_HEADER_ID AS "JournalEntryId",
    'Journal Reversal Processed' AS "ActivityName",
    rev_jh.POSTED_DATE AS "EventTime",
    'Oracle Fusion Financials' AS "SourceSystem",
    SYSTIMESTAMP AS "LastDataUpdate",
    rev_jh.CREATED_BY AS "UserName",
    ud.Department AS "UserDepartment",
    jh.USER_JE_CATEGORY_NAME AS "JournalCategory",
    jh.USER_JE_SOURCE_NAME AS "JournalSource",
    jh.JOURNAL_AMOUNT AS "JournalAmount",
    NULL AS "RejectionReason"
FROM
    JournalHeaders jh
JOIN
    GL_JE_HEADERS rev_jh ON jh.ACCRUAL_REV_JE_HEADER_ID = rev_jh.JE_HEADER_ID
LEFT JOIN UserDepartment ud ON rev_jh.CREATED_BY = ud.USERNAME
WHERE
    jh.ACCRUAL_REV_JE_HEADER_ID IS NOT NULL
    AND rev_jh.STATUS = 'P'
ORDER BY
    "JournalEntryId", "EventTime"

Pasos

Requisitos previos: Asegúrese de tener Python 3 instalado junto con las bibliotecas requests y pandas. Necesitará una cuenta de usuario de Oracle Fusion Financials con los permisos necesarios para acceder a la API REST de General Ledger Journals. Obtenga la URL de su instancia de Oracle Fusion, así como su nombre de usuario y contraseña.
Configuración del script: Cree un archivo de script de Python. Empiece importando las bibliotecas necesarias: requests, json, pandas y datetime.
Configuración: Defina en el script las variables para las credenciales de Oracle Fusion y la URL base. Establezca también los parámetros de extracción, como las fechas de inicio y fin de la consulta.
Autenticación: El script usa autenticación básica. La biblioteca requests codifica el nombre de usuario y la contraseña en los encabezados de la solicitud.
Defina la función de llamada a la API: Cree una función que gestione las solicitudes a la API. Debe controlar la paginación mediante los parámetros offset y limit. La función realizará llamadas sucesivas hasta recuperar todos los asientos del intervalo de fechas especificado.
Construya la consulta a la API: Use el parámetro q de la solicitud para filtrar los asientos según LastUpdateDate. Así podrá extraer datos de un período concreto, por ejemplo, LastUpdateDate between '2023-01-01' and '2023-03-31'.
Inicie la recuperación de datos: Llame a la función para empezar a recuperar datos del endpoint .../fscmRestApi/resources/11.13.18.05/journals. La función devolverá la lista completa de asientos contables.
Procese y transforme los datos: Recorra cada asiento devuelto por la API. Para cada uno, genere varias filas de eventos correspondientes a las distintas actividades empresariales (Journal Entry Created, Journal Entry Approved, etc.). Use los campos de fecha y los códigos de estado de la respuesta de la API (CreationDate, PostedDate, ApprovalStatus, etc.) para crear estos eventos.
Estructure el Registro de eventos: Guarde cada fila de evento generada como un diccionario dentro de una lista. Esta lista contendrá los datos sin procesar del Registro de eventos.
Cree un DataFrame: Cuando haya procesado todos los asientos, convierta la lista de diccionarios de eventos en un DataFrame de Pandas para facilitar su manipulación.
Prepare las columnas: Seleccione y cambie el nombre de las columnas del DataFrame para que coincidan con el esquema requerido por ProcessMind: JournalEntryId, ActivityName, EventTime, UserName, etc.
Exporte a CSV: Guarde el DataFrame final en un archivo CSV. Después podrá cargarlo directamente en ProcessMind para analizarlo.

Configuración

Credenciales: Se necesitan un nombre de usuario y una contraseña válidos de Oracle Fusion para la autenticación básica.
URL de la instancia: Necesita la URL base de su instancia de Oracle Fusion Financials para construir el endpoint de la API (por ejemplo, https://[your-instance].fa.us2.oraclecloud.com).
Endpoint de la API: El script consulta el endpoint fscmRestApi/resources/11.13.18.05/journals para recuperar datos del libro mayor.
Filtro por intervalo de fechas: Configure el script con start_date y end_date para limitar el alcance de la extracción. Para el análisis inicial, se recomienda un período de entre 3 y 6 meses. Para el uso continuo, configure cargas incrementales diarias o semanales.
Límite de paginación: El parámetro limit determina cuántos registros se recuperan en cada llamada a la API. Un valor de entre 200 y 500 suele ser eficiente, ya que equilibra el número de llamadas con el tamaño de cada respuesta.
Roles de Oracle necesarios: La cuenta de usuario debe tener un rol con los privilegios necesarios para leer datos de asientos mediante la API REST, como General Accountant o un rol personalizado con permisos equivalentes.

Consulta de ejemplo python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Oracle Fusion instance details
FUSION_URL = class="hl-string">"https://[your-instance].fa.us2.oraclecloud.com"
USERNAME = class="hl-string">"[your-username]"
PASSWORD = class="hl-string">"[your-password]"

class=class="hl-string">"hl-comment"># --- Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction (YYYY-MM-DD format)
START_DATE = class="hl-string">"2023-01-01"
END_DATE = class="hl-string">"2023-06-30"
PAGE_LIMIT = 500 class=class="hl-string">"hl-comment"># Number of records per API call

def get_all_journals(base_url, user, password, start_date, end_date):
    class="hl-string">"""Fetches all journals from the Oracle Fusion REST API within a date range, handling pagination."""
    all_journals = []
    offset = 0
    has_more = True
    
    api_url = fclass="hl-string">"{base_url}/fscmRestApi/resources/11.13.18.05/journals"
    
    headers = {
        class="hl-string">'Content-Type': class="hl-string">'application/vnd.oracle.adf.resourcecollection+json'
    }
    
    query_filter = fclass="hl-string">"LastUpdateDate between '{start_date}' and '{end_date}'"
    
    while has_more:
        params = {
            class="hl-string">'q': query_filter,
            class="hl-string">'onlyData': class="hl-string">'true',
            class="hl-string">'limit': PAGE_LIMIT,
            class="hl-string">'offset': offset,
            class="hl-string">'fields': class="hl-string">'JeHeaderId,CreatedBy,CreationDate,LastUpdatedBy,LastUpdateDate,PostedDate,ApprovalStatus,ActualFlag,DefaultEffectiveDate,Description,JeCategory,JeSource,PeriodName,TotalDebit,ReversalDate,ReversalPeriodName,ExternalReference,attachments'
        }
        
        print(fclass="hl-string">"Fetching records from offset {offset}...")
        try:
            response = requests.get(api_url, auth=(user, password), headers=headers, params=params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an HTTPError for bad responses (4xx or 5xx)
            data = response.json()
            
            journals = data.get(class="hl-string">'items', [])
            all_journals.extend(journals)
            
            has_more = data.get(class="hl-string">'hasMore', False)
            offset += PAGE_LIMIT

        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"An error occurred: {e}")
            has_more = False

    return all_journals

def transform_to_event_log(journals):
    class="hl-string">"""Transforms the raw journal data into a structured event log."""
    event_log = []
    extraction_timestamp = datetime.now(timezone.utc).isoformat()

    for jrnl in journals:
        journal_id = jrnl.get(class="hl-string">'JeHeaderId')
        created_by = jrnl.get(class="hl-string">'CreatedBy')
        last_updated_by = jrnl.get(class="hl-string">'LastUpdatedBy')
        approval_status = jrnl.get(class="hl-string">'ApprovalStatus')
        rejection_reason_text = class="hl-string">"Rejected per workflow comments" if approval_status == class="hl-string">'REJECTED' else None

        class=class="hl-string">"hl-comment"># 1. Journal Entry Created
        if jrnl.get(class="hl-string">'CreationDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Entry Created',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'CreationDate'),
                class="hl-string">'UserName': created_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 2. Supporting Documentation Attached (Approximation)
        if jrnl.get(class="hl-string">'attachments') and len(jrnl[class="hl-string">'attachments']) > 0:
             event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Supporting Documentation Attached',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class=class="hl-string">"hl-comment"># Approximation: uses last update date
                class="hl-string">'UserName': last_updated_by, 
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 3, 4, 5, 6, 7: Approval Workflow Events (Inferred from final status)
        class=class="hl-string">"hl-comment"># Note: This block infers events. For a more detailed history, workflow-specific APIs would be needed.
        if approval_status in [class="hl-string">'IN_PROCESS', class="hl-string">'REQUIRED']:
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Submitted For Approval',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        elif approval_status == class="hl-string">'REJECTED':
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Rejected',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by, class=class="hl-string">"hl-comment"># Approver is often the last updater
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': rejection_reason_text,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            class=class="hl-string">"hl-comment"># A resubmission is assumed if a rejected journal is updated again
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Corrected and Resubmitted',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': created_by, class=class="hl-string">"hl-comment"># Typically the creator corrects it
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        elif approval_status == class="hl-string">'APPROVED':
            class=class="hl-string">"hl-comment"># class="hl-string">'Journal Entry Reviewed' is often an implicit part of approval
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Reviewed',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Approved',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'LastUpdateDate'), class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># 8, 9: Posting Events
        if jrnl.get(class="hl-string">'PostedDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Posting Initiated',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'PostedDate'), class=class="hl-string">"hl-comment"># Assuming initiation is same as posted time
                class="hl-string">'UserName': class="hl-string">'System', class=class="hl-string">"hl-comment"># Posting is often a system process
                class="hl-string">'UserDepartment': class="hl-string">'Finance Operations', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id, class="hl-string">'ActivityName': class="hl-string">'Journal Entry Posted',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'PostedDate'),
                class="hl-string">'UserName': class="hl-string">'System',
                class="hl-string">'UserDepartment': class="hl-string">'Finance Operations', class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'), class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'), class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials', class="hl-string">'LastDataUpdate': extraction_timestamp
            })
        
        class=class="hl-string">"hl-comment"># 12. Journal Reversal Processed
        if jrnl.get(class="hl-string">'ReversalDate'):
            event_log.append({
                class="hl-string">'JournalEntryId': journal_id,
                class="hl-string">'ActivityName': class="hl-string">'Journal Reversal Processed',
                class="hl-string">'EventTime': jrnl.get(class="hl-string">'ReversalDate'),
                class="hl-string">'UserName': last_updated_by,
                class="hl-string">'UserDepartment': class="hl-string">'[Configure based on your system]',
                class="hl-string">'JournalCategory': jrnl.get(class="hl-string">'JeCategory'),
                class="hl-string">'JournalSource': jrnl.get(class="hl-string">'JeSource'),
                class="hl-string">'JournalAmount': jrnl.get(class="hl-string">'TotalDebit'),
                class="hl-string">'RejectionReason': None,
                class="hl-string">'SourceSystem': class="hl-string">'Oracle Fusion Financials',
                class="hl-string">'LastDataUpdate': extraction_timestamp
            })

        class=class="hl-string">"hl-comment"># Activities not directly available from this API, added as placeholders for potential enrichment
        class=class="hl-string">"hl-comment"># Posting Verified, Journal Entry Reconciled

    return pd.DataFrame(event_log)

class=class="hl-string">"hl-comment"># --- Main Execution ---
if __name__ == class="hl-string">"__main__":
    print(class="hl-string">"Starting Oracle Fusion Journal Entry extraction...")
    raw_journals = get_all_journals(FUSION_URL, USERNAME, PASSWORD, START_DATE, END_DATE)
    
    if raw_journals:
        print(fclass="hl-string">"Successfully extracted {len(raw_journals)} journal records.")
        event_log_df = transform_to_event_log(raw_journals)
        
        if not event_log_df.empty:
            class=class="hl-string">"hl-comment"># Save to CSV
            output_filename = fclass="hl-string">"oracle_fusion_journal_events_{START_DATE}_to_{END_DATE}.csv"
            event_log_df.to_csv(output_filename, index=False)
            print(fclass="hl-string">"Event log saved to {output_filename}")
        else:
            print(class="hl-string">"No events were generated from the extracted data.")
    else:
        print(class="hl-string">"No data extracted. Please check configuration and API availability.")

Pasos

Confirme que BI Cloud Connector, las áreas temáticas de General Ledger o los Public View Objects necesarios de Oracle Fusion Financials y las autorizaciones requeridas para el sistema de origen estén disponibles en su entorno. Consulte con su administrador de Oracle cuál es el destino de entrega de BICC configurado y cuáles son sus credenciales de acceso.
En la consola de BI Cloud Connector, identifique los Public View Objects que contienen encabezados y líneas de asientos, historial de aprobaciones, archivos adjuntos, estado de contabilización, estado de conciliación e información de reversión. Anote los nombres exactos de los objetos y atributos configurados en su entorno. Sustituya los marcadores del script de extracción por esos nombres antes de ejecutarlo.
Configure una tarea de BICC para los Public View Objects seleccionados de General Ledger. Use una extracción incremental cuando haya un atributo fiable de última actualización. Para la carga inicial, use un período controlado de tres a seis meses u otro intervalo contable aprobado.
Configure BICC para entregar los archivos extraídos en la ubicación de almacenamiento en la nube designada. Confirme el formato del archivo, el delimitador, la codificación de caracteres, la compresión, la partición, la convención de nombres y la programación de entrega. Conserve la marca de agua de extracción o la fecha y hora de la última extracción correcta.
Recupere los archivos entregados en el área de preparación aprobada. Cargue cada archivo de origen en la tabla o vista de preparación correspondiente. Use las asignaciones exactas de objetos y atributos de origen documentadas para su entorno. No dé por sentado que un Public View Object tiene la misma estructura que una tabla de base de datos subyacente.
Normalice las marcas de tiempo a una sola zona horaria y convierta las marcas de tiempo de origen a un tipo de datos uniforme. Conserve la marca de tiempo de actualización de origen como LastDataUpdate. Convierta los identificadores de origen y los atributos de actividad a los nombres de salida que utiliza ProcessMind.
Ejecute la consulta siguiente después de sustituir cada marcador profesional por el nombre real del objeto y del atributo de preparación. La consulta crea explícitamente una fila del Registro de eventos para cada una de las 12 actividades requeridas. No infiere actividades que no estén presentes en los datos de origen.
Valide que JournalEntryId, ActivityName, EventTime, SourceSystem y LastDataUpdate estén presentes en cada fila de salida. Revise los eventos duplicados, el orden de las marcas de tiempo, los asientos rechazados y reenviados, las relaciones de reversión y los registros a los que les falten atributos opcionales.
Exporte el resultado como archivo delimitado o en otro formato compatible con ProcessMind. Incluya los nombres de columna exactos JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount y RejectionReason. Cargue el archivo con JournalEntryId configurado como identificador del caso, ActivityName como actividad y EventTime como marca de tiempo del evento.

Configuración

Configure BICC con los Public View Objects de General Ledger necesarios para los encabezados y las líneas de asientos, el historial de aprobaciones o del flujo de trabajo, los archivos adjuntos y los datos de contabilización, conciliación y reversión. Confirme los nombres exactos de los objetos y atributos en el catálogo de BICC de su entorno.
Use un período inicial de extracción de tres a seis meses. Amplíelo solo después de validar el volumen, la capacidad de almacenamiento, la duración de la extracción y el tiempo de procesamiento posterior.
Aplique los filtros aprobados para la fecha contable o la fecha de última actualización, el libro mayor, la entidad jurídica, la unidad de negocio, el código de empresa cuando esté disponible, la categoría y el origen del asiento, el tipo de documento cuando esté disponible y el estado del asiento. Use únicamente los filtros compatibles con los Public View Objects seleccionados.
Configure la extracción incremental con el atributo de última actualización del origen y una marca de agua persistente. Cuando sea necesario, incluya un pequeño intervalo de solapamiento para contemplar las actualizaciones que llegan tarde y, después, elimine los duplicados por JournalEntryId, ActivityName, EventTime y el identificador de evento de origen correspondiente.
Asegúrese de que todos los objetos de origen usen claves de extracción y calendarios de actualización compatibles. Los datos de aprobaciones, archivos adjuntos, contabilización, conciliación y reversión pueden actualizarse en momentos distintos.
Para conjuntos de datos grandes, particione por período contable, libro mayor, entidad jurídica u otro atributo de partición compatible con BICC. Evite las extracciones históricas sin restricciones durante el horario laboral.
Conserve las marcas de tiempo de origen y las marcas de tiempo de actualización de origen antes de transformarlas. Documente la zona horaria utilizada para EventTime y LastDataUpdate.
Los requisitos previos incluyen acceso a la consola de BI Cloud Connector, autorización para configurar y ejecutar las extracciones seleccionadas, acceso al destino de almacenamiento en la nube configurado, acceso al entorno de preparación y autorización para consultar los datos necesarios de General Ledger y del flujo de trabajo.
Confirme que los módulos de Oracle Fusion Financials, la configuración del flujo de trabajo, el almacenamiento de archivos adjuntos, los procesos de contabilización y las fuentes de datos de conciliación necesarios estén habilitados para las actividades previstas.
No interprete la ausencia de un registro de origen como prueba de que una actividad no ocurrió. Los datos de BICC dependen de los Public View Objects seleccionados, los filtros, los tiempos de actualización, la retención y el historial disponible.

Consulta de ejemplo sql

WITH
journal_created AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Created' AS ActivityName,
        CAST([Journal Created Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Created By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Created By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal header staging object]
    WHERE [Journal Created Timestamp attribute] IS NOT NULL
),
supporting_documentation_attached AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Supporting Documentation Attached' AS ActivityName,
        CAST([Attachment Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Attachment User attribute] AS VARCHAR(255)) AS UserName,
        CAST([Attachment User Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal attachment staging object]
    WHERE [Attachment Timestamp attribute] IS NOT NULL
),
journal_submitted_for_approval AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Submitted For Approval' AS ActivityName,
        CAST([Submission Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Submitter attribute] AS VARCHAR(255)) AS UserName,
        CAST([Submitter Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal approval staging object]
    WHERE [Submission Timestamp attribute] IS NOT NULL
),
journal_entry_reviewed AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Reviewed' AS ActivityName,
        CAST([Review Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reviewer attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reviewer Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal review staging object]
    WHERE [Review Timestamp attribute] IS NOT NULL
),
journal_entry_rejected AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Rejected' AS ActivityName,
        CAST([Rejection Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Rejector attribute] AS VARCHAR(255)) AS UserName,
        CAST([Rejector Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST([Rejection Reason attribute] AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal rejection staging object]
    WHERE [Rejection Timestamp attribute] IS NOT NULL
),
journal_corrected_and_resubmitted AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Corrected and Resubmitted' AS ActivityName,
        CAST([Correction Resubmission Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Resubmitter attribute] AS VARCHAR(255)) AS UserName,
        CAST([Resubmitter Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST([Rejection Reason attribute] AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal resubmission staging object]
    WHERE [Correction Resubmission Timestamp attribute] IS NOT NULL
),
journal_entry_approved AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Approved' AS ActivityName,
        CAST([Approval Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Approver attribute] AS VARCHAR(255)) AS UserName,
        CAST([Approver Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal approval staging object]
    WHERE [Approval Timestamp attribute] IS NOT NULL
),
journal_posting_initiated AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Posting Initiated' AS ActivityName,
        CAST([Posting Initiated Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Posting Initiated By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Posting Initiated By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal posting staging object]
    WHERE [Posting Initiated Timestamp attribute] IS NOT NULL
),
journal_entry_posted AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Posted' AS ActivityName,
        CAST([Posted Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Posted By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Posted By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal posting staging object]
    WHERE [Posted Timestamp attribute] IS NOT NULL
),
posting_verified AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Posting Verified' AS ActivityName,
        CAST([Posting Verification Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Verifier attribute] AS VARCHAR(255)) AS UserName,
        CAST([Verifier Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Posting verification staging object]
    WHERE [Posting Verification Timestamp attribute] IS NOT NULL
),
journal_entry_reconciled AS (
    SELECT
        CAST([Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Entry Reconciled' AS ActivityName,
        CAST([Reconciliation Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reconciled By attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reconciled By Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Journal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal reconciliation staging object]
    WHERE [Reconciliation Timestamp attribute] IS NOT NULL
),
journal_reversal_processed AS (
    SELECT
        CAST([Original Journal Entry ID attribute] AS VARCHAR(255)) AS JournalEntryId,
        'Journal Reversal Processed' AS ActivityName,
        CAST([Reversal Posted Timestamp attribute] AS TIMESTAMP) AS EventTime,
        CAST([Source System attribute] AS VARCHAR(255)) AS SourceSystem,
        CAST([Last Update Timestamp attribute] AS TIMESTAMP) AS LastDataUpdate,
        CAST([Reversal User attribute] AS VARCHAR(255)) AS UserName,
        CAST([Reversal User Department attribute] AS VARCHAR(255)) AS UserDepartment,
        CAST([Journal Category attribute] AS VARCHAR(255)) AS JournalCategory,
        CAST([Journal Source attribute] AS VARCHAR(255)) AS JournalSource,
        CAST([Reversal Amount attribute] AS DECIMAL(38, 10)) AS JournalAmount,
        CAST(NULL AS VARCHAR(4000)) AS RejectionReason
    FROM [Journal reversal staging object]
    WHERE [Reversal Posted Timestamp attribute] IS NOT NULL
)
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_created
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM supporting_documentation_attached
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_submitted_for_approval
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_reviewed
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_rejected
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_corrected_and_resubmitted
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_approved
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_posting_initiated
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_posted
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM posting_verified
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_entry_reconciled
UNION ALL
SELECT JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, UserDepartment, JournalCategory, JournalSource, JournalAmount, RejectionReason FROM journal_reversal_processed
ORDER BY JournalEntryId, EventTime, ActivityName;

¿Listo para empezar?

Use este Template para convertir los datos de asientos contables de Oracle Fusion en información útil para la acción y acelerar el ciclo de Registro a informe. Empiece hoy a optimizar sus operaciones financieras.

Volver a la guía de mejora

Descargar Template

Acelere hoy el proceso de Registro a informe: asiento contable

Reduzca un 30 % el tiempo de ciclo de los asientos contables y agilice las operaciones financieras.

Comience la prueba gratuita

No se requiere tarjeta de crédito. Active su prueba ahora.

Su Template de datos de Registro a informe: asiento contable

Su Template de datos de Registro a informe: asiento contable

Atributos de Registro a informe: asiento contable

Actividades de Registro a informe: asiento contable

Guías de extracción

Exportación de informes de Oracle OTBI y BI Publisher

Pasos

Configuración

Consulta de ejemplo sql

Informe de BI Publisher con consulta SQL directa en el modelo de datos

Pasos

Configuración

Consulta de ejemplo sql

Script de Python con la API REST de Oracle Fusion Financials

Pasos

Configuración

Consulta de ejemplo python

Extracción masiva de datos con BI Cloud Connector (BICC)

Pasos

Configuración

Consulta de ejemplo sql

¿Listo para empezar?

Acelere hoy el proceso de Registro a informe: asiento contable