> Mejora Continua de Procesos > Registro a Informe Asiento Contable > Oracle Fusion Financials > Plantilla de Datos

Su Template de Datos de Registro a Informe - Asiento Contable

Oracle Fusion Financials

Registro a Informe - Atributos de Asiento Contable (22) Registro a Informe - Actividades de Asiento Contable (12) Guías de Extracción (4)

Su Template de Datos de Registro a Informe - Asiento Contable

Este template de datos proporciona una guía completa para extraer y estructurar sus datos de Asientos Contables de Oracle Fusion Financials. Describe los atributos esenciales a recopilar y las actividades clave a rastrear, asegurando que capture toda la información necesaria para un análisis de procesos robusto. También encontrará orientación práctica sobre cómo extraer estos datos directamente de su sistema.

Atributos recomendados para recopilar
Actividades clave para el seguimiento
Guía de extracción para Oracle Fusion Financials

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

Descargar Plantilla

Registro a Informe - Atributos de Asiento Contable

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

5 Requerido 6 Recomendado 11 Opcional

	Nombre	Descripción
	Actividad ActivityName	El nombre del evento o tarea de negocio específico que ocurrió en un momento dado en el proceso de asiento contable.
Descripción El Nombre de la actividad describe un solo paso dentro del ciclo de vida del asiento contable, como 'Asiento Contable Creado' o 'Asiento Contable Aprobado'. Estos datos son cruciales para construir el mapa de procesos y comprender la secuencia de eventos. Analizar actividades permite identificar el flow del proceso, incluyendo rutas estándar, desviaciones y bucles de retrabajo. Al rastrear diferentes actividades, podemos medir el tiempo dedicado a etapas específicas, como la aprobación, e identificar qué pasos son los que consumen más tiempo o son más propensos a errores. Por qué es importante Define los pasos del proceso, formando la columna vertebral del mapa de procesos y permitiendo el análisis de flujo, cuellos de botella y variaciones. Dónde obtener Este atributo se deriva típicamente de cambios de estado, Registros de eventos o tablas de seguimiento de auditoría asociadas con objetos de asientos contables en el módulo de Libro Mayor General. Ejemplos Asiento Contable CreadoAsiento Enviado para AprobaciónAsiento Contable AprobadoAsiento Contable Contabilizado
	Hora de Inicio EventTime	El timestamp que indica cuándo ocurrió una actividad o evento específico.
Descripción Este timestamp marca la fecha y hora exactas en que se ejecutó una actividad. Es el elemento temporal principal utilizado en Process Mining para determinar la secuencia de eventos y calcular las duraciones entre ellos. La precisión del Tiempo del Evento es crítica para todos los análisis basados en el tiempo, incluyendo el cálculo de tiempos de ciclo, la identificación de bottlenecks y el monitoreo del rendimiento con respecto a los acuerdos de nivel de servicio. Proporciona el orden cronológico necesario para reconstruir el flow del proceso tal como sucedió. Por qué es importante Este timestamp es esencial para ordenar eventos, calcular todas las duraciones del proceso y realizar cualquier análisis basado en el tiempo. Dónde obtener Esta información se almacena típicamente en tablas de seguimiento de auditoría o como 'Fecha de Última Actualización' o 'Fecha de Creación' 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 de Asiento Contable JournalEntryId	El identificador único para un solo asiento contable, vinculando todas las actividades de transacción financiera relacionadas.
Descripción El ID de Asiento Contable sirve como el identificador principal de case, vinculando de manera única todas las actividades relacionadas con un conjunto específico de transacciones financieras. Esto permite el seguimiento del ciclo de vida completo de un solo asiento contable, desde su inicio hasta su contabilización final, asegurando que todos los débitos y créditos se contabilicen. En Process Mining, este ID es esencial para reconstruir el recorrido de extremo a extremo de cada asiento contable. Conecta eventos dispares como 'Asiento Contable Creado', 'Asiento Contable Enviado para Aprobación' y 'Asiento Contable Contabilizado' en un flow de proceso coherente, permitiendo el análisis de los tiempos de ciclo, los bottlenecks y las variaciones del proceso. Por qué es importante Esta es la clave fundamental para rastrear un asiento contable de principio a fin, haciendo posible analizar todo el flow del proceso para cada unique case. Dónde obtener Esta es una clave primaria que se encuentra en las tablas centrales del Libro Mayor General, como GL_JE_HEADERS y GL_JE_LINES. Ejemplos JE100523JE202311001882019
	Source System SourceSystem	El sistema o módulo donde se originaron los datos.
Descripción Este atributo identifica el sistema de origen del que se extrajeron los datos del proceso. En un panorama de TI complejo, los datos pueden provenir de múltiples sistemas integrados, y este campo ayuda a diferenciarlos. En el análisis de procesos, conocer el sistema de origen es crucial para comprender las variaciones del proceso que pueden ser impulsadas por diferentes comportamientos del sistema. También ayuda en la validación de datos y la resolución de problemas al rastrear los datos hasta su origen. Por qué es importante Identifica el origen de los datos, lo cual es crucial para la gobernanza de datos, la validación y la comprensión de las variaciones del proceso en diferentes sistemas. Dónde obtener Este suele ser un valor estático configurado durante la extracción de datos, o podría ser un campo en las tablas de origen que identifica el sistema de entrada. Ejemplos Oracle Fusion Financials CloudOracle EBS R12Fusion GL
	Última actualización de datos LastDataUpdate	El timestamp de la actualización de datos o extracción más reciente 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 que se analizan, lo cual es importante para comprender la relevancia de los insights derivados. En cualquier análisis, especialmente en dashboards operativos, conocer la hora de la Última Actualización de datos es crítico para que los usuarios confíen en los datos y tomen decisiones informadas. Comunica claramente el punto de corte para los datos incluidos en el modelo de Process Mining. Por qué es importante Indica la actualidad de los datos, asegurando que los usuarios comprendan cuán actual es el análisis del proceso y puedan confiar en los conocimientos. Dónde obtener Este valor se genera y almacena durante el proceso de extracción y transformación de datos. Típicamente es el timestamp cuando se completó el trabajo de 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 'Devengo', 'Ajuste' o 'Reclasificación'.
Descripción La Categoría del Asiento clasifica las entradas basándose en su propósito comercial. Esta clasificación permite un análisis más granular del proceso, ya que las diferentes categorías pueden tener flujos de proceso, reglas de aprobación o tiempos de ciclo distintos. Por ejemplo, los asientos de ajuste de fin de mes podrían tener un proceso más complejo y urgente que los devengos rutinarios. Analizar el proceso por categoría ayuda a descubrir estas variaciones y a adaptar las mejoras a tipos específicos de asientos contables. Por qué es importante Permite segmentar el proceso por el propósito comercial del asiento, revelando diferentes comportamientos y rendimientos para distintos tipos de entrada. Dónde obtener Disponible en la tabla GL_JE_HEADERS, típicamente en un campo llamado 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 proporciona contexto organizacional al vincular una actividad a un departamento específico, como 'Finanzas', 'Operaciones Contables' o 'Auditoría Interna'. Se deriva típicamente de los datos maestros de usuario. El análisis por Departamento de Usuario ayuda a identificar bottlenecks interdepartamentales, comparar el rendimiento del equipo y comprender cómo difiere la ejecución del proceso en toda la organización. Es valioso para la asignación de recursos e iniciativas de mejora de procesos dirigidas. Por qué es importante Proporciona contexto organizacional, permitiendo el análisis de rendimiento por equipo o departamento y destacando ineficiencias interfuncionales. Dónde obtener Esto típicamente no se encuentra en las tablas de transacciones. Debe obtenerse uniendo el UserName con una tabla maestra de datos de usuarios o datos del sistema de RRHH. Ejemplos Contabilidad GeneralInformes FinancierosCuentas por Pagar
	Monto del Asiento JournalAmount	El valor monetario total del asiento contable, típicamente la suma de los débitos.
Descripción Este atributo representa el valor financiero total que se transacciona en el asiento contable. El importe puede ser un factor significativo que influye en el proceso. Por ejemplo, los asientos de alto valor pueden requerir pasos de aprobación adicionales o revisiones más exhaustivas. El análisis del Importe del Asiento permite la segmentación de cases por impacto financiero. Ayuda a responder preguntas como '¿Los asientos de alto valor tardan más en aprobarse?' o '¿Son más comunes los rechazos para asientos por encima de un cierto umbral?'. Esto proporciona un contexto de negocio crucial para el flow del proceso. Por qué es importante Proporciona un contexto de negocio crítico, permitiendo un análisis basado en el impacto financiero y ayudando a identificar si los asientos de alto valor siguen un proceso diferente. Dónde obtener Este valor se calcula típicamente como la suma de débitos o créditos de la tabla GL_JE_LINES para un asiento contable dado. Ejemplos 5000.00125000.75750.50
	Motivo de rechazo RejectionReason	Una descripción textual o un código que explica por qué se rechazó un asiento contable.
Descripción Cuando un asiento contable es rechazado durante el proceso de aprobación, este atributo captura el motivo del rechazo. Esto podría ser un código predefinido o un comentario de texto libre del aprobador. Este es uno de los atributos más importantes para el análisis de la causa raíz de las ineficiencias del proceso. Al analizar las razones de rechazo más comunes, las organizaciones pueden identificar áreas de mejora, como una mejor capacitación para los preparadores, pautas más claras o mejoras en el control del sistema. Soporta directamente el dashboard 'Análisis de la Tasa de Rechazo de Asientos Contables'. Por qué es importante Ofrece una visión directa de las causas raíz del retrabajo y los retrasos del proceso, permitiendo mejoras específicas para reducir las tasas de rechazo. Dónde obtener Esta información puede almacenarse en tablas de workflow o seguimiento de auditoría asociadas con el proceso de aprobación, o en un campo de notas en el encabezado del asiento contable. Ejemplos Combinación de Cuentas IncorrectaDocumentación de Soporte InsuficienteExcede el presupuesto
	Origen del Asiento JournalSource	El subledger o fuente 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 General o generarse automáticamente desde subledgers como Cuentas por Pagar, Cuentas por Cobrar o Activos Fijos. La Fuente del Asiento Contable es un atributo clave para el análisis de la automatización. Ayuda a diferenciar entre asientos manuales y generados por el sistema, apoyando el KPI de 'Tasa de Asientos Contables Automatizados'. Los procesos para los asientos de diferentes fuentes a menudo varían significativamente en términos de complejidad y eficiencia. Por qué es importante Distingue entre asientos manuales y automatizados, lo cual es crítico para medir las tasas de automatización y analizar las diferencias del proceso. Dónde obtener Disponible en la tabla GL_JE_HEADERS, típicamente en un campo llamado 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 o usuario del sistema específico responsable de ejecutar una actividad. Es crucial para comprender la distribución de la carga de trabajo, el rendimiento y la identificación de bottlenecks individuales. En análisis, UserName permite filtrar procesos por usuario, comparar la eficiencia del usuario e investigar las razones de los retrasos o errores. Soporta directamente dashboards como 'Carga de Trabajo y Eficiencia del Usuario entre Equipos' y KPIs como el 'Índice de Bottleneck de Asientos Contables por Usuario'. Por qué es importante Atribuye la responsabilidad de los pasos del proceso, permitiendo el análisis de la carga de trabajo del usuario, el rendimiento individual y las necesidades de formación. Dónde obtener Se encuentra en tablas de transacciones como GL_JE_HEADERS (ej., CREATED_BY, LAST_UPDATED_BY) y tablas de auditoría relacionadas. Ejemplos john.doesusan.smithautoprocess_user
	¿Es Retrabajo? IsRework	Un indicador calculado que 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 cases que han experimentado retrabajo. Típicamente se marca como 'true' para cualquier actividad que siga un evento de 'Asiento Contable Rechazado', como 'Asiento Contable Corregido y Reenviado'. 'Es Retrabajo' es un atributo potente para el análisis, ya que permite cuantificar fácilmente el volumen y el impacto de los bucles de retrabajo. Soporta directamente el KPI de 'Tasa Promedio de Retrabajo de Asientos Contables' y ayuda a comparar el flow del proceso y la duración de los cases retrabajados versus aquellos que se procesan correctamente la primera vez. Por qué es importante Marca directamente los casos que han pasado por bucles de reproceso ineficientes, facilitando la cuantificación de la frecuencia y el impacto de los fallos del proceso. Dónde obtener Esto no está disponible en el sistema de origen. Se calcula dentro de la herramienta de Process Mining analizando la secuencia de actividades para cada case. Ejemplos truefalse
	Es Contabilización a Tiempo IsOnTimePosting	Un indicador calculado que es verdadero si el asiento se contabilizó en o antes de su fecha objetivo.
Descripción Este atributo booleano se deriva al comparar el timestamp de la actividad 'Asiento Contable Contabilizado' con la 'Fecha Objetivo de Contabilización'. Si la contabilización ocurre en o antes de la fecha objetivo, el valor es 'true'; de lo contrario, es 'false'. Este atributo soporta directamente el KPI de 'Tasa de Contabilización de Asientos a Tiempo' al simplificar el cálculo. Permite un fácil filtrado y análisis de los asientos atrasados para identificar causas comunes de los retrasos, como categorías de asientos específicos o aprobadores. Por qué es importante Proporciona un resultado claro y binario para el rendimiento de la contabilización, simplificando el análisis de las tasas de cumplimiento a tiempo y las causas raíz de los retrasos. Dónde obtener Este atributo es calculado por la herramienta de Process Mining. Requiere el atributo 'TargetPostingDate' y el timestamp de la actividad 'Asiento Contable Contabilizado'. Ejemplos truefalse
	Estado de Contabilización PostingStatus	El estado de contabilización actual del asiento contable, por ejemplo, 'No contabilizado' o 'Contabilizado'.
Descripción Este atributo refleja el estado actual del asiento contable con respecto a su contabilización en el libro mayor general. Es un indicador clave de dónde se encuentra un asiento contable en su ciclo de vida, especialmente para cases en curso. El Estado de Contabilización es crucial para el dashboard 'Rastreador de Estado de Asientos Contables en Tiempo Real', proporcionando una instantánea de todos los asientos activos. Ayuda a monitorear los retrasos de los asientos no contabilizados y a identificar demoras en las etapas finales del proceso. Por qué es importante Indica el estado actual de un asiento, lo cual es esencial para monitorear los atrasos y rastrear el estado de los asientos en curso. Dónde obtener Disponible en la tabla GL_JE_HEADERS, típicamente en una columna como STATUS o POSTING_STATUS. Ejemplos ContabilizadoNo ContabilizadoError
	Fecha Objetivo de Contabilización TargetPostingDate	La fecha predeterminada en la que se espera que el asiento contable sea contabilizado.
Descripción La Fecha Objetivo de Contabilización representa la fecha límite para contabilizar un asiento contable en el libro mayor general, a menudo determinada por acuerdos de nivel de servicio (SLAs) o calendarios de cierre de fin de mes. Sirve como un punto de referencia para medir el rendimiento. Este atributo es esencial para calcular el KPI de 'Tasa de Contabilización de Asientos a Tiempo'. Al comparar la fecha de contabilización real con este objetivo, el sistema puede marcar automáticamente los asientos como a tiempo o retrasados, proporcionando una medida clara del cumplimiento del proceso con los cronogramas. Por qué es importante Define el acuerdo de nivel de servicio o la fecha límite para la contabilización, lo que permite el cálculo de los KPIs de rendimiento a tiempo. Dónde obtener Puede que este no sea un campo estándar. Podría derivarse de reglas de negocio basadas en la fecha de creación, el periodo contable o la categoría del asiento contable. 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 culminación de una actividad. Mientras que la Hora de Inicio registra el comienzo, la Hora de Finalización proporciona el punto de cierre, permitiendo un cálculo preciso del tiempo de procesamiento para ese paso específico. Esto es esencial para calcular los tiempos de procesamiento de actividad, que es una métrica central para identificar bottlenecks 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' da el tiempo real que un revisor dedicó a la tarea. Por qué es importante Permite el cálculo de la duración real o el tiempo de procesamiento de las actividades individuales, lo cual es clave para identificar problemas de eficiencia. Dónde obtener Similar a la Hora de Inicio, esto se encuentra a menudo en tablas de seguimiento de auditoría o puede inferirse de la Hora de Inicio de la actividad posterior en el 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 es la reversión de otro asiento.
Descripción Este atributo booleano identifica los asientos contables que se crean para revertir un asiento contabilizado previamente. Las reversiones son un tipo específico de asiento contable que a menudo sigue un proceso distinto y, a veces, problemático. Analizar este indicador es clave para respaldar el dashboard de 'Rendimiento del Proceso de Reversión de Asientos Contables'. Permite aislar los procesos de reversión para medir su frecuencia, causas y tiempos de ciclo, ayudando a identificar problemas subyacentes en los asientos originales que requieren reversión. Por qué es importante Ayuda a aislar y analizar el proceso de reversión, que a menudo es un indicador de errores o problemas en la transacción original. Dónde obtener Esto puede ser un flag específico en la tabla GL_JE_HEADERS, como ACCRUAL_REV_FLAG, o identificado a través de enlaces al asiento contable original que se está revirtiendo. Ejemplos truefalse
	Moneda CurrencyCode	El código de divisa para el importe del asiento contable, como USD, EUR o GBP.
Descripción El Código de Moneda especifica la divisa de los importes financieros en el asiento contable. Esto es esencial para organizaciones multinacionales que transaccionan en múltiples monedas. Este atributo asegura que los valores financieros se interpreten correctamente. Permite filtrar por moneda y es un campo necesario al realizar cualquier análisis que implique comparar o agregar importes monetarios entre diferentes regiones. Por qué es importante Proporciona el contexto necesario para cualquier importe financiero, asegurando una interpretación precisa y permitiendo análisis específicos para diferentes monedas. Dónde obtener Disponible en la tabla GL_JE_HEADERS, típicamente en un campo llamado CURRENCY_CODE. Ejemplos USDEURGBPJPY
	Nombre del Libro Mayor LedgerName	El nombre del libro mayor general donde se registra el asiento contable.
Descripción El Nombre del Libro Mayor identifica el libro mayor específico al que pertenece el asiento contable. En organizaciones con múltiples entidades legales o requisitos de informes, puede haber varios libros mayores, como un libro mayor principal para la contabilidad corporativa y libros mayores secundarios para informes estatutarios locales. Este atributo es esencial para filtrar y comparar procesos entre diferentes entidades legales o unidades de negocio. Asegura que los análisis se realicen dentro del contexto organizacional correcto, lo cual es particularmente importante para el cumplimiento y los informes financieros. Por qué es importante Permite filtrar y comparar el análisis del proceso en diferentes entidades legales o marcos contables, lo cual es vital para grandes organizaciones. Dónde obtener Se encuentra en la tabla GL_JE_HEADERS, típicamente vinculado a través de un LEDGER_ID que se puede unir 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 periodo fiscal al que se contabiliza el asiento contable, como 'Ene-24'.
Descripción El Periodo Contable especifica el periodo financiero en el que se reconoce la transacción. Esto es fundamental para todos los informes y análisis financieros. En Process Mining, este atributo es crucial para el análisis de tendencias. Permite comparar el rendimiento del proceso, como los tiempos de ciclo o las tasas de rechazo, entre diferentes meses o trimestres. Esto ayuda a identificar efectos de estacionalidad, como el aumento de la carga de trabajo durante el cierre de fin de mes, y a medir el impacto de las mejoras del proceso a lo largo del tiempo. Por qué es importante Permite el análisis de tendencias de los KPIs a lo largo del tiempo, ayudando a medir la mejora del proceso e identificar patrones estacionales como las presiones de fin de mes. Dónde obtener Disponible en la tabla GL_JE_HEADERS, típicamente en un campo llamado PERIOD_NAME. Ejemplos Jan-24Feb-24Mar-24
	Tiempo de Aprobación del Asiento JournalApprovalTime	La duración calculada entre la presentación del asiento contable y la decisión final de aprobación o rechazo.
Descripción Esta métrica mide el tiempo transcurrido desde que un asiento contable se envía para aprobación hasta que es aprobado o rechazado. Es una medida crítica de la eficiencia del workflow de aprobación. El Tiempo de Aprobación de Asientos es una entrada directa para el KPI de 'Tiempo Promedio de Aprobación de Asientos' y el dashboard 'Bottlenecks de Aprobación de Asientos Contables'. Analizar esta duración ayuda a identificar retrasos en la cadena de aprobación, ya sean causados por aprobadores, departamentos o tipos de asientos específicos. Por qué es importante Mide directamente la eficiencia del workflow de aprobación, que a menudo es una fuente importante de retrasos en el proceso. Dónde obtener Esta es una métrica calculada dentro de la herramienta de Process Mining. Es la diferencia de tiempo entre los eventos 'Asiento Contable Enviado para Aprobación' y 'Asiento Contable Aprobado' o 'Asiento Contable Rechazado'. Ejemplos P2DT4H30MPT8HP5D
	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 pasa en todo el proceso, desde el primer evento de 'Asiento Contable Creado' hasta el evento final de 'Asiento Contable Conciliado'. Proporciona una visión holística del rendimiento del proceso. Este es un KPI primario para medir la eficiencia general del proceso. Se utiliza en dashboards de tendencias para rastrear el impacto de las iniciativas de mejora a lo largo del tiempo y proporciona una línea de base contra la cual se pueden medir todos los cambios del proceso. Por qué es importante Ofrece una medida de alto nivel de la salud y eficiencia de todo el proceso, convirtiéndola en una métrica clave para los informes ejecutivos. Dónde obtener Esta métrica es calculada por la plataforma de Process Mining como la diferencia de tiempo entre el primero y el último timestamp del evento para cada case. Ejemplos P10DT5HP4DT12HP22D

Requerido Recomendado Opcional

Registro a Informe - Actividades de Asiento Contable

Estos son los pasos clave del proceso y los hitos a capturar en su Registro de eventos para una detección precisa del proceso en Asiento Contable.

5 Recomendado 7 Opcional

	Actividad	Descripción
	Asiento Contable Aprobado	El aprobador designado ha aprobado formalmente el asiento contable, confirmando su precisión y validez. Este es el paso final en el workflow de aprobación, abriendo el camino para la contabilización.
Por qué es importante Este hito marca el final del proceso de aprobación. El tiempo entre la presentación y la aprobación es un KPI clave para medir la eficiencia del workflow e identificar bottlenecks de aprobación. Dónde obtener Este evento se infiere de un cambio de estado en la tabla GL_JE_HEADERS, donde el APPROVAL_STATUS_CODE se actualiza a 'APPROVED'. Las tablas de workflow contienen la identidad y el timestamp del aprobador. Capturar Rastree el timestamp cuando APPROVAL_STATUS_CODE en GL_JE_HEADERS cambie a 'APPROVED'. Tipo de evento inferred
	Asiento Contable Conciliado	El asiento contable ha sido conciliado y compensado durante un proceso de conciliación de cuentas de fin de periodo. Esto confirma que la transacción se alinea con otros datos financieros, como los extractos bancarios.
Por qué es importante Esta actividad sirve como un verdadero punto final para el ciclo de vida del asiento contable. Medir el tiempo desde la contabilización hasta la conciliación es un KPI clave para evaluar la eficiencia del proceso de cierre financiero. Dónde obtener Este evento se captura típicamente en Oracle Financial Consolidation and Close Cloud Service (FCCS) o Account Reconciliation Cloud Service (ARCS), no en el Libro Mayor General mismo. Se infiere de un cambio de estado en el registro de conciliación vinculado al asiento contable. Capturar Correlacionar datos de asientos con actualizaciones de estado de conciliación de tablas de ARCS o FCCS. Tipo de evento inferred
	Asiento Contable Contabilizado	Los datos financieros del asiento contable han sido registrados exitosamente en el Libro Mayor General. Los débitos y créditos ahora se reflejan en los saldos de las cuentas.
Por qué es importante Este es un hito crítico que representa la entrada del asiento contable en el registro financiero oficial. Es esencial para medir la tasa de contabilización a tiempo y el tiempo total desde la creación hasta la contabilización. Dónde obtener Esto se infiere de un cambio de estado en la tabla GL_JE_HEADERS, donde el campo STATUS cambia a 'P' (Contabilizado). La tabla GL_JE_BATCHES también tiene un estado de contabilización. Capturar Rastree el timestamp cuando STATUS en GL_JE_HEADERS cambie a 'P'. Tipo de evento inferred
	Asiento Contable Creado	Esta actividad marca el inicio del proceso de asiento contable. Representa el momento en que un usuario crea un nuevo encabezado de asiento y comienza a ingresar datos, pero antes de que se envíe para cualquier revisión o aprobación.
Por qué es importante Este es el primary start event para el proceso. Analizar el tiempo desde esta actividad hasta los pasos subsiguientes ayuda a medir la eficiencia inicial de la entrada de datos y el tiempo total del ciclo del proceso. Dónde obtener Este evento se infiere típicamente del timestamp de la fecha de creación en la tabla GL_JE_HEADERS para un ID de Asiento Contable específico. El usuario que creó el registro también está disponible en esta tabla. Capturar Use el CREATION_DATE de la tabla GL_JE_HEADERS. Tipo de evento inferred
	Asiento Enviado para Aprobación	Esta actividad ocurre cuando el usuario presenta formalmente el asiento contable completado al workflow de aprobación. Transiciona el asiento de un estado de borrador o incompleto a pendiente de aprobación.
Por qué es importante Este es un hito crítico que pone en marcha el reloj para medir los tiempos del ciclo de aprobación e identificar bottlenecks. Separa la fase de entrada de datos de la fase de revisión y aprobación. Dónde obtener Este evento se infiere de un cambio de estado en la tabla GL_JE_HEADERS, específicamente cuando el APPROVAL_STATUS_CODE cambia a un valor como 'REQUIRED' o 'INITIATED'. También puede registrarse el timestamp de la fecha de envío. Capturar Rastree el timestamp cuando APPROVAL_STATUS_CODE en GL_JE_HEADERS cambie para indicar el envío. Tipo de evento inferred
	Asiento Contable Rechazado	Un aprobador ha revisado el asiento contable y lo ha rechazado debido a errores, falta de documentación o incumplimientos de políticas. Esta acción envía el asiento de vuelta al creador para su corrección.
Por qué es importante Esta actividad es crucial para analizar bucles de retrabajo, tasas de rechazo y métricas de 'primera vez bien'. La alta frecuencia de rechazos apunta a problemas con la calidad de los datos o la capacitación. Dónde obtener Esto se infiere de un cambio de estado en la tabla GL_JE_HEADERS cuando el APPROVAL_STATUS_CODE se actualiza a 'REJECTED'. El historial del workflow registrará el usuario y el timestamp para esta acción. Capturar Rastree el timestamp cuando APPROVAL_STATUS_CODE en GL_JE_HEADERS se establezca en 'REJECTED'. Tipo de evento inferred
	Asiento Contable Revisado	Un paso de revisión que puede ocurrir antes o como parte del proceso de aprobación formal. Esto representa una verificación por parte de un colega o gerente para asegurar la exactitud y el cumplimiento antes de que pase al aprobador final.
Por qué es importante Aislar esta actividad ayuda a diferenciar entre los tiempos de revisión preliminar y los tiempos de aprobación final. Puede revelar cuellos de botella ocultos si la etapa de revisión es informal pero consume mucho tiempo. Dónde obtener Esto puede ser un explicit step en un workflow de aprobación de múltiples etapas, capturado en workflow history tables. Si es informal, no se captura. Puede inferirse si se registra una acción de usuario específica antes de la decisión final de aprobación. Capturar Analizar las tablas de historial de workflow para detectar pasos intermedios de aprobación o revisión antes del estado final 'Aprobado'. Tipo de evento inferred
	Asiento Corregido y Reenviado	Después de que un asiento contable es rechazado, el creador realiza las correcciones necesarias y lo vuelve a enviar para 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 la medición del tiempo y la frecuencia del retrabajo. Dónde obtener Este es un evento posterior de 'Asiento Contable Enviado para Aprobación' para un asiento que previamente estaba en estado 'REJECTED'. Se identifica analizando la secuencia de cambios de estado para un único ID de Asiento Contable. Capturar Identificar una marca de tiempo de evento de envío que ocurre después de un evento de rechazo para el mismo ID de caso. Tipo de evento inferred
	Contabilización de Asiento Iniciada	Se ha iniciado el proceso de contabilizar el asiento aprobado en el Libro Mayor General. Este puede ser un paso automatizado o manual que pone en cola el asiento para su procesamiento por el programa de contabilización.
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 restricciones de recursos en el motor de contabilización. Dónde obtener Esto puede inferirse de los cambios de estado en la tabla GL_JE_BATCHES, o por el tiempo de envío de la solicitud concurrente de contabilización asociada con el lote de asientos. Capturar Identificar el tiempo de envío de la solicitud para el 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 donde un usuario o sistema confirma que el asiento se registró correctamente y que los saldos son los esperados. A menudo es un paso de control manual.
Por qué es importante Analizar esta actividad ayuda a comprender el tiempo dedicado a controles manuales y garantía de calidad después de la contabilización. Puede destacar oportunidades para automatizar los procesos de verificación. Dónde obtener Es poco probable que esto sea un explicit event en Oracle Fusion. Tendría que inferirse de otras acciones, como un usuario ejecutando un informe específico o la actualización de un campo de estado personalizado, lo cual no es estándar. Capturar Requiere lógica personalizada, como el seguimiento del tiempo de ejecución de informes de verificación o actualizaciones a un flexfield descriptivo. Tipo de evento inferred
	Documentación de Soporte Adjunta	Representa la acción de adjuntar documentos de soporte, como facturas u hojas de cálculo, al asiento contable. Esto se hace a menudo para proporcionar contexto y evidencia a auditores y aprobadores.
Por qué es importante El seguimiento de esta actividad ayuda a comprender si los retrasos son causados por la falta de documentación. También proporciona insights sobre el cumplimiento y la exhaustividad de los asientos contables antes de que entren en el workflow de aprobación. Dónde obtener Esto puede ser difícil de rastrear como un evento discreto. Podría inferirse de los timestamps en tablas de archivos adjuntos como FND_ATTACHED_DOCUMENTS, vinculadas al registro del asiento contable en GL_JE_HEADERS. Capturar Inferir de la fecha de creación de los registros en FND_ATTACHED_DOCUMENTS vinculados al asiento. Tipo de evento inferred
	Reversión de Asiento Procesada	Se ha creado y contabilizado un asiento contable de reversión para anular el impacto financiero del asiento original en un período posterior. Esta es una acción común para los devengos.
Por qué es importante El seguimiento de las reversiones ayuda a identificar tipos de asientos que se revierten con frecuencia y a analizar la eficiencia del propio proceso de reversión. Esto puede indicar problemas con la gestión de los devengos. Dónde obtener Esto se infiere al identificar un nuevo asiento contable que está explícitamente vinculado al original como su reversión. La tabla GL_JE_HEADERS tiene campos como REVERSAL_PERIOD y REVERSAL_FLAG para identificar y vincular estas entradas. Capturar Identificar la fecha de creación y contabilización del nuevo asiento cuyo encabezado hace referencia al asiento original como revertido. Tipo de evento inferred

Recomendado Opcional

Guías de Extracción

Cómo obtener sus datos de Oracle Fusion Financials

Pasos

Navegar al Área de Trabajo de Informes y Análisis: Inicie sesión en Oracle Fusion Financials. Utilice el menú Navegador para ir a Herramientas y luego seleccione Informes y Análisis. Este es el centro neurálgico para crear y gestionar todos los análisis e informes.
Crear un Modelo de Datos de BI Publisher: En lugar de empezar con un Análisis de OTBI, es más efectivo para este tipo de extracción de registro de eventos crear un Modelo de Datos de BI Publisher directamente. Esto le permite utilizar una consulta SQL personalizada con sentencias UNION ALL. Haga clic en el botón 'Explorar Catálogo', navegue a una carpeta adecuada y elija Crear > Modelo de Datos.
Definir el Conjunto de Datos de la Consulta SQL: En el editor del Modelo de Datos, haga clic en el icono '+' para añadir un nuevo Conjunto de Datos y seleccione 'Consulta SQL'. Asigne un nombre descriptivo al conjunto de datos, por ejemplo, 'JournalEventLog'.
Introducir la Consulta SQL: Seleccione 'Oracle BI EE' como Fuente de Datos. Copie el script SQL completo de la sección Consulta a continuación y péguelo en el área de texto de la Consulta SQL. La consulta está diseñada para extraer todas las actividades y atributos requeridos en una única estructura unificada.
Definir 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, estableciendo los tipos de datos apropiados (Fecha o Texto) y valores predeterminados si es necesario. Esto permite una ejecución de informes flexible.
Crear un Informe a partir del Modelo de Datos: Después de guardar el modelo de datos, navegue de nuevo al catálogo. Haga clic en Crear > Informe. En el asistente de creación de informes, seleccione 'Usar Modelo de Datos Existente' y localice el modelo de datos que acaba de crear.
Configurar el Diseño del Informe: En el editor de diseño, elija el diseño de 'Tabla'. Es crucial arrastrar y soltar todas las columnas del modelo de datos en la tabla para asegurar que se incluyan en la exportación. No es necesaria una configuración de formato compleja.
Establecer Salida Predeterminada a CSV: Vaya al enlace 'Ver una Lista' en el editor de informes. En la sección 'Formatos de Salida', asegúrese de que 'CSV' esté seleccionado. Se recomienda desmarcar todos los demás formatos para simplificar la programación. Guarde el informe.
Programar el Informe para Extracción Automatizada: Encuentre su informe guardado en el catálogo y haga clic en 'Más', luego en 'Programar'. Cree un nuevo trabajo de programación. Configure la frecuencia, por ejemplo, diaria o semanalmente.
Configurar Exportación y Entrega: En la pestaña 'Salida' del trabajo de programación, especifique los detalles de la salida. Seleccione su informe y elija 'CSV' como formato. En la pestaña 'Destino', puede configurar la entrega del archivo a una ubicación de servidor de contenido (UCM) o a un servidor SFTP externo para su recuperación automatizada.
Recuperar y Preparar los Datos: Una vez que se ejecute el trabajo programado, recupere el archivo CSV generado de su destino configurado. Asegúrese de que los encabezados de las columnas coincidan con los requisitos para la ingesta en ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. El archivo ya está listo para ser cargado.

Configuración

Fuente de Datos: La consulta debe ejecutarse contra la fuente de datos 'Oracle BI EE' dentro de BI Publisher, que se conecta a las vistas de la base de datos transaccional subyacentes que soportan OTBI.
Áreas Temáticas Clave (para referencia): La lógica de la consulta se basa en datos que se encuentran principalmente en el área temática 'General Ledger - Journals Real Time'. También une lógicamente datos que se encontrarían en 'HCM - Workforce Management - Worker Assignment Real Time' para detalles de usuario y, potencialmente, en áreas temáticas de workflow para el historial de aprobaciones.
Filtrado por Rango de Fechas: Es fundamental filtrar los datos a un período manejable. La consulta incluye los parámetros :start_date y :end_date. Recomendamos extraer de 3 a 6 meses de datos para un análisis inicial. El filtro se aplica a la fecha de creación del asiento.
Filtrado por Libro Mayor: Utilice el parámetro :ledger_name para limitar la extracción a un libro mayor principal específico. Extraer para todos los libros mayores a la vez puede resultar en archivos extremadamente grandes y problemas de rendimiento.
Prerrequisitos: El usuario que crea y programa el informe debe tener los roles de BI apropiados, como 'BI Administrator' o 'BI Author'. Además, el perfil de seguridad de datos del usuario debe otorgar acceso a los libros mayores y unidades de negocio específicos que se consultan.
Programación: Para un rendimiento óptimo y para evitar afectar a los usuarios del sistema, programe la tarea de extracción para que se ejecute durante las horas de menor actividad, como por la noche.

a Consulta de ejemplo config

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

Navegar a BI Publisher: Inicie sesión en Oracle Fusion Financials. Utilice el menú Navegador para ir a Herramientas y luego seleccione Informes y Análisis. Esto abrirá el catálogo de Business Intelligence.
Crear un Nuevo Modelo de Datos: En el catálogo de BI, haga clic en el botón Crear y seleccione Modelo de Datos. Esto abrirá el editor del modelo de datos.
Definir el Conjunto de Datos de la Consulta SQL: En el editor del modelo de datos, haga clic en el icono de más en la pestaña Diagrama y seleccione Consulta SQL. En el nuevo cuadro de diálogo, asigne un nombre al conjunto de datos, por ejemplo, ProcessMind_JE_EventLog. Seleccione la Fuente de Datos apropiada, que suele ser FUSIONDB. Pegue la consulta SQL completa proporcionada en el área de texto de la Consulta SQL.
Definir Parámetros: La consulta utiliza parámetros para el rango de fechas (p_start_date y p_end_date). Oracle BI Publisher los detectará automáticamente. Debe configurarlos como parámetros de tipo Texto y establecer etiquetas fáciles de usar como 'Fecha de Inicio (AAAA-MM-DD)' y 'Fecha de Fin (AAAA-MM-DD)'.
Guardar el Modelo de Datos: Después de pegar la consulta y definir los parámetros, haga clic en Aceptar y guarde el modelo de datos en una carpeta adecuada, por ejemplo, Shared Folders/Custom/ProcessMining.
Crear el Informe: Haga clic en el botón Crear Informe en la esquina superior derecha del editor del modelo de datos. Se iniciará el asistente de creación de informes.
Configurar el Diseño del Informe: En el asistente, seleccione la opción para usar el modelo de datos actual. Elija el diseño de 'Tabla'. Arrastre y suelte todas las columnas de la fuente de datos en el área de diseño de la tabla. Desmarque la opción 'Mostrar Fila de Totales Generales'.
Guardar el Informe: Guarde el informe en la misma carpeta que el modelo de datos. Dele un nombre descriptivo como 'Informe de Registro de Eventos de Asiento Contable'.
Establecer Formato de Salida Predeterminado: Edite el informe y navegue a la pestaña 'Visualización'. En 'Formatos de Salida', asegúrese de que CSV esté seleccionado y, preferiblemente, configúrelo como el formato predeterminado. Esto asegura que la salida sea compatible para uso directo.
Ejecutar y Exportar: Abra el informe y se le pedirá que introduzca los parámetros de fecha de inicio y fin. Introduzca el rango de fechas deseado y haga clic en Aplicar. Una vez que se ejecute el informe, haga clic en el botón Exportar y elija el formato CSV para descargar el archivo de registro de eventos.
Preparar para la Carga: Abra el archivo CSV descargado. Verifique que los encabezados de las columnas coincidan con los nombres de atributos esperados (JournalEntryId, ActivityName, EventTime, etc.) y que los datos estén formateados correctamente antes de subirlos a la plataforma ProcessMind.

Configuración

Prerrequisitos: El usuario que ejecuta el informe debe tener un rol con los privilegios de seguridad de datos necesarios para acceder a los datos del Libro Mayor, como Contador General 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 usar la conexión a la base de datos de la aplicación FUSIONDB.
Parámetros de Rango de Fechas: La consulta está diseñada con los parámetros p_start_date y p_end_date para controlar la ventana de extracción de datos. Se recomienda comenzar con un período de 3 a 6 meses de datos para asegurar el rendimiento.
Filtros de Informe: Para organizaciones grandes, se recomienda encarecidamente añadir filtros directamente en la cláusula WHERE de la expresión de tabla común JournalHeaders de la consulta. Filtrar por LEDGER_ID o LEGAL_ENTITY_ID es esencial para gestionar el volumen de datos.
Consideraciones de Rendimiento: Ejecutar esta consulta contra una base de datos de producción grande puede consumir recursos significativos. Programe el informe para que se ejecute durante las horas de menor actividad para minimizar el impacto en el rendimiento del sistema.
Formato de Salida: El informe debe configurarse para generar una salida en formato de archivo CSV. Esto proporciona un formato limpio y estructurado para 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

Prerrequisitos: Asegúrese de tener Python 3 instalado junto con las librerías requests y pandas. Necesitará una cuenta de usuario para Oracle Fusion Financials con los permisos necesarios para acceder a la REST API de Asientos Contables del Libro Mayor. Obtenga la URL, el nombre de usuario y la contraseña de su instancia de Oracle Fusion.
Configuración del Script: Cree un nuevo archivo de script Python. Comience importando las librerías necesarias: requests, json, pandas y datetime.
Configuración: En el script, defina variables para sus credenciales de Oracle Fusion y la URL base. Además, establezca los parámetros para la extracción de datos, como las fechas de inicio y fin para la consulta.
Autenticación: El script utiliza Autenticación Básica. La librería requests gestiona la codificación del nombre de usuario y la contraseña en los encabezados de la solicitud.
Definir Función de Llamada a la API: Cree una función para manejar las solicitudes a la API. Esta función debe gestionar la paginación utilizando los parámetros offset y limit. Realizará un bucle, haciendo llamadas sucesivas a la API, hasta que se hayan recuperado todos los registros de asientos contables dentro del rango de fechas especificado.
Construir Consulta de API: Utilice el parámetro q en la solicitud de la API para filtrar asientos contables basándose en la LastUpdateDate. Esto permite una extracción de datos dirigida dentro de un período de tiempo específico, por ejemplo LastUpdateDate between '2023-01-01' and '2023-03-31'.
Iniciar 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 contables.
Procesar y Transformar Datos: Itere a través de cada asiento contable devuelto por la API. Para cada asiento, genere múltiples filas de eventos correspondientes a las diferentes actividades de negocio (Asiento Contable Creado, Asiento Contable Aprobado, 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 distintos.
Estructurar el Registro de Eventos: A medida que se genera cada fila de evento, almacénela como un diccionario en una lista. Esta lista se convertirá en los datos brutos de su registro de eventos.
Crear DataFrame: Una vez procesados todos los asientos contables, convierta la lista de diccionarios de eventos en un Pandas DataFrame para una manipulación más sencilla.
Finalizar Columnas: Seleccione y renombre las columnas del DataFrame para que coincidan con el esquema requerido para ProcessMind: JournalEntryId, ActivityName, EventTime, UserName, etc.
Exportar a CSV: Guarde el DataFrame final en un archivo CSV. Este archivo podrá luego ser cargado directamente en ProcessMind para su análisis.

Configuración

Credenciales: Se requiere un nombre de usuario y una contraseña válidos de Oracle Fusion para la Autenticación Básica.
URL de Instancia: La URL base de su instancia de Oracle Fusion Financials es necesaria para construir el endpoint de la API (ej., https://[your-instance].fa.us2.oraclecloud.com).
Endpoint de API: El script apunta al endpoint fscmRestApi/resources/11.13.18.05/journals para obtener los datos del Libro Mayor.
Filtro de Rango de Fechas: El script debe configurarse con una start_date y una end_date para limitar el alcance de la extracción. Para un análisis inicial, se recomienda un período de 3 a 6 meses. Para un 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 por cada llamada a la API. Un valor entre 200 y 500 es generalmente eficiente, equilibrando el número de llamadas a la API con el tamaño de cada respuesta.
Roles de Oracle Requeridos: La cuenta de usuario debe tener un rol con los privilegios necesarios para leer datos de asientos contables a través de la REST API, como Contador General 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

Navegar al Área de Trabajo de Informes y Análisis: Inicie sesión en Oracle Fusion Financials. Utilice el menú Navegador para ir a Herramientas y luego seleccione Informes y Análisis. Este es el centro neurálgico para crear y gestionar todos los análisis e informes.
Crear un Modelo de Datos de BI Publisher: En lugar de empezar con un Análisis de OTBI, es más efectivo para este tipo de extracción de registro de eventos crear un Modelo de Datos de BI Publisher directamente. Esto le permite utilizar una consulta SQL personalizada con sentencias UNION ALL. Haga clic en el botón 'Explorar Catálogo', navegue a una carpeta adecuada y elija Crear > Modelo de Datos.
Definir el Conjunto de Datos de la Consulta SQL: En el editor del Modelo de Datos, haga clic en el icono '+' para añadir un nuevo Conjunto de Datos y seleccione 'Consulta SQL'. Asigne un nombre descriptivo al conjunto de datos, por ejemplo, 'JournalEventLog'.
Introducir la Consulta SQL: Seleccione 'Oracle BI EE' como Fuente de Datos. Copie el script SQL completo de la sección Consulta a continuación y péguelo en el área de texto de la Consulta SQL. La consulta está diseñada para extraer todas las actividades y atributos requeridos en una única estructura unificada.
Definir 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, estableciendo los tipos de datos apropiados (Fecha o Texto) y valores predeterminados si es necesario. Esto permite una ejecución de informes flexible.
Crear un Informe a partir del Modelo de Datos: Después de guardar el modelo de datos, navegue de nuevo al catálogo. Haga clic en Crear > Informe. En el asistente de creación de informes, seleccione 'Usar Modelo de Datos Existente' y localice el modelo de datos que acaba de crear.
Configurar el Diseño del Informe: En el editor de diseño, elija el diseño de 'Tabla'. Es crucial arrastrar y soltar todas las columnas del modelo de datos en la tabla para asegurar que se incluyan en la exportación. No es necesaria una configuración de formato compleja.
Establecer Salida Predeterminada a CSV: Vaya al enlace 'Ver una Lista' en el editor de informes. En la sección 'Formatos de Salida', asegúrese de que 'CSV' esté seleccionado. Se recomienda desmarcar todos los demás formatos para simplificar la programación. Guarde el informe.
Programar el Informe para Extracción Automatizada: Encuentre su informe guardado en el catálogo y haga clic en 'Más', luego en 'Programar'. Cree un nuevo trabajo de programación. Configure la frecuencia, por ejemplo, diaria o semanalmente.
Configurar Exportación y Entrega: En la pestaña 'Salida' del trabajo de programación, especifique los detalles de la salida. Seleccione su informe y elija 'CSV' como formato. En la pestaña 'Destino', puede configurar la entrega del archivo a una ubicación de servidor de contenido (UCM) o a un servidor SFTP externo para su recuperación automatizada.
Recuperar y Preparar los Datos: Una vez que se ejecute el trabajo programado, recupere el archivo CSV generado de su destino configurado. Asegúrese de que los encabezados de las columnas coincidan con los requisitos para la ingesta en ProcessMind: JournalEntryId, ActivityName, EventTime, SourceSystem, LastDataUpdate, UserName, etc. El archivo ya está listo para ser cargado.

Configuración

Fuente de Datos: La consulta debe ejecutarse contra la fuente de datos 'Oracle BI EE' dentro de BI Publisher, que se conecta a las vistas de la base de datos transaccional subyacentes que soportan OTBI.
Áreas Temáticas Clave (para referencia): La lógica de la consulta se basa en datos que se encuentran principalmente en el área temática 'General Ledger - Journals Real Time'. También une lógicamente datos que se encontrarían en 'HCM - Workforce Management - Worker Assignment Real Time' para detalles de usuario y, potencialmente, en áreas temáticas de workflow para el historial de aprobaciones.
Filtrado por Rango de Fechas: Es fundamental filtrar los datos a un período manejable. La consulta incluye los parámetros :start_date y :end_date. Recomendamos extraer de 3 a 6 meses de datos para un análisis inicial. El filtro se aplica a la fecha de creación del asiento.
Filtrado por Libro Mayor: Utilice el parámetro :ledger_name para limitar la extracción a un libro mayor principal específico. Extraer para todos los libros mayores a la vez puede resultar en archivos extremadamente grandes y problemas de rendimiento.
Prerrequisitos: El usuario que crea y programa el informe debe tener los roles de BI apropiados, como 'BI Administrator' o 'BI Author'. Además, el perfil de seguridad de datos del usuario debe otorgar acceso a los libros mayores y unidades de negocio específicos que se consultan.
Programación: Para un rendimiento óptimo y para evitar afectar a los usuarios del sistema, programe la tarea de extracción para que se ejecute durante las horas de menor actividad, como por la noche.

a Consulta de ejemplo config

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

Su Template de Datos de Registro a Informe - Asiento Contable

Su Template de Datos de Registro a Informe - Asiento Contable

Registro a Informe - Atributos de Asiento Contable

Registro a Informe - Actividades de Asiento Contable

Guías de Extracción

Exportación de Informes de Oracle OTBI y BI Publisher

Pasos

Configuración

a Consulta de ejemplo config

Informe de BI Publisher con Consulta Directa al Modelo de Datos SQL

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python que utiliza 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 config

¿Listo para comenzar?

Acelere su proceso de Registro a Informe - Asiento Contable hoy mismo

Su Template de Datos de Registro a Informe - Asiento Contable

Su Template de Datos de Registro a Informe - Asiento Contable

Registro a Informe - Atributos de Asiento Contable

Registro a Informe - Actividades de Asiento Contable

Guías de Extracción

Exportación de Informes de Oracle OTBI y BI Publisher

Pasos

Configuración

a Consulta de ejemplo config

Informe de BI Publisher con Consulta Directa al Modelo de Datos SQL

Pasos

Configuración

a Consulta de ejemplo sql

Script de Python que utiliza 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 config

Valoramos su privacidad

¿Listo para comenzar?

Acelere su proceso de Registro a Informe - Asiento Contable hoy mismo