Carga de Asientos Contables No Oficiales - Modos de Operación

Módulo: Contabilidad Tipo: Process Estado: Planificado Fecha: 2026-01-06

Referencia Arquitectural: Este documento implementa el patrón de modos de operación para operaciones CRUD. Para contexto general, consultar:
/docs/features/contabilidad/libro-diario-modos-process.md
/docs/features/contabilidad/consolidacion-informes-contables.md

Descripción General

Propósito

El sistema de carga de asientos contables (operaciones Alta, Modificación y Baja) debe soportar dos modos de operación que permiten al usuario trabajar con asientos no oficiales o asientos oficiales de manera aislada. Estos modos determinan si las operaciones afectan el ambiente no oficial o el ambiente oficial.

Problema de Negocio

Actualmente el sistema de carga de asientos opera únicamente con datos oficiales. Los contadores y analistas contables necesitan:

Registrar asientos no oficiales antes de oficializarlos, sin afectar la contabilidad oficial
Trabajar con asientos preliminares en un ambiente separado para validar su impacto
Capacitar personal nuevo sin riesgo de alterar datos oficiales
Experimentar con cierres de ejercicio y ajustes complejos antes de aplicarlos oficialmente
Prevenir pérdida accidental de datos al cambiar de modo durante operaciones de edición o eliminación

Valor de Negocio

Seguridad operativa: Permite experimentar sin riesgo de corromper datos oficiales
Planificación financiera: Posibilidad de simular asientos y evaluar su impacto antes de oficializarlos
Capacitación efectiva: Personal puede aprender sin afectar la contabilidad real
Control de calidad: Validación exhaustiva de asientos antes de oficializarlos
Integridad de datos: Prevención de pérdida accidental de datos al cambiar de modo
Flexibilidad operativa: Usuarios pueden trabajar en paralelo en ambiente no oficial y oficial según necesidad
Trazabilidad: Identificación clara del origen de cada asiento (no oficial u oficial)

Contexto en el Flujo Contable

El sistema de carga de asientos es el punto de entrada principal para el registro contable. Se utiliza en:

Registro de asientos manuales de apertura y cierre
Ajustes contables del ejercicio
Correcciones de asientos anteriores
Reclasificaciones contables
Asientos de regularización

Los modos de operación permiten que estos procesos se puedan simular completamente antes de afectar la contabilidad oficial.

Modos de Operación

Modo No Oficial

Descripción: Todas las operaciones (Alta, Modificación, Baja) afectan exclusivamente el ambiente de asientos no oficiales.

Casos de Uso:

Registrar asientos preliminares de cierre de ejercicio antes de ejecutarlos oficialmente
Trabajar con ajustes contables complejos sin afectar registros oficiales
Capacitar personal nuevo en el uso del sistema
Experimentar con diferentes escenarios contables
Validar que nuevos asientos balancean correctamente (Debe = Haber)
Desarrollar plantillas de asientos antes de usarlas en oficial

Datos Afectados:

Asientos contables en ambiente no oficial
Movimientos contables (líneas de asiento) en ambiente no oficial
Contador global de numeración de asientos (compartido con modo Oficial)

Datos NO Afectados:

Asientos contables oficiales
Movimientos del ambiente oficial
Cualquier información que alimente estados financieros oficiales

Comportamiento Esperado:

El formulario indica visualmente mediante color que se está trabajando en ambiente no oficial
Los asientos creados se almacenan en el ambiente no oficial
La numeración de asientos sigue la secuencia del ambiente no oficial
Los cambios NO afectan reportes oficiales (Balance, Mayor, Diario oficial)
Los asientos no oficiales pueden ser consultados solo en reportes de modo no oficial

Modo Oficial

Descripción: Todas las operaciones (Alta, Modificación, Baja) afectan exclusivamente el ambiente oficial de la organización. Este es el modo por defecto y el utilizado para la contabilidad formal.

Casos de Uso:

Registro de asientos contables definitivos
Modificación de asientos ya oficializados
Eliminación de asientos incorrectos en la contabilidad oficial
Operaciones contables para cumplimiento fiscal y normativo
Registro de asientos para estados financieros formales

Datos Afectados:

Asientos contables oficiales
Movimientos contables (líneas de asiento) oficiales
Numeración de asientos en secuencia oficial

Datos NO Afectados:

Asientos contables no oficiales
Movimientos del ambiente no oficial
Datos experimentales o de capacitación

Comportamiento Esperado:

El formulario indica visualmente mediante color que se está trabajando en ambiente oficial
Los asientos creados se almacenan en el ambiente oficial
La numeración de asientos sigue la secuencia oficial
Los cambios afectan inmediatamente los reportes oficiales
Los asientos oficiales alimentan estados financieros, balances, y reportes regulatorios
Operaciones requieren permisos específicos para ambiente oficial

Comportamiento por Operación

Alta (Crear Nuevo Asiento)

Cambio de Modo Permitido Libremente

Justificación: Durante la creación de un nuevo asiento, no existe aún información guardada en ningún ambiente. El usuario está únicamente capturando datos en el formulario sin persistirlos. Por lo tanto, puede cambiar de modo sin riesgo de pérdida de datos o inconsistencias.

Comportamiento:

El usuario puede cambiar entre modo No Oficial y Oficial en cualquier momento
Los datos capturados en el formulario se mantienen intactos al cambiar de modo
NO se requiere confirmación para cambiar de modo
NO se recargan ni reinician los datos del formulario
El modo seleccionado determina dónde se guardará el asiento cuando el usuario presione "Guardar"
El indicador visual de modo debe ser claro y visible durante toda la captura

Flujo Típico:

Usuario abre formulario de Alta de Asiento
Usuario comienza a capturar datos (fecha, cuentas, importes, comentarios)
Usuario decide cambiar de modo (ejemplo: de Oficial a No Oficial)
Sistema cambia el indicador visual de modo
Usuario continúa capturando datos sin interrupciones
Usuario puede cambiar de modo nuevamente si lo desea
Al presionar "Guardar", el asiento se crea en el modo actualmente seleccionado

Ejemplo Práctico:

Un contador está por registrar un asiento de ajuste. Comienza a capturar las líneas en modo Oficial, pero a mitad de la captura se da cuenta de que quiere validar primero los montos. Cambia a modo No Oficial sin perder ningún dato ya capturado, termina de ingresar las líneas, guarda el asiento en No Oficial, lo revisa en el Libro Diario No Oficial, y si está correcto, lo vuelve a crear en modo Oficial.

Modificación (Editar Asiento Existente)

Cambio de Modo Requiere Confirmación y Recarga de Datos

Justificación: Durante la modificación, el formulario está cargado con información de un asiento existente de un ambiente específico (no oficial u oficial). Si el usuario cambia de modo accidentalmente, podría intentar guardar datos de un asiento de un ambiente en otro ambiente diferente, causando:

Duplicación de asientos en ambiente incorrecto
Pérdida del asiento original
Corrupción de secuencias de numeración
Inconsistencias en la auditoría

Por esta razón, cambiar de modo durante una modificación es una operación crítica que requiere confirmación explícita y recarga total de datos.

Comportamiento:

Si el usuario intenta cambiar de modo, el sistema muestra un diálogo de confirmación
El diálogo advierte claramente que todos los cambios NO guardados se perderán
Si el usuario confirma el cambio:
- Se descarta el asiento actualmente cargado
- Se limpia completamente el formulario
- Se cambia el modo
- Se recarga el formulario desde el nuevo modo seleccionado
- Si existe un asiento con el mismo número en el nuevo modo, se carga
- Si NO existe asiento con ese número en el nuevo modo, el formulario queda vacío (modo Alta)
Si el usuario cancela el cambio:
- Se mantiene el modo original
- El asiento sigue cargado sin cambios
- El usuario puede continuar modificando normalmente

Flujo con Confirmación:

Usuario está modificando un asiento en modo Oficial
Usuario hace clic en selector de modo (cambia a No Oficial)
Sistema muestra diálogo: "¿Está seguro de cambiar de ambiente? Todos los cambios no guardados se perderán y el formulario se recargará."
Opciones: [Confirmar] [Cancelar]

Si usuario presiona [Confirmar]:

Sistema descarta datos del formulario actual
Sistema cambia el indicador visual a modo No Oficial
Sistema busca si existe asiento con el mismo número en ambiente no oficial
Si existe: carga el asiento no oficial en el formulario
Si NO existe: deja el formulario vacío (modo Alta en No Oficial)

Si usuario presiona [Cancelar]:

Sistema mantiene modo Oficial
Sistema mantiene asiento actual cargado
Usuario continúa modificando sin interrupciones

Advertencias Importantes:

El mensaje de confirmación debe ser claro y específico
Debe resaltar que los cambios NO guardados se perderán
Debe indicar claramente el modo actual y el modo destino
El usuario debe entender que se recargará el formulario con datos del nuevo modo

Ejemplo Práctico:

Un contador está modificando el asiento oficial N° 125 (ajuste de inventario). Lleva varios minutos editando líneas y montos pero NO ha guardado aún. Accidentalmente hace clic en el selector de modo y cambia a "No Oficial". El sistema muestra: "⚠️ ¿Cambiar de modo OFICIAL a NO OFICIAL? Los cambios en el asiento 125 que no haya guardado se perderán. El formulario se recargará buscando el asiento 125 en el ambiente de NO OFICIAL. ¿Desea continuar?". El contador lee la advertencia, se da cuenta del error, presiona "Cancelar" y continúa editando en modo Oficial sin perder su trabajo.

Baja (Eliminar Asiento Existente)

Cambio de Modo Requiere Confirmación y Recarga de Datos

Justificación: Similar a la modificación, durante la eliminación el formulario muestra un asiento existente de un ambiente específico. Si el usuario cambia de modo accidentalmente, podría eliminar un asiento diferente al que pretendía eliminar.

Comportamiento:

Si el usuario intenta cambiar de modo, el sistema muestra un diálogo de confirmación
El diálogo advierte que se descargará el asiento actual y se buscará en el nuevo modo
Si el usuario confirma el cambio:
- Se descarta el asiento actualmente cargado
- Se limpia el formulario
- Se cambia el modo
- Se recarga el formulario desde el nuevo modo seleccionado
- Si existe un asiento con el mismo número en el nuevo modo, se carga para eliminación
- Si NO existe asiento con ese número en el nuevo modo, se informa al usuario
Si el usuario cancela el cambio:
- Se mantiene el modo original
- El asiento sigue cargado para eliminación
- El usuario puede continuar con la eliminación normalmente

Flujo con Confirmación:

Usuario carga asiento N° 50 en modo Oficial para eliminarlo
Usuario verifica los datos del asiento a eliminar
Usuario hace clic en selector de modo (cambia a No Oficial)
Sistema muestra diálogo: "¿Está seguro de cambiar de ambiente? El asiento actual se descargará y se buscará el asiento 50 en el otro ambiente. ¿Desea continuar?"
Opciones: [Confirmar] [Cancelar]

Si usuario presiona [Confirmar]:

Sistema descarta asiento oficial cargado
Sistema cambia el indicador visual a modo No Oficial
Sistema busca asiento N° 50 en ambiente no oficial
Si existe: carga el asiento no oficial en el formulario para eliminación
Si NO existe: muestra mensaje "No existe asiento N° 50 en este ambiente"

Si usuario presiona [Cancelar]:

Sistema mantiene modo Oficial
Sistema mantiene asiento N° 50 oficial cargado
Usuario puede proceder a eliminarlo normalmente

Prevención de Errores:

El mensaje de confirmación debe especificar qué asiento se descargará
Debe indicar qué asiento se buscará en el nuevo modo
Debe advertir claramente que son asientos diferentes aunque tengan el mismo número
El usuario debe entender que los asientos no oficiales y oficiales son independientes

Ejemplo Práctico:

Un analista contable necesita eliminar el asiento no oficial N° 88 que fue un experimento fallido. Carga el asiento 88 en modo No Oficial y revisa que es el asiento correcto. Antes de eliminarlo, accidentalmente cambia el selector de ambiente. El sistema muestra: "⚠️ ¿Cambiar de ambiente? El asiento 88 actual se descargará y se buscará el asiento 88 en el otro ambiente (son asientos diferentes). ¿Desea continuar?". El analista se da cuenta de que eso cargaría un asiento completamente diferente, presiona "Cancelar", y procede a eliminar el asiento 88 no oficial correctamente.

Reglas de Negocio

RN-CAP-001: Aislamiento de Datos por Modo

Descripción: Los datos de asientos contables deben estar completamente aislados entre ambientes (no oficial y oficial). Un asiento creado, modificado o eliminado en un modo NO afecta al otro modo bajo ninguna circunstancia.

Justificación: La separación estricta garantiza que las operaciones no oficiales no contaminen la contabilidad oficial, y que los usuarios puedan experimentar sin riesgo.

Condiciones:

Cada modo opera sobre una fuente de datos independiente
Un asiento con número N en modo No Oficial es completamente distinto de un asiento con número N en modo Oficial
Las operaciones de Alta, Modificación y Baja afectan exclusivamente el ambiente del modo activo
No existe sincronización automática entre modos

Comportamiento Esperado:

Usuario crea asiento 100 en modo No Oficial → NO se crea asiento en modo Oficial
Usuario modifica asiento 50 en modo Oficial → asiento 50 No Oficial (si existe) NO se modifica
Usuario elimina asiento 25 en modo No Oficial → asiento 25 de Oficial (si existe) NO se elimina
Las consultas de asientos (listados, búsquedas) muestran únicamente asientos del modo activo

Validación:

El sistema debe verificar que cada operación CRUD afecte exclusivamente el ambiente correcto
La auditoría debe registrar claramente en qué modo se ejecutó cada operación
Los reportes contables (Diario, Mayor, Balance) deben consultar el modo correcto

RN-CAP-002: Comportamiento en Alta - Cambio Libre de Modo

Descripción: Durante la operación de Alta (creación de nuevo asiento), el usuario puede cambiar de modo en cualquier momento sin perder los datos capturados en el formulario y sin necesidad de confirmación.

Justificación: En Alta no existe información persistida en ningún ambiente. El formulario contiene únicamente datos temporales que el usuario está capturando. No hay riesgo de corrupción de datos ni de afectar información existente.

Condiciones para Cambio Libre:

El formulario está en modo Alta (no está cargado un asiento existente)
El usuario está capturando un nuevo asiento
NO se ha presionado el botón "Guardar" aún

Comportamiento al Cambiar de Modo:

El indicador visual de modo cambia inmediatamente
Los datos del formulario se mantienen sin alteraciones:
- Fecha del asiento
- Comentario general
- Todas las líneas capturadas (cuenta, debe, haber, detalle, operación)
NO se muestra diálogo de confirmación
NO se recargan datos desde ninguna fuente
El usuario puede continuar capturando o modificando líneas
Al presionar "Guardar", el asiento se crea en el modo actualmente seleccionado

Ejemplo de Uso:

Usuario en este ambiente:
- Captura línea 1: Cuenta 1.1.01 Debe $5000
- Captura línea 2: Cuenta 4.1.01 Haber $5000

Usuario cambia a modo NO OFICIAL (SIN confirmación):
- Indicador visual cambia a color naranja/amarillo
- Líneas capturadas se mantienen visibles e intactas
- Usuario agrega línea 3: Cuenta 5.1.01 Debe $500
- Usuario modifica línea 1: cambia importe a $5500

Usuario cambia nuevamente a modo OFICIAL (SIN confirmación):
- Indicador visual cambia a color verde/azul
- Las 3 líneas se mantienen con todos los cambios realizados
- Usuario presiona "Guardar"
- Resultado: Asiento se crea en este ambiente

Beneficios:

Permite al usuario experimentar con el modo antes de guardar
Evita interrupciones durante la captura de datos
Reduce fricción y mejora experiencia de usuario
NO requiere reingreso de datos ya capturados

Validación:

El sistema debe permitir cambio instantáneo de modo sin bloqueos
El formulario debe mantener integridad de datos capturados
El modo final al momento de guardar determina el ambiente destino

RN-CAP-003: Comportamiento en Modificación - Confirmación + Recarga

Descripción: Durante la operación de Modificación (edición de asiento existente), cambiar de modo requiere confirmación explícita del usuario y provoca la recarga completa del formulario con datos del nuevo modo seleccionado.

Justificación: En Modificación, el formulario contiene datos de un asiento existente en un ambiente específico. Cambiar de modo sin control podría causar:

Guardar datos de un asiento de un ambiente en otro ambiente
Pérdida del asiento original
Duplicación de asientos
Corrupción de secuencias de numeración
Inconsistencias en auditoría

Por seguridad, el cambio de modo debe ser explícito y controlado.

Condiciones para Activar esta Regla:

El formulario está en modo Modificación
Se ha cargado un asiento existente para edición
El usuario tiene cambios guardados o no guardados en el formulario
El usuario intenta cambiar el selector de modo

Flujo al Intentar Cambiar de Modo:

Usuario hace clic en selector de modo
Sistema intercepta el cambio y muestra diálogo de confirmación con:
- Advertencia clara de que cambios NO guardados se perderán
- Indicación del modo actual y modo destino
- Número del asiento actualmente cargado
- Botones: [Confirmar] [Cancelar]
Si usuario presiona [Confirmar]:
- Sistema descarta datos del formulario actual
- Sistema cambia el modo al modo seleccionado
- Sistema actualiza indicador visual de modo
- Sistema busca asiento con el mismo número en el nuevo modo
- Si existe: carga el asiento del nuevo modo en el formulario
- Si NO existe: muestra mensaje informativo y deja formulario en estado Alta
Si usuario presiona [Cancelar]:
- Sistema mantiene el modo original
- Sistema mantiene el asiento cargado sin cambios
- El selector de modo vuelve a su posición original
- Usuario puede continuar editando normalmente

Mensaje de Confirmación Recomendado:

⚠️ ¿Cambiar de modo [MODO_ACTUAL] a [MODO_DESTINO]?

El asiento N° [NUMERO] actualmente cargado se descartará.
Todos los cambios NO guardados se perderán.

El formulario se recargará buscando el asiento N° [NUMERO]
en el ambiente de [MODO_DESTINO].

¿Desea continuar?

[Confirmar]  [Cancelar]

Casos Especiales:

Asiento existe en nuevo modo: Se carga en el formulario para edición
Asiento NO existe en nuevo modo: Se muestra mensaje "No se encontró asiento N° [NUMERO] en este ambiente" y el formulario queda en estado Alta en el nuevo modo
Cambios guardados recientemente: Aplica la misma confirmación (el usuario podría querer seguir editando)

Validación:

El sistema debe interceptar el cambio de modo ANTES de ejecutarlo
El diálogo de confirmación debe ser modal (bloquear otras acciones)
La recarga de datos debe ser completa (no parcial)
La auditoría debe registrar el cambio de modo y la recarga

RN-CAP-004: Comportamiento en Baja - Confirmación + Recarga

Descripción: Durante la operación de Baja (eliminación de asiento existente), cambiar de modo requiere confirmación explícita del usuario y provoca la recarga del formulario con el asiento correspondiente del nuevo modo seleccionado.

Justificación: En Baja, el formulario muestra un asiento existente que está por ser eliminado. Si el usuario cambia de modo accidentalmente, podría eliminar un asiento diferente al que pretendía eliminar. Aunque ambos asientos tengan el mismo número, son asientos completamente distintos en ambientes diferentes.

Condiciones para Activar esta Regla:

El formulario está en modo Baja
Se ha cargado un asiento existente para eliminación
El usuario está revisando el asiento antes de eliminarlo
El usuario intenta cambiar el selector de modo

Flujo al Intentar Cambiar de Modo:

Usuario hace clic en selector de modo
Sistema intercepta el cambio y muestra diálogo de confirmación con:
- Advertencia de que se descargará el asiento actual
- Indicación de que se buscará un asiento diferente en el nuevo modo
- Número del asiento y descripción de ambos ambientes
- Botones: [Confirmar] [Cancelar]
Si usuario presiona [Confirmar]:
- Sistema descarta asiento cargado actualmente
- Sistema cambia el modo al modo seleccionado
- Sistema actualiza indicador visual de modo
- Sistema busca asiento con el mismo número en el nuevo modo
- Si existe: carga el asiento del nuevo modo en el formulario para eliminación
- Si NO existe: muestra mensaje "No existe asiento N° [NUMERO] en este ambiente" y vuelve a listado de asientos
Si usuario presiona [Cancelar]:
- Sistema mantiene el modo original
- Sistema mantiene el asiento cargado para eliminación
- El selector de modo vuelve a su posición original
- Usuario puede proceder a eliminar el asiento original normalmente

Mensaje de Confirmación Recomendado:

⚠️ ¿Cambiar de modo [MODO_ACTUAL] a [MODO_DESTINO]?

El asiento N° [NUMERO] de [MODO_ACTUAL] se descargará.
Se buscará el asiento N° [NUMERO] en el ambiente de [MODO_DESTINO].

IMPORTANTE: Es muy probable que NO exista el asiento N° [NUMERO]
en el modo [MODO_DESTINO] porque la numeración es compartida y este
número ya está asignado al modo [MODO_ACTUAL].

¿Desea continuar?

[Confirmar]  [Cancelar]

Casos Especiales:

Asiento existe en nuevo modo: Se carga en el formulario para eliminación
Asiento NO existe en nuevo modo: Se muestra mensaje "No se encontró asiento N° [NUMERO] en este ambiente. No hay nada que eliminar." y se redirige al usuario al listado de asientos
Usuario confirma eliminación después de cambio: El asiento eliminado es el del nuevo modo (NO el original)

Validación:

El sistema debe interceptar el cambio de modo ANTES de ejecutarlo
El diálogo de confirmación debe destacar que son asientos diferentes
La recarga debe ser completa y mostrar claramente el asiento del nuevo modo
La auditoría debe registrar el cambio de modo previo a la eliminación

RN-CAP-005: Numeración Compartida y Consecutiva

Descripción: Ambos modos (No Oficial y Oficial) comparten la misma secuencia de numeración de asientos. El contador es único y consecutivo, independientemente del modo en que se cree cada asiento.

Contexto Técnico:

Actualmente el sistema usa una sola base de datos con una única secuencia de numeración en la tabla ejerci (campo nroasi)
Con la nueva funcionalidad, los datos se separan en dos bases de datos:
- Modo Oficial: database → asientos almacenados en tabla items
- Modo No Oficial: database_p → asientos almacenados en tabla items
PERO el contador de numeración ejerci.nroasi es único y compartido
Los asientos no oficiales y oficiales toman números consecutivos del mismo contador

Justificación: La numeración compartida garantiza que:

No hay duplicación de números de asiento
La numeración es única y secuencial en todo el ejercicio contable
Se evitan conflictos al cambiar entre modos
La trazabilidad es clara (cada número de asiento es único)
Futuras funcionalidades de "oficialización" de asientos no oficiales son más simples

Comportamiento de Numeración:

Contador Único:
- Existe un solo contador ejerci.nroasi por ejercicio contable
- Tanto Modo No Oficial como Modo Oficial incrementan este contador
- La numeración es consecutiva global: 1, 2, 3, 4, 5...
Asignación de Números:
- Usuario crea asiento en Modo Oficial → Toma siguiente número disponible
- Usuario crea asiento en Modo No Oficial → Toma siguiente número disponible
- El número asignado es consecutivo sin importar el modo
Implicación Importante:
- Un número de asiento existe en UN SOLO modo a la vez
- Si el asiento N° 5 existe en Modo Oficial, NO existe un asiento N° 5 en Modo No Oficial
- Si el asiento N° 8 existe en Modo No Oficial, NO existe un asiento N° 8 en Modo Oficial

Ejemplos:

Escenario 1: Numeración Compartida Consecutiva

Contador global: Empieza en 0

Usuario crea asiento en Modo Oficial → Asiento N° 1 (Oficial)
Usuario crea asiento en Modo No Oficial → Asiento N° 2 (No Oficial)
Usuario crea asiento en Modo Oficial → Asiento N° 3 (Oficial)
Usuario crea asiento en Modo No Oficial → Asiento N° 4 (No Oficial)
Usuario crea asiento en Modo Oficial → Asiento N° 5 (Oficial)

Resultado:
- Modo Oficial: Asientos 1, 3, 5
- Modo No Oficial: Asientos 2, 4
- Contador actual: 5 (el siguiente asiento será el 6)

Escenario 2: NO Hay Duplicación de Números

NO es posible que exista:
- Asiento N° 10 en Modo Oficial
- Asiento N° 10 en Modo No Oficial (simultáneamente)

Cada número es único y pertenece a UN SOLO asiento en UN SOLO modo.

Escenario 3: Mezcla de Creación

Día 1: Contador en 0
- Usuario crea 5 asientos en Modo Oficial → Asientos 1, 2, 3, 4, 5 (Oficial)

Día 2: Contador en 5
- Usuario crea 3 asientos en Modo No Oficial → Asientos 6, 7, 8 (No Oficial)

Día 3: Contador en 8
- Usuario crea 2 asientos en Modo Oficial → Asientos 9, 10 (Oficial)
- Usuario crea 2 asientos en Modo No Oficial → Asientos 11, 12 (No Oficial)

Resultado final:
- Modo Oficial: Asientos 1, 2, 3, 4, 5, 9, 10
- Modo No Oficial: Asientos 6, 7, 8, 11, 12
- Contador actual: 12

Implicaciones:

Al cambiar de modo durante Modificación o Baja, casi siempre NO existirá asiento con el mismo número en el nuevo modo (porque ese número pertenece a un asiento en el modo original)
Los reportes contables deben consultar solo el modo correspondiente, pero la numeración será discontinua (tendrá "huecos")
La auditoría debe registrar el modo junto con el número de asiento
Los usuarios deben comprender que los números NO son consecutivos dentro de un modo (pueden tener saltos)
Al ver un listado de asientos en un modo, la numeración puede tener huecos (ej: 1, 3, 5, 7, 10, 15...)

Validación:

El sistema debe calcular el siguiente número del contador global (NO por modo)
El contador se incrementa independientemente del modo activo
La consulta de asientos debe filtrar por modo activo
Al guardar, se asigna el próximo número del contador global

RN-CAP-006: Validaciones según Modo

Descripción: Las validaciones contables se aplican por igual en ambos modos, sin distinción. Un asiento debe cumplir todas las reglas de negocio independientemente de si se crea en modo No Oficial u Oficial.

Justificación: El propósito del modo No Oficial es permitir experimentación en un ambiente seguro, NO permitir la creación de asientos inválidos o desbalanceados. Todas las validaciones contables deben aplicarse para garantizar que los asientos no oficiales tengan la misma calidad que los oficiales.

Validaciones que Aplican en Ambos Modos:

Balance Debe = Haber:
- La suma de todos los importes al Debe debe igualar la suma de todos los importes al Haber
- Esta es la validación fundamental de la partida doble
- Aplica en No Oficial y Oficial sin excepciones
Fecha Dentro del Periodo Contable:
- La fecha del asiento debe estar dentro de un ejercicio contable activo
- NO se permiten asientos con fechas de ejercicios cerrados
- Aplica en ambos modos
Cuentas Contables Válidas:
- Todas las cuentas utilizadas deben existir en el plan de cuentas
- Las cuentas deben ser imputables (nivel más bajo de la jerarquía)
- Las cuentas NO deben estar inactivas o eliminadas
- Aplica en ambos modos
Importes Válidos:
- Los importes deben ser numéricos y mayores a cero
- NO se permiten importes negativos en Debe o Haber
- Aplica en ambos modos
Asiento con al Menos 2 Líneas:
- Un asiento debe tener mínimo 2 líneas (una al Debe, una al Haber)
- NO se permiten asientos de una sola línea
- Aplica en ambos modos
Información Obligatoria:
- Fecha del asiento
- Al menos un comentario (general o por línea)
- Ejercicio contable asociado
- Aplica en ambos modos

Comportamiento al Violar Validaciones:

El sistema debe mostrar mensajes de error claros
NO se debe permitir guardar el asiento hasta que se corrijan los errores
Los mensajes de error son idénticos en ambos modos
La validación ocurre antes de persistir datos

Validaciones que NO Difieren por Modo:

❌ NO se relajan validaciones en modo No Oficial
❌ NO se permiten asientos desbalanceados en No Oficial
❌ NO se omiten validaciones de fechas en No Oficial
❌ NO se permiten cuentas inválidas en No Oficial

Beneficios:

Los asientos no oficiales son de igual calidad que los oficiales
Se pueden copiar asientos no oficiales a oficial sin re-validar
El modo No Oficial se convierte en un ensayo general real
Se detectan errores antes de oficializar

Validación del Sistema:

Las mismas reglas de validación deben aplicarse en ambos modos
Los mensajes de error deben ser consistentes
La lógica de validación debe ser reutilizada (NO duplicada)

RN-CAP-008: Auditoría por Modo

Descripción: Todas las operaciones de Alta, Modificación y Baja de asientos contables deben ser auditadas, registrando claramente en qué modo se ejecutó cada operación.

Justificación: La auditoría es crítica para:

Rastreabilidad de cambios en contabilidad oficial
Seguimiento de operaciones no oficiales para análisis de uso
Identificación de errores y correcciones
Cumplimiento normativo y regulatorio
Detección de accesos no autorizados

El modo de operación es un dato fundamental de auditoría porque determina el impacto de la operación.

Información Obligatoria a Auditar:

Para toda operación (Alta, Modificación, Baja) se debe registrar:

Datos de la Operación:
- Tipo de operación: Alta | Modificación | Baja
- Modo de operación: No Oficial | Oficial
- Fecha y hora exacta de la operación
- Número del asiento afectado
- Ejercicio contable
Datos del Usuario:
- ID del usuario que ejecutó la operación
- Nombre completo del usuario
- Modo de operación (No Oficial u Oficial)
- Dirección IP de origen
- Sesión o token JWT utilizado
Datos del Asiento (antes y después cuando aplique):
- Para Alta: Estado final del asiento creado
- Para Modificación: Estado antes y después de la modificación
- Para Baja: Estado del asiento eliminado
Contexto de la Operación:
- Sucursal/Caja desde donde se ejecutó
- Schema de base de datos utilizado
- Conexión de base de datos utilizada (oficial o no oficial)

Formato de Registro de Auditoría:

[TIMESTAMP] [USUARIO] [MODO] [OPERACION] [ASIENTO] [RESULTADO]

Ejemplo Alta en No Oficial:
2026-01-06 14:35:22 | Juan Pérez (ID: 45) | NO OFICIAL | ALTA | Asiento N° 125 | ÉXITO

Ejemplo Modificación en Oficial:
2026-01-06 15:10:05 | María González (ID: 12) | OFICIAL | MODIFICACIÓN | Asiento N° 50 | ÉXITO | Cambios: línea 3 importe $5000 → $5500

Ejemplo Baja en No Oficial:
2026-01-06 16:45:30 | Carlos Ruiz (ID: 78) | NO OFICIAL | BAJA | Asiento N° 88 | ÉXITO

Operaciones Especiales a Auditar:

Cambio de Modo durante Modificación/Baja:
- Registrar que el usuario cambió de modo
- Registrar si confirmó o canceló el cambio
- Registrar qué asiento se descargó y cuál se cargó
Intentos de Acceso Denegado:
- Registrar intentos de acceso al formulario sin el permiso requerido
- Registrar usuario y timestamp del intento
Errores de Validación:
- Registrar asientos que no se pudieron guardar por errores de validación
- Útil para detectar problemas recurrentes

Consulta de Auditoría:

Los usuarios con permisos adecuados deben poder consultar la auditoría filtrando por:

Modo de operación (No Oficial, Oficial, Todos)
Tipo de operación (Alta, Modificación, Baja)
Usuario
Rango de fechas
Número de asiento

Retención de Registros de Auditoría:

Los registros de auditoría de modo Oficial deben retenerse según normativa contable (mínimo 5-10 años)
Los registros de auditoría de modo No Oficial pueden tener retención menor (ejemplo: 1-2 años)
NO se deben eliminar registros de auditoría bajo ninguna circunstancia durante el periodo de retención

Validación:

El sistema debe registrar auditoría ANTES de confirmar la operación al usuario
Si falla el registro de auditoría, la operación debe revertirse (rollback)
La auditoría debe estar en una tabla separada, NO junto a los datos de asientos

Frontend (Perspectiva de Negocio)

Vistas

Formulario de Carga de Asientos Contables:

Propósito: Permitir al usuario crear, modificar o eliminar asientos contables seleccionando el modo de operación apropiado
Ubicación: Menú Contabilidad → Carga de Asientos
Modos de Apertura: Alta, Modificación, Baja

Selector de Modo:

Control visual mediante colores e iconos distintivos (sin texto adicional)
Debe ser prominente y fácilmente identificable
Debe estar disponible en todo momento durante la operación
Debe mostrar claramente el ambiente activo mediante color

Indicador Visual de Modo Activo:

Debe ser altamente visible mediante color distintivo e icono
El ambiente se indica visualmente sin texto adicional
Sugerencias:
- Modo No Oficial: Color naranja o amarillo con icono de laboratorio/no oficial
- Modo Oficial: Color verde o azul con icono de certificado/oficial
Debe estar presente en:
- Encabezado del formulario
- Junto al selector de modo
- Cerca del botón de guardar (último recordatorio)

Diálogo de Confirmación de Cambio de Modo:

Modal que aparece al intentar cambiar de modo durante Modificación o Baja
Debe bloquear toda interacción hasta que el usuario confirme o cancele
Debe destacar visualmente la advertencia (icono de alerta, texto claro)
Debe tener dos botones claramente diferenciados: "Confirmar" y "Cancelar"

Interacciones del Usuario

Seleccionar modo inicial:
- Al abrir el formulario de Alta, el usuario selecciona en qué modo desea trabajar
- El sistema muestra el modo seleccionado de forma destacada
Cambiar de modo durante Alta:
- El usuario puede cambiar el selector de modo en cualquier momento
- El cambio es instantáneo sin confirmación
- Los datos del formulario se mantienen intactos
Cambiar de modo durante Modificación:
- El usuario hace clic en el selector de modo
- El sistema muestra diálogo de confirmación con advertencia
- El usuario puede confirmar (recarga formulario) o cancelar (mantiene modo actual)
Cambiar de modo durante Baja:
- Similar a Modificación
- El usuario hace clic en el selector de modo
- El sistema muestra diálogo de confirmación
- El usuario puede confirmar (carga asiento del nuevo modo) o cancelar (mantiene modo actual)
Guardar asiento:
- Al presionar "Guardar", el asiento se crea/modifica/elimina en el modo actualmente activo
- El sistema muestra confirmación incluyendo el modo donde se guardó
Consultar asientos del modo actual:
- El listado de asientos muestra únicamente asientos del modo seleccionado
- El usuario puede cambiar el modo para ver asientos del otro ambiente
- Al cargar un asiento para modificación o baja, se carga del modo activo

Permisos

Permisos Requeridos para Funcionalidad:

Permiso	Descripción	Impacto en UI
Permiso de acceso al formulario (existente en sidebar)	Permite acceder al formulario de asientos contables	Sin este permiso, el menú lateral no muestra la opción de asientos

Comportamiento de Acceso:

Todos los usuarios con acceso al formulario pueden usar ambos modos (No Oficial y Oficial)
No hay permisos adicionales o granulares por modo
El selector de modo está disponible para todos los usuarios con acceso
La restricción de acceso se hace a nivel de formulario completo, no por modo individual
Los permisos existentes de CRUD (Alta, Modificación, Baja) aplican por igual en ambos modos

Estados de UI

Estado Inicial (Modo Alta):

Formulario vacío esperando captura de datos
Selector de modo habilitado (disponible para todos los usuarios con acceso)
Indicador visual muestra modo por defecto (sugerido: Oficial)
Botón "Guardar" habilitado al completar datos válidos

Estado Cargando Asiento (Modificación/Baja):

Formulario muestra indicador de carga mientras obtiene datos
Selector de modo deshabilitado temporalmente hasta que cargue el asiento
Al terminar carga, selector se habilita con el modo del asiento cargado

Estado Durante Cambio de Modo (Modificación/Baja):

Diálogo de confirmación modal en primer plano
Formulario de fondo atenuado (deshabilitado)
Dos opciones claras: Confirmar o Cancelar
Hasta que el usuario elija, no puede interactuar con el formulario

Estado Confirmado el Cambio (Recargando):

Diálogo de confirmación se cierra
Indicador de carga mientras busca asiento en nuevo modo
Al encontrar asiento (o no): formulario se actualiza con datos del nuevo modo
Selector de modo muestra el nuevo modo activo

Estado de Validación con Errores:

Mensajes de error visibles junto a los campos con problemas
Botón "Guardar" deshabilitado hasta corregir errores
Los errores son idénticos en modo No Oficial y Oficial (mismas validaciones)

Estado Guardado Exitoso:

Mensaje de confirmación indicando: "Asiento N° [NUMERO] guardado exitosamente"
El color de la página indica el ambiente donde se guardó
Opción de crear nuevo asiento o volver al listado

Backend (Perspectiva de Datos de Negocio)

Entidades de Negocio

Asiento Contable:

Representa un registro contable que agrupa movimientos relacionados
Cumple la partida doble (Debe = Haber)
Atributos principales:
- Número de asiento (secuencial por modo)
- Fecha del asiento
- Ejercicio contable
- Comentario general
- Modo de origen (No Oficial u Oficial)
- Estado del asiento (Activo, Anulado)

Línea de Asiento (Movimiento Contable):

Representa un movimiento individual dentro de un asiento
Puede ser un débito o un crédito a una cuenta específica
Atributos principales:
- Cuenta contable afectada
- Importe al Debe (si aplica)
- Importe al Haber (si aplica)
- Detalle/concepto del movimiento
- Operación asociada (si aplica)
- Relación con el asiento contenedor

Modo de Operación:

Categoría que clasifica dónde se almacenan y consultan los datos
Dos valores posibles: No Oficial, Oficial
Determina el ambiente de base de datos a utilizar
Afecta permisos, auditoría, y reportes

Ejercicio Contable:

Periodo de tiempo en el que se registran asientos
Atributos principales:
- Código del ejercicio
- Fecha inicio
- Fecha fin
- Estado (Abierto, Cerrado)
Compartido entre modos (los ejercicios son los mismos en No Oficial y Oficial)

Plan de Cuentas:

Estructura jerárquica de cuentas contables
Utilizada para clasificar movimientos
Compartido entre modos (las cuentas son las mismas en No Oficial y Oficial)

Datos Necesarios

Configuración del Modo del Usuario:

Qué modo tiene habilitado el usuario actualmente
Acceso del usuario al formulario (permiso existente en sidebar)
Modo por defecto al abrir el formulario

Conexión de Base de Datos por Modo:

Conexión a base de datos oficial
Conexión a base de datos no oficiales
Mapeo entre modo seleccionado y conexión a utilizar

Numeración de Asientos:

Contador global de numeración (compartido entre ambos modos)
Último número de asiento generado (sin importar el modo)
Próximo número a asignar (incremental, sin importar el modo)

Información de Auditoría:

Usuario que ejecuta la operación
Modo en el que se ejecuta
Fecha y hora de la operación
Datos antes y después (en modificaciones)
Resultado de la operación (éxito o error)

Estado de Sesión:

Modo activo durante la sesión del usuario
Sucursal/Caja activa
Ejercicio contable activo

Relaciones de Negocio

Modo → Conexión de Base de Datos:

Cada modo se mapea a una conexión de base de datos específica
Modo No Oficial → Conexión a base de datos no oficiales
Modo Oficial → Conexión a base de datos oficial
Esta relación es fundamental para el aislamiento de datos

Asiento → Líneas de Asiento:

Un asiento contiene múltiples líneas (relación uno a muchos)
Todas las líneas de un asiento residen en el mismo modo
No puede haber líneas en modo No Oficial de un asiento en modo Oficial

Asiento → Ejercicio Contable:

Un asiento pertenece a un ejercicio contable específico
El ejercicio es compartido entre modos (mismo maestro)
La fecha del asiento debe estar dentro del periodo del ejercicio

Línea de Asiento → Cuenta Contable:

Cada línea afecta una cuenta contable específica
El plan de cuentas es compartido entre modos (mismo maestro)
La cuenta debe existir y ser imputable

Usuario → Acceso al Formulario:

Todos los usuarios con acceso al formulario pueden usar ambos modos
No hay permisos separados por modo
El selector de modo está disponible para todos los usuarios con acceso

Operación → Registro de Auditoría:

Cada operación (Alta, Modificación, Baja) genera un registro de auditoría
El registro incluye el modo donde se ejecutó
Los registros son persistentes e inmutables

Validaciones de Negocio

Validación de Balance (Debe = Haber):

La suma de importes al Debe debe igualar la suma de importes al Haber
Esta validación aplica en ambos modos sin excepción
Comportamiento esperado: NO permitir guardar asiento desbalanceado

Validación de Fecha dentro del Periodo:

La fecha del asiento debe estar dentro de un ejercicio contable activo
El ejercicio NO debe estar cerrado
Esta validación aplica en ambos modos
Comportamiento esperado: Mostrar error si fecha está fuera de periodo válido

Validación de Cuentas Contables:

Cada cuenta utilizada debe existir en el plan de cuentas
La cuenta debe ser imputable (no puede ser cuenta padre/agrupadora)
La cuenta NO debe estar inactiva
Esta validación aplica en ambos modos
Comportamiento esperado: Mostrar error si cuenta no existe o no es válida

Validación de Importes:

Los importes deben ser numéricos y mayores a cero
NO se permiten importes negativos
Una línea debe tener importe en Debe O en Haber, no en ambos
Esta validación aplica en ambos modos
Comportamiento esperado: Mostrar error si importes son inválidos

Validación de Asiento Mínimo:

Un asiento debe tener al menos 2 líneas
NO se permiten asientos de una sola línea (violaría partida doble)
Esta validación aplica en ambos modos
Comportamiento esperado: Mostrar error si asiento tiene menos de 2 líneas

Validación de Información Obligatoria:

Fecha del asiento: Requerida
Ejercicio contable: Requerido
Comentario: Requerido (general o al menos en una línea)
Esta validación aplica en ambos modos
Comportamiento esperado: Mostrar error si falta información obligatoria

Validación de Numeración Única Global:

El número de asiento debe ser único globalmente (entre ambos modos)
Un número solo puede existir en UN modo a la vez
Comportamiento esperado: Asignar siguiente número del contador global, sin importar el modo activo

Validación de Conexión Correcta:

Antes de guardar, verificar que la conexión utilizada corresponde al modo seleccionado
Comportamiento esperado: Evitar guardar en ambiente incorrecto

Casos de Uso

UC-CAP-001: Crear Asiento en Modo No Oficial y Cambiar a Modo Oficial Antes de Guardar

Actor: Contador

Precondiciones:

Usuario tiene acceso al formulario de asientos (permiso existente en sidebar)
Existe al menos un ejercicio contable activo
El plan de cuentas contiene cuentas imputables

Flujo Principal:

Contador accede a Contabilidad → Carga de Asientos → Nuevo
Sistema muestra formulario vacío en modo Alta
Selector de ambiente en color verde/azul por defecto (ambiente oficial - modo más restrictivo)
Contador cambia selector a ambiente no oficial (cambio instantáneo, sin confirmación)
Indicador visual cambia a color naranja/amarillo
Contador selecciona ejercicio contable (ejemplo: Ejercicio 2026)
Contador ingresa fecha del asiento (ejemplo: 15/01/2026)
Contador ingresa comentario general: "Asiento de ajuste por inventario"
Contador agrega primera línea:
- Cuenta: 1.1.01 - Caja
- Debe: $10.000
- Haber: (vacío)
- Detalle: "Faltante de inventario"
Contador agrega segunda línea:
- Cuenta: 5.2.05 - Pérdidas extraordinarias
- Debe: (vacío)
- Haber: $10.000
- Detalle: "Registro de pérdida"
Sistema valida en tiempo real: Balance OK (Debe $10.000 = Haber $10.000)
Contador revisa los datos y decide que quiere guardarlo directamente en ambiente oficial
Contador cambia selector a ambiente oficial (cambio instantáneo, sin confirmación porque está en modo Alta)
Indicador visual cambia a color verde/azul
Todos los datos capturados se mantienen intactos (fecha, comentario, 2 líneas)
Contador presiona botón "Guardar"
Sistema valida:
- Fecha dentro de ejercicio activo: ✅ OK
- Cuentas existen y son imputables: ✅ OK
- Balance Debe = Haber: ✅ OK ($10.000 = $10.000)
- Asiento tiene mínimo 2 líneas: ✅ OK
Sistema asigna siguiente número del contador global (ejemplo: asiento N° 52)
Sistema guarda asiento en base de datos oficial
Sistema registra en auditoría:
- Usuario: Contador (ID: 45)
- Modo: OFICIAL
- Operación: ALTA
- Asiento: N° 52
- Resultado: ÉXITO
Sistema muestra mensaje: "✅ Asiento N° 52 creado exitosamente"
Sistema ofrece opciones: [Crear Nuevo] [Ver Asiento] [Volver al Listado]

Postcondiciones:

Asiento N° 52 existe en el ambiente oficial
NO existe asiento en el ambiente no oficial
El asiento aparece en reportes oficiales (Libro Diario Oficial, Mayor Oficial, Balance Oficial)
El asiento NO aparece en reportes no oficiales
La auditoría registró la operación en modo Oficial
La numeración oficial avanzó a 53

Flujos Alternativos:

Alt-1: Asiento desbalanceado:

En paso 11, si Debe ≠ Haber, sistema muestra error: "El asiento no balancea. Debe: $10.000, Haber: $8.000, Diferencia: $2.000"
Botón "Guardar" se deshabilita hasta corregir el error
Contador corrige importes hasta que balance

Alt-2: Cuenta contable inválida:

En paso 9 o 10, si cuenta no existe o no es imputable, sistema muestra error: "La cuenta 1.1.99 no existe en el plan de cuentas"
Contador selecciona cuenta válida del catálogo

Alt-3: Fecha fuera del periodo:

En paso 7, si fecha está fuera del ejercicio activo, sistema muestra error: "La fecha 15/01/2025 está fuera del ejercicio activo (01/01/2026 - 31/12/2026)"
Contador corrige la fecha

UC-CAP-002: Modificar Asiento Oficial y Cambiar Accidentalmente a Modo No Oficial

Actor: Contador

Precondiciones:

Usuario tiene acceso al formulario de asientos (permiso existente en sidebar)
Existe asiento N° 125 en modo Oficial
NO existe asiento N° 125 en modo No Oficial (porque el número 125 ya está asignado al asiento oficial)

Flujo Principal:

Contador accede a Contabilidad → Carga de Asientos
Selector de modo está en "Oficial"
Listado muestra asientos del modo Oficial
Contador busca asiento N° 125 en el listado
Contador hace clic en botón "Modificar" del asiento N° 125
Sistema carga formulario de modificación con datos del asiento 125 oficial:
- Fecha: 10/01/2026
- Comentario: "Venta de mercadería a cliente X"
- Línea 1: Cuenta 1.1.01 Debe $15.000
- Línea 2: Cuenta 4.1.01 Haber $15.000
Indicador visual en color verde/azul (color verde/azul)
Contador comienza a editar:
- Cambia importe de línea 1 de $15.000 a $18.000
- Cambia importe de línea 2 de $15.000 a $18.000
Contador NO ha guardado los cambios aún
Contador hace clic accidental en selector de modo y selecciona "No Oficial"
Sistema intercepta el intento de cambio y muestra diálogo modal de confirmación:

⚠️ ¿Cambiar de modo OFICIAL a NO OFICIAL?

El asiento N° 125 de modo OFICIAL actualmente cargado se descartará.
TODOS LOS CAMBIOS NO GUARDADOS SE PERDERÁN.

El formulario se recargará buscando el asiento N° 125
en el ambiente de NO OFICIAL (puede ser un asiento diferente
o puede no existir).

¿Desea continuar?

[Confirmar]  [Cancelar]

Contador lee la advertencia y se da cuenta del error
Contador presiona [Cancelar]
Sistema cierra el diálogo de confirmación
Selector de modo vuelve a "Oficial" (posición original)
El asiento 125 oficial sigue cargado con los cambios editados (importes $18.000)
Indicador visual permanece en color verde/azul
Contador puede continuar editando sin pérdida de datos
Contador corrige el comentario: "Venta de mercadería a cliente X - CORREGIDO"
Contador presiona "Guardar"
Sistema valida y guarda el asiento 125 oficial con los nuevos datos
Sistema registra en auditoría:
- Usuario: Contador (ID: 45)
- Modo: OFICIAL
- Operación: MODIFICACIÓN
- Asiento: N° 125
- Cambios: Línea 1 Debe $15.000 → $18.000, Línea 2 Haber $15.000 → $18.000
- Resultado: ÉXITO
Sistema muestra mensaje: "✅ Asiento N° 125 modificado exitosamente"

Postcondiciones:

Asiento N° 125 oficial fue modificado correctamente con los nuevos importes
NO se perdieron los cambios capturados
NO se afectó el asiento N° 125 No Oficial (si existe)
El modo se mantuvo en Oficial
La auditoría registró la modificación exitosa

Flujos Alternativos:

Alt-1: Contador confirma el cambio de modo:

En paso 13, contador presiona [Confirmar] en lugar de [Cancelar]
Sistema descarta el asiento 125 oficial (SE PIERDEN LOS CAMBIOS de $18.000)
Sistema cambia indicador visual a color naranja/amarillo
Sistema busca asiento N° 125 en ambiente no oficial
Sub-caso A: Existe asiento 125 en No Oficial:
- Sistema carga asiento 125 no oficial en el formulario
- Los datos mostrados son del asiento no oficial (probablemente diferentes)
- Contador puede modificar el asiento no oficial si lo desea
Sub-caso B: NO existe asiento 125 en No Oficial:
- Sistema muestra mensaje: "No se encontró asiento N° 125 en este ambiente"
- Formulario queda vacío (modo Alta en No Oficial)
- Contador puede crear un nuevo asiento en No Oficial si lo desea

Alt-2: Contador guarda antes de cambiar de modo:

Después del paso 9, contador presiona "Guardar"
Sistema guarda los cambios en el asiento 125 oficial
Contador luego cambia a modo No Oficial
Sistema muestra diálogo de confirmación (porque sigue en modo Modificación)
Si confirma: carga asiento 125 No Oficial (diferente) o muestra que no existe
NO hay pérdida de datos porque ya se guardó previamente

UC-CAP-003: Consultar Asientos en Modo No Oficial

Actor: Analista Contable

Precondiciones:

Usuario tiene acceso al formulario de asientos (permiso existente en sidebar)
Existen asientos en ambiente no oficial
Puede haber o no asientos en ambiente oficial (los datos están separados)

Flujo Principal:

Analista accede a Contabilidad → Carga de Asientos
Sistema muestra pantalla de listado de asientos
Selector de modo muestra "Oficial" por defecto
Listado muestra asientos del ambiente oficial (ejemplo: asientos 1, 3, 5, 7, 9... con posibles saltos)
Analista cambia selector de modo a "No Oficial"
Sistema recarga el listado automáticamente
Indicador visual cambia a color naranja/amarillo (color naranja/amarillo)
Listado muestra asientos del ambiente no oficial (ejemplo: asientos 2, 4, 6, 8, 10... con posibles saltos debido a numeración compartida)
Analista observa los datos de los asientos no oficiales:
- Asiento N° 2: Fecha 05/01/2026, "Simulación apertura ejercicio"
- Asiento N° 4: Fecha 06/01/2026, "Borrador de asiento de ajuste"
- Asiento N° 6: Fecha 20/01/2026, "Ajuste por inflación - BORRADOR"
- (La numeración tiene saltos porque algunos números están en Modo Oficial)
- Asiento N° 8: Fecha 25/01/2026, "Otro ajuste no oficial"
- Asiento N° 10: Fecha 31/01/2026, "Cierre mensual - EXPERIMENTAL"
Analista selecciona asiento N° 6 para ver detalles
Sistema muestra asiento N° 6 No Oficial en modo lectura (solo consulta):
- Fecha: 20/01/2026
- Comentario: "Ajuste por inflación - BORRADOR"
- Línea 1: Cuenta 1.2.05 - Mercaderías, Debe $25.000
- Línea 2: Cuenta 6.1.08 - Ajustes por inflación, Haber $25.000
- Balance: Debe $25.000 = Haber $25.000 ✅
Analista verifica que el asiento balancea correctamente
Analista cierra la consulta y vuelve al listado
Analista cambia selector de modo a "Oficial"
Sistema recarga el listado
Indicador visual cambia a color verde/azul
Listado muestra asientos oficiales (ejemplo: asientos 1, 3, 5, 7, 9... con numeración diferente)
Analista observa que el asiento N° 6 NO aparece en el listado oficial (porque pertenece al modo No Oficial)
Analista confirma que los datos No Oficial y Oficial están completamente separados

Postcondiciones:

Analista consultó exitosamente asientos de modo No Oficial
Analista verificó que el aislamiento entre modos funciona correctamente
NO se modificaron datos en ningún modo
Analista puede reportar qué asientos existen en No Oficial

Flujos Alternativos:

Alt-1: No existen asientos en modo No Oficial:

En paso 8, sistema muestra mensaje: "No hay asientos en este ambiente"
Listado aparece vacío
Analista confirma que no hay asientos no oficiales aún

Alt-2: Filtrar asientos por fecha en modo No Oficial:

En paso 8, analista aplica filtro de fecha (ejemplo: solo enero 2026)
Sistema filtra asientos No Oficial por el rango de fechas
Solo muestra asientos No Oficial que coincidan con el filtro

UC-CAP-004: Eliminar Asiento en Modo No Oficial y Cambiar a Modo Oficial

Actor: Contador

Precondiciones:

Usuario tiene acceso al formulario de asientos (permiso existente en sidebar)
Existe asiento N° 88 en ambiente no oficial (asiento experimental fallido)
Existe asiento N° 88 en ambiente oficial (asiento completamente diferente)

Flujo Principal:

Contador accede a Contabilidad → Carga de Asientos
Selector de modo está en "Oficial" por defecto
Contador cambia selector a "No Oficial"
Indicador visual cambia a color naranja/amarillo
Listado muestra asientos del ambiente no oficial
Contador busca asiento N° 88 en el listado
Contador hace clic en botón "Eliminar" del asiento N° 88
Sistema carga formulario de eliminación con datos del asiento 88 no oficial:
- Fecha: 25/01/2026
- Comentario: "EXPERIMENTO - Error de captura - ELIMINAR"
- Línea 1: Cuenta 9.9.99 Debe $999.999
- Línea 2: Cuenta 9.9.98 Haber $999.999
- (Claramente es un asiento no oficial con datos ficticios)
Indicador visual en color naranja/amarillo (color naranja)
Contador revisa los datos y confirma que es el asiento correcto a eliminar
Antes de eliminarlo, contador hace clic accidental en selector de modo y selecciona "Oficial"
Sistema intercepta el intento de cambio y muestra diálogo modal de confirmación:

⚠️ ¿Cambiar de modo NO OFICIAL a OFICIAL?

El asiento N° 88 de modo NO OFICIAL se descargará.
Se buscará el asiento N° 88 en el ambiente de OFICIAL.

IMPORTANTE: Es muy probable que NO exista el asiento N° 88
en este ambiente porque la numeración es compartida y este
número ya está asignado al modo NO OFICIAL.

¿Desea continuar?

[Confirmar]  [Cancelar]

Contador lee la advertencia y se da cuenta del error
Contador entiende que cambiar de modo cargaría un asiento oficial diferente
Contador presiona [Cancelar]
Sistema cierra el diálogo de confirmación
Selector de modo vuelve a "No Oficial" (posición original)
El asiento 88 no oficial sigue cargado para eliminación
Indicador visual permanece en color naranja/amarillo
Contador puede continuar con la eliminación del asiento no oficial
Contador presiona botón "Eliminar Asiento"
Sistema muestra confirmación final: "¿Está seguro de eliminar el asiento N° 88? Esta acción no se puede deshacer."
Contador confirma la eliminación
Sistema elimina el asiento N° 88 del ambiente no oficial
Sistema registra en auditoría:
- Usuario: Contador (ID: 45)
- Modo: NO OFICIAL
- Operación: BAJA
- Asiento: N° 88
- Resultado: ÉXITO
Sistema muestra mensaje: "✅ Asiento N° 88 eliminado exitosamente"
Sistema redirige al listado de asientos en modo No Oficial
El asiento N° 88 ya no aparece en el listado No Oficial
Contador cambia selector a "Oficial" para verificar
Listado muestra asientos oficiales
El asiento N° 88 oficial sigue existiendo intacto (no fue afectado)

Postcondiciones:

Asiento N° 88 No Oficial fue eliminado exitosamente
Asiento N° 88 de Oficial NO fue afectado (sigue existiendo)
El aislamiento entre modos se preservó
La auditoría registró la eliminación en modo No Oficial
La confirmación del cambio de modo previno un error crítico

Flujos Alternativos:

Alt-1: Contador confirma el cambio de modo:

En paso 15, contador presiona [Confirmar] en lugar de [Cancelar]
Sistema descarta el asiento 88 no oficial
Sistema cambia indicador visual a color verde/azul
Sistema busca asiento N° 88 en ambiente oficial
Sistema carga asiento N° 88 oficial en el formulario:
- Fecha: 18/01/2026
- Comentario: "Cobro de factura 1255"
- Línea 1: Cuenta 1.1.01 - Caja Debe $50.000
- Línea 2: Cuenta 1.1.05 - Clientes Haber $50.000
- (Es un asiento oficial completamente diferente)
Contador se da cuenta de que es un asiento oficial real
Contador NO elimina este asiento (no es el que quería eliminar)
Contador cambia selector a "No Oficial" nuevamente
Sistema muestra confirmación (porque sigue en modo Baja)
Contador confirma, sistema busca asiento 88 en No Oficial
Sistema muestra mensaje: "No se encontró asiento N° 88 en este ambiente" (porque ya lo había descargado antes)
Contador debe buscar nuevamente en el listado el asiento que quería eliminar

Alt-2: Asiento N° 88 NO existe en modo Oficial:

Si en paso donde se busca asiento 88 en Oficial no existe
Sistema muestra mensaje: "No se encontró asiento N° 88 en este ambiente. No hay nada que eliminar."
Sistema redirige al listado de asientos en modo Oficial
Contador puede cambiar a modo No Oficial para buscar el asiento 88 no oficial

Alt-3: Contador cancela la eliminación final:

En paso 23, contador presiona "Cancelar" en la confirmación final
Sistema NO elimina el asiento
Asiento 88 No Oficial sigue existiendo
Contador puede volver al listado o seguir revisando el asiento

UC-CAP-005: Trabajar Exclusivamente en No Oficial para Cierre de Ejercicio

Actor: Contador Senior

Precondiciones:

Usuario tiene acceso al formulario de asientos (permiso existente en sidebar)
El ejercicio contable 2026 está por cerrar
Existen asientos oficiales del ejercicio 2026 (asientos 1-250)
El contador necesita simular asientos de cierre antes de ejecutarlos oficialmente

Flujo Principal:

Contador Senior accede a Contabilidad → Carga de Asientos
Selector de modo está en "Oficial" por defecto
Contador cambia selector a "No Oficial"
Indicador visual cambia a color naranja/amarillo (color naranja)
Contador decide trabajar exclusivamente en No Oficial durante todo el proceso de simulación
Primera fase: Crear asientos de cierre simulados
Contador crea nuevo asiento en modo No Oficial:
- Fecha: 31/12/2026
- Comentario: "SIMULACIÓN - Cierre cuentas de resultado - Ingresos"
- Agrega 15 líneas con todas las cuentas de ingresos (débitos)
- Agrega línea final: Cuenta 3.5.01 - Resultado del Ejercicio (crédito)
- Total: Debe $1.250.000 = Haber $1.250.000
Contador guarda asiento → Sistema asigna N° 1 en No Oficial
Contador crea segundo asiento en modo No Oficial:
- Fecha: 31/12/2026
- Comentario: "SIMULACIÓN - Cierre cuentas de resultado - Egresos"
- Agrega 20 líneas con todas las cuentas de egresos (créditos)
- Agrega línea final: Cuenta 3.5.01 - Resultado del Ejercicio (débito)
- Total: Debe $980.000 = Haber $980.000
Contador guarda asiento → Sistema asigna N° 2 en No Oficial
Contador crea tercer asiento en modo No Oficial:
- Fecha: 31/12/2026
- Comentario: "SIMULACIÓN - Cierre resultado del ejercicio"
- Línea 1: Cuenta 3.5.01 - Resultado del Ejercicio Debe $270.000 (1.250.000 - 980.000)
- Línea 2: Cuenta 3.1.15 - Resultados Acumulados Haber $270.000
Contador guarda asiento → Sistema asigna N° 3 en No Oficial
Segunda fase: Generar reportes en modo No Oficial para validar
Contador accede a Informes → Libro Diario General
Contador selecciona:
- Ejercicio: 2026
- Periodo: Diciembre 2026
- Modo: No Oficial
Sistema genera Libro Diario con asientos No Oficial (asientos 1, 2, 3 de cierre simulados)
Contador verifica que los asientos balancean correctamente
Contador accede a Informes → Balance de Comprobación
Contador selecciona Modo: Consolidado (Oficial + No Oficial)
Sistema genera Balance consolidado mostrando:
- Movimientos oficiales del ejercicio (asientos 1-250)
- Movimientos no oficial (asientos 1-3 de cierre)
- Totales consolidados
Contador verifica que el resultado del ejercicio queda en $270.000 en Resultados Acumulados
Tercera fase: Detectar error y corregir en No Oficial
Contador detecta que olvidó incluir una cuenta de egreso en el asiento N° 2
Contador vuelve a Contabilidad → Carga de Asientos (en modo No Oficial)
Contador busca asiento N° 2 en No Oficial
Contador hace clic en "Modificar" del asiento N° 2
Sistema carga asiento N° 2 No Oficial en modo Modificación
Indicador visual en color naranja/amarillo
Contador agrega nueva línea:
- Cuenta: 5.3.08 - Gastos bancarios Crédito $5.000
Contador ajusta línea final (Resultado del Ejercicio) de $980.000 a $985.000
Contador guarda cambios
Sistema valida: Balance OK (Debe $985.000 = Haber $985.000)
Sistema guarda asiento N° 2 modificado en No Oficial
Contador regenera Balance de Comprobación en modo Consolidado
Ahora el resultado del ejercicio es $265.000 (1.250.000 - 985.000)
Cuarta fase: Oficializar asientos después de validar
Contador verifica que todo es correcto en No Oficial
Contador cambia selector de modo a "Oficial"
Contador crea los mismos asientos de cierre pero ahora en modo Oficial
Sistema asigna N° 251, 252, 253 en el ambiente Oficial
Contador genera Balance de Comprobación en modo Oficial
El balance oficial ahora incluye los asientos de cierre definitivos
Quinta fase: Limpiar asientos No Oficial
Contador cambia selector a "No Oficial"
Contador elimina asientos N° 1, 2, 3 No Oficial (ya fueron oficializados)
Sistema elimina los asientos No Oficial
Ambiente No Oficial queda limpio para futuras simulaciones

Postcondiciones:

Contador simuló completamente el cierre de ejercicio en No Oficial sin afectar datos oficiales
Detectó y corrigió errores en el ambiente No Oficial antes de oficializar
Generó reportes consolidados para validar el impacto de los asientos de cierre
Oficializó los asientos correctos después de validarlos exhaustivamente
Limpió el ambiente No Oficial dejándolo listo para futuras simulaciones
La contabilidad oficial NO fue afectada hasta que el contador estuvo completamente seguro
La auditoría registró todas las operaciones en ambos modos

Flujos Alternativos:

Alt-1: Contador cambia accidentalmente a modo Oficial durante la simulación:

En cualquier paso durante creación/modificación en No Oficial
Si está en modo Alta: cambio es libre, no hay problema
Si está en modo Modificación: sistema muestra confirmación, contador cancela y sigue en No Oficial

Alt-2: Contador decide NO oficializar los asientos:

Después de validar en No Oficial, contador decide hacer más ajustes
NO crea los asientos en Oficial aún
Sigue trabajando en No Oficial hasta estar completamente seguro

Alt-3: Diferentes asientos en No Oficial y Oficial:

Contador crea asientos de cierre con estructura diferente en Oficial
Los asientos No Oficial fueron solo experimentales
NO hay correspondencia directa entre asientos No Oficial y Oficial

Consideraciones

Seguridad

Autenticación y Autorización:

Todo usuario debe estar autenticado mediante JWT antes de acceder al formulario de asientos
El sistema debe validar que el token JWT es válido y no ha expirado
El acceso al formulario está controlado por el permiso existente en el sidebar
Si el usuario pierde acceso durante la sesión, debe ser desconectado o restringido

Validación de Permisos en Backend:

NUNCA confiar en la validación de permisos del frontend únicamente
El backend debe validar el acceso al formulario antes de ejecutar cualquier operación CRUD
Al cambiar de modo, el usuario mantiene el mismo nivel de acceso (no hay permisos diferentes por modo)
Al guardar, validar que el usuario tiene acceso al formulario independientemente del modo activo

Prevención de Ataques de Manipulación:

Un usuario malicioso podría intentar enviar datos con un modo diferente al seleccionado
El backend debe validar que la conexión utilizada corresponde al modo enviado
Validar que el número de asiento asignado pertenece a la secuencia correcta del modo
Evitar que un usuario pueda forzar la creación de un asiento en una base de datos no autorizada

Protección de Datos Sensibles:

Los asientos contables son datos críticos de la organización
Aplicar HTTPS para toda comunicación entre frontend y backend
NO exponer información de conexión de base de datos en respuestas
Encriptar información sensible en logs y auditoría si es necesario

Control de Acceso:

El acceso al formulario se controla mediante el permiso existente en el sidebar
Todos los usuarios con acceso pueden trabajar en ambos modos (No Oficial y Oficial) sin restricciones adicionales
No se requieren permisos específicos o diferenciados por modo
Los permisos CRUD existentes (Alta, Modificación, Baja) aplican por igual en ambos modos

Prevención de Inyección SQL:

Utilizar prepared statements en todas las consultas
NUNCA concatenar input del usuario directamente en SQL
Validar y sanitizar todos los inputs antes de usarlos en consultas
Aplicar validación tanto en frontend como en backend

Auditoría de Seguridad:

Registrar intentos de acceso denegado al formulario
Registrar todos los cambios de modo realizados por los usuarios
Alertar si se detectan patrones sospechosos (múltiples intentos fallidos de acceso)
Monitorear accesos a asientos de modo Oficial para detectar anomalías

Auditoría

Registro Obligatorio de Operaciones:

Todas las operaciones deben ser auditadas sin excepción:

Alta: Registrar creación del asiento con todos sus datos
Modificación: Registrar estado antes y después de la modificación
Baja: Registrar el asiento eliminado con todos sus datos

Información Mínima a Auditar:

Fecha y hora exacta de la operación (timestamp con zona horaria)
Usuario que ejecutó la operación (ID, nombre completo)
Modo en el que se ejecutó (No Oficial u Oficial)
Tipo de operación (Alta, Modificación, Baja)
Número del asiento afectado
Ejercicio contable asociado
Resultado de la operación (Éxito, Error, Validación fallida)
Dirección IP desde donde se ejecutó
Sesión o token JWT utilizado

Datos Adicionales Recomendados:

Schema/Sucursal/Caja desde donde se ejecutó
Conexión de base de datos utilizada
Tiempo de ejecución de la operación
Tamaño de los datos afectados (cantidad de líneas del asiento)

Auditoría de Cambios en Modificación:

Registrar estado completo ANTES de la modificación
Registrar estado completo DESPUÉS de la modificación
Identificar exactamente qué campos cambiaron (diff)
Permitir reconstruir el historial completo de un asiento

Auditoría de Cambios de Modo:

Registrar cuando un usuario cambia de modo durante Modificación/Baja
Registrar si confirmó o canceló el cambio
Registrar qué asiento se descargó y cuál se cargó
Útil para detectar errores operativos o intentos de manipulación

Inmutabilidad de Registros de Auditoría:

Los registros de auditoría NUNCA deben modificarse o eliminarse
Utilizar tabla separada con permisos restrictivos de escritura
Considerar almacenamiento append-only o write-once
Implementar checksums o firmas digitales para detectar manipulación

Retención de Auditoría:

Auditoría de modo Oficial: Mínimo 5-10 años (según normativa contable del país)
Auditoría de modo No Oficial: Mínimo 1-2 años (suficiente para análisis de uso)
Considerar archivado de auditoría antigua en almacenamiento de largo plazo
Mantener disponibles para consultas de auditoría externa o inspecciones

Consulta de Auditoría:

Proporcionar pantalla de consulta de auditoría para usuarios autorizados
Filtros: Modo, Tipo de operación, Usuario, Rango de fechas, Número de asiento
Exportación a Excel/PDF para reportes de auditoría
Visualización de cambios línea por línea (diff visual)

Auditoría de Accesos Denegados:

Registrar intentos de acceso al formulario sin el permiso requerido
Registrar cambios de modo realizados por los usuarios
Útil para detectar intentos de acceso no autorizado
Puede generar alertas automáticas ante múltiples intentos sospechosos

Rendimiento

Impacto de Consultar Diferentes Conexiones:

Cambiar de modo implica cambiar de conexión de base de datos
Cada conexión puede estar en un servidor diferente (oficial en producción, no oficial en servidor de desarrollo)
El cambio de conexión puede tener latencia adicional (especialmente si están en diferentes datacenters)
Expectativa aceptable: El cambio de modo debe completarse en menos de 2 segundos desde la perspectiva del usuario

Optimización de Cambio de Modo:

Mantener conexiones pre-establecidas (pool de conexiones) para evitar overhead de conexión
Cachear datos maestros (plan de cuentas, ejercicios) que son compartidos entre modos
Al cambiar de modo, solo recargar datos transaccionales (asientos y líneas)
Implementar indicadores de carga (spinner, progress bar) para feedback visual

Rendimiento en Listado de Asientos:

Al cambiar de modo, el listado debe recargar solo los asientos del nuevo modo
Implementar paginación para evitar cargar miles de asientos a la vez
Expectativa: El listado debe mostrar la primera página en menos de 1 segundo
Considerar lazy loading o scroll infinito para grandes volúmenes

Rendimiento en Carga de Asiento Individual:

Al cargar un asiento para modificación/baja, consultar solo ese asiento y sus líneas
Expectativa: Cargar un asiento debe tardar menos de 500ms
Optimizar consultas para obtener asiento + líneas + cuentas en una sola operación (JOIN eficiente)

Rendimiento en Guardado de Asiento:

Al guardar un asiento con múltiples líneas, utilizar transacciones para garantizar atomicidad
Expectativa: Guardar asiento de 10-20 líneas debe tardar menos de 1 segundo
Para asientos con muchas líneas (50+), mostrar indicador de progreso
Considerar batch inserts para mejorar performance en asientos grandes

Optimización de Validaciones:

Validaciones simples (formato, tipo de dato) en frontend antes de enviar al backend
Validaciones de negocio (balance, cuentas válidas) en backend
Cachear validación de cuentas contables para evitar consultas repetidas
Expectativa: Validación completa debe completarse en menos de 500ms

Manejo de Alto Volumen de Asientos:

Si el ambiente No Oficial acumula miles de asientos, considerar:
- Paginación eficiente con índices en fecha y número de asiento
- Búsqueda por rangos de fecha para reducir resultados
- Posibilidad de archivar o limpiar asientos no oficiales antiguos
Expectativa: Consultar asientos en modo con 10,000+ registros no debe degradar performance significativamente

Monitoreo de Performance:

Medir tiempo de respuesta de operaciones CRUD por modo
Identificar cuellos de botella (consultas lentas, conexiones bloqueadas)
Establecer alertas si el tiempo de respuesta excede umbrales aceptables
Revisar logs de performance regularmente para optimización continua

Consideraciones de Conexión de Base de Datos:

El ambiente No Oficial puede estar en un servidor con menos recursos (aceptable para asientos no oficiales)
El ambiente Oficial debe estar en servidor de producción con recursos adecuados
Si la latencia entre ambientes es alta, considerar mensajes de advertencia al usuario
NO sacrificar integridad de datos por performance (transacciones siempre completas)

Usabilidad

Indicadores Claros del Modo Actual:

El modo activo debe ser extremadamente visible en todo momento
Utilizar colores distintivos:
- Modo No Oficial: Naranja, Amarillo, o Ámbar (colores de advertencia/precaución)
- Modo Oficial: Verde, Azul, o Gris oscuro (colores de estabilidad/formalidad)
Ubicar indicadores en múltiples lugares:
- Encabezado del formulario (grande y prominente)
- Junto al selector de modo
- Cerca del botón de guardar (última confirmación visual)
- En la barra de título de la ventana/pestaña del navegador
Incluir icono representativo:
- Modo No Oficial: Icono de laboratorio, flask, o símbolo no oficial
- Modo Oficial: Icono de certificado, check, o símbolo de oficial

Selector de Modo Intuitivo:

Control visual debe ser autoexplicativo mediante colores e iconos distintivos (toggle, radio buttons, o dropdown)
Diferenciación visual: naranja/amarillo con icono para ambiente no oficial, verde/azul con icono para ambiente oficial
El selector debe estar disponible para todos los usuarios con acceso al formulario
El selector debe estar en un lugar fijo y consistente (no moverse entre operaciones)
El cambio de ambiente se indica únicamente mediante el cambio de color visual de la página

Confirmaciones que Previenen Cambios Accidentales:

El diálogo de confirmación al cambiar de modo debe ser:
- Modal: Bloquear interacción con el resto del formulario
- Claro: Texto simple y directo sin ambigüedades
- Específico: Indicar qué asiento se descargará y qué se buscará
- Destacado: Usar icono de advertencia (⚠️) y color llamativo
- Accionable: Botones "Confirmar" y "Cancelar" claramente diferenciados
El texto del diálogo debe evitar jerga técnica
Evitar confirmaciones genéricas como "¿Está seguro?" (ser específico)

Mensajes de Error Claros y Accionables:

Los mensajes de error deben:
- Explicar QUÉ salió mal en términos comprensibles
- Indicar POR QUÉ ocurrió el error (causa)
- Sugerir CÓMO corregirlo (acción a tomar)
Ejemplos de buenos mensajes:
- ❌ Mal: "Error 403"
- ✅ Bien: "No tiene acceso al formulario de asientos contables. Contacte al administrador del sistema para solicitar acceso."
- ❌ Mal: "Validación fallida"
- ✅ Bien: "El asiento no balancea. Debe: $10.000, Haber: $8.000, Diferencia: $2.000. Corrija los importes para que Debe = Haber."

Feedback Visual de Operaciones Exitosas:

Al guardar asiento exitosamente:
- Mostrar mensaje de confirmación claro: "✅ Asiento N° 125 creado exitosamente"
- El color de la página indica el ambiente donde se guardó
- Usar color verde y icono de éxito (✅)
- El mensaje debe permanecer visible suficiente tiempo (3-5 segundos o hasta que el usuario lo cierre)
Considerar efectos visuales sutiles (fade in/out, slide) para mejor experiencia

Indicadores de Progreso:

Al cambiar de modo y recargar datos:
- Mostrar spinner o barra de progreso
- Texto: "Cargando asiento..."
- Deshabilitar formulario durante la carga para evitar interacciones prematuras
Al guardar asiento:
- Deshabilitar botón "Guardar" durante el proceso
- Mostrar texto: "Guardando..." o spinner en el botón
- Al completar: Cambiar a "Guardado" brevemente antes de mostrar confirmación

Prevención de Pérdida de Datos:

Si el usuario intenta cerrar el formulario con cambios no guardados:
- Mostrar confirmación: "Tiene cambios sin guardar. ¿Desea salir sin guardar?"
- Aplica tanto en modo Alta como en Modificación
Si el usuario intenta navegar a otra página:
- Interceptar navegación y mostrar confirmación
- Prevenir pérdida accidental de trabajo

Ayuda Contextual:

Botón de ayuda (?) junto al selector de modo (opcional)
El ambiente se diferencia únicamente por color visual e icono
Enlace a documentación completa para usuarios que quieran profundizar

Consistencia Visual:

El diseño y comportamiento del formulario debe ser consistente en ambos modos
Los mismos campos, validaciones, y mensajes en No Oficial y Oficial
Solo el indicador de modo debe ser diferente
Evitar confusión manteniendo el mismo layout y flujo de trabajo

Accesibilidad:

Asegurar que el indicador de modo sea accesible para usuarios con:
- Daltonismo: NO depender únicamente del color (incluir texto e iconos)
- Baja visión: Texto suficientemente grande y con buen contraste
- Lectores de pantalla: Etiquetas ARIA apropiadas para el selector de modo
El diálogo de confirmación debe ser navegable por teclado (Tab, Enter, Escape)

Dependencias

Funcionalidades Relacionadas

Sistema de Ejercicios Contables:

Los asientos se registran dentro de ejercicios contables específicos
El modo (No Oficial u Oficial) NO afecta los ejercicios (son compartidos)
La validación de fecha dentro del periodo del ejercicio aplica en ambos modos
El cierre de ejercicio puede simularse primero en No Oficial

Plan de Cuentas Contables:

El catálogo de cuentas es compartido entre modos (único maestro)
Las validaciones de cuentas válidas e imputables aplican en ambos modos
Cambios en el plan de cuentas afectan a ambos modos inmediatamente

Informes Contables con Soporte de Modos:

Libro Diario General (ya soporta modos): Consultar asientos por modo seleccionado
Mayor Analítico (ya soporta modos): Movimientos por cuenta según modo
Balance de Comprobación (ya soporta modos): Saldos por modo o consolidado
Estos informes deben respetar el modo seleccionado para consultar datos correctos

Sistema de Auditoría:

Todas las operaciones CRUD de asientos deben generar registros de auditoría
La auditoría debe identificar claramente el modo (No Oficial u Oficial)
Consultas de auditoría deben poder filtrar por modo

Sistema de Permisos y Seguridad:

Control de acceso basado en el permiso existente en el sidebar
Todos los usuarios con acceso pueden trabajar en ambos modos sin restricciones adicionales
Validación de acceso en frontend (UI) y backend (API)

Módulo de Tesorería:

Tesorería puede generar asientos contables automáticamente (cobros, pagos)
Implicación: Tesorería también debería soportar modos de operación
Si Tesorería crea asientos en modo No Oficial, deberían ir al ambiente no oficial
Coordinación necesaria para consistencia entre módulos

Módulo de Compras:

Compras puede generar asientos de compras y retenciones automáticamente
Implicación: Similar a Tesorería, debería respetar el modo de operación
Asientos generados en No Oficial NO deben afectar contabilidad oficial

Módulo de Ventas:

Ventas puede generar asientos de facturación automáticamente
Implicación: Debe soportar modos si genera asientos contables
Evitar inconsistencias entre ventas y contabilidad por modo

Oficialización de Asientos No Oficial (Funcionalidad Futura):

Capacidad de "promover" asientos No Oficial a Oficial
Seleccionar asientos No Oficial validados y copiarlos a Oficial
Simplificaría el flujo de trabajo de simulación → oficialización
Estado: Planificado, NO implementado actualmente

Consolidación de Modos en Informes:

Ya implementado en Libro Diario, Mayor, y Balance
Modo 0: Solo No Oficial
Modo 1: Solo Oficial
Modo 2: Consolidado (Oficial + No Oficial)
El CRUD de asientos debe ser consistente con esta funcionalidad

Integraciones

Base de Datos PostgreSQL Multi-Tenant:

Sistema utiliza schemas separados por sucursal/caja
Los modos se implementan mediante conexiones a bases de datos diferentes:
- Base oficial: Producción
- Base no oficial: Con sufijo _p (ejemplo: database_oficial_p)
Cada operación debe usar la conexión apropiada según el modo

Sistema de Conexiones de Base de Datos:

Gestión de múltiples conexiones simultáneas (oficial, no oficial)
Pool de conexiones para optimizar performance
Cambio de conexión al cambiar de modo sin cerrar sesión del usuario

Autenticación JWT:

Token JWT contiene información del usuario y acceso al formulario
El acceso al formulario permite trabajar en ambos modos sin restricciones
Validación de acceso en cada request al backend

API REST del Backend:

Endpoints CRUD de asientos deben aceptar parámetro de modo
Validación en backend de que el usuario tiene acceso al formulario de asientos
Respuestas deben indicar en qué modo se ejecutó la operación

Frontend React/TypeScript:

Componentes deben manejar el estado del modo activo
Interceptores de API deben incluir el modo en los requests
Manejo de estado global (Context o Redux) para el modo seleccionado

Sistema de Notificaciones:

Notificaciones de éxito/error deben incluir el modo
Alertas de cambio de modo durante Modificación/Baja
Feedback visual consistente en ambos modos

Reportes PDF/Excel:

Asientos No Oficial pueden necesitarse en reportes impresos
Reportes deben identificar claramente el modo de los datos
Color de fondo diferenciado según ambiente (naranja/amarillo para no oficial, verde/azul para oficial)

Criterios de Aceptación

Funcionales - Modo

AC-CAP-001: El usuario puede seleccionar entre dos modos de operación: No Oficial y Oficial mediante un selector visible en el formulario de carga de asientos

AC-CAP-002: En modo No Oficial, todas las operaciones (Alta, Modificación, Baja) afectan exclusivamente el ambiente no oficial y NO afectan el ambiente oficial

AC-CAP-003: En modo Oficial, todas las operaciones (Alta, Modificación, Baja) afectan exclusivamente el ambiente oficial y NO afectan el ambiente no oficial

AC-CAP-004: Los asientos creados en modo No Oficial aparecen solo en listados y reportes de modo No Oficial, y NO aparecen en reportes oficiales

AC-CAP-005: Los asientos creados en modo Oficial aparecen solo en listados y reportes de modo Oficial, y NO aparecen en reportes no oficiales (excepto en modo Consolidado de informes)

Funcionales - Operación Alta

AC-CAP-006: Durante la operación de Alta (crear nuevo asiento), el usuario puede cambiar de modo en cualquier momento sin mostrar diálogo de confirmación y sin perder los datos capturados en el formulario

AC-CAP-007: Al cambiar de modo durante Alta, todos los datos del formulario (fecha, comentario, líneas capturadas) se mantienen intactos y visibles

AC-CAP-008: Al guardar un asiento en modo Alta, el asiento se crea en el modo actualmente seleccionado al momento de presionar "Guardar", independientemente de los cambios de modo previos

Funcionales - Operación Modificación

AC-CAP-009: Durante la operación de Modificación (editar asiento existente), si el usuario intenta cambiar de modo, el sistema muestra un diálogo de confirmación advirtiendo que los cambios NO guardados se perderán y el formulario se recargará con datos del nuevo modo

AC-CAP-010: Si el usuario confirma el cambio de modo durante Modificación, el sistema descarta el asiento cargado, cambia el modo, y busca el asiento con el mismo número en el nuevo modo. Si lo encuentra, lo carga en el formulario; si NO lo encuentra, muestra mensaje informativo

AC-CAP-011: Si el usuario cancela el cambio de modo durante Modificación, el sistema mantiene el modo original, mantiene el asiento cargado sin cambios, y el usuario puede continuar editando normalmente

AC-CAP-012: Al guardar cambios después de modificar un asiento, los cambios se aplican al asiento del modo actualmente seleccionado, NO al asiento del modo original si hubo cambio de modo confirmado

Funcionales - Operación Baja

AC-CAP-013: Durante la operación de Baja (eliminar asiento existente), si el usuario intenta cambiar de modo, el sistema muestra un diálogo de confirmación advirtiendo que se descargará el asiento actual y se buscará un asiento diferente en el nuevo modo

AC-CAP-014: Si el usuario confirma el cambio de modo durante Baja, el sistema busca el asiento con el mismo número en el nuevo modo. Si lo encuentra, lo carga para eliminación; si NO lo encuentra, muestra mensaje "No existe asiento N° [NUMERO] en este ambiente"

AC-CAP-015: Si el usuario cancela el cambio de modo durante Baja, el sistema mantiene el modo original y el asiento cargado para eliminación sin cambios

Funcionales - Numeración

AC-CAP-016: Ambos modos (No Oficial y Oficial) comparten la misma secuencia de numeración global. El contador de asientos es único y se incrementa consecutivamente sin importar en qué modo se cree cada asiento.

AC-CAP-017: Al crear un asiento en cualquier modo, el sistema asigna el siguiente número del contador global. Un número de asiento existe en un solo modo a la vez (no puede haber asiento N° 5 en No Oficial y N° 5 en Oficial simultáneamente).

Funcionales - Validaciones

AC-CAP-018: Todas las validaciones contables (balance Debe = Haber, fecha dentro del periodo, cuentas válidas, importes válidos, mínimo 2 líneas) se aplican por igual en modo No Oficial y modo Oficial sin excepciones

AC-CAP-019: El sistema NO permite guardar asientos desbalanceados (Debe ≠ Haber) en ninguno de los dos modos

AC-CAP-020: Los mensajes de error de validación son idénticos en ambos modos y proporcionan información clara sobre cómo corregir el error

Seguridad y Permisos

AC-CAP-021: Todos los usuarios con permiso de acceso al formulario de asientos pueden trabajar en ambos modos (No Oficial y Oficial) sin restricciones adicionales

AC-CAP-022: El selector de modo está disponible y habilitado para todos los usuarios con acceso al formulario, sin requerir permisos específicos por modo

AC-CAP-023: Las operaciones en modo No Oficial y modo Oficial tienen el mismo nivel de seguridad y validación, sin diferencias en los requisitos de permisos

Auditoría

AC-CAP-024: Todas las operaciones (Alta, Modificación, Baja) generan un registro de auditoría que incluye obligatoriamente: fecha/hora, usuario, modo (No Oficial u Oficial), tipo de operación, número de asiento, y resultado

AC-CAP-025: Los registros de auditoría son inmutables (NO pueden modificarse o eliminarse) y se retienen según política de retención (mínimo 5-10 años para Oficial, 1-2 años para No Oficial)

AC-CAP-026: Los cambios de modo durante Modificación/Baja (confirmados o cancelados) también se registran en auditoría para trazabilidad completa

UI/UX

AC-CAP-027: El indicador visual de modo actual es altamente visible, utiliza colores distintivos (naranja/amarillo para No Oficial, verde/azul para Oficial), e icono representativo. El ambiente se indica mediante color visual, sin texto adicional en la interfaz. El indicador debe estar presente en al menos tres ubicaciones: encabezado del formulario, junto al selector, y cerca del botón de guardar

AC-CAP-028: El diálogo de confirmación de cambio de modo (durante Modificación/Baja) es modal, bloquea interacciones con el formulario, utiliza icono de advertencia (⚠️), incluye texto claro y específico sobre qué se descartará y qué se buscará, y ofrece botones "Confirmar" y "Cancelar" claramente diferenciados

AC-CAP-029: Los mensajes de confirmación de operaciones exitosas NO incluyen referencia al modo/ambiente en el texto, por ejemplo: "✅ Asiento N° 125 creado exitosamente". El ambiente se indica únicamente mediante el color visual de la página

Notas Adicionales

Relación con Informes Existentes que Soportan Modos

Los informes contables (Libro Diario General, Mayor Analítico, Balance de Comprobación) ya implementan el patrón de modos de operación con tres opciones:

Modo 0: Solo No Oficial
Modo 1: Solo Oficial
Modo 2: Consolidado (Oficial + No Oficial)

El sistema de carga de asientos (CRUD) debe ser completamente consistente con esta funcionalidad:

Los asientos creados en modo No Oficial deben aparecer en informes de Modo 0 (Solo No Oficial) y Modo 2 (Consolidado)
Los asientos creados en modo Oficial deben aparecer en informes de Modo 1 (Solo Oficial) y Modo 2 (Consolidado)
La numeración, fechas, y contenido de los asientos deben ser idénticos en CRUD e informes

Esta consistencia es fundamental para que los usuarios puedan:

Crear asientos en No Oficial
Validarlos en Libro Diario modo No Oficial
Verificar su impacto en Balance modo Consolidado
Oficializarlos creándolos en modo Oficial
Confirmar que aparecen correctamente en informes oficiales

Importancia Crítica de la Prevención de Pérdida de Datos

El comportamiento diferenciado entre Alta vs Modificación/Baja al cambiar de modo NO es arbitrario. Tiene una justificación técnica y de experiencia de usuario fundamental:

En Alta (cambio libre):

NO hay datos persistidos → NO hay riesgo de corrupción
Los datos del formulario son temporales → Se pueden mantener intactos
Permite flexibilidad y experimentación sin consecuencias

En Modificación/Baja (confirmación + recarga):

HAY datos persistidos en un ambiente específico → Alto riesgo de corrupción si se mezclan
Cambiar de modo sin control podría causar:
- Guardar datos de un asiento No Oficial en ambiente Oficial (contaminación)
- Eliminar un asiento de Oficial cuando se quería eliminar uno No Oficial (error crítico)
- Pérdida de integridad referencial
- Secuencias de numeración desincronizadas
- Auditoría inconsistente

Por estas razones, la confirmación explícita y la recarga de datos son requisitos de seguridad NO NEGOCIABLES.

Posibles Mejoras Futuras

Oficialización Masiva de Asientos No Oficial:

Permitir seleccionar múltiples asientos No Oficial validados
Con un solo clic, copiarlos al ambiente Oficial
Asignar nueva numeración oficial automáticamente
Registrar auditoría de la oficialización
Beneficio: Simplifica enormemente el flujo de trabajo de simulación → oficialización

Modo Consolidado para CRUD (NO solo para informes):

Actualmente, CRUD solo permite trabajar en No Oficial O Oficial
Una vista consolidada permitiría ver ambos listados juntos
Útil para identificar visualmente qué asientos ya fueron oficializados
Desafío: Evitar confusión en operaciones de edición/eliminación

Comparación Visual entre Asientos No Oficial y Oficial:

Herramienta para comparar asiento N° X No Oficial vs asiento N° X de Oficial
Resaltar diferencias (diff visual)
Útil para validar que la oficialización fue correcta
Beneficio: Control de calidad mejorado

Plantillas de Asientos No Oficial:

Guardar asientos No Oficial como plantillas reutilizables
Aplicar plantillas en modo Oficial para asientos recurrentes
Beneficio: Acelera captura de asientos repetitivos

Etiquetas o Categorías en Asientos No Oficial:

Permitir etiquetar asientos No Oficial (ejemplo: "Cierre 2026", "Ajuste inflación")
Filtrar asientos No Oficial por etiqueta
Beneficio: Organización mejorada de simulaciones

Exportación/Importación de Asientos No Oficial:

Exportar asientos No Oficial a archivo (JSON, Excel)
Importar asientos en otro ambiente No Oficial
Beneficio: Compartir simulaciones entre contadores

Referencias a Documentación Relacionada

Para comprender completamente el contexto de esta funcionalidad, se recomienda revisar:

Libro Diario General - Modos de Operación (libro-diario-modos-process.md): Describe cómo los informes manejan los modos
Consolidación de Informes Contables (consolidacion-informes-contables.md): Explica la arquitectura de consolidación multi-schema y multi-modo
Arquitectura de Consolidación Multi-Schema (/docs/architecture/consolidacion-informes-multi-schema.md): Patrón arquitectural general

Consideraciones de Migración y Adopción

Impacto en Usuarios Existentes:

Los usuarios actuales están acostumbrados a trabajar únicamente en modo Oficial
La introducción de modos requiere capacitación
Se recomienda un periodo de transición donde:
- Modo Oficial sea el predeterminado al abrir el formulario
- El selector de modo esté visible para todos los usuarios con acceso
- Se ofrezcan sesiones de capacitación sobre los beneficios de usar No Oficial

Migración de Datos Existentes:

Todos los asientos existentes se consideran asientos Oficiales
NO se requiere migración de datos (están en la base oficial)
El ambiente No Oficial comienza vacío
Los usuarios pueden comenzar a experimentar inmediatamente

Comunicación del Cambio:

Documentar claramente el nuevo flujo de trabajo
Crear tutoriales visuales (screenshots o videos)
Destacar casos de uso concretos (cierre de ejercicio, ajustes complejos)
Enfatizar que modo No Oficial NO reemplaza Oficial, es complementario

Historial de Cambios

Fecha	Versión	Autor	Descripción
2026-01-06	1.0	Sistema	Creación del documento de requerimientos de negocio para soporte de modos de operación (No Oficial y Oficial) en el CRUD de asientos contables. Incluye comportamiento diferenciado por operación (Alta: cambio libre, Modificación/Baja: confirmación + recarga), 8 reglas de negocio detalladas, 5 casos de uso completos, 29 criterios de aceptación específicos, y consideraciones de seguridad, auditoría, rendimiento y usabilidad. Basado en patrón establecido por informes contables que ya soportan modos.

Retenciones

Ganancias

Retenciones

Carga de Asientos Contables No Oficiales - Modos de Operación ​

Descripción General ​

Propósito ​

Problema de Negocio ​

Valor de Negocio ​

Contexto en el Flujo Contable ​

Modos de Operación ​

Modo No Oficial ​

Modo Oficial ​

Comportamiento por Operación ​

Alta (Crear Nuevo Asiento) ​

Modificación (Editar Asiento Existente) ​

Baja (Eliminar Asiento Existente) ​

Reglas de Negocio ​

RN-CAP-001: Aislamiento de Datos por Modo ​

RN-CAP-002: Comportamiento en Alta - Cambio Libre de Modo ​

RN-CAP-003: Comportamiento en Modificación - Confirmación + Recarga ​

RN-CAP-004: Comportamiento en Baja - Confirmación + Recarga ​

RN-CAP-005: Numeración Compartida y Consecutiva ​

RN-CAP-006: Validaciones según Modo ​

RN-CAP-008: Auditoría por Modo ​

Frontend (Perspectiva de Negocio) ​

Vistas ​

Interacciones del Usuario ​

Permisos ​

Estados de UI ​

Backend (Perspectiva de Datos de Negocio) ​

Entidades de Negocio ​

Datos Necesarios ​

Relaciones de Negocio ​

Validaciones de Negocio ​

Casos de Uso ​

UC-CAP-001: Crear Asiento en Modo No Oficial y Cambiar a Modo Oficial Antes de Guardar ​

UC-CAP-002: Modificar Asiento Oficial y Cambiar Accidentalmente a Modo No Oficial ​

UC-CAP-003: Consultar Asientos en Modo No Oficial ​

UC-CAP-004: Eliminar Asiento en Modo No Oficial y Cambiar a Modo Oficial ​

UC-CAP-005: Trabajar Exclusivamente en No Oficial para Cierre de Ejercicio ​

Consideraciones ​

Seguridad ​

Auditoría ​

Rendimiento ​

Usabilidad ​

Dependencias ​

Funcionalidades Relacionadas ​

Integraciones ​

Criterios de Aceptación ​

Funcionales - Modo ​

Funcionales - Operación Alta ​

Funcionales - Operación Modificación ​

Funcionales - Operación Baja ​

Funcionales - Numeración ​

Funcionales - Validaciones ​

Seguridad y Permisos ​

Auditoría ​

UI/UX ​

Notas Adicionales ​

Relación con Informes Existentes que Soportan Modos ​

Importancia Crítica de la Prevención de Pérdida de Datos ​

Posibles Mejoras Futuras ​

Referencias a Documentación Relacionada ​

Consideraciones de Migración y Adopción ​

Historial de Cambios ​

Carga de Asientos Contables No Oficiales - Modos de Operación

Descripción General

Propósito

Problema de Negocio

Valor de Negocio

Contexto en el Flujo Contable

Modos de Operación

Modo No Oficial

Modo Oficial

Comportamiento por Operación

Alta (Crear Nuevo Asiento)

Modificación (Editar Asiento Existente)

Baja (Eliminar Asiento Existente)

Reglas de Negocio

RN-CAP-001: Aislamiento de Datos por Modo

RN-CAP-002: Comportamiento en Alta - Cambio Libre de Modo

RN-CAP-003: Comportamiento en Modificación - Confirmación + Recarga

RN-CAP-004: Comportamiento en Baja - Confirmación + Recarga

RN-CAP-005: Numeración Compartida y Consecutiva

RN-CAP-006: Validaciones según Modo

RN-CAP-008: Auditoría por Modo

Frontend (Perspectiva de Negocio)

Vistas

Interacciones del Usuario

Permisos

Estados de UI

Backend (Perspectiva de Datos de Negocio)

Entidades de Negocio

Datos Necesarios

Relaciones de Negocio

Validaciones de Negocio

Casos de Uso

UC-CAP-001: Crear Asiento en Modo No Oficial y Cambiar a Modo Oficial Antes de Guardar

UC-CAP-002: Modificar Asiento Oficial y Cambiar Accidentalmente a Modo No Oficial

UC-CAP-003: Consultar Asientos en Modo No Oficial

UC-CAP-004: Eliminar Asiento en Modo No Oficial y Cambiar a Modo Oficial

UC-CAP-005: Trabajar Exclusivamente en No Oficial para Cierre de Ejercicio

Consideraciones

Seguridad

Auditoría

Rendimiento

Usabilidad

Dependencias

Funcionalidades Relacionadas

Integraciones

Criterios de Aceptación

Funcionales - Modo

Funcionales - Operación Alta

Funcionales - Operación Modificación

Funcionales - Operación Baja

Funcionales - Numeración

Funcionales - Validaciones

Seguridad y Permisos

Auditoría

UI/UX

Notas Adicionales

Relación con Informes Existentes que Soportan Modos

Importancia Crítica de la Prevención de Pérdida de Datos

Posibles Mejoras Futuras

Referencias a Documentación Relacionada

Consideraciones de Migración y Adopción

Historial de Cambios