← Volver al inicio

Pendientes con el experto tributario

Decisiones de reglas de negocio que el sistema aún no puede tomar con certeza. Cada punto incluye contexto, pregunta concreta y la evidencia del sample para facilitar la validación. Una vez que el experto confirma, marcar el item como resolved enapps/web/lib/expert-review.tsy ajustar el código relacionado.

8 pendientes 0 resueltos

Pendientes

  1. 1

    Agregación de acumuladores

    Contexto
    El documento de reglas dice: "los acumuladores no se reflejan bien en el resumen mensual — guiarse por los contratos ISDA". La cartola OTC lista cada evento diario de acumulación (0.01515 MT/día, etc.) como una fila separada.
    Pregunta al experto

    ¿Cómo se debe reflejar cada acumulador en la DJ 1820? ¿Una fila por contrato padre con la cantidad total del mes? ¿Usar la cantidad notional del contrato ISDA original? ¿Excluirlos completamente y dejar solo los padres?

    Comportamiento actual
    El sistema emite una fila por cada confirmación ISDA de acumulador. En Enero 2026 aparecen 16 filas de 0.1471 MT cada una para el mismo contrato padre — claramente no es lo que espera SII.
    Evidencia del sample
    Ver confirmaciones 44014714, 44071372, 44121223, 44167005, 44213571, 44261157, 44324343, 44377047, 44435064, 44488332, 44543405, 44588348, 44642970 — todas apuntan al mismo contrato padre 36061546.
    Archivos relacionados:packages/core/src/parsers/otc-confirmations-parser.tspackages/core/src/extractors/otc-confirmations-extractor.ts
  2. 2

    Inferencia de posición LONG/SHORT para trades OTC

    Contexto
    El documento de reglas dice: "StoneX es Fixed Price Payer → cliente es SHORT (2); StoneX es Fixed Price Receiver → cliente es LONG (1)". En los OTC Confirmations casi todas tienen "Fixed Price Payer: Counterparty" (el cliente), lo que devolvería LONG universal.
    Pregunta al experto

    ¿La regla Fixed Payer → posición es correcta tal como está en el documento? En la muestra DJ 1820 Enero 2026 TM, las azúcares 10628571..76 son SHORT pero mis confirmaciones las marcan LONG. ¿Hay otro campo en la confirmación que determina la posición real? ¿O la regla es al revés de como está escrita?

    Comportamiento actual
    Sistema deriva posición desde "Fixed Price Payer" → mayoría LONG. El DJ de muestra tiene mezcla LONG/SHORT que no matchea.
    Evidencia del sample
    Azúcar 10628571 (Fixed Price Payer = Counterparty) aparece en DJ como Posición = 2 (SHORT). Azúcar 10628577 (misma fecha, mismo payer) aparece en DJ como Posición = 1 (LONG). Ambas confirmaciones tienen el mismo texto — la posición difiere por otro criterio.
    Archivos relacionados:packages/core/src/parsers/otc-confirmations-parser.ts (función derivePosition)
  3. 3

    Detección de futuros vencidos/cedidos durante el mes

    Contexto
    Los futuros cedidos (Estado P = EFRP) o liquidados durante el mes no aparecen en la cartola del último día. El DJ 1820 Enero 2026 sample tiene 9 filas "Vencido" (evento 4) de futuros que presumiblemente se cerraron en Enero.
    Pregunta al experto

    ¿De dónde se obtienen esos 9 futuros vencidos? ¿Se comparan posiciones día-a-día y se detectan los que desaparecen entre dos statements consecutivos? ¿O vienen de otra fuente (confirmaciones, otro PDF)?

    Comportamiento actual
    Sistema emite solo las posiciones abiertas del último día (Jan 30). Futuros cerrados durante el mes NO se incluyen.
    Evidencia del sample
    DJ 1820 Enero 2026 TRESMONTES rows 17-18 (trade IDs 9727, 1706 cafe, modalidad=2, evento=4) no están en mi output actual.
    Archivos relacionados:packages/core/src/parsers/futures-statement-parser.ts (allObservedPositions ya guarda todos los días)packages/core/src/transformers/event-classifier.ts
  4. 4

    Lifecycle OTC → Futuro (mismo mes)

    Contexto
    El documento dice: "OTC suscrito y liquidado el mismo mes → se transforma en futuro. El OTC tiene posición SHORT, se traspasa a futuro al mismo precio y cantidad. El futuro nuevo queda con posición COMPRA." En Enero 2026: OTC 44885257 (Short @$4114, 70 MT) se convirtió en futuros 7990 (LONG) + 4735 (SHORT) @$4114, 7 contratos cada uno.
    Pregunta al experto

    ¿El OTC original (44885257) debe OMITIRSE del DJ cuando se transforma, o aparece también? En el sample solo aparecen 7990 y 4735 como evento 1/3; 44885257 no aparece. ¿Cómo detecta el sistema esta transformación? ¿Por matching de precio+cantidad+fecha?

    Comportamiento actual
    Sistema emite las 3 filas (OTC original + ambos futuros) dando duplicación.
    Archivos relacionados:packages/core/src/extractors/trade-merger.ts (donde habría que agregar detección de OTC→Futuro)
  5. 5

    Valor exacto de Acuerdo Marco Fecha

    Contexto
    El sample usa 42015 para OTC y 42016 para Futuros. El DJ 1829 anual muestra variaciones (42015, 42016, 42017, 42018). Actualmente uso constantes 42015/42016 según modalidad.
    Pregunta al experto

    ¿Los valores 42015 y 42016 son constantes fijas, o vienen del PDF de alguna parte? ¿Qué representan esas fechas?

    Comportamiento actual
    Hardcoded: OTC=42015, Futuros=42016.
    Archivos relacionados:packages/core/src/config/constants.ts (ACUERDO_MARCO_FECHA_DEFAULTS)
  6. 6

    Modalidad de Cumplimiento para Lucchetti (col 14)

    Contexto
    El sample DJ 1820 Enero muestra que Lucchetti tiene Modalidad Cumplimiento = 1 mientras que Tres Montes tiene = 2. El documento de reglas dice "Lucchetti el trigo es compensación / Tres Montes el café y el azúcar es entrega física".
    Pregunta al experto

    ¿La regla es: entrega física → 2; compensación → 1? ¿Esto se aplica por cliente (Lucchetti siempre 1, TM siempre 2) o por commodity?

    Comportamiento actual
    Hardcoded a 2 para todos los trades. Lucchetti saldrá mal cuando se reciban sus PDFs.
    Archivos relacionados:packages/core/src/config/constants.ts (DJ1820_CONSTANTS.MODALIDAD_CUMPLIMIENTO)packages/core/src/domain/types.ts (agregar `deliveryType` ya existe en ClientConfig pero no se usa)
  7. 7

    Origen de los PDFs de Lucchetti

    Contexto
    Solo disponemos de los PDFs de Tres Montes. Las DJ de Lucchetti existen pero no sabemos si sus datos vienen de los mismos PDFs de TM o de archivos separados.
    Pregunta al experto

    ¿Lucchetti tiene su propio set de 3 PDFs (OTC statement cuenta 10551, Futuros cuenta 45237, Confirmaciones) o los datos salen de alguna otra parte?

    Comportamiento actual
    Sistema acepta N PDFs y rutea por cuenta automáticamente. Con Tres Montes-only PDFs, la hoja LUCCHETTI queda vacía (0 filas).
  8. 8

    Distinguir ICE Coffee C (arábica) vs ICE Robusta

    Contexto
    El documento diferencia: Ice Coffee C (arábica) → precio × 2204.64/100 y cantidad × 17.01; Ice Robusta → precio directo y cantidad × 10. Ambos aparecen como "cafe" en col 19 de DJ.
    Pregunta al experto

    ¿El detector de "arabica" por el texto "ICE COFFEE C" o "KC" es suficiente y correcto? ¿Hay algún caso borde donde falle?

    Comportamiento actual
    Detector actual: regex /arabica|coffee c\b|kc\b/i.
    Archivos relacionados:packages/core/src/extractors/conversion-helpers.ts (convertFuturesQuantity/Price)

¿Cómo resolver un pendiente?

  1. Conversar con el experto usando los campos Contexto, Pregunta y Evidencia del sample.
  2. Actualizar el código en los archivos listados bajo Archivos relacionados.
  3. Agregar un test de regresión en packages/core/tests/ que capture la regla confirmada.
  4. Cambiar status de 'pending' a 'resolved' en apps/web/lib/expert-review.ts y añadir decision + decidedOn.