Saltar a contenido

SOURCE-003 Line Identity Decision

Fecha: 2026-06-10

Estado: AMARILLO ACEPTADO

Scope: tenant

tenant_id: alpuntodeventa

Owner: Gabi / Carlos Canu

Fuente de verdad: docs/tenants/alpuntodeventa/business-observer/design/SOURCE-003-LINE-IDENTITY-DECISION.md

Documentos relacionados:

  • docs/tenants/alpuntodeventa/business-observer/SOURCE-INVENTORY-RESULTS-003.md
  • docs/tenants/alpuntodeventa/business-observer/design/SOURCE-003-SALES-ITEMS-DDL-DESIGN.md
  • docs/tenants/alpuntodeventa/business-observer/design/SOURCE-003-SALES-ITEMS-PILOT-MIGRATION.md
  • docs/tenants/alpuntodeventa/business-observer/design/sql/001_source_003_sales_items_design.sql
  • docs/tenants/alpuntodeventa/business-observer/design/sql/002_source_003_sales_items_pilot_migration.sql
  • docs/tenants/alpuntodeventa/business-observer/design/sql/002_source_003_sales_items_pilot_rollback.sql
  • docs/tenants/alpuntodeventa/business-observer/sources/SOURCE-003-SGC-VENTAS-COMPROBANTES.md
  • docs/tenants/alpuntodeventa/business-observer/source-authority/SOURCE-003-VENTAS-VNEXT-TABLA2-AUTHORITY.sql

1. Decision

Gabi acepta avanzar con line_key_v4 para el sync inicial analitico de SOURCE-003 / Tabla 2 vNext.

La decision queda marcada como AMARILLO ACEPTADO. No debe leerse como VERDE absoluto de identidad fisica del ERP.

La aceptacion permite preparar una migracion piloto/documental ejecutable para source_003_sales_items, orientada a analitica y observabilidad de negocio, sin autorizar produccion final ni auditoria legal perfecta de renglones ERP.

2. Alcance

Incluye:

  • Business Observer
  • analytics
  • BI
  • IA
  • ML
  • sync inicial analitico de SOURCE-003 / Tabla 2 vNext
  • preparacion documental de una migracion piloto, ya dejada como SQL no ejecutado

No incluye:

  • auditoria legal perfecta de renglones ERP
  • prueba de identidad fisica de linea en origen
  • carga productiva final
  • cambio de runtime
  • cambio de VPS
  • cambio de Docker
  • cambio de PostgreSQL
  • creacion de tablas fisicas
  • ejecucion de migraciones
  • produccion final

3. Hechos confirmados

  • En el origen SGC solo hay acceso a una vista.
  • El identificador fisico de linea del ERP no esta disponible en esa vista.
  • v.Hora existe y fue incorporada como Hora / hora_origen_sgc.
  • Hora mejora trazabilidad, pero no resuelve por si sola la unicidad.
  • line_key_v1 falla unicidad en ventana mayor.
  • line_key_v3 tambien falla porque los duplicados restantes comparten la misma Hora.
  • line_key_v2 y line_key_v4, al incluir line_sequence_v1, resuelven unicidad agregada.
  • line_sequence_v1 resuelve tecnicamente ocurrencias duplicadas dentro de una misma identidad documental, pero no demuestra identidad fisica de linea ERP.

4. line_key_v4 aceptada

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_codigo, line_sequence_v1 ))

Reglas:

  • line_key debe contener line_key_v4 en el diseno documental.
  • unique (tenant_id, line_key) es aceptable para el sync inicial analitico si line_key se genera con esta version.
  • en el raw snapshot el componente vendedor_codigo proviene de Vendedor; en el prepared CSV, el DDL y los checks se conserva normalizado como vendedor_codigo
  • line_key_v4 no debe presentarse como identificador fisico nativo del ERP.
  • id puede existir como surrogate key tecnica del pipeline, pero no forma parte de la identidad logica aprobada; la unicidad logica sigue en tenant_id + line_key
  • Si el ERP expone en el futuro un id fisico de detalle, la identidad debera evolucionar.

5. line_sequence_v1

line_sequence_v1 es una columna tecnica generada por el pipeline.

Debe basarse en ROW_NUMBER() y recalcularse de forma deterministica con el mismo orden canonico documentado. No representa un id fisico del ERP.

Definicion conceptual:

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_codigo 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:

  • se conserva como columna tecnica line_sequence_v1
  • se genera por pipeline
  • resuelve ocurrencias duplicadas dentro de una misma identidad documental
  • no proviene del origen
  • no usa IdFila de sesion
  • no representa id fisico de linea ERP
  • debe versionarse si cambia el PARTITION BY, el ORDER BY o la canonicalizacion

6. Riesgo residual

El riesgo residual aceptado es que filas completamente identicas son diferenciadas por line_sequence_v1, no por identidad fisica ERP.

Implicancia:

  • para analytics, BI, IA y ML, el riesgo se acepta controladamente para el sync inicial
  • para auditoria legal perfecta de renglones ERP, el riesgo no queda cerrado
  • una correccion futura de una sola ocurrencia identica podria no mapearse con certeza documental a la misma ocurrencia historica

7. Mitigacion

Mitigaciones obligatorias:

  • preservar hora_origen_sgc
  • preservar line_sequence_v1
  • preservar source_row_hash_v1
  • preservar sync_batch_id
  • preservar evidencia documental de la decision
  • mantener el estado AMARILLO ACEPTADO
  • documentar que no existe line_id_source fisico disponible en la vista SGC

8. Futuro

Si el ERP o el proveedor expone un identificador fisico de detalle, se debera incorporar como line_id_source.

En ese caso, la identidad podra evolucionar a line_key_v5, con migracion y compatibilidad documental explicitamente versionadas.

9. Checklist

  • decision humana documentada: SI
  • line_key_v4 aceptada: SI
  • estado AMARILLO ACEPTADO: SI
  • id fisico ERP no disponible documentado: SI
  • line_sequence_v1 preservada como tecnica: SI
  • Hora preservada como hora_origen_sgc: SI
  • source_row_hash_v1 preservado: SI
  • migracion piloto/documental preparada: SI
  • rollback piloto preparado: SI
  • sin runtime: SI
  • sin queries: SI
  • sin tablas fisicas: SI
  • sin migraciones ejecutadas: SI