SOURCE-003 Query Delta Review¶

Fecha: 2026-06-10

Estado: IMPACTO MEDIO / V2 TABLA 2 REVALIDADA EXPLICITA / HORA PRESERVADA

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/source-authority/SOURCE-003-QUERY-DELTA-REVIEW.md

1. Objetivo¶

Comparar documentalmente la autoridad SOURCE-003 / Ventas vNext Tabla 2 preservada como V1 contra la query actual completa pegada por Gabi y registrada como V2 candidata.

Esta revision textual inicial no ejecuto queries, no tomo snapshots, no cargo datos, no toco PostgreSQL, no modifico tablas y no avanzo sync. La revalidacion real posterior de Tabla 2 V2 queda agregada en la seccion 18.

2. Safe point¶

git status -sb: ## main...origin/main
git rev-parse HEAD: 59a2be84bed14ca57d6b5e5bb6325fd697f9f1e8

3. Archivos comparados¶

V1 preservada: docs/tenants/alpuntodeventa/business-observer/source-authority/SOURCE-003-VENTAS-VNEXT-TABLA2-AUTHORITY.sql

V2 candidata nueva: docs/tenants/alpuntodeventa/business-observer/source-authority/SOURCE-003-VENTAS-VNEXT-TABLA2-AUTHORITY-V2.sql

Nota humana:

Gabi aclaro durante esta auditoria que la query pegada omitio Hora por olvido
Hora debe quedar incluida en la query definitiva
V2 se preserva como candidata corregida con Hora, sin tocar calculos, joins ni filtros

Delta funcional final V1 vs V2 corregida, ignorando espacios finales normalizados para que git diff --check pase:

Metrica	Resultado
diff funcional	`3` inserciones / `3` eliminaciones
sha256 V1	`4F49A9E0E8BD1475C17B1EBD2C510CE684AAC165D93657ED1443E0CFBB3214DC`
sha256 V2 corregida	`F23B671E2AC6C20E0A62734124A279573A8153BC187082B2F5E1C75A078ABF71`

4. Resumen ejecutivo¶

La V2 corregida conserva Hora en #base_raw y en Tabla 2. Por lo tanto, no elimina campos necesarios para line_key_v4, source_row_hash_v1 ni el DDL documental vigente.

El delta final queda limitado a flags de salida:

Tabla 1 vuelve a quedar encendida por defecto
Tabla 5 vuelve a quedar encendida por defecto
Tabla 6 vuelve a quedar encendida por defecto
Tabla 2 sigue encendida

La clasificacion final es MEDIO, porque no cambia el grano, filtros, joins, calculos financieros, identidad, hash ni DDL, pero si cambia la cantidad de resultsets que una ejecucion no parametrizada puede devolver.

5. Cambios de flags de salida¶

Flag	V1	V2 corregida	Impacto
`@ShowTabla1`	`0`	`1`	agrega resultset por defecto
`@ShowTabla2`	`1`	`1`	sin cambio
`@ShowTabla3`	`0`	`0`	sin cambio
`@ShowTabla4`	`0`	`0`	sin cambio
`@ShowTabla5`	`0`	`1`	agrega resultset por defecto
`@ShowTabla6`	`0`	`1`	agrega resultset por defecto

Lectura:

Tabla 2 sigue siendo la salida canonica candidata para sync
V2 puede devolver multiples resultsets si se ejecuta sin parametrizacion
cualquier extractor futuro debera seleccionar explicitamente Tabla 2 o forzar Tabla 1/5/6 apagadas para sync

6. Columnas nuevas y eliminadas¶

Columnas nuevas en Tabla 2 V2 corregida respecto de V1:

ninguna observada por diff textual

Columnas eliminadas de Tabla 2 V2 corregida respecto de V1:

ninguna observada por diff textual

Confirmacion critica:

V1 incluye LTRIM(RTRIM(v.Hora)) AS Hora en #base_raw
V1 expone b.Hora AS Hora inmediatamente a la derecha de Fecha en Tabla 2
V2 corregida conserva ambos puntos

7. Cambios de joins¶

Resultado: SIN CAMBIO TEXTUAL OBSERVADO.

Joins preservados:

ecommerce.dbo.V_VENTAS v
ecommerce.dbo.VCLIENTES c
ecommerce.dbo.PRODUCTS p
ecommerce.dbo.VPROVEEDORES pr

No se observaron cambios textuales en las condiciones de join.

8. Cambios de filtros¶

Resultado: SIN CAMBIO TEXTUAL OBSERVADO.

Filtros preservados:

ventana por @FechaDesde / @FechaHasta
v.Estado <> 'ANULADO'
filtros opcionales por marca, proveedor y vendedor

Lectura:

la clasificacion de fuente viva y drift por Estado sigue vigente
no se corrige ni se modifica el comportamiento de anulaciones

9. Cambios de calculos¶

Resultado: SIN CAMBIO TEXTUAL OBSERVADO.

No se observaron cambios textuales en:

reglas de signo
IVA
IIBB
descuentos
CMVBruto_Item
creditos NP
mermas
ajustes de cuenta corriente 4010
BalanceCtaCteFinal
Contribucion_BalanceCtaCteFinal

10. Cambios especificos sobre Tabla 2¶

Tabla 2 sigue existiendo y @ShowTabla2 permanece en 1.

Cambios relevantes:

Hora queda preservada
no se observaron columnas nuevas ni eliminadas en la salida Tabla 2
no se observaron cambios textuales de calculo en Tabla 2
V2 queda pendiente de inventario real para confirmar columnas, orden, conteos, unicidad y conciliacion

11. Impacto sobre line_key_v4¶

Impacto: BAJO / SIN CAMBIO TEXTUAL, con revalidacion pendiente.

La formula documental vigente de line_key_v4 requiere:

text fecha, hora_origen_sgc, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, sku, vendedor, line_sequence_v1

V2 corregida conserva Hora, por lo tanto no invalida textualmente line_key_v4.

Regla:

la aceptacion AMARILLO ACEPTADO sigue siendo evidencia historica vigente
aun asi, V2 debe revalidarse antes de snapshot porque es una nueva candidata autoridad

12. Impacto sobre source_row_hash_v1¶

Impacto: BAJO / SIN CAMBIO TEXTUAL, con revalidacion pendiente.

source_row_hash_v1 vigente incluye hora_origen_sgc como campo canonico. V2 corregida conserva Hora, por lo tanto no invalida textualmente el hash vigente.

Regla:

no recalcular ni comparar hashes contra V2 sin inventario/snapshot de V2
mantener version explicita source_row_hash_v1 hasta que una revalidacion demuestre necesidad de cambiarla

13. Impacto sobre DDL¶

Impacto: BAJO / SIN CAMBIO TEXTUAL, con revalidacion pendiente.

El DDL documental vigente de source_003_sales_items depende de:

hora_origen_sgc
line_key_v4
line_sequence_v1
source_row_hash_v1

Como V2 corregida conserva Hora, no hay invalidacion textual directa del DDL.

No corresponde convertir el diseno ni el SQL piloto en migracion ejecutable hasta revalidar V2.

14. Impacto sobre estrategia de sync¶

Impacto: MEDIO.

La estrategia de fuente viva sigue vigente:

carga historica inicial
snapshot diario
ventana movil inicial sugerida de 10 dias
upsert por tenant_id + line_key
comparacion por source_row_hash
last_seen_at
missing_from_source
sin hard delete
freeze date desde snapshot

V2 requiere cuidado adicional de extraccion porque puede devolver multiples resultsets por Tabla 1, Tabla 2, Tabla 5 y Tabla 6.

Regla actualizada:

V2 queda habilitada solo para preparar snapshot controlado de Tabla 2
no avanzar con carga
no avanzar con sync
ejecutar siempre Tabla 2 con flags explicitos
no depender de los defaults de V2

15. Clasificacion de impacto¶

Clasificacion final: MEDIO.

Criterio:

no cambia Tabla 2 en columnas ni calculos observados por diff textual
no cambia campos de sync
no cambia line_key_v4
no cambia source_row_hash_v1
no cambia DDL
si cambia la superficie operativa de resultsets por flags @ShowTabla

No se clasifica como BAJO porque una ejecucion no parametrizada de V2 puede devolver mas resultsets y afectar extractores ingenuos.

No se clasifica como ALTO porque, con Hora preservada, no cambia grano, filtros, calculos financieros, identidad, hash, conciliacion ni contrato fisico documental.

16. Proximo paso obligatorio¶

Estado: CERRADO PARA SNAPSHOT CONTROLADO / ABIERTO PARA CARGA Y SYNC.

SOURCE-003 / Tabla 2 V2 fue revalidada en modo explicito contra SGC para la fecha minima controlada 2026-06-08.

La revalidacion confirmo:

columnas reales de Tabla 2 V2
presencia de Hora
unicidad de identidad de linea
vigencia de line_key_v4
vigencia de source_row_hash_v1
impacto sobre DDL
seleccion de resultset cuando Tabla 1/5/6 tambien estan encendidas

Proximo paso:

preparar un snapshot controlado de Tabla 2 V2, con seleccion explicita de resultset, sin usar 2026-06-08 como fecha estable y sin carga/sync.

17. Checklist¶

V1 preservada: SI
V2 registrada como archivo nuevo: SI
Hora preservada por aclaracion humana: SI
V1 vs V2 comparada: SI
columnas nuevas revisadas: SI
columnas eliminadas revisadas: SI
joins revisados: SI
filtros revisados: SI
calculos revisados: SI
cambios sobre Tabla 2 revisados: SI
impacto sobre line_key_v4: BAJO / REVALIDADO EN TABLA 2 V2 EXPLICITA
impacto sobre source_row_hash_v1: BAJO / SIN CAMBIO TEXTUAL
impacto sobre DDL: BAJO / SIN CAMBIO TEXTUAL
impacto sobre sync: MEDIO
impacto final: MEDIO
snapshots ejecutados: NO
cargas ejecutadas: NO
sync ejecutada: NO
runtime tocado: NO
PostgreSQL tocado: NO

18. Revalidacion real Tabla 2 V2 explicita - 2026-06-10¶

Safe point:

git status -sb: ## main...origin/main
git rev-parse HEAD: 4cdda7b7c576986c4bb8c537a2745ac32ed3328f

Alcance:

conexion SGC: solo lectura
PostgreSQL: no tocado
runtime, VPS, Docker: no tocados
snapshot, carga, sync, migracion: no ejecutados
datos personales: no expuestos

Flags forzados:

Flag	Valor
`@ShowTabla1`	`0`
`@ShowTabla2`	`1`
`@ShowTabla3`	`0`
`@ShowTabla4`	`0`
`@ShowTabla5`	`0`
`@ShowTabla6`	`0`

Resultado:

Metrica	Resultado
fecha	`2026-06-08`
resultsets con filas	`1`
columnas `Tabla 2`	`68`
filas `Tabla 2`	`1262`
importe total	`24866892.52`
`CMV` total	`19078909.1264`
clientes unicos	`124`
vendedores unicos	`23`
`SKU` unicos	`178`
`Hora` presente	`SI`, posicion `2`
`Hora` vacia o nula	`0`
formato `Hora` observado	`HHMMSS`
duplicados `line_key_v3`	`0`
duplicados `line_key_v4 + line_sequence_v1`	`0`

Tipos de comprobante:

Tipo de comprobante	Filas
`FACTURA A`	`124`
`FACTURA B`	`16`
`GUIA DE DESPACHO`	`951`
`N/C GUIA DE DESPACHO`	`151`
`NOTA CREDITO A`	`1`
`NOTA CREDITO B`	`19`

Conclusion:

V2 queda revalidada como candidata actual de Tabla 2 para snapshot controlado
la extraccion futura de sync debe ejecutar Tabla 2 en modo explicito
no se debe depender de los flags por defecto de V2
esta validacion no habilita carga, sync ni migracion