Revisar el Registro de asientos

El Registro de asientos es una consola a nivel de tenant, fuera de cualquier proyecto individual, donde finanzas y contabilidad revisan los asientos de ERP de todos los proyectos y conexiones que tienen permitido ver. Mientras que el historial de contabilizaciones de ERP se limita a un proyecto al que ya tiene acceso, el Registro de asientos es la vista entre proyectos creada para un revisor que necesita ver en un solo lugar los asientos de muchos proyectos y conexiones.

El Registro de asientos está pensado primero para la revisión. Dos acciones masivas (borrar asientos simulados y reintentar los que fallaron), un Reintentar individual en el panel de detalle, la reversión y la reversión de una ejecución intercompañía completa de una sola vez le permiten actuar directamente desde la cuadrícula y el panel de detalle; la asistencia de IA le ayuda a encontrar y comprender los asientos más rápido, y las tendencias, el linaje, los totales de control, los cierres y la exportación le permiten analizar, volver a la fuente, sellar un período y extraer datos. La colaboración permite que un equipo comente, apruebe y siga un asiento en conjunto, sin poner nunca dinero en una notificación.

La consola es un único espacio de trabajo acoplado, no un conjunto de ventanas flotantes. Un riel de navegación a la izquierda abre cada pantalla (asientos, simulados, excepciones, aprobaciones, delegaciones, resumen consolidado, tendencias, totales de control, linaje, exportaciones y alertas y asistencia de IA) como un panel en el lugar, de modo que al cambiar de pantalla se intercambia lo que hay en el centro del espacio de trabajo en lugar de apilar otra ventana sobre la anterior. Al abrir un asiento, su detalle se desliza desde la derecha sin ocultar la lista en la que estaba trabajando.

Un único espacio de trabajo acoplado: el riel abre una pantalla en el centro, en el lugar, y el detalle de un asiento se abre en un panel a la derecha sin ocultar la lista.

Quién puede abrirlo

Para abrir el Registro de asientos se necesita uno de cuatro ámbitos del realm de Keycloak: erp.register.view, .operate, .approve y .admin. Son concesiones independientes, no una escalera ascendente: tener .admin no concede por sí solo lo que concede .operate, y cada acción que modifica datos o los saca de la consola verifica explícitamente su propio ámbito o ámbitos requeridos, en lugar de deducirlos de un nivel superior.

Ámbito	Concede
`erp.register.view`	Abrir el registro y revisar asientos: la cola de excepciones, la cuadrícula, las vistas de resumen consolidado, Tendencias, Linaje y Asistencia de IA. Nada de esto aplica, exporta ni notifica nada.
`erp.register.operate`	La base de todo lo que cambia el estado o sale de la consola: acciones masivas, iniciar una reversión, solicitar la aprobación de una, abrir la bandeja de aprobaciones y decidir una solicitud sobre la que tenga autoridad, ver o devolver una delegación, exportar o programar una entrega, suscribirse al resumen de Asistencia de IA y publicar un comentario, una aprobación final o un seguimiento. Las acciones que requieren `.approve` y `.admin` se verifican además de `.operate`, nunca en su lugar; vea más abajo.
`erp.register.approve`	Autoridad de aprobación sobre una reversión igual o superior al umbral de segregación de funciones del tenant, ya sea por tener este ámbito directamente o mediante una delegación activa de alguien que lo tenga, y resolver un intento de reversión atascado (`released` o `confirmed`). Conceder a otra persona una delegación de esa autoridad también requiere tener `.approve` usted mismo; usar, ver o revocar una no lo requiere. Todo ello junto con `.operate`.
`erp.register.admin`	La exportación de auditor y el perfil de lectura a una fecha (importes sin enmascarar e identidad del autor) y establecer la política de retención del tenant, cada uno junto con `.operate`. También permite eliminar o activar la programación de otro miembro.

La regla de visibilidad

Tener un ámbito erp.register.* abre la consola, pero por sí solo no hace visible ningún asiento. Un asiento es visible en el registro solo si además tiene una concesión personal de conexión sobre la conexión de ese asiento y, cuando el asiento pertenece a un proyecto, acceso a ese proyecto. Un asiento que no está vinculado a un proyecto queda controlado únicamente por la concesión de la conexión.

Es una concesión distinta del ámbito del registro descrito arriba, y se requieren ambas:

Concesión de conexión. Debe ser propietario explícito de la conexión, estar nombrado individualmente en ella o ser miembro de un grupo de seguridad nombrado en ella: las mismas concesiones que controla el Modelo de seguridad de una conexión. Una conexión configurada como All Workspace Members no concede visibilidad en el registro. Esa configuración hace que la conexión pueda ser usada por todos; no es una concesión personal, de grupo ni de propiedad, y el registro requiere específicamente una de esas.
Acceso al proyecto, para cualquier asiento que pertenezca a un proyecto: el mismo acceso que requiere el resto de su trabajo en el proyecto.

Un miembro que tiene erp.register.view pero ninguna concesión de conexión ve un registro correctamente vacío, y la consola se lo indica en lugar de parecer averiada. Una concesión de conexión o de proyecto que se revoca surte efecto en su siguiente carga de página: no hay visibilidad obsoleta que limpiar.

Qué ve según su rol

La consola es adaptable al rol: una entrada del riel o un botón de acción para el que no tiene el ámbito está oculto, no solo atenuado, por lo que el espacio de trabajo muestra únicamente lo que realmente puede hacer. Esto refleja lo que el servidor hace cumplir, sin sustituirlo:

Tiene	Ve
`erp.register.view`	Las pantallas de revisión: cola de excepciones, cuadrícula, resumen consolidado, tendencias, linaje, totales de control y asistencia de IA.
`erp.register.operate`	Agrega los botones de acción: reintentar, revertir y borrar asientos simulados.
`erp.register.approve`	Agrega la bandeja de aprobaciones, las decisiones de aprobación y la delegación.
`erp.register.admin`	Agrega la configuración de retención y la exportación de auditor sin enmascarar.

Ocultar un control es solo presentación: una comodidad para que no se le ofrezca algo que sería rechazado. El servidor sigue siendo la autoridad: cada acción que modifica datos o los saca de la consola vuelve a verificar su propio ámbito requerido, y sus concesiones de conexión y de proyecto, en el momento en que la ejecuta. Nada se permite porque el cliente mostró un botón, y nada queda realmente bloqueado solo porque el cliente ocultó uno.

La cola de excepciones

Al abrir el registro llega a la Cola de excepciones, no a la cuadrícula: los asientos con más probabilidades de requerir su atención, agrupados en cuatro categorías y mostrados por orden de prioridad:

En duda: el asiento se envió y nada confirma todavía qué fue de él.
Sin confirmar: se envió y superó el plazo en el que debía haberse confirmado.
Pendiente: un asiento asíncrono que superó el plazo en el que debía haberse resuelto.
Error: rechazado por el ERP.

Cada categoría aparece como un mosaico de recuento sobre la cola, con su total en vivo, de modo que la magnitud del trabajo se ve antes de abrir nada. Al seleccionar un mosaico se filtra la cola a esa categoría mientras los demás mosaicos siguen mostrando sus propios totales, así que cambiar a Error nunca hace que el recuento de En duda parezca vacío.

“Antigüedad” se mide con los propios temporizadores de la plataforma, no con un umbral inventado, de modo que un asiento cae en una categoría exactamente cuando la propia plataforma lo consideraría vencido. Dentro de cada categoría, los asientos más antiguos van primero.

Los asientos simulados nunca aparecen en la cola ni en sus recuentos: la cola indica cuántos se excluyeron, de modo que un recuento bajo nunca se confunda con “nada que revisar” cuando el motivo son las simulaciones. Filtrar a una categoría reduce las filas mostradas; no cambia lo que indican los recuentos de las demás categorías, así que cambiar a Error nunca hace que En duda parezca vacío.

Aquí se aplica la misma regla de visibilidad que en la cuadrícula: solo ve las excepciones de asientos vinculados a una conexión sobre la que tiene una concesión personal, en un proyecto al que puede acceder.

Reversiones aún pendientes

La lista de excepciones a través de la API, GET /erp/register/exceptions, informa también de una quinta categoría, reversal_outstanding: un asiento contabilizado cuya reversión se envió pero nunca se liquidó, porque el ERP no dio respuesta o el intento se cortó a mitad del envío. Tiene su propio recuento junto a los otros cuatro, se ordena en la parte superior junto con En duda, y cada fila nombra el intento de reversión y su estado. Ese asiento permanece en la lista hasta que se resuelve, como se describe en Reversión; no desaparece por antigüedad.

Estado de las conexiones

Un banner sobre la Cola de excepciones y las vistas de resumen consolidado (más abajo) responde una pregunta que ninguna de ellas responde por sí sola: ¿hay alguna de sus conexiones caída? Para cada conexión sobre la que tiene una concesión personal, y solo esas, muestra la última contabilización correcta y si la conexión está generando errores en este momento. Una conexión concedida que aún no tiene asientos lo indica en lugar de omitirse de la lista, y si no se puede completar la propia comprobación de estado, el banner también lo dice en lugar de informar silenciosamente de que todo está bien.

Formato de importes

Todo importe que muestra el registro (cuadrícula, resumen consolidado, totales de control, panel de detalle, cola de excepciones, bandeja de aprobaciones, Asistencia de IA y el cuadro de diálogo de reversión) se presenta como una cifra contable: separadores de miles, negativos entre paréntesis y numerales tabulares (de ancho fijo) para que una columna de importes quede alineada en el punto decimal. Los decimales dependen de la propia moneda y no de un valor fijo de dos: el JPY no muestra ninguno, el KWD muestra tres.

Los subtotales nunca se suman entre monedas. Un grupo o lote que contiene más de una moneda se divide en una fila por moneda, cada una rotulada con su propia moneda, tanto en las vistas de resumen consolidado como en los Totales de control; en ninguna parte de la plataforma se supone un tipo de cambio.
El redondeo para mostrar nunca oculta una diferencia real. Cuando el redondeo a los decimales habituales de la moneda eliminaría un dígito distinto de cero, el panel de detalle muestra el valor exacto capturado junto al redondeado. Las cifras de los Totales de control nunca se redondean, por la misma razón: una diferencia comparada con una tolerancia se mantiene con precisión completa, de modo que una diferencia real fuera de tolerancia como 0.004 no pueda mostrarse como 0.00 junto a un veredicto de “Desequilibrado”.

La cuadrícula del registro

Cambie a la cuadrícula para ver todos los asientos y no solo las excepciones: lista los asientos de todos los proyectos y conexiones que puede ver, una fila por asiento. Una barra de ámbito recorre la parte superior de la cuadrícula, donde acota lo que está viendo:

Proyecto
Entorno
Conexión
Tipo de ERP
Entidad
Fecha de contabilización
Estado
Modo de contabilización

Para crear su propio filtro de tipo de ERP, GET /erp/register/erp-types devuelve, ordenados, todos los tipos de ERP de los asientos que puede ver.

La barra de ámbito usa selectores: usted elige un proyecto, una conexión o una entidad por su nombre en una lista acotada a lo que tiene permitido ver, en lugar de escribir un identificador. Estado es de selección múltiple, de modo que puede observar varios estados a la vez.

Modo de contabilización es un conmutador de tres botones siempre visible, para que vea de un vistazo qué incluyen las cifras. En vivo muestra solo los asientos que llegaron al ERP, Simulados muestra solo los asientos de ejecuciones en modo Simular y Todos (el valor predeterminado) muestra ambos. La columna Modo de contabilización de la cuadrícula indica de qué tipo es cada fila. Las pantallas Reconcile y Resumen consolidado tienen su propio selector de Modo de contabilización con las mismas opciones, con En vivo como valor predeterminado. Cuando el modo no es En vivo, una nota junto a los totales de dinero indica que incluyen asientos simulados que nunca llegaron al ERP o, en Simulados, que ninguno llegó al ERP. Lo que haya configurado permanece visible en pantalla mientras trabaja, de modo que nunca tiene que adivinar qué está mostrando la cuadrícula en ese momento.

Acciones masivas

Desde la cuadrícula, seleccione más de un asiento y actúe sobre todos a la vez. Seleccione asientos marcando sus filas o eligiendo seleccionar todos los que coinciden con el filtro actual, lo que alcanza todos los asientos que el filtro coincide en todas las páginas, no solo los ya cargados.

Se ofrecen dos acciones:

Borrar asientos simulados: una eliminación lógica para los asientos simulados que ya no necesita conservar.
Reintentar asientos fallidos: reenviar los asientos que el ERP rechazó o que nunca se enviaron.

La vista previa del impacto

Antes de que se ejecute cualquiera de las dos acciones, PlaidCloud muestra una vista previa del impacto: cuántos asientos se ven afectados, el dinero implicado (desglosado por moneda: los importes nunca se mezclan entre monedas, y un importe no capturado se muestra en blanco, nunca como 0.00) y a qué conexiones y entidades pertenecen los asientos afectados. Todo lo de su selección que la acción no puede tocar se indica por separado, de modo que “24 de los 30 asientos seleccionados no harán nada” se ve antes de confirmar, no se descubre después.

Escribir para confirmar

Por encima de un umbral, Aplicar permanece deshabilitado hasta que escriba el importe afectado tal como aparece, de forma exacta.

El reintento solo se ejecuta sobre lo que marcó

Borrar asientos simulados puede ejecutarse con cualquiera de los dos tipos de selección: filas marcadas o todo lo que coincida con su filtro. Reintentar como acción masiva no puede: solo se ejecuta sobre los asientos que marcó individualmente. Una selección de todo el filtro no tiene una lista fija de asientos a la que ceñir el reintento, de modo que reintentar le pide que pegue de nuevo los asientos y se niega a continuar a menos que lo pegado sea exactamente lo que mostró la vista previa: los mismos asientos, sin duplicados y con el mismo recuento. Ese vínculo es lo que mantiene honesta la confirmación: el lote que confirmó es el lote que se envía.

Qué se puede reintentar

Solo se puede reintentar un asiento que el ERP rechazó o que nunca se envió. Uno que todavía está en curso, en duda o ya contabilizado no se puede reintentar desde aquí.

Cuando el ERP de la conexión lo admite, PlaidCloud consulta directamente al ERP antes de reintentar: si el ERP ya tiene el documento como contabilizado, el reintento se rechaza y se sugiere la reversión. Si el ERP no puede responder esa comprobación, el reintento se rechaza en lugar de arriesgarse: nunca adivina. Algunas conexiones no admiten esta comprobación en absoluto; para ellas, el reintento se basa en el propio rechazo registrado del asiento.

Reintentar requiere erp.register.operate y su propia concesión personal sobre la conexión de ese asiento: la misma concesión de conexión que La regla de visibilidad exige para ver el asiento.

Reintentar desde el panel de detalle

El panel de detalle de un asiento también incluye su propio botón Reintentar, junto a los controles de seguimiento: el mismo reintento, fila por fila, al que se llega sin pasar por la cuadrícula. No es de un solo clic: al abrirlo muestra la misma vista previa del impacto y, por encima del umbral, el mismo desafío de escribir para confirmar que usa la acción masiva; hay exactamente una ruta de reintento, a la que se entra desde dos lugares. El botón aparece en todas las filas para un miembro que tenga erp.register.operate; el panel nunca presupone que una fila es reintentable antes de ofrecerlo, así que una fila que resulta no ser elegible (ya contabilizada, en curso o una que el ERP ya tiene) es rechazada por la vista previa con el motivo del propio servidor, no ocultada en silencio.

Borrar asientos simulados

Borrar es una eliminación lógica: PlaidCloud registra quién lo borró y cuándo, y requiere un motivo antes de habilitar Aplicar. Elimina los asientos del almacén de vista previa de simulación y del diario de simulación propio del libro mayor; nunca toca un asiento en vivo y no hay forma de apuntarlo a uno.

La vista de asientos simulados

Asientos simulados se abre como un panel desde el riel y lista lo que hay en el almacén de simulación, en lugar de obligarle a buscar filas simuladas en la cuadrícula principal. Filtre por conexión, proyecto, entorno o id de ejecución de simulación.

Incluir borrados está desactivado de forma predeterminada, igual que el valor predeterminado del propio servidor: una fila borrada es el registro de auditoría de un borrado y se conserva brevemente por ese motivo, de modo que la vista se abre con lo que aún está en vivo en el almacén y no con su propio historial.
Borrar desde aquí sigue pasando por la misma vista previa del impacto que la acción masiva de la cuadrícula (nunca un borrado de un solo clic), acotada a lo que coincidan en ese momento los filtros de la vista.
La línea de resumen de la vista también informa de la misma cifra simulated_excluded que muestra la Cola de excepciones: cuántos asientos simulados del libro de asientos, una tabla distinta del almacén de simulación, quedan fuera de la cola porque una fila simulada nunca llegó al ERP y por tanto nunca es una excepción.

Asistencia de IA

Asistencia abre un cuadro de búsqueda, una fila de tarjetas proactivas y un panel de consejos por fila: cada cifra que contiene la calcula el propio registro, sobre sus propias concesiones en vivo; el modelo, cuando hay uno configurado, solo explica o redacta, y nunca inventa un número ni un predicado.

Pregunte con sus propias palabras

Escriba una oración (“asientos en duda de la conexión EMEA la semana pasada”) y se analiza al vocabulario de filtros propio del registro mediante una tabla fija, no mediante una llamada a un modelo: un análisis solo puede reducir las filas que la cuadrícula ya le mostraría, nunca llegar a una fila sobre la que no tiene concesión. La única función del modelo es explicar el análisis en una oración: nombra el campo que coincidió y cuántas de sus filas encuentra el filtro resultante.

Tarjetas proactivas

Siete tarjetas resumen lo que vale la pena revisar, cada una con un recuento en vivo y filas de muestra acotadas a sus propias concesiones: pendientes de cierre, casi duplicados, la brecha de neto cero intercompañía, cambiados respecto del último cierre, confirmados en el ERP, antigüedad y responsables y ya revertidos. Junto a las cifras aparece una breve oración narrativa cuando hay una conexión de LLM configurada para su espacio de trabajo; cuando no la hay, la tarjeta se muestra igualmente completa e indica por qué falta la narrativa. Un importe no capturado en una tarjeta siempre queda en blanco, nunca 0.00: la misma regla que siguen las vistas de resumen consolidado.

Consejos por fila

Elija un asiento y obtenga dos tipos de consejo, según su estado:

Un borrador de reversión, para cualquier asiento: cómo sería revertirlo, si el controlador de la conexión lo admite siquiera, el total de control con el que tendría que cuadrar y una comprobación del período. Es solo un borrador; nada aquí revierte nada.
Orientación sobre el error, para un asiento rechazado o en duda: por qué falló, si conviene reintentarlo o corregir antes los datos de origen, qué campo corregir y el riesgo de duplicado al pulsar reintentar. El mensaje de error del propio ERP es texto libre, así que se clasifica en una causa del lado del servidor en lugar de mostrárselo directamente: la misma regla que mantiene el texto libre fuera del resto del registro.

El resumen diario

Un resumen muestra, a petición, una vista previa de las tarjetas anteriores acotadas a un subconjunto relevante para el cierre (pendientes de cierre, antigüedad y responsables, casi duplicados, la brecha de neto cero intercompañía y confirmados en el ERP) tal como aparecerían si se le enviaran hoy. Un interruptor le suscribe o le da de baja; la suscripción no almacena nada más que su id de miembro, de modo que una concesión que pierda después simplemente elimina esas filas de su siguiente resumen en lugar de filtrar una vista obsoleta.

Reversión

Revertir un asiento (crear en el ERP un documento nuevo y opuesto) está disponible desde el control Revertir del panel de detalle, y directamente mediante la API para la automatización.

La elegibilidad depende del propio estado del asiento (solo se puede revertir un asiento contabilizado con un id de documento de ERP confirmado), del controlador de la conexión (Business Central, Oracle Fusion y Acumatica no admiten ninguna reversión programática, y lo indican cuando lo intenta) y de si ya hay un intento de reversión pendiente sobre él. El panel vuelve a comprobar la elegibilidad tanto al abrir Revertir como inmediatamente antes de enviar, de modo que una fila que quedó obsoleta entre tanto (otra reversión ya pendiente, por ejemplo) muestra el rechazo del propio controlador con sus propias palabras en lugar de lanzar una solicitud condenada al fracaso.
Revertir requiere erp.register.operate y está protegido por un desafío de escribir para confirmar: usted vuelve a escribir el id de documento de ERP del propio asiento, que se comprueba solo en el navegador y nunca se envía, antes de que Revertir se desbloquee: el mismo patrón de alcance del impacto que usan las acciones masivas, un aviso de seguridad y no un paso de aprobación.
Al revertir se puede redirigir opcionalmente el nuevo asiento a un período de destino distinto del de la contabilización original; se respeta en los adaptadores cuyo ERP acepta un período de contabilización explícito, y se rechaza con un error claro en los que no pueden dirigirlo. Una redirección aún puede acabar en un período distinto del solicitado: algunos adaptadores solo saben si la respetaron después del envío, así que el panel indica un período de destino solo cuando el intento ya se ha liquidado como revertido, nunca antes, y se remite al propio mensaje del servidor para cualquier otro resultado. Un cerrojo duro de base de datos impide que se envíe un segundo intento de reversión mientras haya uno pendiente, incluso tras una caída del proceso a mitad del envío; un rechazo del ERP libera ese cerrojo automáticamente, ya que no se creó nada.
Una reversión a la vez, se inicie donde se inicie. Una reversión enviada desde el Registro de asientos y otra enviada por un flujo de trabajo o por la API de reversión a nivel de proyecto comparten el mismo cerrojo, y cada una vuelve a leer el asiento una vez que lo tiene, de modo que un asiento nunca se revierte dos veces: ni por una reejecución ni por dos solicitudes simultáneas.
Una respuesta desconocida se retiene, no se adivina. Cuando el ERP agota el tiempo de espera, devuelve un error de servidor o responde de una manera que PlaidCloud no reconoce, la reversión se registra como in_doubt en lugar de rechazada, y el cerrojo permanece retenido. Un documento de reversión cuenta como la reversión solo cuando refleja el original (misma entidad y moneda, con fecha no anterior, con el débito y el crédito de cada línea intercambiados); cualquier otra cosa permanece en duda para que usted la compruebe.
Una reversión que queda pending o in_doubt, con resultado desconocido, permanece así hasta que se liquide. Para Workday y Dynamics 365 Finance & Operations, PlaidCloud busca en el ERP una reversión in_doubt la próxima vez que se intente revertir ese asiento, y la liquida según lo que encuentre. Una reversión pending en esas conexiones, y cualquier reversión sin liquidar en todas las demás, se resuelve con los controles de resolución del panel, que requieren erp.register.approve además de .operate: una persona comprueba el ERP directamente y registra lo que encontró, ya sea Liberar (allí no se creó nada, de modo que el libro mayor queda intacto y el asiento vuelve a ser reversible) o Marcar como revertido (existe un documento de reversión, con su id), que es la única forma de liberar ese cerrojo. Marcar una reversión como confirmed es permanente; el producto no ofrece forma de deshacerlo.

Segregación de funciones

Una reversión igual o superior al umbral configurado de su tenant requiere aprobación antes de continuar, y la aprobación es algo que hace un aprobador, no un nombre que el remitente proporcione en la solicitud.

Autor≠verificador. El miembro que envía la reversión no puede ser también su aprobador, ni puede ser su propio autorizador de emergencia.
Medido por magnitud. El umbral compara el tamaño de la reversión sin importar el signo: revertir un crédito se mide igual que revertir un débito.
Las reversiones recientes cuentan para el umbral. Una ventana móvil suma las propias reversiones de un remitente en la misma conexión, de modo que una reversión grande no pueda dividirse en varias más pequeñas para quedar por debajo. Los importes se suman por magnitud, no se compensan: una reversión negativa y una positiva no se anulan entre sí.
Falla de forma cerrada. Si no se puede verificar una reversión previa de la ventana (un importe o una moneda no capturados, por ejemplo), la reversión requiere aprobación en lugar de omitir la comprobación.
El aprobador debe estar calificado. Necesita erp.register.approve, o una delegación activa de alguien que lo tenga, y su propia concesión sobre la conexión que se revierte. Si menos de dos miembros tienen ambas cosas, las reversiones iguales o superiores al umbral se rechazan en lugar de dejarlas pasar.
La emergencia (break-glass) sigue siendo la única vía en la que el remitente nombra directamente quién autorizó una anulación: una emergencia genuina, decidida por un autorizador independiente de la cadena operativa (que tiene erp.register.admin pero no .operate ni .approve, además de su propia concesión sobre la conexión), y cada anulación se registra de forma permanente en la pista de auditoría.
Un rechazo no dice por qué. Ya sea que una solicitud no tenga aprobador calificado, la haya decidido la persona equivocada o nunca se haya abierto, la reversión se rechaza con el mismo mensaje; es deliberado, para que un rechazo no pueda usarse para averiguar quién tiene qué rol o concesión. El motivo real está en la pista de auditoría, no en el error.
Una reversión de ejecución necesita una aprobación por tramo, no una para la ejecución. Revertir una ejecución intercompañía completa de una sola vez no recibe una única aprobación a nivel de ejecución: cada tramo necesita la suya, porque una aprobación está vinculada a un asiento, una conexión y un aprobador con una concesión allí, y no hay un único nombre al que vincular todos los tramos de una ejecución.
Las reversiones pasan por el registro. Mientras la segregación de funciones está activada, una reversión solicitada mediante la API de reversión de ERP a nivel de proyecto (la vía que usan un proyecto, una función definida por el usuario o una cuenta de servicio) se rechaza antes de que nada llegue al ERP, con un mensaje que indica revertirla desde el Registro de asientos. Un asiento para el que el registro no conserva detalle de captura tampoco puede revertirse allí y debe corregirse en el ERP. Las contabilizaciones no se ven afectadas, y Business Central, Oracle Fusion y Acumatica siguen dando su propio motivo: que no admiten la reversión.

La activación de la segregación de funciones y la definición de su umbral las configura PlaidCloud para su tenant; todavía no hay un interruptor en la consola.

La bandeja de aprobaciones

Cuando el umbral lo exige, Solicitar aprobación, que se ofrece junto a Revertir en el panel de detalle, enruta la reversión a todos los aprobadores que tengan una concesión personal vigente sobre esa conexión. No hay nadie a quien dirigirla; la concesión de la conexión es el enrutamiento. Los aprobadores trabajan la cola desde Aprobaciones en el riel: una bandeja de solicitudes que esperan su decisión y una segunda cola con las solicitudes que ellos mismos han enviado. Cada fila muestra el importe, la entidad y el período del asiento, y cuánto tiempo lleva esperando, de modo que decidir nunca implica salir de la cola para buscar algo antes. Aprobar o Rechazar toma un único motivo, que se registra con la decisión.

Una aprobación está vinculada exactamente a aquello para lo que se concedió (el asiento, su conexión, el motivo indicado y el período de destino) y no puede reutilizarse para una reversión distinta, un motivo distinto o un período de destino modificado; una solicitud modificada necesita una aprobación nueva. Solo puede haber una solicitud abierta sobre un asiento a la vez, y una aprobación se consume en el momento en que se canjea. Tras cada aprobación sigue una breve retención durante la cual el aprobador o el remitente aún pueden cancelarla; cuando pasa la retención, la reversión puede ser ya un documento en el ERP, y nada lo deshace. Todo se vuelve a comprobar en el momento en que la reversión se aplica realmente (el rol del aprobador, el acceso de ambas partes a la conexión y el mínimo de dos aprobadores del tenant), de modo que una aprobación concedida antes no sobrevive a que el aprobador pierda el acceso entre tanto.

Delegación

Un aprobador puede delegar su autoridad de aprobación en otro miembro durante un período limitado, desde el panel Delegaciones del riel, útil cuando un aprobador no va a estar disponible y las reversiones aún necesitan decidirse. Conceder una delegación requiere erp.register.approve; usar una, ver las propias y devolver una solo requieren .operate, ya que el delegado típico no tiene el rol de aprobador en absoluto: ese es el sentido de delegar en él.

La autodelegación se rechaza, igual que un par recíproco (delegar en alguien que ya delegó en usted) o cualquier cadena más larga: ninguna se respeta, de modo que dos miembros no pueden hacer que, sin que nadie lo note, las decisiones del otro cuenten como cobertura para ambos, ni directamente ni a través de un paso intermedio. Autor≠verificador sigue aplicándose a través de una delegación: un delegado no puede aprobar una solicitud de la persona que delegó en él, ni puede aprobar una solicitud propia en ninguno de los dos casos. Cada decisión que toma un delegado se registra en la pista de auditoría como tomada bajo la autoridad del aprobador que delega, no como si el delegado tuviera el rol de pleno derecho.

Escalación

Una aprobación que pasa demasiado tiempo sin decisión genera una alerta, para que no envejezca en silencio en una cola que nadie vigila. A cada destinatario solo se le informa de las solicitudes que él mismo podría decidir realmente: el correo de escalación de un colega nunca nombra una solicitud enrutada a las concesiones de otra persona, y la alerta no lleva importe ni texto libre, la misma minimización que siguen el resto de las notificaciones del registro.

Ejecuciones intercompañía

Una ejecución intercompañía es el grupo de asientos (sus tramos) realizados juntos para un cierre, identificado por el día de cierre y la secuencia estampados en ellos en ese momento, nunca por la ejecución del flujo de trabajo que los produjo. (Ese id de ejecución del flujo de trabajo se conserva aparte en el historial propio del libro mayor y puede sobrevivir al sello de cierre de un asiento, por lo que no es una forma segura de identificar una ejecución). Liste las ejecuciones, abra una para ver sus tramos cuadrados y emparejados, y revierta la ejecución completa como una única acción gobernada.

Por ahora solo es accesible mediante la API (GET /erp/register/runs, GET /erp/register/runs/{run_day}/{sequence} y POST /erp/register/runs/{run_day}/{sequence}/reverse); todavía no hay una pantalla en la consola.

Neto cero y emparejamiento

Abra una ejecución y sus tramos se cuadran de dos maneras, ambas acotadas a las conexiones sobre las que tiene una concesión personal: la misma regla de visibilidad que en el resto del registro, de modo que una ejecución que abarca conexiones que solo ve en parte se informa como parcialmente visible y no como desequilibrada.

Neto cero, por moneda: un veredicto equilibrado, desequilibrado o indeterminado, con las entidades detrás de cada neto desglosadas. Una moneda no se considera cuadrada a menos que se haya capturado cada tramo: un tramo sin capturar hace que toda la moneda sea indeterminada, nunca un neto calculado solo sobre lo que se llegó a medir.
Emparejamiento asocia cada tramo por pagar con su contrapartida por cobrar mediante una clave de emparejamiento que el flujo de trabajo de contabilización estampa en ambos antes de enviar cualquiera de los dos. Un par coincidente suma cero en una moneda; todo lo demás lleva un motivo con nombre: ningún tramo de contrapartida visible para usted, un importe no capturado, un neto que realmente no es cero o multimoneda, que se informa y nunca se cuadra, ya que en ninguna parte de la plataforma hay un tipo de cambio.

Una ejecución de más de 200 tramos es demasiado grande para cuadrarse o emparejarse en una sola respuesta: ambas devuelven indeterminado en lugar de calcularse sobre un fragmento truncado de la ejecución, de modo que una ejecución grande nunca informa de un saldo falso, ni de una contrapartida faltante falsa, causados solo por su tamaño.

Revertir una ejecución

Revierta todos los tramos de una ejecución en una sola acción, desde POST /erp/register/runs/{run_day}/{sequence}/reverse.

La elegibilidad se comprueba de antemano para cada tramo. Todo lo que se puede saber de antemano (estado, compatibilidad del adaptador, un intento pendiente, su propia concesión de conexión) rechaza la ejecución completa antes de que una sola solicitud llegue a un ERP.
Lo que no se puede saber de antemano se informa después, por tramo. El estado en vivo del ERP y de la autorización puede cambiar durante la ejecución, de modo que una ejecución puede terminar parcialmente revertida aunque nada pareciera mal en la comprobación previa. No se compensa nada automáticamente: contabilizar más documentos para deshacer un fallo parcial es una escritura más arriesgada que la que falló. Una ejecución parcial se corrige tramo por tramo, igual que una reversión individual.
Volver a ejecutar una reversión de ejecución es como se termina una parcial. Los tramos que un intento anterior ya revirtió se apartan en lugar de rechazarse, de modo que reintentar solo revierte lo que realmente queda.
La segregación de funciones se aplica por tramo, no al total de la ejecución. Cuando la política de SoD de su tenant está en vigor, cada tramo necesita su propia aprobación antes de que la ejecución envíe nada, con cualquier importe, no solo por encima del umbral. Es deliberadamente conservador: el requisito de un tramo solo puede determinarse en el momento en que se envía (una ventana móvil contra la fragmentación que cuenta los propios tramos de la ejecución a medida que se revierten, y una lectura de comprobación en vivo del ERP que puede fallar), así que exigir todas las aprobaciones de antemano es lo que impide que una ejecución revierta la mitad de sus tramos antes de descubrir a mitad de camino que el resto también necesita aprobación.
Las acciones masivas cubren toda la ejecución en una sola llamada. POST /erp/register/runs/{run_day}/{sequence}/approval-requests abre una solicitud de aprobación para cada tramo sobre el que puede actuar el remitente, y POST .../approval-decisions decide cada tramo para el que un aprobador está calificado: una llamada en cada caso en lugar de una solicitud y una decisión por tramo (20 llamadas para una ejecución habitual de 10 tramos). El modelo de seguridad subyacente no cambia: cada tramo sigue recibiendo su propia aprobación, vinculada a ese asiento, su conexión, el motivo y el período de destino, y el aprobador sigue necesitando su propio acceso a la conexión de cada tramo; un tramo que no puede autorizar simplemente queda pendiente para alguien que sí pueda, nunca se incluye por arrastre. Un solicitante sin ninguna autoridad de aprobación se rechaza de plano, sin enterarse de qué tramos tienen solicitudes abiertas. Los resultados llegan por tramo, de modo que una ejecución parcialmente autorizable informa exactamente qué tramos se decidieron y cuáles quedaron pendientes, y por qué.
La emergencia (break-glass) no está disponible para una reversión de ejecución. Es una anulación entre dos personas de un solo asiento, y aplicar la autorización de un testigo a toda una ejecución la multiplicaría por el número de tramos. Use en su lugar la emergencia por tramo desde POST /entries/{ledger_id}/reverse.
Las ejecuciones de más de 200 tramos no pueden revertirse como una sola acción. Revíertalas por partes desde la lista de asientos.

Tendencias

Tendencias muestra la tasa de errores y la latencia, agrupadas por conexión o tipo de ERP, además de la distribución de códigos de motivo de reversión: cada cifra, incluido cada denominador, se calcula sobre sus propias concesiones en vivo. Una conexión sin nada terminal en la ventana muestra un guion largo como tasa de errores, nunca 0%, ya que un cero perfecto colocaría a una conexión que nadie usa en lo más alto de una lista de salud. La latencia es una muestra acotada de los asientos terminales más recientes, rotulada como muestra y no presentada como si abarcara toda la ventana. Los motivos de reversión aparecen solo como sus códigos estructurados: el motivo en texto libre que escribió una persona nunca se agrupa ni se muestra aquí.

Linaje

Linaje permite pasar de un asiento a la ejecución del flujo de trabajo que lo produjo, y de ahí al documento en el propio ERP. Búsquelo por id de ejecución o por el id de libro de un asiento: al consultar por id de libro, la ejecución se resuelve primero a través de sus propias concesiones, de modo que un asiento de una conexión que no puede ver no resuelve nada en lugar de exponer de qué ejecución proviene. Cuando PlaidCloud puede verificar la forma de la URL del documento del ERP para ese adaptador, el linaje incluye un enlace directo al documento; cuando no puede, o el asiento nunca se confirmó, indica cuál de esos es el motivo en lugar de adivinar un enlace. La clave de negocio del ERP sigue sin aparecer nunca aquí: la clave de linaje es el run_id del flujo de trabajo, y el puntero al ERP es confirmation_id, igual que en el resto del registro.

Cierres

Solicitar un cierre sella un período (para una o más conexiones y entidades) en una instantánea inmutable en un punto del tiempo: todo lo que el registro sabía de esos asientos en ese momento, conservado aunque las filas en vivo se reintenten, se reviertan o se borren más adelante. Está pensado para un período contable bloqueado en el que necesita un registro defendible e inalterable en lugar de lo que muestre hoy la cuadrícula en vivo. Solicitar o leer un cierre solo es accesible por ahora mediante la API; todavía no hay una pantalla en la consola para solicitar o explorar uno.

Solicitar un cierre (erp.register.operate) es una acción administrativa de todo el tenant, no personal: las conexiones y entidades que nombre son exactamente las que se sellan, con independencia de sus propias concesiones de conexión. Volver a cerrar un período ya cerrado nunca es destructivo: siempre genera una revisión nueva, numerada por separado, en lugar de sobrescribir la anterior.

Los cierres se materializan por sí solos. Solicitar un cierre no lo sella de inmediato: un trabajo en segundo plano recorre automáticamente todos los cierres pendientes, según una programación diaria, y escribe su instantánea de Iceberg sin ninguna acción adicional de su parte. Si un recorrido no puede completar un cierre determinado (por una caída del almacén, por ejemplo), ese cierre se marca como fallido en lugar de quedar atascado, y se recoge y reintenta automáticamente en el recorrido del día siguiente; nunca se omite en silencio. Un cierre inusualmente grande (que abarque más de unos 500,000 asientos) es el único caso que no se resolverá por sí solo de esta manera: el recorrido se niega a sellarlo en una sola pasada y se necesita la ayuda de PlaidCloud para cerrarlo en lotes más pequeños. Es un caso límite poco frecuente en la mayoría de los períodos de informe.

Una vez materializado un cierre, su lectura aplica las reglas habituales del registro, resueltas de nuevo en vivo en cada lectura en lugar de incorporarse a la instantánea al sellarla: solo ve filas de las conexiones y proyectos sobre los que tiene una concesión vigente. A diferencia de la cuadrícula en vivo, que muestra el dinero y la identidad del autor a cualquier espectador que pueda ver la fila, las cifras de un cierre se enmascaran a menos que tenga erp.register.admin: la misma regla que aplica Exportar. Un cierre también informa de su propio recuento de llegadas tardías: asientos enviados o modificados después de la marca de agua máxima del cierre y que, por tanto, nunca se capturaron en el sello; solo es visible solicitando un cierre nuevo para el mismo período, ya que nada reabre uno antiguo.

Exportar

Exportaciones y alertas es donde el registro sale de la consola como archivo o como notificación, y la única superficie donde los controles de PlaidCloud dejan de aplicarse en cuanto los bytes salen. Generar una exportación o programar una entrega requiere erp.register.operate; abrir el registro para mirarlo no.

Descargar ahora

Exporte el registro que está viendo como un CSV compatible con Excel o como JSON, generado en el momento con sus propias concesiones en vivo. Se aplican dos perfiles de enmascaramiento según su rol:

erp.register.operate obtiene el perfil estándar, enmascarado: se omiten el dinero y la identidad del autor.
erp.register.admin obtiene el perfil de auditor, el único que incluye el dinero y la identidad del autor sin enmascarar.

Toda exportación sigue las mismas reglas que el resto del registro: natural_key nunca aparece, los campos de texto libre (comentarios, valores de dimensiones y de worktags) se excluyen por completo y no solo se depuran, y un importe no capturado queda en blanco, distinguido de uno enmascarado, para que un blanco nunca se lea como “no se contabilizó nada” cuando en realidad significa “su rol no ve esto”.

Programar una entrega

Cree una programación: un filtro, una cadencia, un formato y una lista de destinatarios por miembro, o una conexión de Slack para una notificación sin ningún contenido de filas. Se ofrecen dos tipos:

Exportar: una entrega recurrente en CSV o JSON del registro filtrado.
Alerta: una notificación activada por una de tres condiciones: un asiento en vivo fallido, una autorización que envejece o la reversión de un asiento. Obtenga una vista previa de lo que un activador coincidiría actualmente para usted antes de suscribirse a él.

El archivo de cada destinatario se genera con sus propias concesiones en vivo en el momento del envío, no con las del propietario de la programación: dos destinatarios de la misma programación pueden recibir dos archivos distintos, y un destinatario que haya perdido desde entonces el rol de exportación, haya perdido todas las concesiones de conexión, haya sido deshabilitado o no tenga una dirección registrada se omite individualmente con un motivo indicado, en lugar de descartarse en silencio. Solo el propietario de la programación o alguien con erp.register.admin puede eliminar o activar la programación de otra persona.

Retención

Configure durante cuánto tiempo conserva el registro tres tipos de historial: el detalle de la carga útil capturada, los asientos simulados y la pista de auditoría, cada uno como un número de días, para todo el tenant, y requiere erp.register.admin. Cada campo se escribe en cada llamada; un campo omitido borra ese horizonte en lugar de dejarlo sin cambios, y un tenant sin configurar lo conserva todo (cada horizonte aparece como nulo, no como un valor predeterminado oculto).

El recorrido de retención que aplica esta política ahora se ejecuta automáticamente, una vez al día, para todo el tenant: el mismo mecanismo de trabajos periódicos que también impulsa las exportaciones y alertas programadas, lleva los asientos vencidos a la cola de excepciones y expira los asientos simulados antiguos.

Vistas de resumen consolidado

Resumen consolidado se abre como un panel desde el riel. Agrupe el registro por ejecución, período o conexión para ver subtotales y un resumen de estado en lugar de filas individuales; la agrupación es un control segmentado en la parte superior del panel, de modo que cambia entre Por ejecución, Por período y Por conexión en el lugar sin volver a abrir nada.

El dinero en blanco sigue en blanco. Un asiento sin importe capturado (todos los asientos de SAP, un asiento nacido terminal o uno escrito antes de que existiera esta función) no aporta nada a un subtotal y nunca se muestra como 0.00. Cada grupo indica con palabras si se capturaron todos los asientos que contiene, algunos no o ninguno.
Las monedas nunca se mezclan en un solo total. PlaidCloud no hace ninguna conversión de moneda extranjera, así que un grupo que abarca más de una moneda recibe una fila por moneda en lugar de una cifra única mezclada; consulte Formato de importes.
Una lista de grupos limitada sigue totalizando correctamente. Si una agrupación produce más grupos de los que muestra la vista, la línea de totales sigue cubriendo todos los grupos, no solo los mostrados, y lo indica.

El banner de Estado de las conexiones también aparece en esta vista.

Totales de control

Totales de control se abre como un panel desde el riel, sobre las mismas conexiones y entidades a las que La regla de visibilidad ya le limita. Agrupa los asientos en lotes e indica, para cada uno, un veredicto de tres estados (Equilibrado, Desequilibrado o Indeterminado) con el motivo indicado por el propio servidor, nunca una palabra suelta.

Indeterminado es una respuesta real, no un visto bueno suave. Un lote está Equilibrado solo cuando se midió cada fila y sus grupos cuadran. Una ventana vacía, un importe no capturado, un adaptador que envía y se olvida, o una exploración interrumpida antes de leer todo el lote devuelven Indeterminado, con el motivo detallado; nunca un verde por defecto.
El dinero está en blanco, nunca en cero. Los totales de origen y contabilizados de un grupo, y su diferencia, quedan en blanco siempre que el importe no se capturó o confirmó: la misma regla que siguen las vistas de resumen consolidado, porque un 0.00 fabricado subestimaría un lote no medido a la vez que parecería una cifra autorizada.
Los grupos son por moneda y entidad, y nunca se suman entre sí. PlaidCloud no hace ninguna conversión de moneda extranjera, así que un lote que abarca más de una moneda o entidad enumera los totales propios de cada grupo en paralelo en lugar de mezclarlos; consulte Formato de importes para ver cómo se presentan esas cifras.
Las filas anteriores a la captura tienen su propio grupo (no batch id). Un asiento escrito antes de que existiera la captura de lotes no puede reagruparse en un lote que nunca lo contuvo, por lo que se muestra como su propia fila en lugar de incorporarse a otro o descartarse.

La misma lectura cubre también dos preguntas relacionadas: la preparación para el cierre del período, por entidad y período, que degrada a Indeterminado (no a un falso Bloqueado) para un grupo del que la plataforma aún no tiene cifras, como una fila anterior a la captura en un cierre de transición; y la desviación de confirmación, informada por documento y no por grupo, porque dos documentos que se desvían en direcciones opuestas dentro del mismo grupo de moneda y entidad pueden cuadrar en el total y ocultar ambos.

El panel de detalle

El panel de detalle se acopla a la derecha del espacio de trabajo, de modo que la lista sigue visible mientras lee un asiento. Ábralo desde el icono de lupa de una fila, pulsando Intro en la fila seleccionada o haciendo doble clic en la fila. Está organizado en pestañas:

Pestaña	Muestra
Diario	Las líneas de débito y crédito del asiento, leídas como las leería un contador. Consulte La pestaña Diario.
Solicitud/respuesta	La solicitud saliente y la respuesta del ERP, filtradas para la minimización de datos (vea más abajo).
Errores	Cualquier error devuelto por el ERP o por el paso de contabilización.
Cronología	Los estados del asiento en orden, desde el envío hasta su estado actual.
Relacionados	El asiento original y su reversión, vinculados entre sí, cuando existe una.
Auditoría	Un registro de solo lectura de la actividad sobre este asiento. Escaso por ahora; consulte La pestaña Auditoría más abajo.
Comentarios	Comentarios en hilos sobre este asiento, con @mención por id de miembro. Consulte Colaboración.
Aprobación final	El estado de revisión actual del asiento (Revisado, Despejado o Requiere seguimiento) con su historial completo. Consulte Colaboración.

La pestaña Diario

La pestaña Diario lee un asiento como lo haría un contador: sus líneas de débito y crédito por cuenta, en lugar de la carga útil bruta de la solicitud.

Solo las columnas que cada ERP realmente captura. La pestaña muestra los campos que envía un sistema determinado y ningún otro: un asiento de Acumatica muestra su subcuenta, mientras que un sistema que nunca envía una no muestra ninguna columna de subcuenta vacía; no tiene que recorrer columnas que nunca contendrán nada.
Las dimensiones y los worktags van debajo de cada línea. El detalle analítico de una línea (sus dimensiones o sus worktags de Workday) aparece bajo la línea a la que pertenece, no apretado en columnas adicionales en la parte superior.
Una suma por moneda con una comprobación de saldo exacta. Cada moneda se suma por separado; la comprobación nunca mezcla monedas y nunca redondea a cero un asiento desequilibrado, de modo que un desequilibrio genuino se muestra como la cifra que es y no desaparece en un 0.00.
Un adaptador que no captura detalle de líneas lo indica. Cuando un controlador, como el de SAP local, no registra un desglose por línea, la pestaña lo indica claramente en lugar de mostrar una cuadrícula vacía que podría malinterpretarse como “sin líneas”.

Clasificación con el teclado

En la Cola de excepciones, las teclas de flecha arriba y abajo recorren un asiento tras otro con el panel de detalle siguiendo la selección, de modo que puede realizar toda una pasada de clasificación desde el teclado, leyendo el detalle de cada asiento por turno sin recurrir al ratón.

La cuadrícula principal conserva deliberadamente la selección con el ratón, Intro y el doble clic: su selección de varias filas es lo que impulsa las acciones masivas como reintentar y borrar asientos simulados, así que las teclas de flecha allí mueven la selección en lugar de barrer el panel por todas las filas.

Colaboración

Trabaje un asiento con su equipo sin salir del registro: comente con @mención, registre una aprobación final o siga una conexión o una ejecución para conocer su actividad futura.

Los comentarios son notas en hilos y en texto sin formato sobre un asiento, desde su pestaña Comentarios. Mencione con @ a un colega por id de miembro y se le notifica, si puede ver el asiento en ese momento; esa comprobación se rehace al enviar, nunca se presupone por quién fue mencionado.
La aprobación final registra uno de tres estados (Revisado, Despejado o Requiere seguimiento) con una nota opcional, y conserva el historial completo de quién estableció qué y cuándo. Es un registro, no una puerta: nada bloquea actualmente un asiento ni una reversión por su estado de aprobación final.
Seguir una conexión o una ejecución, con dos interruptores separados, para recibir notificaciones de la actividad de cualquiera de las dos en adelante.

Publicar un comentario, una aprobación final o un seguimiento requiere erp.register.view y .operate; leerlos requiere solo .view.

Minimización de datos

El registro está diseñado para mostrar lo que un revisor necesita para confirmar que un asiento ocurrió, sin sacar a la superficie los datos sensibles que un paso de contabilización manejó para lograrlo.

Las cargas útiles de solicitud y respuesta se permiten por lista, por adaptador. Un campo solo aparece si se ha clasificado explícitamente como seguro de conservar. Los números de cuenta bancaria, los números de ruta, los IBAN, los identificadores fiscales y otros identificadores personales se eliminan antes de que usted vea la carga útil.
La clave de negocio del ERP se omite por completo. Puede incrustar el nombre de un proveedor u otro token de referencia, por lo que nunca llega al registro, incluida la Asistencia de IA: la misma lista de permitidos que decide lo que usted ve decide lo que un prompt de modelo puede ver, y un valor de clave natural en cualquier parte de esa carga útil se rechaza de plano en lugar de enviarse. Identifique una fila por su id de libro y use confirmation_id como el puntero propio del ERP al documento: el mismo campo que el historial de contabilizaciones de ERP llama confirmation_id.
Los campos de texto libre se depuran por patrones al leerse, y se excluyen por completo (no solo se depuran) del resumen, de cualquier prompt de modelo de IA y de cualquier exportación. La depuración por patrones detecta una forma como un IBAN o un identificador fiscal; no puede detectar el nombre de un proveedor escrito en un memo, y por eso todo lo que sale de la consola como archivo elimina esos campos por completo en lugar de depender solo de la depuración.

La pestaña Auditoría

La pestaña Auditoría es solo de visualización. Su detalle es intencionalmente escaso en esta versión, porque el vocabulario de auditoría subyacente aún no se ha clasificado: espere que se complete a medida que ese trabajo llegue, no que cambie la forma en que lee el resto del panel.

Todo lo demás de esta página (la cola de excepciones, el estado de las conexiones, las vistas de resumen consolidado, las acciones masivas, el reintento de una sola fila, la reversión, los totales de control, la Asistencia de IA, las tendencias, el linaje, los cierres, la colaboración y la exportación) funciona hoy.