Atribución de Cargo/Abono por documento
El problema: Poliza_Detalle no baja al nivel de documento
Poliza_Detalle.Pd_Referencia solo referencia el Gr_Folio, nunca el Grd_ID
específico. Cuando un folio tiene un solo documento el join es 1 a 1 sin ambigüedad;
cuando tiene 2 o más (~7-8% de los folios “normales” de un mes típico), no hay forma
directa de saber a cuál documento corresponde cada línea de póliza — es un dato a nivel
folio, no por documento.
Emparejamiento por valor vía Gasto_Registro_Control
Gasto_Registro_Control sí desglosa cada documento por centro de costo (ver
Modelo de datos). Dentro de un mismo (folio, centro de costo),
las líneas de Gasto_Registro_Control (agrupadas por documento) y las de
Poliza_Detalle (que también trae Pd_Centro_Costo) se generan en MPRO en el mismo
momento — y coinciden exacto en importe cuando se ordenan ambos lados por valor, no
por orden de creación. Este último punto no es trivial: se verificó con un folio de
depreciación real (8 documentos, 642 líneas de póliza en 77 centros de costo) que el
documento con el importe más grande no cae en la misma posición de inserción del lado
de la póliza — cae en la posición que le corresponde por valor. Ordenar por orden de
creación en vez de por valor da resultados silenciosamente incorrectos (misma cuenta,
documento equivocado); ordenar por valor con ROW_NUMBER() en ambos lados y emparejar
posición a posición es exacto.
Reglas, de más a menos preciso:
- Exacto: mismo conteo de documentos en ambos lados dentro de
(folio, centro de costo)→ emparejamiento 1 a 1 por valor. - Proporcional: conteo distinto pero datos en ambos lados (la póliza combinó 2+
documentos idénticos en una sola línea, o viceversa) → se reparte el importe de la
póliza entre los documentos en proporción a lo que cada uno aportó en
Gasto_Registro_Control. - Respaldo (a nivel folio): sin centro de costo capturado, o un centro que no
aparece del todo en
Gasto_Registro_Controlpara ese folio → se agrega por folio y se pega al último documento — mismo comportamiento que las versiones que no distinguen por documento.
En la práctica (validado contra un año completo de datos), el respaldo termina siendo necesario solo para un puñado de folios de un solo documento (donde no hay ambigüedad de todos modos) — cero folios con ambigüedad real de múltiples documentos quedan sin resolver con este método.
Regla de inclusión de Abono (y por qué Cargo NO se filtra igual)
Un Pd_Tipo=2 (Abono) solo cuenta como reducción real de gasto si la cuenta es de raíz
'F' (Gastos) en el árbol de Grupo_Cuenta_Contable, o —cuando la cuenta no tiene
grupo asignado (hueco de catálogo)— si empieza con 6 o su descripción es “Gastos a
cuenta de costo estandar” (ver Modelo de datos).
Esta misma regla no se puede aplicar a Cargo (Pd_Tipo=1): hay miles de líneas de
Cargo legítimas en cuentas que tampoco tienen raíz 'F' — cuentas de depreciación
acumulada (raíz E, familia 1140.xxx) y de costo integral de financiamiento (raíz
G, intereses) son gasto real aunque su raíz contable no sea F. Filtrar Cargo por
raíz de la misma forma rompería esos folios (se verificó: ~125 líneas / $2.66M de enero
2026 quedarían mal excluidas). La asimetría es intencional, no un descuido.
Reversiones contables reales (Importe negativo)
Cuando el Importe de un folio (sumado por documento) es negativo, el folio es una
reversión/saldo de una operación previa, no un gasto nuevo — típicamente reclasificación
de nómina o ajustes de renta de maquinaria. En estos folios la póliza trae Cargo y Abono
a la vez, pero el lado Cargo cae en una cuenta de Provisión/Pasivo por pagar (no un
gasto real, es la contrapartida de la reversión), mientras el Abono sí es la cuenta de
Gastos real que se está reduciendo — y por sí solo ya es igual al Importe (con signo),
por garantía de partida doble (una reversión siempre tiene Cargo Abono monto
revertido, porque se está deshaciendo una póliza anterior).
Regla: si Importe_folio ≤ −$1, se usa solo el Abono (el Cargo se pone en 0). Se probó
primero excluir por nombre de cuenta (“Provision”/“por pagar”) en vez de por esta
combinación — resultó ser una mala idea: esas mismas cuentas se usan legítimamente como
Cargo en folios de Importe positivo (costeo estándar, donde la expensa se reconoce
contra una cuenta “Provision” de forma normal). La regla por combinación
Importe+neto a nivel folio nunca toca esos folios porque exige Importe negativo.
Resultado
Con las reglas de arriba, un año completo de datos de Trivasa reconcilia al 99.9%+ (Cargo − Abono == Importe por documento), y el 100% de las discrepancias restantes tiene una explicación conocida (ruido de redondeo menor a $1, o un único folio sin ninguna línea de póliza capturada en MPRO) — cero casos sin explicar.
Véase también
- Layout de Gastos — panorama general del reporte.
- Modelo de datos — las tablas de origen y los bugs de datos que motivaron algunas de estas reglas.
- Versiones y cuándo usar cada una — en qué versión del reporte está implementado cada nivel de precisión.