Saltar a contenido

SOURCE Inventory Results 003 - SOURCE-003 Tabla 2 vNext

Fecha: 2026-06-10

Estado: AMARILLO ACEPTADO / V2 TABLA 2 REVALIDADA EXPLICITA / HORA_ORIGEN_SGC / LINE_KEY_V4

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/SOURCE-INVENTORY-RESULTS-003.md

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

Fuente V2 candidata revalidada en modo explicito: docs/tenants/alpuntodeventa/business-observer/source-authority/SOURCE-003-VENTAS-VNEXT-TABLA2-AUTHORITY-V2.sql

Decision humana: docs/tenants/alpuntodeventa/business-observer/design/SOURCE-003-LINE-IDENTITY-DECISION.md

1. Objetivo

Validar funcionalmente la salida Tabla 2 de SOURCE-003 vNext con datos reales de SGC, medir agregados sin exponer datos personales y dejar una propuesta documentada de line_key y source_row_hash antes de cualquier DDL.

2. Safe point

  • git status -sb: ## main...origin/main
  • git rev-parse HEAD: 5ed86a68df1d54e371ff728052658ca7a2bc3b7d

3. Alcance aplicado

  • modo: INVENTORY
  • runtime: no tocado
  • VPS: no tocado
  • Docker: no tocado
  • tablas fisicas: no creadas
  • vistas fisicas: no creadas
  • migraciones: no creadas
  • datos origen: no modificados
  • conexion SGC: solo lectura
  • documentacion: solo agregados y nombres de campos
  • datos personales: no expuestos

La medicion uso la autoridad SQL preservada y capturo la salida de Tabla 2 en una tabla temporal de sesion para calcular agregados. No se persistio ningun objeto en el origen ni en destino. La transaccion fue cerrada con rollback y las tablas temporales desaparecen al cerrar la sesion.

4. Parametros confirmados

La corrida de inventario uso:

Parametro Valor
@FechaDesde 2026-06-08
@FechaHasta 2026-06-08
@ShowTabla1 0
@ShowTabla2 1
@ShowTabla3 0
@ShowTabla4 0
@ShowTabla5 0
@ShowTabla6 0

La fecha de ejemplo preservada en la query fue valida y devolvio filas, por lo tanto no hizo falta buscar otra ventana.

5. Ventana usada

  • ventana: 2026-06-08 a 2026-06-08
  • criterio: ventana chica controlada de un dia
  • alias de conexion: mssql:mssql-sgc-ecommerce
  • fuente leida: ecommerce.dbo.V_VENTAS enriquecida por la logica completa de la autoridad SOURCE-003 vNext

6. Resultados agregados

Metrica Resultado
filas totales 1269
clientes unicos 125
comprobantes unicos 305
SKU unicos 178
vendedores unicos 23
fecha minima 2026-06-08
fecha maxima 2026-06-08
filas con SKU vacio 0
filas con cliente vacio 0
filas con vendedor vacio 0
filas con Documento o NroComp vacio 0
filas con unidades nulas o cero 0
filas con importes nulos o cero 0
filas con CMVBruto_Item nulo o cero 6
suma Importe_Total_Todos_los_Items 24852533.32
suma CMVBruto_Item 19122718.36

Tipos de comprobante observados:

Tipo de comprobante Filas
FACTURA A 124
FACTURA B 16
GUIA DE DESPACHO 954
N/C GUIA DE DESPACHO 155
NOTA CREDITO A 1
NOTA CREDITO B 19

7. Candidatos de line_key

Resultado medido sin exponer valores de claves:

Candidato Composicion evaluada Filas Claves distintas Claves duplicadas Filas en duplicados Resultado
A fecha + tipo_comp + nro_comp + sku 1269 1269 0 0 PASS
B fecha + tipo_comp + nro_comp + documento + sku 1269 1269 0 0 PASS
C fecha + tipo_doc_int + nro_int_doc + sku 1269 1269 0 0 PASS
D fecha + documento + sku + vendedor 1269 1269 0 0 PASS
E fecha + tipo_comp + nro_comp + documento + sku + vendedor 1269 1269 0 0 PASS
F E + line_sequence derivada por grupo 1269 1269 0 0 WARNING

Perfil adicional de duplicados para E:

Metrica Resultado
grupos E 1269
grupos unicos 1269
grupos duplicados 0
maximo de filas por grupo E 1
filas en grupos duplicados 0

Lectura de F:

  • la query genera un IdFila tecnico de sesion dentro de #base
  • ese IdFila fue distinto para las 1269 filas medidas
  • no se observo en metadata de ecommerce.dbo.V_VENTAS un line_id estable de origen
  • ImpIntLinea existe como columna de metadata, pero no debe tratarse como identificador de linea sin validacion funcional adicional
  • por lo tanto line_sequence queda como fallback futuro, no como necesidad actual para esta ventana

8. Line_key propuesta inicial

La propuesta inicial fue una clave natural versionada:

text line_key_v1 = sha256(canonical( fecha, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, sku, vendedor ))

Estado vigente:

  • line_key_v1 no debe usarse sola como clave unica
  • la revalidacion mayor detecto colisiones documentadas en la seccion 14.5
  • antes de migrar se requiere un line_sequence estable o identificador funcional de linea

Justificacion original:

  • contiene a la candidata E, que paso sin duplicados en la ventana chica medida
  • suma tipo_doc_int, nro_int_doc y codigo_cliente para alinearse con el grano documental previsto en la arquitectura fisica
  • no usa importes, costos, descuentos ni otros campos economicos como clave
  • no usa nombre de cliente ni datos personales textuales
  • conserva separacion entre comprobante, documento interno, cliente, SKU y vendedor transaccional
  • la ventana mayor ya observo el mismo SKU bajo la misma clave natural; por lo tanto debe agregarse un line_sequence estable expuesto o definido por la autoridad SQL antes de escribir DDL

No se recomienda usar el IdFila temporal actual como clave persistida porque es una secuencia de sesion generada por la query, no un identificador estable del origen.

9. Source_row_hash recomendado

La propuesta recomendada es:

text source_row_hash_v1 = sha256(canonical( fecha, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, vendedor, sku, unidades, precio_neto_unitario, imponible_neto_item, iva, iibb, importe_total_todos_los_items, cmv_bruto_item, descuentos, canal, ramo, motivo_devolucion ))

Mapeo recomendado desde Tabla 2:

Campo canonico Campo Tabla 2
fecha Fecha
tipo_comp TipoComp
nro_comp NroComp
tipo_doc_int TipoDocInt
nro_int_doc NroIntDoc
documento Documento
codigo_cliente CodigoCliente
vendedor Vendedor
sku SKU
unidades Unidades
precio_neto_unitario Precio_Neto_Unitario
imponible_neto_item ImponibleNetoItem
iva IVA, IVAItemUnidad, IVATotalItems
iibb PercIIBB, PercIIBBItemUnidad, PercIIBBItemImporte
importe_total_todos_los_items Importe_Total_Todos_los_Items
cmv_bruto_item CMVBruto_Item
descuentos PorcDescLinea, DescNetoUnitarioXLinea, DescAlPie, Total_Desc_Neto_Linea, Total_Desc_Neto_Al_Pie, Total_Desc_NP
canal Canal
ramo Ramo
motivo_devolucion MotivoDevolucion

Reglas de canonicalizacion:

  • fechas en formato ISO YYYY-MM-DD
  • textos con LTRIM/RTRIM
  • nulos con sentinel estable
  • decimales con escala definida por columna antes de serializar
  • separador escapado o serializacion estructurada para evitar colisiones
  • versionar el hash como source_row_hash_v1

10. Conciliacion minima

Comparacion agregada para la misma ventana:

Comparacion Total Tabla 2 Total Tabla 1 Diferencia absoluta Diferencia porcentual
Importe_Total_Todos_los_Items vs BalanceCtaCteFinal 24852533.32 24852533.60 0.28 0.000001%
CMVBruto_Item vs CMVBruto_Item 19122718.36 19122718.37 0.01 0.000000%

Lectura:

  • la conciliacion minima contra Tabla 1 queda ejecutada
  • las diferencias son residuales y compatibles con redondeos de salidas a dos decimales
  • queda pendiente, fuera de esta tarea, ampliar conciliacion contra Tabla 3, Tabla 4, Tabla 5 y Tabla 6

11. Conclusion

Conclusion original de ventana chica: VERDE.

Conclusion tras revalidacion de ventana mayor previa a line_sequence_v1: ROJO.

Motivos:

  • Tabla 2 vNext ejecuto con datos reales
  • la ventana de ejemplo fue valida y medible
  • no hubo vacios en SKU, cliente, vendedor, documento ni numero de comprobante
  • existe una clave natural propuesta para line_key_v1, pero la revalidacion posterior en ventana mayor detecto colisiones
  • source_row_hash_v1 queda propuesto con campos funcionales y economicos relevantes
  • la conciliacion minima contra Tabla 1 fue ejecutada con diferencias residuales

Este cierre no crea DDL ni autoriza migraciones por si solo. La evidencia ampliada bloquea el indice unico sobre tenant_id + line_key hasta definir un identificador o secuencia estable de linea.

12. Proximo paso recomendado previo a line_sequence_v1

La recomendacion previa era definir y validar un line_sequence estable o identificador funcional de linea. Esa investigacion queda actualizada en la seccion 15.

13. Checklist

  • modo INVENTORY aplicado: SI
  • lectura minima aplicada: SI
  • solo lectura SGC: SI
  • sin runtime: SI
  • sin tablas fisicas: SI
  • Tabla 2 validada: SI
  • line_key propuesta: SI
  • source_row_hash propuesto: SI
  • datos personales expuestos: NO

14. Revalidacion ventana mayor - 2026-06-10

14.1 Safe point

  • git status -sb: ## main...origin/main
  • git rev-parse HEAD: a46e56da1019d49b9b7abc4f46ec1025abf17c5b

14.2 Alcance aplicado

  • modo: INVENTORY
  • runtime: no tocado
  • VPS: no tocado
  • Docker: no tocado
  • PostgreSQL: no tocado
  • tablas fisicas: no creadas
  • vistas fisicas: no creadas
  • migraciones: no creadas
  • datos origen: no modificados
  • conexion SGC: solo lectura
  • documentacion: solo agregados
  • datos personales: no expuestos

La medicion ejecuto la autoridad SOURCE-003 vNext con temporales de sesion y rollback de la conexion. No se persistio ningun objeto.

14.3 Parametros y ventana

Parametro Valor
@FechaDesde 2026-05-05
@FechaHasta 2026-06-09
@ShowTabla1 0
@ShowTabla2 1
@ShowTabla3 0
@ShowTabla4 0
@ShowTabla5 0
@ShowTabla6 0

Criterio de ventana:

  • se usaron 30 fechas recientes con datos
  • se excluyo 2026-06-10 por ser dia en curso y ventana movil
  • la fecha maxima cerrada con datos fue 2026-06-09

14.4 Resultados generales

Metrica Resultado
filas totales Tabla 2 48976
columnas observadas Tabla 2 67
fecha minima 2026-05-05
fecha maxima 2026-06-09

Tipos de comprobante observados:

Tipo de comprobante Filas
FACTURA A 8956
FACTURA B 78
GUIA DE DESPACHO 33967
N/C GUIA DE DESPACHO 5481
NOTA CREDITO A 458
NOTA CREDITO B 36

14.5 Revalidacion de line_key_v1

Formula revalidada:

text line_key_v1 = sha256(canonical( fecha, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, sku, vendedor ))

Resultado:

Metrica Resultado
filas totales 48976
claves distintas 48970
claves duplicadas 6
filas involucradas en duplicados 12
maximo de filas por grupo duplicado 2

Tipos de comprobante involucrados en duplicados:

Tipo de comprobante Filas
FACTURA A 2
GUIA DE DESPACHO 8
N/C GUIA DE DESPACHO 2

Perfil agregado de duplicados:

Metrica Resultado
grupos duplicados 6
grupos con salida completa identica 3
grupos con source_row_hash_v1 identico 3
grupos con valores economicos identicos 3
grupos con logistica identica 6
grupos con direccion de pedidos distinta 0
grupos con nombre de cliente distinto 0
grupos con articulo distinto 0

Fechas con grupos duplicados:

Fecha Grupos
2026-05-07 1
2026-05-21 1
2026-05-26 1
2026-06-02 1
2026-06-04 1
2026-06-06 1

Candidatos adicionales medidos sin exponer valores:

Candidato Claves distintas Claves duplicadas Filas en duplicados Resultado
line_key_v1 48970 6 12 FAIL
line_key_v1 + importe_total 48973 3 6 FAIL
line_key_v1 + source_row_hash_fields 48973 3 6 FAIL
line_key_v1 + logistica_no_pii 48970 6 12 FAIL
line_key_v1 + direccion_de_pedidos 48970 6 12 FAIL
line_key_v1 + todas_las_columnas_salida 48973 3 6 FAIL

Conclusion line_key_v1: FAIL.

Lectura:

  • line_key_v1 no sostiene unicidad en ventana mayor
  • hay 3 grupos donde incluso toda la salida de Tabla 2 queda identica
  • agregar importes, hash de valores o campos logisticos no resuelve todos los duplicados
  • el IdFila de la autoridad sigue siendo tecnico de sesion y no debe usarse como identidad persistida sin una definicion funcional estable

14.6 Completitud

Control Filas
SKU vacio 0
cliente vacio (CodigoCliente) 0
vendedor vacio (Vendedor) 0
Documento o NroComp vacio 0
TipoComp vacio 0
TipoDocInt vacio 0
NroIntDoc vacio 0

14.7 Escalas numericas

Campo destino Campo Tabla 2 Min Max Nulos Ceros Negativos Positivos Max enteros aprox. Max decimales obs. Tipo recomendado
unidades Unidades -432 1440 0 0 5975 43001 4 0 numeric(19,4)
precio_unitario Precio_Neto_Unitario 171.78 9525000.00 0 0 0 48976 7 2 numeric(19,6)
imponible_neto_item ImponibleNetoItem -667964.50 9525000.00 0 0 5975 43001 7 2 numeric(19,4)
iva_item IVATotalItems -140272.55 2000250.00 0 6 5974 42996 7 2 numeric(19,4)
iibb_item PercIIBBItemImporte -5297.32 10325.37 0 48305 80 591 5 2 numeric(19,4)
importe_total_item Importe_Total_Todos_los_Items -808237.05 11525250.00 0 0 5975 43001 8 2 numeric(19,4)
cmv_bruto_item CMVBruto_Item -666333.6939 1742957.4700 0 381 5594 43001 7 4 numeric(19,4)
descuento_item descuentos consolidados -485724.25 49591.61 0 39287 3244 6445 6 2 numeric(19,4)
contribucion_item Contribucion_BalanceCtaCteFinal -808237.05 11525250.00 0 0 5975 43001 8 2 numeric(19,4)
peso_total Peso_Total -200.000 200.000 0 3145 2935 42896 3 2 numeric(19,6)
volumen_total Volumen_Total -1.239 4.047 0 3266 2915 42795 1 3 numeric(19,6)
cant_bultos_vendidos Cant_Bultos_Vendidos -20 60 0 5517 4331 39128 2 0 numeric(19,6)

Lectura de tipos:

  • los tipos documentales actuales alcanzan para la escala observada
  • numeric(19,4) cubre importes, impuestos, descuentos, CMV y unidades
  • numeric(19,6) se conserva para precio unitario y metricas fisicas por margen documental, aunque la salida actual observe menos decimales
  • no se requiere modificar el SQL documental por escalas numericas

14.8 Casos especiales

Caso Filas
notas de credito, incluyendo N/C GUIA DE DESPACHO 5975
notas de credito A/B 494
guias de despacho, incluyendo N/C GUIA DE DESPACHO 39448
facturas A/B 9034
MotivoDevolucion informado 5281
CMVBruto_Item cero 381
CMVBruto_Item nulo 0
importes negativos 5975
unidades negativas 5975
descuentos negativos 3244
creditos NP 2977
mermas 795
ajustes de cuenta corriente 63

14.9 Conciliacion opcional contra Tabla 1

Comparacion Total Tabla 2 Total Tabla 1 Diferencia absoluta Diferencia porcentual
Importe_Total_Todos_los_Items vs BalanceCtaCteFinal 1203472649.80 1203472654.13 4.33 0.00000036%
CMVBruto_Item vs CMVBruto_Item 954441593.9410 954685335.29 243741.3490 0.02553107%

Lectura:

  • importe total concilia con diferencia residual
  • CMV presenta diferencia baja porcentual pero no residual absoluta; queda pendiente explicar si proviene de formula, redondeo acumulado o filtros de Tabla 1

14.10 Conclusion previa a line_sequence_v1

Conclusion: ROJO.

Motivos:

  • line_key_v1 no sostiene unicidad en una ventana mayor
  • existen duplicados que no se resuelven agregando campos economicos ni todas las columnas expuestas por Tabla 2
  • las escalas numericas documentales alcanzan y no requieren ajuste
  • la completitud de campos clave es buena, sin vacios observados
  • la conversion del DDL documental a migracion ejecutable queda bloqueada hasta definir identidad estable de linea

14.11 Checklist de revalidacion

  • modo INVENTORY aplicado: SI
  • lectura minima aplicada: SI
  • solo lectura SGC: SI
  • sin runtime: SI
  • sin VPS: SI
  • sin Docker: SI
  • sin PostgreSQL: SI
  • sin tablas fisicas: SI
  • sin vistas fisicas: SI
  • sin migraciones: SI
  • line_key_v1 revalidada: SI
  • escalas numericas revisadas: SI
  • datos personales expuestos: NO

15. Investigacion line_sequence_v1 - 2026-06-10

15.1 Safe point

  • git status -sb: ## main...origin/main
  • git rev-parse HEAD: 9e228804510749d770e96570882064c26087f483

15.2 Alcance aplicado

  • modo: INVENTORY
  • runtime: no tocado
  • VPS: no tocado
  • Docker: no tocado
  • PostgreSQL: no tocado
  • tablas fisicas: no creadas
  • vistas fisicas: no creadas
  • migraciones: no creadas
  • datos origen: no modificados
  • conexion SGC: solo lectura
  • documentacion: solo agregados y metadata de columnas
  • datos personales: no expuestos

La medicion ejecuto la autoridad SOURCE-003 vNext con temporales de sesion y transaccion cerrada con rollback. No se persistio ningun objeto. No se devolvieron valores de clientes, documentos ni direcciones; solo nombres de columnas, tipos y agregados.

15.3 Identificador de linea en la autoridad

Revision de SOURCE-003-VENTAS-VNEXT-TABLA2-AUTHORITY.sql:

  • IdFila se crea como IDENTITY(INT,1,1) dentro de #base
  • IdFila es tecnico de sesion y depende del orden en que SQL Server materializa #base_raw
  • no proviene de V_VENTAS, VCLIENTES, PRODUCTS ni VPROVEEDORES
  • no debe persistirse como identidad funcional de linea

No se observo en la salida Tabla 2 un campo equivalente a id detalle, nro item, renglon, linea, secuencia, orden, row o fila que sea apto como identificador real de linea.

15.4 Metadata candidata de V_VENTAS

Consulta segura:

  • fuente: ecommerce.INFORMATION_SCHEMA.COLUMNS
  • objeto: ecommerce.dbo.V_VENTAS
  • filtro de nombres: id, item, linea, línea, renglon, renglón, sec, orden, detalle, row, fila

Columnas candidatas encontradas:

Ordinal Columna Tipo Nullable
25 Unidades decimal(10,3) YES
27 PorcDescLinea decimal(5,2) NO
47 ImpIntLinea decimal(10,3) NO
50 Localidad char(30) NO
52 Repartidor numeric(6,0) YES

Lectura:

  • Unidades matchea por contener id, pero es cantidad vendida
  • Localidad matchea por contener id, pero es dato logistico/geografico
  • Repartidor matchea por contener id, pero es dato logistico de cabecera
  • PorcDescLinea e ImpIntLinea son los unicos nombres con senal de linea, pero son importes/porcentajes, no identificadores

15.5 Evaluacion de line_id_source

Ventana exacta de validacion:

Parametro Valor
@FechaDesde 2026-05-05
@FechaHasta 2026-06-09
salida evaluada Tabla 2

La corrida exacta de esta investigacion midio 48973 filas en Tabla 2. Se conserva la revalidacion previa de 48976 filas como evidencia historica de la misma ventana; la diferencia no cambia la conclusion de identidad porque line_key_v1 sigue duplicando.

Evaluacion agregada por candidata:

Columna Tipo Lectura probable Disponibilidad en filas Tabla 2 Nulos Valores distintos Duplicados con line_key_v1 + candidata Conclusion
ImpIntLinea decimal(10,3) importe/indicador de linea, no id 48973 0 1 6 grupos / 12 filas no apta
Localidad char(30) cabecera/logistica 48973 0 214 6 grupos / 12 filas no apta
PorcDescLinea decimal(5,2) metrica de descuento de linea 48973 0 9 6 grupos / 12 filas no apta
Repartidor numeric(6,0) cabecera/logistica 48973 0 27 6 grupos / 12 filas no apta
Unidades decimal(10,3) cantidad de item 48973 0 140 3 grupos / 6 filas no apta

Conclusion:

  • no existe line_id_source apto en la metadata visible de V_VENTAS
  • ImpIntLinea no sirve como identificador porque tiene un unico valor observado en toda la salida evaluada
  • Unidades reduce parcialmente duplicados pero es una metrica mutable y no identifica linea
  • las demas candidatas pertenecen a cabecera/logistica o a atributos mutables

15.6 Diseno recomendado de line_sequence_v1

Como no hay line_id_source apto, la recomendacion documental es generar una columna tecnica de pipeline:

text line_sequence_v1 = ROW_NUMBER() OVER ( PARTITION BY fecha, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, sku, vendedor ORDER BY articulo, marcas, proveedor, unidades, precio_neto_unitario, precio_neto_unitario_cdesc_linea, subtotal_neto_item_cdesc_linea, desc_al_pie, desc_pie_unitario_neto, precio_neto_unitario_cdesc_pie, imponible_neto_item, perc_iibb, alicuota_perc_iibb_calculada, perc_iibb_item_unidad, perc_iibb_item_importe, iva_item_unidad, iva_total_items, importe_total_item, importe_total_todos_los_items, total_desc_neto_linea, total_desc_neto_al_pie, total_desc_np, total_ajustes_saldos_ctacte, perc_iva, costo_lista, desc_compra1, desc_compra2, desc_compra3, cmv_bruto_unidad, cmv_bruto_item, markup, max_dcto_articulo, contribucion_balance_ctacte_final, indicador_tipo_registro, lista_de_precio, hoja_de_ruta, cod_repartidor, motivo_devolucion, peso_total, volumen_total, cant_bultos_vendidos, zona, ramo, canal, grupo, rubro, razon_social_proveedor )

Reglas:

  • line_sequence_v1 no es dato fuente
  • no usa IdFila
  • no usa nombre de cliente ni direccion como orden tecnico
  • debe versionarse porque depende de la lista de campos y de su canonicalizacion
  • si dos ocurrencias quedan completamente identicas en los campos de orden, el ROW_NUMBER() distingue ocurrencias pero no demuestra identidad fisica estable

15.7 line_key_v2 recomendada

Formula recomendada:

text line_key_v2 = sha256(canonical( fecha, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, sku, vendedor, line_sequence_v1 ))

line_key_v1 queda preservada como historicamente fallida y no debe usarse sola como clave unica.

15.8 Validacion de unicidad

Resultado de line_key_v1 en la corrida exacta de esta investigacion:

Metrica Resultado
filas totales 48973
claves distintas 48967
claves duplicadas 6
filas involucradas en duplicados 12
maximo de filas por grupo duplicado 2

Resultado de line_key_v2 con line_sequence_v1:

Metrica Resultado
filas totales 48973
claves distintas 48973
claves duplicadas 0
filas involucradas en duplicados 0
grupos absolutamente identicos en toda la salida Tabla 2 3
filas en grupos absolutamente identicos 6
grupos con empate completo en el ORDER BY de line_sequence_v1 3
filas con empate completo en el ORDER BY de line_sequence_v1 6

Conclusion tecnica:

  • line_key_v2 con line_sequence_v1 pasa unicidad agregada
  • la estabilidad queda en WARNING porque existen 3 grupos donde dos filas son indistinguibles incluso con toda la salida expuesta de Tabla 2
  • sin un id fisico de linea, una correccion futura de una sola ocurrencia identica no puede asociarse con certeza documental a la misma ocurrencia historica

15.9 Impacto en DDL documental

Impacto recomendado:

  • agregar line_sequence como columna tecnica generada por pipeline
  • documentar que line_sequence corresponde a line_sequence_v1
  • actualizar line_key para que represente line_key_v2
  • mantener source_row_hash_v1 como hash de valores de linea
  • mantener line_key_v1 solo como evidencia historica fallida
  • no crear migracion ejecutable hasta revision humana del riesgo WARNING

15.10 Conclusion vigente

Conclusion: AMARILLO.

Motivos:

  • no se encontro line_id_source apto
  • line_sequence_v1 resuelve unicidad agregada en la ventana evaluada
  • existen ocurrencias absolutamente identicas y por eso la estabilidad no puede declararse VERDE
  • el DDL documental puede incorporar line_sequence y line_key_v2, pero no debe convertirse automaticamente en migracion ejecutable

15.11 Proximo paso unico recomendado

Revision humana de la decision AMARILLO: aceptar line_sequence_v1 como identidad tecnica suficiente para sync inicial o solicitar al proveedor/ERP un identificador fisico de detalle antes de migrar.

15.12 Checklist de investigacion

  • modo INVENTORY aplicado: SI
  • lectura minima aplicada: SI
  • solo lectura SGC: SI
  • sin runtime: SI
  • sin VPS: SI
  • sin Docker: SI
  • sin PostgreSQL: SI
  • sin tablas fisicas: SI
  • sin vistas fisicas: SI
  • sin migraciones: SI
  • line_key_v1 preservada como fallida: SI
  • line_key_v2 evaluada: SI
  • line_sequence_v1 documentada: SI
  • datos personales expuestos: NO

16. Revalidacion Hora y line_key_v3 - 2026-06-10

16.1 Safe point

  • git status -sb: ## main...origin/main
  • git rev-parse HEAD: 71549aa55b3c9054175174831388532a76de1f2f

16.2 Alcance aplicado

  • modo: DESIGN + INVENTORY
  • runtime: no tocado
  • VPS: no tocado
  • Docker: no tocado
  • PostgreSQL: no tocado
  • tablas fisicas: no creadas
  • vistas fisicas: no creadas
  • migraciones: no creadas
  • datos origen: no modificados
  • conexion SGC: solo lectura
  • documentacion: query autoridad y agregados
  • datos personales: no expuestos

La medicion ejecuto la autoridad SOURCE-003 vNext modificada documentalmente para exponer Hora en Tabla 2. La conexion se mantuvo en solo lectura funcional y se cerro con rollback. No se persistio ningun objeto ni resultado.

16.3 Confirmacion de v.Hora

Consulta segura:

  • fuente: ecommerce.INFORMATION_SCHEMA.COLUMNS
  • objeto: ecommerce.dbo.V_VENTAS
  • columna: Hora

Resultado:

Columna Tipo Longitud Nullable Ordinal
Hora char 6 NO 16

Lectura:

  • v.Hora existe en ecommerce.dbo.V_VENTAS
  • se incorpora como LTRIM(RTRIM(v.Hora)) AS Hora
  • el valor observado esperado es raw de SGC con formato HHMMSS
  • ejemplo documental de formato: 085923
  • no debe usarse como timestamp unico sin validacion funcional
  • si se usa para identidad, debe ser parte candidata junto con la identidad documental, SKU, vendedor y un resolvedor de colisiones

16.4 Cambio en autoridad SQL

Archivo actualizado:

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

Cambios:

  • #base_raw: suma LTRIM(RTRIM(v.Hora)) AS Hora
  • #base: recibe Hora por el SELECT * INTO #base FROM #base_raw
  • Tabla 2: expone Hora inmediatamente a la derecha de Fecha
  • #t1: se mantiene sin Hora porque es la temporal agregada de Tabla 1; agregarla ahi exigiria agrupar o inventar una hora y alteraria las salidas Tabla 1/3/4/5/6

No se modificaron filtros, joins, reglas de signo, calculos financieros, reglas de CMV, descuentos, creditos, mermas ni salidas agregadas.

16.5 Parametros y ventana

Parametro Valor
@FechaDesde 2026-05-05
@FechaHasta 2026-06-09
@ShowTabla1 0
@ShowTabla2 1
@ShowTabla3 0
@ShowTabla4 0
@ShowTabla5 0
@ShowTabla6 0

16.6 Resultados de Hora

Metrica Resultado
filas totales Tabla 2 48973
columnas observadas Tabla 2 68
posicion Fecha 1
posicion Hora 2
filas con Hora vacia o nula 0
filas con Hora formato HHMMSS 48973
valores Hora distintos 7944
Hora minima observada 061000
Hora maxima observada 165312

16.7 Evaluacion de line_key_v3

Formula evaluada:

text line_key_v3 = sha256(canonical( fecha, hora, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, sku, vendedor ))

Comparacion agregada:

Candidato Filas Claves distintas Claves duplicadas Filas en duplicados Resultado
line_key_v1 48973 48967 6 12 FAIL
line_key_v2 48973 48973 0 0 PASS / WARNING
line_key_v3 48973 48967 6 12 FAIL

Duplicados y Hora:

Metrica Resultado
duplicados line_key_v1 con misma Hora 6 grupos / 12 filas
duplicados line_key_v1 con distinta Hora 0 grupos / 0 filas
duplicados restantes line_key_v3 con misma Hora 6 grupos / 12 filas
grupos con empate completo en ORDER BY de line_sequence_v1 3
filas con empate completo en ORDER BY de line_sequence_v1 6

Conclusion:

  • Hora mejora la trazabilidad de origen y debe preservarse como hora_origen_sgc
  • Hora no alcanza sola para resolver la unicidad de linea
  • los duplicados de line_key_v1 ya comparten exactamente la misma Hora
  • line_key_v3 falla con los mismos 6 grupos y 12 filas duplicadas que line_key_v1
  • line_sequence_v1 sigue siendo necesario como resolvedor tecnico de colisiones

16.8 line_key_v4 recomendada

Formula recomendada:

text line_key_v4 = sha256(canonical( fecha, hora_origen_sgc, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, sku, vendedor, line_sequence_v1 ))

Lectura:

  • line_key_v4 conserva la unicidad agregada de line_key_v2 porque incluye line_sequence_v1
  • suma hora_origen_sgc como dato raw real de SGC y parte candidata de identidad
  • mantiene el riesgo WARNING ya documentado para ocurrencias absolutamente identicas
  • no habilita migracion ejecutable sin revision humana

16.9 Impacto documental

Impacto recomendado:

  • documentar Hora como hora_origen_sgc
  • actualizar line_key documental para que represente line_key_v4
  • preservar line_key_v1 como fallida historica
  • preservar line_key_v2 como evidencia previa con unicidad agregada
  • preservar line_key_v3 como fallida porque Hora no resuelve las colisiones existentes
  • mantener line_sequence_v1 como fallback/resolvedor tecnico de linea

16.10 Conclusion vigente

Conclusion: AMARILLO.

Motivos:

  • Hora existe en el origen y fue agregada a Tabla 2 sin tocar calculos
  • Hora queda como segunda columna de la salida itemizada
  • line_key_v3 no sostiene unicidad
  • line_key_v4 pasa a ser la recomendacion documental porque combina Hora con line_sequence_v1
  • el riesgo de estabilidad por filas absolutamente identicas sigue abierto

16.11 Proximo paso unico recomendado

Revision humana de la decision AMARILLO: aceptar line_key_v4 con hora_origen_sgc + line_sequence_v1 como identidad tecnica suficiente para sync inicial o solicitar al proveedor/ERP un identificador fisico de detalle antes de migrar.

16.12 Checklist de revalidacion Hora

  • modo DESIGN + INVENTORY aplicado: SI
  • v.Hora confirmada en metadata de V_VENTAS: SI
  • Hora agregada a #base_raw: SI
  • Hora propagada a #base: SI
  • Hora agregada a salida Tabla 2: SI
  • Hora ubicada a la derecha de Fecha: SI
  • #t1 preservada sin alterar salidas agregadas: SI
  • filtros, joins y calculos preservados: SI
  • line_key_v3 evaluada: SI
  • line_sequence_v1 preservada como fallback/resolvedor: SI
  • datos personales expuestos: NO

17. Decision humana line_key_v4 - 2026-06-10

Estado: AMARILLO ACEPTADO.

Decision de Gabi:

  • aceptar line_key_v4 para el sync inicial analitico de SOURCE-003 / Tabla 2 vNext
  • avanzar con la mejor solucion disponible porque el id fisico de linea del ERP no esta disponible en la vista SGC accesible
  • mantener la decision en AMARILLO ACEPTADO, no en VERDE, porque no existe identidad fisica ERP de renglon

Evidencia historica preservada:

Candidato Resultado Lectura
line_key_v1 FAIL falla unicidad en ventana mayor
line_key_v3 FAIL sumar Hora no resuelve duplicados porque los duplicados comparten la misma Hora
line_key_v2 PASS / WARNING line_sequence_v1 resuelve unicidad agregada, con riesgo por ocurrencias absolutamente identicas
line_key_v4 AMARILLO ACEPTADO suma hora_origen_sgc y conserva line_sequence_v1 como resolvedor tecnico

Formula aceptada:

text line_key_v4 = sha256(canonical( fecha, hora_origen_sgc, tipo_comp, nro_comp, tipo_doc_int, nro_int_doc, documento, codigo_cliente, sku, vendedor, line_sequence_v1 ))

Lectura:

  • Hora agrega trazabilidad real de SGC, pero no resuelve duplicados sola
  • line_sequence_v1 es tecnica de pipeline basada en ROW_NUMBER()
  • line_sequence_v1 no representa un id fisico del ERP
  • filas completamente identicas quedan diferenciadas por secuencia tecnica, no por identidad fisica del origen

Mitigacion aceptada:

  • preservar hora_origen_sgc
  • preservar line_sequence_v1
  • preservar source_row_hash_v1
  • preservar sync_batch_id
  • preservar esta evidencia documental

Proximo paso recomendado:

preparar un snapshot controlado de SOURCE-003 / Tabla 2 V2 usando siempre seleccion explicita de resultset. Ese paso no debe cargar, sincronizar ni usar 2026-06-08 como fecha piloto estable.

18. Registro V2 candidata - 2026-06-10

Estado previo: PENDIENTE DE REVALIDACION.

Gabi no confirmo que la query vigente fuera igual a V1 y pego una nueva query completa. Esa query queda registrada como:

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

Aclaracion humana durante la auditoria:

  • la query pegada omitio Hora por olvido
  • Hora debe quedar incluida en la query definitiva
  • V2 queda preservada con Hora en #base_raw y en la salida Tabla 2

Delta review:

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

Resultado documental del delta:

  • impacto final: MEDIO
  • V2 conserva Hora
  • V2 no cambia textualmente joins, filtros ni calculos financieros
  • V2 no cambia textualmente columnas de Tabla 2
  • V2 cambia flags por defecto: Tabla 1, Tabla 5 y Tabla 6 quedan encendidas junto con Tabla 2

Lectura de inventario:

  • toda medicion previa de conteos, columnas, unicidad, conciliacion, line_key_v4 y source_row_hash_v1 queda como evidencia historica de V1
  • V2 requeria revalidacion real antes de usarse para snapshot, carga o sync; la revalidacion de Tabla 2 en modo explicito queda documentada en la seccion 19
  • no se debe inventar resultado de V2 por equivalencia textual parcial

Checklist V2:

  • V2 preservada: SI
  • V1 preservada: SI
  • Hora preservada en V2: SI
  • V2 ejecutada contra SGC: SI, ver seccion 19
  • snapshot tomado: NO
  • carga ejecutada: NO
  • sync ejecutada: NO

19. Revalidacion V2 Tabla 2 explicita - 2026-06-10

Estado: VALIDADA PARA SNAPSHOT CONTROLADO / NO CARGA / NO SYNC.

19.1 Safe point

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

19.2 Alcance aplicado

  • modo: INVENTORY + VALIDATE
  • runtime: no tocado
  • VPS: no tocado
  • Docker: no tocado
  • PostgreSQL: no tocado
  • tablas fisicas: no creadas
  • vistas fisicas: no creadas
  • migraciones: no creadas
  • snapshot: no creado
  • sync: no creada
  • inserts: no ejecutados
  • conexion SGC: solo lectura
  • documentacion: solo agregados
  • datos personales: no expuestos

La medicion ejecuto V2 en una sesion controlada contra SGC, con READ UNCOMMITTED, temporales de sesion de la autoridad y cierre con rollback. No se persistio ningun objeto ni resultado.

19.3 Parametros y seleccion de resultset

La corrida forzo explicitamente estos flags, sin depender de los defaults de V2:

Parametro Valor
@FechaDesde 2026-06-08
@FechaHasta 2026-06-08
@ShowTabla1 0
@ShowTabla2 1
@ShowTabla3 0
@ShowTabla4 0
@ShowTabla5 0
@ShowTabla6 0

Resultado de resultsets:

Control Resultado
resultsets con filas 1
resultset seleccionado Tabla 2
columnas observadas 68
filas observadas 1262

Lectura:

  • V2 puede emitir multiples resultsets si se ejecuta con defaults
  • la extraccion futura de sync debe apagar explicitamente Tabla 1, Tabla 3, Tabla 4, Tabla 5 y Tabla 6
  • Tabla 2 debe quedar encendida de forma explicita
  • no se debe depender del orden implicito de resultsets ni de flags por defecto

19.4 Resultados agregados

La fecha 2026-06-08 se uso solo para comparar contra la deriva ya documentada. No queda habilitada como snapshot estable.

Metrica Resultado
filas totales Tabla 2 V2 1262
columnas observadas Tabla 2 V2 68
fecha minima 2026-06-08
fecha maxima 2026-06-08
clientes unicos 124
comprobantes unicos 299
vendedores unicos 23
SKU unicos 178
suma Importe_Total_Todos_los_Items 24866892.52
suma CMVBruto_Item 19078909.1264

Tipos de comprobante observados:

Tipo de comprobante Filas Importe total CMV total
FACTURA A 124 4311929.18 3045966.6289
FACTURA B 16 460205.46 324310.3792
GUIA DE DESPACHO 951 24514320.20 17018487.6089
N/C GUIA DE DESPACHO 151 -3629636.91 -713499.1325
NOTA CREDITO A 1 -9989.46 -8963.1076
NOTA CREDITO B 19 -779935.95 -587393.2505

19.5 Confirmacion de Hora

Control Resultado
columna Hora presente SI
posicion Hora en Tabla 2 2
filas con Hora vacia o nula 0
filas con formato HHMMSS 1262
filas fuera de formato HHMMSS 0
valores Hora distintos 272
Hora minima observada 080221
Hora maxima observada 160711

Lectura:

  • V2 contiene LTRIM(RTRIM(v.Hora)) AS Hora en #base_raw
  • V2 expone b.Hora AS Hora inmediatamente a la derecha de Fecha en Tabla 2
  • Hora queda confirmada como campo requerido para hora_origen_sgc

19.6 Confirmacion line_key_v4

Campos requeridos observados para line_key_v4:

Campo Presente Vacios
Fecha SI 0
Hora SI 0
TipoComp SI 0
NroComp SI 0
TipoDocInt SI 0
NroIntDoc SI 0
Documento SI 0
CodigoCliente SI 0
SKU SI 0
Vendedor SI 0
line_sequence_v1 SI, tecnica de pipeline 0

line_sequence_v1 se recalculo en memoria para esta validacion, sin persistirlo y sin usar IdFila.

Candidato Filas Claves distintas Claves duplicadas Filas en duplicados Resultado
line_key_v3 1262 1262 0 0 PASS
line_key_v4 + line_sequence_v1 1262 1262 0 0 PASS

Controles de line_sequence_v1:

Control Resultado
particiones 1262
secuencia maxima 1
grupos empatados en ORDER BY tecnico 0
filas en empates de ORDER BY tecnico 0

Lectura:

  • para esta fecha actual de SGC, line_key_v3 no duplica
  • line_key_v4 queda revalidada sobre V2 porque conserva Hora y suma el resolvedor line_sequence_v1
  • la aceptacion global de identidad sigue siendo AMARILLO ACEPTADO, no VERDE, por la evidencia historica de ventana mayor con ocurrencias absolutamente identicas

19.7 Decision

Decision: V2 HABILITADA PARA SNAPSHOT CONTROLADO DE TABLA 2.

Condiciones:

  • ejecutar siempre con seleccion explicita de Tabla 2
  • no depender de flags por defecto de V2
  • no usar 2026-06-08 como snapshot estable
  • no interpretar esta validacion como carga, sync, migracion ni alta de datos
  • mantener la estrategia de fuente viva: snapshot diario, ventana movil, upsert, source_row_hash, last_seen_at y missing_from_source sin hard delete

No queda habilitado:

  • carga hacia PostgreSQL
  • sync diaria
  • migracion productiva
  • snapshot estable basado en evidencia historica de 2026-06-08

19.8 Checklist V2 explicita

  • sin PostgreSQL: SI
  • sin snapshot: SI
  • sin carga: SI
  • sin sync: SI
  • solo lectura SGC: SI
  • V2 Tabla 2 revalidada: SI
  • flags explicitos documentados: SI
  • Hora confirmada: SI
  • line_key_v4 confirmada: SI
  • datos personales expuestos: NO