Búsquedas frecuentes
Tutoriales actualizados
La pista de auditoría es el conjunto de documentos, físicos o digitales, que guarda el rastro de cada operación de la empresa y permite reconstruirla más tarde. Se diferencia del comprobante suelto en que no es una pieza sino un encadenamiento: cada asiento remite a su factura, cada factura a su pedido y cada cambio a quién lo hizo y cuándo. Se apoya en los comprobantes, en los libros y en el historial de modificaciones de los registros. Su ausencia no se nota mientras nadie pregunta, y se nota entera el día que hay que explicar un número.
La pista de auditoría debe suministrar información que permita comprobar un movimiento en cuentas a partir de un documento o archivo.
Estos documentos pueden ser los recibos o facturas que maneja la empresa, por ejemplo.
Toda clase de documento contable, manuscrito o digital, sirve como evidencia de los movimientos de la compañía.
Mientras existan en la compañía pistas de auditoría en cantidad y calidad apropiada, existirá un buen control interno.
Una pista de auditoría simple y ordenada demuestra que la empresa mantiene una contabilidad prolija y control sobre sus actividades.
Se llama pista de auditoría suficiente a la que refleja esa claridad en las anotaciones contables de toda la actividad de la empresa.
Una pista de auditoría suficiente garantiza que no haya actividades sospechosas o fraudulentas que comprometan las actividades de la organización.
Como parte fundamental del control que debe llevarse a cabo internamente y asegurar cualquier proceso de auditoría externa, las pistas son útiles porque:
La falta de documentación que sustente o permita comparar las diferentes operaciones realizadas es un problema grave.
Sin embargo, es muy común que se cometan errores humanos en las labores de archivo y registro. De manera que, mientras existan las pruebas se pueden solucionar los problemas.
Para que los procesos realizados puedan ser eficaces, claros y llevarse a cabo rápidamente, es necesario lo siguiente:
Cuando se realiza el trabajo de auditoría se comienza por ubicar los libros y documentos donde constan los resultados o la situación final de la empresa.
A partir de allí, la empresa debe presentar cada uno de los documentos que demuestran esos resultados.
Así se puede descomponer la información más general en sus pequeñas partes.
Este procedimiento, entonces, va desde adelante hacia atrás, desde lo más grande hasta lo más pequeño (por ejemplo, las facturas y deudas por cobrar).
Cada movimiento debe estar justificado por:
Si se realiza la auditoría a través de medios digitales, estos deben cumplir con todas las normas contables y de seguridad.
El hub de Contabilidad empresarial ubica este concepto dentro de un proceso empresarial.
En Claudeforce: qué cambia cuando el CRM vive dentro de Claude vemos cómo se aplica a decisiones y tareas concretas.
EGA Futura Conta muestra cómo se refleja dentro de la Plataforma.
Y Informes y Paneles de la Plataforma lo muestra desde otra parte del sistema.
En la Plataforma de EGA Futura ERP, la pista de auditoría tiene dos ejes que se leen juntos.
Uno es el contable de siempre, que encadena cada asiento con su comprobante. El otro es el del sistema, que guarda quién tocó qué y cuándo.
La traza no se guarda en un solo lugar, porque no todas las preguntas son la misma pregunta.
El primer plano es el dato: cada cambio en un registro de negocio queda guardado con el campo que se tocó, el valor anterior y el valor nuevo.
El segundo es la configuración: cuando cambia un componente de la Org queda registrado qué se tocó, en qué categoría de gobierno cae y por qué se hizo.
El tercero es la ejecución: cada corrida de una automatización deja su resultado, su duración y, cuando algo sale mal, el texto del error.
La frase que ordena los tres es corta: el historial del registro dice qué pasó, la traza de configuración dice qué se decidió, y la de automatizaciones dice si algo falló.
El eje contable no se reemplaza: la factura sigue respaldando el asiento y el asiento sigue respaldando el saldo.
Lo que suma la Plataforma es el eslabón que en el papel quedaba afuera, que es la identidad de quien modificó el dato.
Los tres planos guardan al usuario que hizo el cambio, así que la reconstrucción llega hasta la persona y hasta el minuto.
La discusión típica no es con un inspector sino interna, y aparece cuando un importe dejó de coincidir con lo que alguien recordaba.
Con el historial a mano, la respuesta deja de ser una reconstrucción de memoria y pasa a ser una consulta: quién, cuándo, de qué valor a qué valor.
Es el mismo criterio que sostiene la auditoría contable, aplicado también al comportamiento del sistema. Quien la configura y la consulta en la Org es el administrador del sistema.
Estas son las preguntas que aparecen cuando alguien necesita reconstruir un movimiento y ya no alcanza con mirar el comprobante.
Queda el usuario que hizo el cambio, guardado como una relación al registro de esa persona y no como un texto suelto.
Junto a él quedan el campo que se tocó, el valor anterior y el valor nuevo, más la fecha y la hora del evento.
No. Los objetos que guardan la traza son tablas independientes, así que no se borran en cascada junto con el registro que auditan.
Es una decisión de diseño: una traza que desaparece junto con el dato no serviría para reconstruir nada.
El cambio de un dato es un importe, una fecha o un estado que pasó de un valor a otro dentro de un registro de negocio.
El cambio de configuración es una modificación sobre la Org misma, y queda clasificado en categorías de gobierno como Seguridad, Accesos y Permisos o Compliance.
Los dos se consultan por separado, y esa separación es la que permite responder qué pasó sin mezclarlo con qué se decidió.
Porque en la traza de automatizaciones el valor almacenado está en inglés aunque la pantalla muestre español: Exitoso se guarda como Success.
Pasa algo parecido en el historial de registros, donde los valores llevan tilde y se guardan como Creación, Modificación y Eliminación.
La regla práctica es filtrar siempre por el valor almacenado, nunca por la etiqueta.
La traza queda guardada como registros de la Org, así que se conserva mientras esos registros existan.
El plazo mínimo lo fija la normativa contable de cada país y la política interna de tu empresa, y sobre eso se define después qué se archiva y qué se mantiene a mano, con el mismo criterio de conservación que pide la auditoría contable.
El pedido rinde mucho más si trae el objeto y el período que interesan, y el campo puntual cuando la pregunta apunta a uno solo.
Con esos tres datos el informe sale acotado y se puede volver a correr todos los meses.
Esta sección es para quien escribe requerimientos sobre la Org y necesita nombrar con precisión qué traza está pidiendo.
Cada uno mira un plano distinto y no se superponen entre sí.
| Objeto | Nombre de API | Qué audita |
|---|---|---|
| Record History | EGAFutura__RecordHistory__c | El dato. Un cambio de campo en un registro de negocio |
| Setup Audit | EGAFutura__SetupAudit__c | La configuración. Un cambio sobre un componente de Setup |
| Automation Audit | EGAFutura__Automation_Audit__c | La ejecución. Una corrida de una automatización |
Es el objeto que reconstruye un cambio campo por campo.
| Campo | Tipo | Nota |
|---|---|---|
| Name | Numeración automática | Etiqueta EGA Futura ID. Lo numera la Plataforma |
| EGAFutura__EventType__c | Lista de selección | Creación, Modificación o Eliminación |
| EGAFutura__FieldLabel__c | Text(255) | La etiqueta del campo que cambió |
| EGAFutura__OldValue__c | Text(255) | El valor anterior |
| EGAFutura__NewValue__c | Text(255) | El valor nuevo |
| EGAFutura__EventDateTime__c | Date/Time | Cuándo ocurrió el evento |
| EGAFutura__User__c | Lookup a User | Quién hizo el cambio |
| EGAFutura__ParentObject__c | Text(80) | Nombre del objeto auditado |
| EGAFutura__ParentId__c | Text(18), External ID | Id del registro auditado, guardado como texto |
| EGAFutura__RecordName__c | Text(255) | Nombre del registro auditado, para leerlo sin resolver el Id |
| EGAFutura__RecordLink__c | Fórmula (Texto) | Arma el enlace al registro auditado a partir del Id |
| EGAFutura__Detail__c | Long Text Area(32768) | Detalle libre del evento |
| EGAFutura__Amount__c | Currency(16, 2) | Importe asociado al evento |
| EGAFutura__ProjectTask__c | Lookup a EGAFutura__Proyecto_Tarea_proyecto__c | Relación tipada a Tarea de proyecto |
Es el objeto que registra qué se decidió sobre la Org, con su motivo.
| Campo | Tipo | Nota |
|---|---|---|
| Name | Numeración automática | Etiqueta EGA Futura ID |
| EGAFutura__SetupComponent__c | Text(255) | Nombre del componente de Setup sobre el que se trabajó |
| EGAFutura__Action__c | Text(255) | Qué se hizo sobre ese componente |
| EGAFutura__Category__c | Lista de selección | Clasifica el cambio en diez categorías de gobierno |
| EGAFutura__ProcessedDateTime__c | Date/Time | Fecha y hora de proceso |
| EGAFutura__User__c | Lookup a User | Quién hizo el cambio |
| EGAFutura__DeveloperNotes__c | Long Text Area(32768) | Por qué se hizo |
| EGAFutura__TechnicalDetail__c | Long Text Area(32768) | Detalle técnico del cambio |
Es el objeto que dice si un proceso corrió, cuánto tardó y cómo terminó.
| Campo | Tipo | Nota |
|---|---|---|
| Name | Numeración automática | Etiqueta EGA Futura ID |
| EGAFutura__Status__c | Lista de selección | Resultado de la corrida. El valor almacenado está en inglés |
| EGAFutura__ErrorMessage__c | Long Text Area(32768) | Texto del error cuando la corrida termina fallida |
| EGAFutura__DurationMs__c | Number(18, 0) | Duración de la corrida en milisegundos |
| EGAFutura__ExecutedDateTime__c | Date/Time | Fecha y hora de ejecución |
| EGAFutura__Date__c | Date | Fecha de la corrida |
| EGAFutura__ExecutedByUser__c | Lookup a User | Quién la ejecutó. Es la relación real al usuario |
| EGAFutura__User__c | Text(255) | Usuario guardado como texto. Conviene filtrar por el Lookup |
| EGAFutura__FlowApiName__c | Text(255) | Nombre de API del Flow que corrió |
| EGAFutura__Automation_Type__c | Lista de selección | Nueve valores, todos en inglés |
| EGAFutura__EGAFutura_Automation__c | Text(255) | Nombre de la automatización de EGA Futura |
| EGAFutura__RelatedRecordId__c | Text(18) | Id del registro relacionado, guardado como texto |
| EGAFutura__Reference__c | Text Area(255) | Referencia libre de la corrida |
| EGAFutura__Autolaunched_Flow__c | Casilla de verificación | Marca que el Flow se lanza por sí solo |
| EGAFutura__Record_Triggered_Flow__c | Casilla de verificación | Marca que lo dispara un cambio en un registro |
| EGAFutura__Schedule_Triggered_Flow__c | Casilla de verificación | Marca que lo dispara una programación horaria |
| EGAFutura__Platform_Event_Triggered_Flow__c | Casilla de verificación | Marca que lo dispara un evento de plataforma |
| EGAFutura__Screen_Flow__c | Casilla de verificación | Marca que corre con pantallas, guiado por una persona |
| EGAFutura__Custom_Automation__c | Casilla de verificación | Marca que la automatización es propia de la empresa |
Estas cuatro listas ordenan las consultas sobre la traza, y en varias el valor almacenado difiere de la etiqueta que se ve.
Etiqueta y valor coinciden, y los tres llevan tilde.
| Label | Valor almacenado |
|---|---|
| Creación | Creación |
| Modificación | Modificación |
| Eliminación | Eliminación |
Acá la etiqueta va en español y el valor almacenado va en inglés.
| Label | Valor almacenado |
|---|---|
| Exitoso | Success |
| Fallido | Failed |
| Omitido | Skipped |
| Catálogo | Catalog |
Etiqueta y valor coinciden, y los dos van en inglés.
| Label | Valor almacenado |
|---|---|
| AI | AI |
| Approval | Approval |
| Email Alert | Email Alert |
| Flow | Flow |
| IoT | IoT |
| Next Best Action | Next Best Action |
| Notification | Notification |
| Other | Other |
| Prediction | Prediction |
La etiqueta va en español y el valor en inglés, salvo tres que se escriben igual en los dos idiomas.
| Label | Valor almacenado |
|---|---|
| Seguridad | Security |
| Interfaz de Usuario | User Interface |
| Automatización | Automation |
| Data | Data |
| Integración | Integration |
| Accesos y Permisos | Access & Permissions |
| Configuración | Configuration |
| Performance | Performance |
| Compliance | Compliance |
| Arquitectura | Architecture |
Hay cuatro cosas que cambian cómo se escribe un requerimiento y que ninguna fila deja ver.
La primera es por qué el registro auditado se guarda como texto.
El par formado por el objeto y el Id es lo que permite auditar cualquier objeto de la Org sin abrir un campo nuevo por cada uno, y el enlace se resuelve por el valor guardado.
La segunda es que el enlace al registro auditado es un campo fórmula, así que se calcula solo.
Un pedido que necesite un enlace armado de otra manera se escribe como cambio de esa fórmula, y no como carga de un dato.
La tercera es que la traza de automatizaciones guarda dos campos de usuario: uno es la relación real al usuario y el otro es un texto.
Cualquier informe o filtro conviene apoyarlo en la relación.
Y la cuarta es que ninguno de los tres objetos cuelga de un padre en la base de datos, así que la traza sobrevive al registro auditado.
Es lo que hace que la pista siga siendo consultable cuando el dato original ya se dio de baja. Quien la opera del lado de la Org es el administrador del sistema, y el resto de la arquitectura del producto está en las características del ERP.
Los términos del glosario que empiezan igual que este. Las demás letras se abren acá mismo, sin salir de la página.
Ventas, compras, inventario, finanzas y equipo, con la información al día y disponible desde cualquier dispositivo. Funciona en la nube, así que no hay servidores que mantener.
