> Mejora continua de procesos > Del registro al informe: asiento contable > Oracle Fusion Financials > Template de datos

Su Template de datos de Record to Report - Journal Entry

Oracle Fusion Financials

← Volver a la guía de mejora

Del registro al informe: atributos del asiento contable (21) Del registro al informe: actividades del asiento contable (12) Guías de extracción (4)

Su Template de datos de Record to Report - Journal Entry

Este Template de datos ofrece una guía completa para extraer y estructurar los datos de Journal Entry de Oracle Fusion Financials. Describe los atributos esenciales que debe recopilar y las actividades clave que debe supervisar para garantizar que capture toda la información necesaria para un análisis sólido del proceso. También encontrará instrucciones prácticas para extraer estos datos directamente de su sistema.

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

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

Descargar Template

Del registro al informe: atributos del asiento contable

Estos son los campos de datos recomendados para incluir en su registro de eventos y realizar un análisis completo de su proceso de registro al informe de asientos contables.

5 Obligatorio 6 Recomendado 10 Opcional

	Nombre	Descripción
	Actividad ActivityName	El nombre del evento empresarial o la tarea específicos que tuvieron lugar en un momento determinado del proceso de asientos contables.
Descripción El nombre de la actividad describe un único paso del ciclo de vida del asiento contable, como 'Asiento contable creado' o 'Asiento contable aprobado'. 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 estándar, las desviaciones y los ciclos de retrabajo. Al realizar un seguimiento de las distintas actividades, podemos medir el tiempo dedicado a etapas específicas, como la aprobación, e identificar qué pasos requieren más tiempo o son más propensos a errores. Por qué es importante Define los pasos del proceso, forma la estructura básica del mapa de procesos 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 pistas de auditoría asociadas a objetos de asientos contables del módulo de libro mayor. Ejemplos Asiento contable creadoAsiento contable enviado para aprobaciónAsiento contable aprobadoAsiento contable contabilizado
	Hora de inicio EventTime	La marca de tiempo que indica cuándo se produjo una actividad o evento específico.
Descripción Esta marca de tiempo indica la fecha y hora exactas en que se ejecutó una actividad. Es el elemento temporal principal que se utiliza en process mining para determinar la secuencia de eventos y calcular las duraciones entre ellos. La precisión de la hora del evento es fundamental para todos los análisis basados en el tiempo, incluido el cálculo de tiempos de ciclo, la identificación de cuellos de botella y la supervisión del rendimiento frente a los acuerdos de nivel de servicio. Proporciona el orden cronológico necesario para reconstruir el flujo del proceso tal como ocurrió. 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 basado en el tiempo. Dónde obtenerlo Esta información suele almacenarse en tablas de pistas de auditoría o como 'Last Update Date' o 'Creation Date' en 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	El identificador único de un asiento contable individual, que vincula todas las actividades de transacción financiera relacionadas.
Descripción El Journal Entry ID actúa como identificador principal del caso y vincula de forma única todas las actividades relacionadas con un conjunto específico de transacciones financieras. Esto permite realizar un seguimiento del ciclo de vida completo de un único asiento contable, desde su inicio hasta su contabilización final, garantizando que todos los débitos y créditos queden registrados. En process mining, este ID es esencial para reconstruir el recorrido integral de cada asiento contable. Conecta eventos independientes como 'Asiento contable creado', 'Asiento contable enviado para aprobación' y 'Asiento contable contabilizado' en un flujo de proceso coherente, lo que permite analizar tiempos de ciclo, cuellos de botella y variaciones del proceso. Por qué es importante Es la clave fundamental para realizar el seguimiento de un asiento contable de principio a fin y analizar el flujo completo del proceso de cada caso único. Dónde obtenerlo Es una clave principal que se encuentra en tablas esenciales del libro mayor, como GL_JE_HEADERS y GL_JE_LINES. Ejemplos JE100523JE202311001882019
	Sistema de origen SourceSystem	El 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, y este campo ayuda a diferenciarlos. En el análisis de procesos, conocer el sistema de origen es fundamental para comprender las variaciones del proceso que pueden deberse al comportamiento de distintos sistemas. También ayuda a validar los datos y resolver problemas al rastrearlos hasta su origen. Por qué es importante Identifica el origen de los datos, algo fundamental para la gobernanza y validación de datos y para comprender 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 introdujo el dato. Ejemplos Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Última actualización de datos LastDataUpdate	La 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 actualizó por última vez el conjunto de datos. Proporciona contexto sobre la actualidad de los datos analizados, un aspecto importante para comprender la relevancia de las conclusiones obtenidas. En cualquier análisis, especialmente en los Dashboards operativos, conocer la hora de Last Data Update es fundamental para que los usuarios confíen en los datos y tomen decisiones fundamentadas. Comunica claramente el punto de corte de los datos incluidos en el modelo de Process Mining. Por qué es importante Indica la actualidad de los datos, para que los usuarios comprendan 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 el proceso de extracción y transformación de datos. Normalmente corresponde a la marca de tiempo en la que finalizó el trabajo ETL/ELT. Ejemplos 2023-11-20T08:00:00Z2023-11-21T08:00:00Z2023-11-22T08:00:00Z
	Categoría del asiento JournalCategory	La categoría del asiento contable, como 'Periodificación', 'Ajuste' o 'Reclasificación'.
Descripción La categoría del asiento clasifica los asientos según su finalidad empresarial. Esta clasificación permite analizar el proceso con mayor detalle, ya que las distintas categorías pueden tener flujos de proceso, reglas de aprobación o tiempos de ciclo diferentes. Por ejemplo, los asientos de ajuste de cierre mensual pueden seguir un proceso más complejo y urgente que las periodificaciones habituales. Analizar el proceso por categoría ayuda a descubrir estas variaciones y adaptar las mejoras a tipos específicos de asientos contables. Por qué es importante Permite segmentar el proceso según la finalidad empresarial del asiento y revela comportamientos y rendimientos diferentes para cada tipo de asiento. Dónde obtenerlo Está disponible en la tabla GL_JE_HEADERS, normalmente en un campo denominado JE_CATEGORY. Ejemplos DevengoManualAjusteRevaluación
	Departamento del usuario UserDepartment	El 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'. Normalmente se obtiene 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. Es valioso para asignar recursos y orientar iniciativas de mejora del proceso. Por qué es importante Aporta contexto organizativo, permite analizar el rendimiento por equipo o departamento y pone de relieve las ineficiencias interfuncionales. Dónde obtenerlo Normalmente no se encuentra en las tablas de transacciones. Debe obtenerse uniendo 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 JournalAmount	El valor monetario total del asiento contable, normalmente la suma de los débitos.
Descripción Este atributo representa el valor financiero total de la operació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 permite segmentar los casos según su impacto financiero. Ayuda a responder preguntas como «¿Los asientos de importe elevado tardan más en aprobarse?» o «¿Son más frecuentes los rechazos de asientos que superan un determinado umbral?». Esto aporta un contexto empresarial esencial al flujo del proceso. Por qué es importante Aporta un contexto empresarial esencial, ya que permite analizar el impacto financiero y determinar si los asientos de importe elevado siguen un proceso diferente. 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	Una descripción textual o un 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 del rechazo. Puede tratarse de un código predefinido o de un comentario de texto libre del aprobador. 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 identificar áreas de mejora, como una mejor capacitación para quienes preparan los asientos, directrices más claras o mejoras en los controles del sistema. Además, respalda 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 las tasas de rechazo. Dónde obtenerlo Esta información puede almacenarse en tablas de Workflow 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 JournalSource	El sublibro 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 a partir de submódulos como Cuentas por pagar, Cuentas por cobrar o Activos fijos. El origen del asiento es un atributo clave para analizar la automatización. Ayuda a diferenciar entre asientos manuales y generados por el sistema, y respalda el KPI «Tasa de asientos contables automatizados». Los procesos de los asientos procedentes de distintas fuentes suelen variar considerablemente en complejidad y eficiencia. Por qué es importante Distingue entre asientos manuales y automatizados, algo fundamental para medir las tasas de automatización y analizar las diferencias entre procesos. Dónde obtenerlo Disponible en la tabla GL_JE_HEADERS, normalmente en un campo denominado JE_SOURCE. Ejemplos ManualCuentas por pagarActivosCuentas por cobrar
	Usuario UserName	El usuario que realizó la actividad, como crear, aprobar o contabilizar el asiento contable.
Descripción Este atributo identifica al empleado concreto 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 identificar cuellos de botella individuales. En el análisis, UserName permite filtrar los procesos por usuario, comparar la eficiencia de los usuarios e investigar las causas de retrasos o errores. Respalda directamente Dashboards como «Carga de trabajo y eficiencia de los usuarios entre equipos» y KPI como el «Índice de cuellos de botella de asientos por usuario». Por qué es importante Atribuye la responsabilidad de los pasos del proceso y permite analizar la carga de trabajo de los usuarios, el rendimiento individual y las necesidades de formación. Dónde obtenerlo Se encuentra en tablas de transacciones como GL_JE_HEADERS, por ejemplo, CREATED_BY y LAST_UPDATED_BY, y en tablas relacionadas de pistas de auditoría. Ejemplos john.doesusan.smithautoprocess_user
	¿Contabilización puntual? IsOnTimePosting	Un indicador calculado cuyo valor es verdadero si el asiento se contabilizó en la fecha objetivo o antes.
Descripción Este atributo booleano se obtiene comparando la marca de tiempo de la actividad «Asiento contable contabilizado» con la «Fecha objetivo de contabilización». Si la contabilización se produce en la fecha objetivo o antes, el valor es «true»; de lo contrario, es «false». Este atributo respalda directamente el KPI «Tasa de contabilización puntual de asientos contables» al simplificar su cálculo. Permite filtrar y analizar fácilmente los asientos atrasados para identificar las causas habituales de las demoras, como determinadas categorías de asientos o aprobadores. Por qué es importante Proporciona un resultado binario claro sobre el rendimiento 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 La herramienta de Process Mining calcula este atributo. Requiere el atributo «TargetPostingDate» y la marca de tiempo de la actividad «Asiento contable contabilizado». Ejemplos truefalse
	¿Es retrabajo? IsRework	Un indicador calculado cuyo valor es verdadero si el asiento contable ha pasado 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 «true» para cualquier actividad posterior a un evento «Asiento contable rechazado», como «Asiento contable corregido y reenviado». ¿Es retrabajo? es un atributo muy útil para el análisis, ya que permite cuantificar fácilmente el volumen y el impacto de los ciclos de retrabajo. Respalda directamente el KPI «Tasa media de retrabajo de asientos contables» y ayuda a comparar el flujo y la duración de los casos retrabajados con los de aquellos que se procesan correctamente desde el primer intento. Por qué es importante Marca directamente los casos que han pasado por ciclos de retrabajo ineficientes, lo que facilita cuantificar la frecuencia y el impacto de los fallos del proceso. Dónde obtenerlo No está disponible en el sistema de origen. La herramienta de Process Mining lo calcula mediante el análisis de la secuencia de actividades de cada caso. Ejemplos truefalse
	Estado de contabilización PostingStatus	El 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. Es un indicador clave de la etapa del ciclo de vida en la que se encuentra el asiento, especialmente en los casos en curso. El estado de contabilización es fundamental para el Dashboard «Seguimiento en tiempo real del estado de los asientos contables», ya que proporciona una vista instantánea de todos los asientos activos. Ayuda a supervisar los atrasos de asientos sin contabilizar e identificar demoras en las etapas finales 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 Disponible en la tabla GL_JE_HEADERS, normalmente en una columna como STATUS o POSTING_STATUS. Ejemplos ContabilizadoSin contabilizarError
	Fecha objetivo de contabilización TargetPostingDate	La fecha predeterminada en la que se espera que se contabilice el asiento contable.
Descripción La fecha objetivo de contabilización representa el plazo para contabilizar un asiento en el libro mayor, que suele determinarse mediante acuerdos de nivel de servicio (SLA) o calendarios de cierre mensual. Sirve como referencia para medir el rendimiento. Este atributo es esencial para calcular el KPI «Tasa de contabilización puntual de asientos contables». Al comparar la fecha real de contabilización con esta fecha objetivo, el sistema puede marcar automáticamente los asientos como puntuales o atrasados, proporcionando una medida clara del cumplimiento de los plazos del proceso. Por qué es importante Define el acuerdo de nivel de servicio o el plazo de contabilización y permite calcular los KPI de rendimiento puntual. 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	La marca de tiempo que indica cuándo se completó una actividad específica.
Descripción La hora de finalización marca la conclusión de una actividad. Mientras que la hora de inicio registra el comienzo, la hora de finalización proporciona el punto de cierre, lo que permite calcular con precisión el tiempo de procesamiento de ese paso concreto. Esto 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 'Asiento contable revisado' muestra 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 actividades individuales, un dato clave para identificar problemas de eficiencia. Dónde obtenerlo Al igual que la hora de inicio, suele encontrarse en tablas de pistas de auditoría o puede inferirse a partir de la hora de inicio de la actividad posterior del proceso. Ejemplos 2023-10-26T10:15:00Z2023-11-15T14:55:10Z2024-01-05T09:22:00Z
	Indicador de reversión ReversalIndicator	Un 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 fundamental para respaldar el Dashboard «Rendimiento del proceso de reversión de asientos contables». Permite aislar los procesos de reversión para medir su frecuencia, sus causas y sus tiempos de ciclo, y ayuda a identificar los problemas subyacentes de los asientos originales que hacen necesaria la reversión. Por qué es importante Ayuda a aislar y analizar el proceso de reversión, que a menudo indica errores o problemas en la operació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 está revirtiendo. Ejemplos truefalse
	Moneda CurrencyCode	El código de moneda del importe del asiento contable, como USD, EUR o GBP.
Descripción El código de moneda especifica la divisa de los importes financieros del asiento contable. Es esencial para las organizaciones multinacionales que operan con varias monedas. Este atributo garantiza que los valores financieros se interpreten correctamente. Permite filtrar por moneda y es necesario para cualquier análisis que implique comparar o agregar 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 Disponible en la tabla GL_JE_HEADERS, normalmente en un campo denominado CURRENCY_CODE. Ejemplos USDEURGBPJPY
	Nombre del libro mayor LedgerName	El nombre del libro mayor en el que se registra el asiento contable.
Descripción El nombre del libro mayor identifica el libro específico al que pertenece el asiento contable. En las organizaciones con varias entidades legales o requisitos de información financiera, puede haber varios libros mayores, como un libro principal para la contabilidad corporativa y libros secundarios para la presentación de información financiera conforme a la normativa local. Este atributo es esencial para filtrar y comparar procesos entre distintas entidades legales o unidades de negocio. Garantiza que los análisis se realicen en el contexto organizativo correcto, algo especialmente importante para el cumplimiento y la presentación de información financiera. Por qué es importante Permite filtrar y comparar el análisis de procesos entre distintas entidades legales o estructuras contables, algo fundamental para las grandes organizaciones. Dónde obtenerlo Se encuentra en la tabla GL_JE_HEADERS, normalmente vinculado mediante un LEDGER_ID que puede combinarse 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	El período fiscal en el que se contabiliza el asiento contable, como «Ene-24».
Descripción El período contable especifica el período financiero en el que se reconoce la operación. Es fundamental para todos los análisis y la presentación de información financiera. En Process Mining, este atributo es esencial para analizar tendencias. Permite comparar el rendimiento del proceso, como 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 mensual, y a medir el impacto de las mejoras del proceso a lo largo del tiempo. Por qué es importante Permite analizar la evolución de los KPI a lo largo del tiempo, medir la mejora del proceso e identificar patrones estacionales, como la presión del cierre mensual. Dónde obtenerlo Disponible en la tabla GL_JE_HEADERS, normalmente en un campo denominado PERIOD_NAME. Ejemplos Ene-24Feb-24Mar-24
	Tiempo de ciclo de extremo a extremo EndToEndCycleTime	La duración total calculada desde la creación de un asiento contable hasta su conciliación final.
Descripción Esta métrica representa el tiempo total que un asiento contable permanece en todo el proceso, desde el primer evento «Asiento contable creado» hasta el evento final «Asiento contable conciliado». Proporciona 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 proporciona una referencia con la que se pueden medir todos los cambios del proceso. Por qué es importante Proporciona una medida general de la salud y la eficiencia de todo el proceso, por lo que es una métrica clave para los informes dirigidos a la dirección. Dónde obtenerlo La plataforma de Process Mining calcula esta métrica como la diferencia de tiempo entre las marcas de tiempo del primer y el último evento de cada caso. Ejemplos P10DT5HP4DT12HP22D

Obligatorio Recomendado Opcional

Del registro al informe: actividades del asiento contable

Estos son los pasos clave y los hitos del proceso que debe capturar en su registro de eventos para descubrir el proceso de asientos contables con precisión.

5 Recomendado 7 Opcional

	Actividad	Descripción
	Asiento contable aprobado	La persona aprobadora designada ha aprobado formalmente el asiento contable, confirmando su precisión y validez. Este es el paso final del Workflow de aprobación y permite proceder a la contabilización.
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 Workflow 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, donde APPROVAL_STATUS_CODE se actualiza a 'APPROVED'. Las tablas del Workflow contienen la identidad de la persona aprobadora y la marca de tiempo. Recopilar Registre la marca de tiempo en la que APPROVAL_STATUS_CODE de GL_JE_HEADERS cambia a 'APPROVED'. Tipo de evento inferred
	Asiento contable conciliado	El asiento contable se ha cotejado y compensado durante un proceso de conciliación de cuentas al cierre del periodo. 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 transcurrido 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 capturarse en Oracle Financial Consolidation and Close Cloud Service (FCCS) o Account Reconciliation Cloud Service (ARCS), no en el propio libro mayor. Se infiere a partir de un cambio de estado en el registro de conciliación vinculado al asiento. Recopilar Correlacione los datos del asiento con las actualizaciones del estado de conciliación de 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 crítico que representa la entrada del asiento en el registro financiero oficial. Es esencial para medir la tasa de contabilización puntual y el tiempo total desde la creación hasta la contabilización. Dónde obtenerlo Se infiere a partir de un cambio de estado en la tabla GL_JE_HEADERS, donde el campo STATUS cambia a 'P' (Posted). La tabla GL_JE_BATCHES también contiene un estado de contabilización. Recopilar Registre la marca de tiempo en la que STATUS de GL_JE_HEADERS cambia a 'P'. Tipo de evento inferred
	Asiento contable creado	Esta actividad marca el inicio del proceso de asientos contables. Representa el momento en que un usuario crea una nueva cabecera de asiento y comienza 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 posteriores ayuda a medir la eficiencia de la introducción inicial de datos y el tiempo total del ciclo del proceso. Dónde obtenerlo Este evento suele inferirse a partir de la marca de tiempo de la fecha de creación en la tabla GL_JE_HEADERS para un Journal Entry ID específico. Esta tabla también contiene el usuario que creó el registro. Recopilar 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 Workflow de aprobación. El asiento pasa de un estado de borrador o incompleto a un estado pendiente de aprobación.
Por qué es importante Este es un hito crítico que inicia el cómputo de los tiempos del ciclo de aprobación y permite identificar cuellos de botella. Separa la fase de introducción de datos de la fase 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. Recopilar Registre la marca de tiempo en la que APPROVAL_STATUS_CODE de GL_JE_HEADERS cambia para indicar el envío. Tipo de evento inferred
	Asiento contable rechazado	Una persona aprobadora ha revisado el asiento contable y lo ha rechazado por errores, falta de documentación o incumplimiento de políticas. Esta acción devuelve el asiento a su creador 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 corrección al primer intento. Una frecuencia elevada de rechazos apunta a problemas de calidad de datos o 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 Workflow registra el usuario y la marca de tiempo de esta acción. Recopilar Registre la marca de tiempo en la que APPROVAL_STATUS_CODE de GL_JE_HEADERS se establece en 'REJECTED'. Tipo de evento inferred
	Asiento contable revisado	Un paso de revisión que puede producirse antes o como parte del proceso formal de aprobación. Representa una comprobación realizada por un colega o responsable para garantizar la precisión y el cumplimiento antes de pasar a la persona aprobadora final.
Por qué es importante Aislar esta actividad ayuda a diferenciar los tiempos de revisión preliminar de los tiempos de aprobación final. Puede revelar cuellos de botella ocultos si la fase de revisión es informal, pero requiere mucho tiempo. Dónde obtenerlo Puede ser un paso explícito de un Workflow de aprobación de varias etapas, registrado en tablas del historial del Workflow. Si la revisión es informal, no se captura. Puede inferirse si se registra una acción de un usuario específico antes de la decisión de aprobación final. Recopilar Analice las tablas del historial del Workflow para identificar pasos intermedios de aprobación o revisión antes del estado final 'Approved'. Tipo de evento inferred
	Asiento corregido y enviado de nuevo	Después de rechazar un asiento contable, su creador realiza las correcciones necesarias y lo vuelve a enviar para su aprobación. Esta actividad representa 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 la ineficiencia del proceso. Esta actividad, combinada con 'Asiento contable rechazado', permite medir el tiempo y la frecuencia del retrabajo. Dónde obtenerlo Este es un evento posterior de 'Asiento contable enviado para aprobación' correspondiente a un asiento que anteriormente se encontraba en estado 'REJECTED'. Se identifica analizando la secuencia de cambios de estado de un único Journal Entry ID. Recopilar Identifique una marca de tiempo de envío que se produzca después de un evento de rechazo para el mismo ID de caso. Tipo de evento inferred
	Contabilización del asiento iniciada	Ha comenzado el proceso de contabilización del asiento aprobado en el libro mayor. Puede ser un paso automatizado o manual que pone el asiento en cola para que el programa de contabilización lo procese.
Por qué es importante Esta actividad separa la aprobación del proceso técnico de contabilización. Los retrasos 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 Puede inferirse a partir de cambios de estado en la tabla GL_JE_BATCHES o de la hora de envío de la solicitud simultánea de contabilización asociada al lote de asientos. Recopilar Identifique la hora de envío de la solicitud del programa de contabilización del libro mayor para el lote de asientos específico. Tipo de evento inferred
	Contabilización verificada	Un paso de verificación posterior a la contabilización en el que un usuario o sistema confirma que el asiento se contabilizó correctamente y que los saldos son los esperados. A menudo es un control manual.
Por qué es importante Analizar esta actividad ayuda a comprender el tiempo dedicado a los controles manuales y al aseguramiento de la calidad después de la contabilización. Puede poner de manifiesto oportunidades para automatizar los procesos de verificación. Dónde obtenerlo Es poco probable que sea un evento explícito en Oracle Fusion. Tendría que inferirse a partir de otras acciones, como la ejecución de un informe específico por parte de un usuario o la actualización de un campo de estado personalizado, que no es estándar. Recopilar Requiere lógica personalizada, como el seguimiento de la hora de ejecución de los informes de verificación o de las actualizaciones de un 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 realiza para proporcionar contexto y evidencias a auditores y personas aprobadoras.
Por qué es importante El seguimiento de esta actividad ayuda a determinar si los retrasos se deben a documentación faltante. También proporciona información sobre el cumplimiento y la integridad de los asientos contables antes de que entren en el Workflow de aprobación. Dónde obtenerlo Puede resultar difícil realizar un seguimiento como evento independiente. Podría inferirse a partir de las marcas de tiempo de tablas de adjuntos como FND_ATTACHED_DOCUMENTS, vinculadas al registro del asiento en GL_JE_HEADERS. Recopilar Infiera el evento a partir de la fecha de creación de los registros de FND_ATTACHED_DOCUMENTS vinculados al asiento. Tipo de evento inferred
	Reversión del asiento procesada	Se ha creado y contabilizado un asiento de reversión para anular el impacto financiero del asiento original en un periodo posterior. Es una acción habitual en las periodificaciones.
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 indicar problemas en la gestión de periodificaciones. Dónde obtenerlo Se infiere identificando un nuevo asiento contable vinculado explícitamente al original como su reversión. La tabla GL_JE_HEADERS contiene campos como REVERSAL_PERIOD y REVERSAL_FLAG para identificar y vincular estos asientos. Recopilar Identifique la fecha de creación y contabilización del nuevo asiento cuya cabecera indica que el asiento original se ha revertido. 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. Utilice el menú Navigator para ir a Tools y seleccione Reports and Analytics. Este es el centro para crear y gestionar todos los análisis e informes.
Cree un modelo de datos de BI Publisher: En lugar de comenzar con un análisis de OTBI, para este tipo de extracción de Registro de eventos resulta más eficaz crear directamente un modelo de datos de BI Publisher. Así podrá utilizar 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 de modelos de datos, haga clic en el icono '+' para añadir un nuevo Data Set y seleccione 'SQL Query'. Asigne al conjunto 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 a continuación y péguelo en el área de texto SQL Query. La consulta está diseñada para incorporar todas las actividades y atributos necesarios en una única estructura unificada.
Defina los parámetros: La consulta proporcionada utiliza 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, establecer los tipos de datos adecuados (Date o Text) y definir valores predeterminados cuando sea necesario. Esto permite ejecutar el informe con flexibilidad.
Cree un informe a partir del modelo de datos: Después de guardar el modelo de datos, vuelva al catálogo. Haga clic en Create > Report. En el asistente de creación del informe, seleccione 'Use Existing Data Model' y localice el modelo que acaba de crear.
Configure el diseño del informe: En el editor de diseño, seleccione el diseño 'Table'. Es fundamental arrastrar y soltar en la tabla todas las columnas del modelo de datos para garantizar que se incluyan en la exportación. No necesita aplicar un formato complejo.
Establezca CSV como formato de salida predeterminado: Vaya al enlace 'View a List' del editor del informe. 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, después, en 'Schedule'. Cree un nuevo trabajo programado. Configure la frecuencia, por ejemplo, diaria o semanal.
Configure la exportación y la entrega: En la pestaña 'Output' del trabajo programado, especifique los detalles de salida. Seleccione su 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 el trabajo programado, 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: La consulta debe ejecutarse en la fuente de datos 'Oracle BI EE' dentro de BI Publisher, que se conecta a las vistas de la base de datos transaccional subyacentes a 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, potencialmente, en áreas temáticas de Workflow para el historial de aprobaciones.
Filtrado por intervalo de fechas: Es fundamental limitar los datos a un periodo manejable. La consulta incluye los parámetros :start_date y :end_date. Recomendamos extraer entre 3 y 6 meses de datos para el análisis inicial. El filtro se aplica a la fecha de creación del diario.
Filtrado por libro mayor: Utilice el parámetro :ledger_name para limitar la extracción a un libro mayor principal específico. Extraer todos los libros mayores a la vez puede generar archivos extremadamente grandes y problemas de rendimiento.
Requisitos previos: La persona que cree y programe el informe debe contar con los roles de BI adecuados, como 'BI Administrator' o 'BI Author'. Además, su perfil de seguridad de datos debe permitirle acceder a los libros mayores y las unidades de negocio consultados.
Programación: Para obtener un rendimiento óptimo y evitar afectar a las personas usuarias del sistema, programe el trabajo de extracción fuera del horario de mayor actividad, por ejemplo, durante la noche.

a 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. Utilice el menú Navigator para ir a Tools y seleccione Reports and Analytics. Se abrirá el catálogo de Business Intelligence.
Cree un modelo de datos nuevo: En el catálogo de BI, haga clic en el botón Create y seleccione Data Model. Se abrirá el editor de modelos de datos.
Defina el conjunto de datos de la consulta SQL: En el editor de modelos de datos, haga clic en el icono de suma de la pestaña Diagram y seleccione SQL Query. En el nuevo cuadro de diálogo, asigne un nombre al conjunto, por ejemplo, ProcessMind_JE_EventLog. Seleccione la fuente de datos adecuada, normalmente FUSIONDB. Pegue la consulta SQL completa proporcionada en el área de texto SQL Query.
Defina los parámetros: La consulta utiliza 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 situado en la esquina superior derecha del editor del modelo de datos. Se abrirá el asistente de creación del informe.
Configure el diseño del informe: En el asistente, seleccione la opción para utilizar el modelo de datos actual. Elija el diseño 'Table'. Arrastre y suelte todas las columnas de la fuente de datos en el área de diseño de la tabla. Desmarque la opción 'Show Grand Totals Row'.
Guarde el informe: Guarde el informe 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 CSV esté seleccionado y, preferiblemente, establézcalo como formato predeterminado. Así garantizará que la salida sea compatible para su uso directo.
Ejecute y exporte: Abra el informe. Se le solicitará que introduzca los parámetros de fecha inicial y final. Introduzca el intervalo deseado y haga clic en Apply. Cuando se ejecute el informe, haga clic en el botón Export y seleccione el formato CSV para descargar el archivo del Registro de eventos.
Prepárese para la carga: 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 la plataforma ProcessMind.

Configuración

Requisitos previos: La persona que ejecute el informe debe tener un rol con los privilegios de seguridad de datos necesarios para acceder a los datos de General Ledger, como General Accountant o un rol de BI personalizado. También se requiere acceso a la herramienta BI Publisher.
Fuente de datos: El modelo de datos de BI Publisher debe configurarse para utilizar la conexión a la base de datos de la aplicación FUSIONDB.
Parámetros del intervalo de fechas: La consulta está diseñada con los parámetros p_start_date y p_end_date para controlar el periodo de extracción. Se recomienda comenzar 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 común de tabla 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 del horario de mayor actividad para minimizar el impacto en el rendimiento del sistema.
Formato de salida: El informe debe configurarse para generar un archivo CSV. Este formato limpio y estructurado facilita la ingesta en herramientas de Process Mining.

a 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, el nombre de usuario y la contraseña.
Configuración del script: Cree un archivo de script de Python nuevo. Comience importando las bibliotecas necesarias: requests, json, pandas y datetime.
Configuración: En el script, defina las variables correspondientes a sus credenciales de Oracle Fusion y a la URL base. Establezca también los parámetros de extracción, como las fechas inicial y final de la consulta.
Autenticación: El script utiliza autenticación básica. La biblioteca requests gestiona la codificación del 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 para gestionar las solicitudes a la API. Esta función debe controlar la paginación mediante los parámetros offset y limit. Repetirá las llamadas a la API hasta recuperar todos los registros de diarios del intervalo de fechas especificado.
Construya la consulta de la API: Utilice el parámetro q de la solicitud de la API para filtrar los diarios según LastUpdateDate. Esto permite extraer datos de un periodo concreto, por ejemplo, LastUpdateDate between '2023-01-01' and '2023-03-31'.
Inicie la recuperación de datos: Llame a la función para comenzar a obtener datos del endpoint .../fscmRestApi/resources/11.13.18.05/journals. La función devolverá una lista completa de asientos.
Procese y transforme los datos: Recorra cada asiento devuelto por la API. Para cada diario, genere varias filas de eventos correspondientes a las distintas actividades empresariales (Journal Entry Created, Journal Entry Approved, etc.). Utilice los campos de fecha y los códigos de estado de la respuesta de la API (CreationDate, PostedDate, ApprovalStatus, etc.) para crear estos eventos diferenciados.
Estructure el Registro de eventos: A medida que genere cada fila de evento, guárdela como un diccionario en una lista. Esta lista se convertirá en los datos sin procesar de su Registro de eventos.
Cree el DataFrame: Cuando haya procesado todos los diarios, convierta la lista de diccionarios de eventos en un DataFrame de Pandas para facilitar su manipulación.
Finalice 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 utiliza el endpoint fscmRestApi/resources/11.13.18.05/journals para obtener datos de General Ledger.
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 periodo de entre 3 y 6 meses. Para el uso continuo, configúrelo para cargas incrementales diarias o semanales.
Límite de paginación: El parámetro limit controla cuántos registros se obtienen en cada llamada a la API. Normalmente, un valor entre 200 y 500 ofrece un buen equilibrio entre el número de llamadas y 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 diarios mediante la API REST, como General Accountant o un rol personalizado con permisos equivalentes.

a 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 de Oracle Fusion Financials o los Public View Objects necesarios y las autorizaciones requeridas del sistema de origen estén disponibles en su entorno. Confirme con su administrador de Oracle el destino de entrega de BICC configurado y sus credenciales de acceso.
En la consola de BI Cloud Connector, identifique los Public View Objects que contienen los encabezados y las líneas de los diarios, el historial de aprobaciones, los archivos adjuntos, el estado de contabilización, el estado de conciliación y la información de reversión. Registre los nombres exactos de los objetos y atributos configurados en su entorno. Sustituya los marcadores de posición del script de extracción por esos nombres antes de ejecutarlo.
Configure un trabajo de BICC para los Public View Objects de General Ledger seleccionados. Utilice una extracción incremental cuando exista un atributo fiable de última actualización. Para la carga inicial, utilice un periodo controlado de entre tres y 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. Utilice las asignaciones exactas de objetos y atributos de origen documentadas para su entorno. No dé por hecho que un Public View Object tiene la misma estructura que una tabla de base de datos subyacente.
Normalice las marcas de tiempo a una única zona horaria y convierta las marcas de tiempo de origen a un tipo de datos de marca de tiempo coherente. Conserve la marca de tiempo de actualización de origen como LastDataUpdate. Convierta los identificadores y atributos de actividad de origen a los nombres de salida utilizados por ProcessMind.
Ejecute la consulta siguiente después de sustituir cada marcador de posición por los nombres reales de los objetos y atributos 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 ausentes 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 diarios rechazados y reenviados, las relaciones de reversión y los registros con atributos opcionales ausentes.
Exporte el resultado como un archivo delimitado u otro formato compatible con ProcessMind. Incluya los nombres exactos de columna 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 los diarios, el historial de aprobaciones o Workflow, los archivos adjuntos y los datos de contabilización, conciliación y reversión. Debe confirmar los nombres exactos de los objetos y atributos en el catálogo de BICC de su entorno.
Utilice un periodo de extracción inicial de entre tres y 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 filtros aprobados para la fecha contable o la fecha de última actualización, el libro mayor, la entidad legal, la unidad de negocio, el código de empresa cuando esté disponible, la categoría del diario, el origen del diario, el tipo de documento cuando esté disponible y el estado del diario. Utilice únicamente filtros compatibles con los Public View Objects seleccionados.
Configure la extracción incremental mediante el atributo de última actualización del origen y una marca de agua persistente. Cuando sea necesario, incluya una pequeña ventana de solapamiento para protegerse frente a actualizaciones recibidas con retraso y, después, elimine duplicados por JournalEntryId, ActivityName, EventTime y el identificador del evento de origen correspondiente.
Asegúrese de que todos los objetos de origen utilicen claves de extracción y programaciones de actualización compatibles. Los datos de aprobaciones, archivos adjuntos, contabilización, conciliación y reversión pueden actualizarse en momentos diferentes.
Para conjuntos de datos grandes, particione por periodo contable, libro mayor, entidad legal 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 la transformación. 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 Workflow.
Confirme que los módulos necesarios de Oracle Fusion Financials, la configuración de Workflow, el almacenamiento de archivos adjuntos, los procesos de contabilización y las fuentes de datos de conciliación estén habilitados cuando se esperen esas actividades.
No considere que la ausencia de un registro de origen demuestra que una actividad no ocurrió. La salida de BICC refleja los Public View Objects seleccionados, los filtros, el momento de actualización, la retención y el historial disponible.

a 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 comenzar?

Utilice este Template para transformar sus datos de Oracle Fusion Journal Entry en información útil, acelerar su ciclo de Record to Report y avanzar hacia unas operaciones financieras optimizadas.

Volver a la guía de mejora Descargar Template

Acelere hoy su proceso de Record to Report - Journal Entry

Reduzca un 30 % el tiempo de ciclo de Journal Entry y optimice sus operaciones financieras.

Iniciar la prueba gratuita

No necesita tarjeta de crédito. Active su prueba ahora.

Su Template de datos de Record to Report - Journal Entry

Su Template de datos de Record to Report - Journal Entry

Del registro al informe: atributos del asiento contable

Del registro al informe: actividades del asiento contable

Guías de extracción

Exportación de informes de Oracle OTBI y BI Publisher

Pasos

Configuración

a Consulta de ejemplo sql

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

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST de Oracle Fusion Financials

Pasos

Configuración

a Consulta de ejemplo python

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

Pasos

Configuración

a Consulta de ejemplo sql

¿Listo para comenzar?

Acelere hoy su proceso de Record to Report - Journal Entry

Su Template de datos de Record to Report - Journal Entry

Su Template de datos de Record to Report - Journal Entry

Del registro al informe: atributos del asiento contable

Del registro al informe: actividades del asiento contable

Guías de extracción

Exportación de informes de Oracle OTBI y BI Publisher

Pasos

Configuración

a Consulta de ejemplo sql

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

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python mediante la API REST de Oracle Fusion Financials

Pasos

Configuración

a Consulta de ejemplo python

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

Pasos

Configuración

a Consulta de ejemplo sql

¿Listo para comenzar?

Acelere hoy su proceso de Record to Report - Journal Entry

Valoramos su privacidad