cruce-cuentas-glm-centralizado/IMPLEMENTACION_REPUBLICA_DOMINICANA_READY.md

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.