Tul xxx Tul

Viewing: parametros.md

# Parámetros — Estado de sugerencias

## Leyenda de estado
- ✅ Hecho
- 🟨 En progreso
- ⬜ Pendiente
- ⛔ Bloqueado / Requiere decisión

## Fortalecimiento de debilidades

### Usuarios (seguridad y gobierno)
- ✅ Asociar usuarios a empresas (ej. `user_company_access` / permisos por empresa).
- ⬜ Agregar auditoría de cambios (ej. tabla `audit_log`: quién/qué/cuándo).
- 🟨 Completar matriz de permisos por rol (no solo Admin) y mantenerla consistente en UI + backend.

### Empresas (contexto contable base)
- ✅ Restringir “empresa activa” según acceso del usuario (no solo por sesión).
- ⬜ Definir estado de empresa “bloqueada/cerrada” para impedir cambios de catálogos.
- ⬜ Definir estrategia de re-sincronización del plan base (`company_id=0`) hacia empresas (versionado o “sync controlado”).

### Catálogos contables (cuentas, tipos, centros, periodos)
- ⬜ Definir política de eliminación cuando existan movimientos: “no borrar si está usado” (solo inactivar).
- ⬜ Validar relaciones con `is_active` (ej. evitar usar cuentas inactivas en plantillas).
- ⬜ Definir reglas sobre edición de códigos (ej. si se permite cambiar `accounts.code` después de estar en uso).

## Implementación para evitar riesgos
- ⬜ Bloqueo por cierre: impedir registrar/editar asientos en periodos cerrados.
- ⬜ Definir si puede existir más de un periodo abierto y cuál es el periodo por defecto.
- ⬜ Numeración transaccional para comprobantes (reservar/bloquear `next_number` ante concurrencia).
- ✅ Numeración transaccional para traslados (prefijo + consecutivo con bloqueo transaccional).
- ⬜ Validación contable en asientos reales: total débito = total crédito.
- ⬜ Reglas de integridad futura: impedir inactivar cuentas/centros “con movimientos” (cuando existan asientos).

## Desarrollo de previsiones recomendadas

### Parámetros contables por empresa (MVP)
- ✅ Periodo contable actual por defecto (ej. `accounting_period_id`).
- ⬜ Política de numeración (por tipo / por periodo / por sucursal / por centro de costo).
- ✅ Centro de costo: obligatorio u opcional, por asiento o por línea, y centro por defecto.
- ⬜ Moneda funcional vs moneda de presentación + formato/redondeo.
- ⬜ Políticas de cierre (qué se bloquea, cuándo, y cómo reabrir).

### Catálogos operativos (multisucursal)
- ✅ Sucursales (catálogo por empresa, predeterminada, responsable, activo/inactivo).
- ✅ Traslados entre sucursales (cabecera + líneas, estados borrador/enviado/recibido/cancelado, consecutivo).

### Asientos contables (comprobantes reales)
- ⬜ Modelo de cabecera (empresa, fecha, periodo, tipo, número, estado).
- ⬜ Modelo de líneas (cuenta, débito/crédito, memo, centro de costo según política).
- ⬜ Estados (borrador/contabilizado) y reglas de edición/anulación.

### Reportes básicos
- ⬜ Libro diario.
- ⬜ Libro mayor.
- ⬜ Balanza de comprobación.
- ⬜ Estados financieros.

### Gobernanza
- ⬜ Permisos por rol/empresa + auditoría.

---

## Referencia (análisis original)

Informe técnico: secciones de Configuración (relaciones, “parámetros” que generan, fortalezas/debilidades y previsiones)
A continuación te presento un análisis exhaustivo basado en la implementación actual (PHP MVC + PDO, sesiones, CSRF, middlewares, tablas y vistas ya creadas). Incluye cómo se conectan las secciones y qué “parámetros” están dejando listos para el módulo contable, y qué conviene ajustar antes de seguir (especialmente porque “Parámetros” aún no existe).

1) Mapa general de dependencias (qué habilita a qué)
Núcleo transversal
Autenticación (users + AuthController)
Determina quién entra al sistema y su rol.
Empresa activa en sesión (active_company_id)
Es el “scope” de casi todos los catálogos contables (cuentas, periodos, centros de costo, tipos de asiento).
Se establece desde Empresas → Seleccionar o automáticamente desde Controller::view() usando la primera empresa.
Catálogos contables (por empresa)
Plan de cuentas (accounts)
Base para: líneas de asientos, reportes, y plantillas.
Tipos de Asientos (entry_types + entry_type_lines)
Plantillas que referencian accounts.
Define lógica de numeración (prefijo + next_number).
Centros de costos (cost_centers)
Catálogo adicional para análisis contable (aún no ligado a asientos reales porque ese módulo aún no está).
Periodos contables (accounting_periods)
Define intervalos (start/end), estado abierto/cerrado y activo/inactivo.
Sección pendiente: Parámetros
Debería ser el lugar donde se centraliza:

Políticas contables por empresa (cierre, numeración, reglas de validación, moneda secundaria, etc.)
Valores por defecto (periodo activo, centro de costo por defecto, etc.)
2) Análisis por sección
A) Usuarios (seguridad y gobierno)
Qué “parametriza” para contabilidad
Define roles y por ende qué se puede modificar (admin vs no admin).
Hoy impacta directamente en:
posibilidad de crear/editar/eliminar catálogos (cuentas, tipos, centros, periodos).
Fortalezas
Autenticación con hash seguro (password_hash/password_verify).
CSRF en acciones sensibles.
AdminMiddleware bloquea acciones POST de catálogos (buena base).
Debilidades / riesgos
Usuarios no están asociados a empresa (no hay company_id en users).
Si luego quieres multiempresa con permisos por empresa, faltará ese vínculo.
Roles “hardcoded”: Administrador, Contador, Cajero, Supervisor, pero solo “Administrador” tiene permisos efectivos.
No hay auditoría de cambios (quién cambió cuentas/periodos, etc.)
Previsiones recomendadas
Próximo paso (antes de contabilidad real):
Definir matriz de permisos real por rol (ej. Contador puede crear asientos pero no borrar cuentas).
(Opcional) Introducir user_company_access si quieres multiempresa real.
B) Empresas (contexto contable base)
Qué “parametriza”
En companies ya están:

Moneda (currency)
Año fiscal (fiscal_year)
Datos generales (tax_id, dirección, logo)
Además:

Al crear o seleccionar empresa se ejecuta Account::syncFromTemplate(companyId, 0):
Esto clona el plan base (company_id=0) hacia la empresa (muy útil para arranque).
Fortalezas
Manejo de empresa activa por sesión (active_company_id) y fallback automático (Controller).
Copia automática del plan de cuentas base al crear/seleccionar empresa.
Validación de moneda contra catálogo currencies_es().
Debilidades / riesgos
No hay control de integridad para “empresa activa” vs usuario
Cualquier usuario autenticado puede “Seleccionar” empresa (aunque crear/editar esté restringido a admin).
No existe la noción de “empresa bloqueada” o “empresa cerrada” (para impedir cambios de catálogos).
Account::syncFromTemplate usa INSERT IGNORE y deja el resto como estaba:
Si el template (company_id=0) cambia, no “actualiza” lo ya copiado.
Previsiones recomendadas
Antes de “asientos reales”, definir:
si la empresa activa debe estar limitada por permisos del usuario.
si existirán “plantillas de plan” versionadas o “re-sincronización controlada”.
En la futura sección Parámetros, conviene mover o reflejar:
moneda funcional vs moneda de presentación,
año fiscal,
políticas de cierre.
C) Plan de Cuentas (accounts)
Qué “parametriza”
Estructura contable: type, nature, code, level, jerarquía.
Campos extra importados (tipo_es, categoria_es, etc.) provenientes de accounts_plan_csv_import.
Naturaleza es clave porque alimenta:
auto-selección de naturaleza en Tipos de Asiento,
validaciones contables futuras.
Fortalezas
Multiempresa: company_id en cuentas.
Unicidad: UNIQUE(company_id, code).
Jerarquía soportada (parent_id, level).
UI con filtros ricos (tipo/naturaleza/estado/búsqueda).
Sincronización desde template company_id=0.
Debilidades / riesgos
Borrado de cuentas: hoy solo evita borrar si tiene hijos, pero no contempla:
referencias futuras (asientos reales, plantillas, centros).
Falta regla: “no permitir inactivar cuentas con movimientos” (cuando existan asientos).
No hay “cierre” sobre cuentas (bloqueo por periodo, por ejemplo).
Previsiones recomendadas
Cuando se implemente el módulo de asientos reales:
añadir validación “no se puede eliminar cuenta si está usada”.
decidir si “inactivar” debe estar permitido con historial.
Definir en Parámetros:
reglas de creación de códigos,
si se permite editar código una vez usado.
D) Tipos de Asientos (entry_types)
Qué “parametriza”
Plantillas de asientos:
cabecera: code, name, prefix, next_number, is_active
líneas: account_id + nature + memo
Son un “generador de comprobantes” (cuando exista el módulo de asientos).
Fortalezas
Diseño sólido de datos:
entry_types + entry_type_lines con FK y ON DELETE CASCADE.
UI rica:
crear/editar con editor dinámico de líneas,
auto-naturaleza por cuenta (basado en accounts.nature),
validación mínima (2 líneas + al menos 1 débito y 1 crédito),
botón “Ver” detalle.
Control de permisos:
lectura para autenticados,
cambios solo admin.
Debilidades / riesgos
Aún no se valida balance (porque es plantilla, pero en asientos reales será clave):
podría requerirse regla: total débito = total crédito si se agregan montos.
next_number aún no está “reservado” transaccionalmente contra asientos reales (porque aún no existe).
No se valida si una cuenta está inactiva al usarla en la plantilla (solo existsInCompany, no is_active).
Previsiones recomendadas
Antes de implementar asientos reales:
decidir si plantillas pueden apuntar a cuentas inactivas (mi recomendación: no, o al menos advertencia).
definir en “Parámetros” la estrategia de numeración:
por tipo de asiento (ya existe next_number),
por periodo,
por sucursal/centro de costo (si existirá).
al crear asientos reales: bloquear concurrentemente la numeración.
E) Centros de Costos (cost_centers)
Qué “parametriza”
Catálogo para análisis de rentabilidad y segmentación.
Está listo para ser asignado a:
asientos (cabecera o línea),
reportes (libro mayor por centro, etc.)
Fortalezas
Multiempresa con FK a companies.
Jerarquía soportada (parent_id, level).
UI con filtros y estado activo.
Debilidades / riesgos
No está integrado aún con ninguna entidad de movimiento (asientos).
El FK parent_id usa ON DELETE RESTRICT y el controlador además evita borrar con hijos: bien, pero
falta política cuando tenga movimientos (no borrar nunca, solo inactivar).
No hay campo “tipo” (operativo/administrativo/etc.) ni presupuesto (si lo quieres a futuro).
Previsiones recomendadas
Decidir desde ya (en “Parámetros”):
centro por asiento vs por línea.
si es obligatorio o opcional.
centro por defecto.
F) Periodos Contables (accounting_periods)
Qué “parametriza”
Define ventanas de operación contable:
start/end,
cierre (open/closed),
activo/inactivo.
Fortalezas
Modelo claro con status + closed_at.
Validación de no solapamiento (en backend).
UI con filtros + toggle de cierre y activo.
Debilidades / riesgos
Hoy el cierre es informativo, aún no bloquea nada porque no hay asientos reales.
status es varchar (válido) pero sin constraint SQL (en MySQL no hay CHECK real en versiones antiguas).
No existe “periodo actual” o “periodo por defecto” a nivel empresa.
Previsiones recomendadas
Antes de asientos reales:
definir regla: no permitir crear/editar asientos en periodos cerrados.
definir regla: ¿puede haber más de un periodo abierto?
definir periodo activo (por defecto) en “Parámetros”.
3) Relación entre secciones: “qué se está generando para la herramienta contable”
Hoy ya tienes el esqueleto de parametrización:

Empresa
moneda + año fiscal + “empresa activa” (scope)
Plan de cuentas
catálogo base y naturaleza de cuentas
Tipos de asientos
plantillas con cuentas y naturaleza (prepara automatización)
Centros de costos
catálogo de segmentación (para reportes)
Periodos
calendario contable + cierre (para control)
En otras palabras, estas secciones ya producen casi todos los “inputs” necesarios para:

libro diario / mayor,
balanza,
estados financieros,
cierres y bloqueo.
Lo único que falta para “contabilidad operativa real” es:

módulo de Asientos (comprobantes reales) + sus líneas y validaciones,
y la sección Parámetros para centralizar políticas.
4) Fortalezas globales del diseño actual
Patrón consistente (CRUD + offcanvas + filtros + middlewares).
Multiempresa real para catálogos contables (accounts, entry_types, cost_centers, periods).
CSRF + roles aplicados en todas las acciones sensibles.
Estructuras SQL razonables con claves únicas por empresa y FKs donde aplica.
UX consistente y rápida: filtros live, toggles, confirm modal reutilizable.
5) Debilidades globales / riesgos antes de seguir
No existe aún la capa de “Parámetros”, por lo que reglas claves están dispersas o implícitas:
“periodo actual”
políticas de numeración
obligatoriedad de centro de costo
restricciones por rol
bloqueo por cierre
No hay contabilidad transaccional todavía:
sin asientos reales, no se puede verificar integridad “en uso” (no borrar cuentas/centros/periodos).
Gobernanza multiempresa incompleta:
usuarios no están ligados a empresas, y selección de empresa está abierta a autenticados.
Integridad referencial aún incompleta por falta de movimientos:
cuando existan asientos, habrá que agregar FKs y políticas (RESTRICT vs soft delete).
6) Ajustes/previsiones recomendadas (antes de desarrollar más)
Te dejo un checklist priorizado:

Prioridad Alta (antes de asientos reales)
Definir “Parámetros contables” por empresa (aunque sea mínimo):
periodo actual (accounting_period_id)
política de numeración (por tipo, por periodo, etc.)
exigir o no centro de costo
permitir o no asientos en periodo cerrado (debe ser NO)
moneda funcional y formato de redondeo
Bloqueo por cierre
Cuando exista asientos reales: validar que el periodo esté open para registrar/editar.
Políticas de eliminación
Definir que catálogos no se eliminan si están usados (solo inactivar).
Prioridad Media (mejoras de calidad y control)
Asociar usuarios a empresas / permisos por empresa (si aplica a tu negocio).
Agregar auditoría simple de cambios (tabla audit_log).
Validaciones de “is_active” en relaciones:
evitar usar cuentas inactivas en plantillas.
Prioridad Baja (UX y refinamientos)
“periodo por defecto” seleccionado en UI.
mejores mensajes (por qué no se puede cerrar si hay asientos pendientes, etc.) cuando exista el módulo de asientos.
7) Orden recomendado de desarrollo (para minimizar retrabajo)
Parámetros (mínimo viable): definir políticas contables por empresa.
Asientos contables (comprobantes reales):
cabecera: empresa, fecha, periodo, tipo de asiento, número, estado (borrador/contabilizado)
líneas: cuenta, débito/crédito, memo, centro de costo (según política)
Reportes básicos: libro diario, mayor, balanza (usando periodos, cuentas y centros).
Mejoras de gobernanza: permisos por rol/empresa + auditoría.
Estado
Informe entregado con relaciones, fortalezas/debilidades y previsiones.
Si me confirmas cómo planeas manejar “Asientos reales” (por línea vs cabecera centro de costo; y numeración por periodo o global por tipo), te propongo el diseño exacto de la sección Parámetros para que encaje sin retrabajo.
User / IP	: 216.73.216.217
Host / Server	: 45.84.207.204 / aircan.me
System	: Linux lt-bnk-web1726.main-hosting.eu 5.14.0-611.36.1.el9_7.x86_64 #1 SMP PREEMPT_DYNAMIC Tue Mar 3 11:23:52 EST 2026 x86_64