Agregar República Dominicana y ajustes finales del portal
This commit is contained in:
@@ -0,0 +1,182 @@
|
||||
# Cruce de Cuentas GLM — República Dominicana (RD)
|
||||
|
||||
## Objetivo
|
||||
|
||||
Dejar República Dominicana integrada al Portal de Cruce de Cuentas con una lógica reutilizable cada quincena, todos los meses y años, usando la misma arquitectura multi-país ya existente.
|
||||
|
||||
Configuración RD:
|
||||
|
||||
- Código: `RD`
|
||||
- Moneda: `DOP`
|
||||
- Locale: `es-DO`
|
||||
- Zona horaria: `America/Santo_Domingo`
|
||||
- RRHH destinataria de reportes: **Noralmy Laureano** — `nlaureano@gomezleemarketing.com`
|
||||
- Bandera: `https://dbit.digitalcompass.agency/storage/v1/object/public/public-assets/Flag_of_the_Dominican_Republic.svg.webp`
|
||||
|
||||
## Archivos incluidos
|
||||
|
||||
### n8n
|
||||
|
||||
Importar desde `workflows_n8n/`:
|
||||
|
||||
1. `Portal de Verificación de Nómina - República Dominicana.json`
|
||||
2. `Portal de Verificación de Nómina República Dominicana - Históricos.json`
|
||||
3. `Portal de Verificación de Nómina República Dominicana - Envío de Reporte.json`
|
||||
4. `Portal de Verificación de Nómina - Analizar Nómina con Gemini GT TT PA SV HN PR RD.json`
|
||||
5. `Portal de Verificación de Nómina - Reportar corrección BambooHR a RRHH - GT TT PA SV HN PR RD.json`
|
||||
|
||||
Los workflows se entregan **inactivos** para que puedan importarse/configurarse sin disparar una ejecución accidental. Los dos workflows compartidos (Gemini y correcciones BambooHR) sustituyen las versiones equivalentes sin RD una vez validados.
|
||||
|
||||
### Supabase
|
||||
|
||||
Ejecutar:
|
||||
|
||||
`SUPABASE_Republica_Dominicana_READY.sql`
|
||||
|
||||
Este script habilita `RD` en las restricciones multi-país, accesos, alias BambooHR e históricos/RPC existentes. La tabla `cruces_cuentas_gt_reportes` conserva su nombre legado, pero funciona como tabla multi-país.
|
||||
|
||||
## Webhooks RD
|
||||
|
||||
- Cruce principal: `/webhook/nominard-bamboo-test`
|
||||
- Históricos: `/webhook/cruce-cuentas-rd-historicos`
|
||||
- Marcar resuelto: `/webhook/cruce-cuentas-rd-marcar-resuelto`
|
||||
- Analizar nómina con Gemini: webhook compartido `/webhook/cruce-cuentas-analizar-nomina`
|
||||
- Reportar corrección BambooHR: webhook compartido `/webhook/cruce-cuentas-bamboo-correccion`
|
||||
|
||||
La app ya contiene las variables `VITE_N8N_REPUBLICA_DOMINICANA_WEBHOOK_URL`, `VITE_HISTORICOS_RD_URL` y `VITE_MARCAR_RESUELTO_RD_URL`.
|
||||
|
||||
## Entrada esperada cada quincena
|
||||
|
||||
### Nómina
|
||||
|
||||
RD requiere **exactamente un Excel de nómina** (`.xlsx`, `.xls` o `.xlsm`) por período. El flujo valida que el archivo tenga filas de empleados cuyo campo `PERÍODO` corresponda al rango seleccionado en la app; si detecta empleados de otro período, se detiene para evitar cruzar una nómina equivocada.
|
||||
|
||||
Hojas operativas observadas y soportadas tras analizar las 16 nóminas de enero a agosto de 2026:
|
||||
|
||||
- `GLM RD `
|
||||
- `Whirlpool`
|
||||
- `Bice`
|
||||
- `P&G`
|
||||
- `KRAFT`
|
||||
- `Motorola`
|
||||
- `PMI`
|
||||
- `Caribe`
|
||||
- `Latam `
|
||||
- `Purina`
|
||||
- `Claro`
|
||||
- `Essity`
|
||||
|
||||
Se excluyen hojas auxiliares como `Resumen`, `Validacion TSS`, `Validacion ISR`, `ISR`, `Calculo Horas extras`, `NVScriptsProperties`, AutoCrat, copias auxiliares como `Copia de Latam ` y hojas genéricas que no forman parte de la nómina operativa.
|
||||
|
||||
Campos utilizados: nombre, cuenta, `NETO A PAGAR`, `PERÍODO` y, cuando existen, cédula, referencia y correo.
|
||||
|
||||
### Banco
|
||||
|
||||
Se aceptan **uno o varios archivos CSV y/o PDF** de la misma quincena. Esto es indispensable en RD porque una quincena puede incluir lotes normales, temporales, suplementos y ACH separados.
|
||||
|
||||
El parser CSV soporta los formatos observados en 2026 y nombres de archivos como:
|
||||
|
||||
- BICE
|
||||
- CLARO
|
||||
- GLM
|
||||
- Kraft
|
||||
- LATAM
|
||||
- Motorola
|
||||
- P&G
|
||||
- PMI
|
||||
- Purina
|
||||
- Temp Purina
|
||||
- Temp Moto
|
||||
- Whirlpool
|
||||
- Essity / Temp Essity
|
||||
- Bono BICE / Bono BICE inactivos
|
||||
|
||||
También admite sufijos de lote como `.1.csv` y normaliza el texto `N#U00f3minas` que aparece en algunos nombres exportados.
|
||||
|
||||
Los PDF BHD se interpretan como ACH complementarios. El flujo extrae beneficiario, cuenta, fecha efectiva, monto, estado, motivo, número de instrucción y descripción. La fecha de cada CSV/PDF se valida contra el período seleccionado.
|
||||
|
||||
## Reglas de conciliación RD
|
||||
|
||||
La lógica final está construida a partir de los cuatro reportes de entrenamiento de junio/julio 2026.
|
||||
|
||||
1. Se normalizan cuentas eliminando formato visual/ceros iniciales solo para comparación; el valor visible se conserva cuando corresponde.
|
||||
2. La prioridad de match es **cuenta + monto**.
|
||||
3. Cuando nómina no trae cuenta, se permite match por **nombre fuerte + monto**, evitando forzar coincidencias ambiguas.
|
||||
4. Se usa tolerancia monetaria de **RD$0.05 por transacción**.
|
||||
5. Un pago rechazado se conserva como hallazgo y puede explicar una discrepancia Nómina > Banco.
|
||||
6. Antes de clasificar `Banco sin Nómina`, se hace una segunda búsqueda para detectar una **posible cuenta mal digitada** usando nombre/referencia/correo + monto.
|
||||
7. Los suplementos `Bono BICE` se integran como pago esperado adicional para que formen parte del total de nómina de conciliación, igual que en el reporte patrón de 15-jun-2026.
|
||||
8. `Banco sin Bamboo` es una revisión paralela y **no se suma a `Pendientes cruce principal`**, tal como muestran los reportes oficiales de entrenamiento.
|
||||
9. Las diferencias de nombre bancario se mantienen como `Pendiente revisión`; no se fuerzan como identidad confirmada.
|
||||
10. Diferencias agregadas insignificantes de centavos no generan una discrepancia si todas las transacciones individuales conciliaron dentro de tolerancia.
|
||||
11. Las transacciones bancarias duplicadas exactas entre dos archivos/lotes provocan error para evitar doble contabilización.
|
||||
|
||||
## BambooHR
|
||||
|
||||
La consulta usa:
|
||||
|
||||
`/api/v1/reports/custom?format=JSON&onlyCurrent=false`
|
||||
|
||||
Esto permite validar también empleados históricos que pudieron participar en una quincena anterior. El filtro RD reconoce país/localización como `RD`, `República Dominicana`, `Dominican Republic` y variantes de localización dominicana.
|
||||
|
||||
El flujo usa Employee Number cuando está disponible y trabaja con alias de nombres. Las correcciones manuales confirmadas pueden persistirse en Supabase mediante el workflow compartido de correcciones.
|
||||
|
||||
## Reporte de salida
|
||||
|
||||
El Google Sheet conserva siempre las seis pestañas patrón de RD:
|
||||
|
||||
1. `01 Nómina vs Banco`
|
||||
2. `02 Banco sin Nómina`
|
||||
3. `03 Banco sin Bamboo`
|
||||
4. `04 Diferencias nombre banco`
|
||||
5. `05 Cuenta Mal Digitada`
|
||||
6. `06 Resumen`
|
||||
|
||||
La pestaña 05 se crea incluso cuando no existen casos, para que el formato sea estable entre quincenas.
|
||||
|
||||
Las hojas se protegen para preservar datos calculados. La columna `Resolución` queda reservada para RRHH/administración autorizada; Noralmy Laureano está incluida entre las personas autorizadas para RD. El reporte también se comparte automáticamente con los accesos internos configurados.
|
||||
|
||||
## Correo RD
|
||||
|
||||
El correo automático del reporte generado se envía a:
|
||||
|
||||
`nlaureano@gomezleemarketing.com`
|
||||
|
||||
Utiliza branding GLM, bandera RD y muestra los indicadores relevantes del cruce. El workflow de `Marcar resuelto` también está adaptado a RD y utiliza la zona horaria de Santo Domingo.
|
||||
|
||||
## Históricos
|
||||
|
||||
Los históricos se guardan con `country = RD` y una identidad de período del tipo:
|
||||
|
||||
`RD-2026-06-quincena_15`
|
||||
|
||||
Si se vuelve a procesar el mismo período, la arquitectura reutiliza/actualiza el reporte existente y conserva resoluciones compatibles en lugar de crear duplicados innecesarios.
|
||||
|
||||
## Detección automática de período
|
||||
|
||||
Se actualizó el analizador compartido Gemini y el detector local de la app. Para RD se reconocen:
|
||||
|
||||
- día 15 → `quincena_15`
|
||||
- día 30/31 → `quincena_30`
|
||||
- último día real del mes → `quincena_30` (por ejemplo, 28/29 de febrero)
|
||||
|
||||
Se validaron correctamente los 16 nombres reales de nómina de enero a agosto de 2026.
|
||||
|
||||
## Orden de despliegue recomendado
|
||||
|
||||
1. Hacer respaldo de los workflows actualmente publicados.
|
||||
2. Ejecutar `SUPABASE_Republica_Dominicana_READY.sql`.
|
||||
3. Importar el workflow principal RD.
|
||||
4. Importar Históricos RD.
|
||||
5. Importar Envío de Reporte RD.
|
||||
6. Reemplazar/actualizar el analizador compartido por la versión `... PR RD`.
|
||||
7. Reemplazar/actualizar el workflow de correcciones BambooHR por la versión `... PR RD`.
|
||||
8. Confirmar que las credenciales de BambooHR, Google Sheets/Drive y Gmail quedaron asociadas tras la importación.
|
||||
9. Desplegar el frontend desde el código fuente actualizado (`npm ci && npm run build`).
|
||||
10. Activar los cinco workflows una vez revisados los paths de webhook.
|
||||
11. Ejecutar una prueba controlada con una de las cuatro quincenas conocidas y comparar con `VALIDACION_REPUBLICA_DOMINICANA_FINAL.md`.
|
||||
12. Ejecutar después una quincena nueva/no entrenada antes de declararlo operación mensual definitiva.
|
||||
|
||||
## Nota de despliegue frontend
|
||||
|
||||
El `dist` heredado del ZIP original no debe usarse porque fue generado antes de incorporar RD. El entregable final de RD se prepara sin ese `dist` antiguo; el servidor de despliegue debe instalar dependencias y generar un `dist` nuevo desde el código fuente actualizado.
|
||||
Reference in New Issue
Block a user