Appearance
SICORE - Relevamiento de Datos
Módulo: Compras Tipo: Planning Estado: ✅ Respondido — P-10 pendiente Fecha: 2026-03-23
Resumen de Respuestas
| # | Pregunta | Estado | Respuesta |
|---|---|---|---|
| P-01 | Tabla de órdenes de pago | ✅ | ordcte (movimientos CtaCte proveedores) |
| P-02 | Tabla movimientos CtaCte | ✅ | ordcte (misma tabla) |
| P-03 | Relación orden ↔ comprobante | ✅ | N:M via ordcte_subdicom |
| P-04 | Código de comprobante ARCA | ✅ | Tabla comprob.codigo → subdicom.tipcom |
| P-05 | Código provincia ARCA | ⚠️ | No existe — hay que crear el mapeo |
| P-06 | CUIT del agente de retención | ✅ | empres.cuit |
| P-07 | Retenciones anuladas | ✅ | Anulación de órdenes no implementada aún |
| P-08 | Formato número comprobante | ✅ | Sin separador: 000100001234 (16 chars) |
| P-09 | Líneas por concepto | ✅ | Una línea por cada registro en detgan |
| P-10 | Base de cálculo SICORE | ⚠️ | Pendiente — verificar si se persiste; si no, consultar instructivo ARCA |
| P-11 | Fecha de filtro de período | ✅ | Fecha de la orden de pago (ordcte.fecha) |
| P-12 | Consolidado multi-sucursal | ✅ | Un ZIP por sucursal con mismo CUIT |
| P-13 | Alcance: Ganancias o todo | ✅ | Solo Ganancias ahora, diseño extensible para IIBB/SUSS |
Detalle de Respuestas
P-01 / P-02: Tabla ordcte — Movimientos CtaCte Proveedores
ordcte es la tabla de movimientos de cuenta corriente de proveedores (tabla legacy sin migration propia). Se mapea vía mulcta:
mulcta.codigo = 2 → Proveedores
base = 'ordcte' (tabla de movimientos)
basecli = 'cpdprov' (tabla maestra de proveedores)
tipo = 'A' (Acreedores)detgan.id_orden y detgan.id_mov_ret apuntan ambos a ordcte.id (UUID).
Columnas relevantes confirmadas (inferidas de migration 20251215151618):
| Columna | Tipo | Descripción |
|---|---|---|
id | uuid | PK |
zf | string(6) | Código proveedor |
cnro | decimal(6) | Código proveedor (join con cpdprov.cnro) |
nrocomp | decimal(20) | Número de comprobante |
id_tipo | integer | FK → comprob.codigo (código ARCA del comprobante) |
tipcom | decimal(2) | Tipo de comprobante (igual a subdicom.tipcom) |
⚠️ Pendiente confirmar: nombre exacto de columnas
fechaymonto/importeenordcte.
P-03: Relación N:M via ordcte_subdicom
Tabla ordcte_subdicom (migration 20251215145713):
| Columna | Tipo | Descripción |
|---|---|---|
id | serial PK | Auto |
id_movimiento | uuid | FK → ordcte.id |
id_subdicom | integer | FK → subdicom.id |
Impacto en SICORE: Una orden puede cancelar múltiples comprobantes. Para el campo "Número del comprobante" se debe definir una política: tomar el primer comprobante asociado (ORDER BY id_subdicom ASC) o el de mayor importe.
⚠️ Pendiente definir con el cliente cuál comprobante reportar cuando hay múltiples.
P-04: Código de Comprobante ARCA — Tabla comprob
Tabla comprob (migration 20240823200780, level LEVEL_EMPRESA):
codigo | descri | tipo |
|---|---|---|
| 1 | FACTURA A | D |
| 2 | NOTA DE DEBITO A | D |
| 3 | NOTA DE CREDITO A | C |
| 6 | FACTURA B | D |
| 7 | NOTA DE DEBITO B | D |
| 8 | NOTA DE CREDITO B | C |
| 11 | FACTURA C | D |
| 12 | NOTA DE DEBITO C | D |
| 13 | NOTA DE CREDITO C | C |
subdicom.tipcom = comprob.codigo = código ARCA de 2 chars (rellenado con cero a la izquierda en el archivo SICORE).
P-05: Código Provincia ARCA — Pendiente Implementación
No existe actualmente un mapeo entre la tabla de provincias y los códigos ARCA de 2 dígitos. Hay que crearlo.
Alternativas:
- Agregar columna
codigo_arca smallinta la tabla de provincias - Crear tabla de lookup estática con los 24 códigos ARCA
Códigos ARCA oficiales de provincias:
| Código | Provincia |
|---|---|
| 0 | CIUDAD AUTÓNOMA DE BUENOS AIRES |
| 1 | BUENOS AIRES |
| 2 | CATAMARCA |
| 3 | CÓRDOBA |
| 4 | CORRIENTES |
| 5 | ENTRE RÍOS |
| 6 | JUJUY |
| 7 | MENDOZA |
| 8 | LA RIOJA |
| 9 | SALTA |
| 10 | SAN JUAN |
| 11 | SAN LUIS |
| 12 | SANTA FE |
| 13 | SANTIAGO DEL ESTERO |
| 14 | TUCUMÁN |
| 16 | CHACO |
| 17 | CHUBUT |
| 18 | FORMOSA |
| 19 | MISIONES |
| 20 | NEUQUÉN |
| 21 | LA PAMPA |
| 22 | RÍO NEGRO |
| 23 | SANTA CRUZ |
| 24 | TIERRA DEL FUEGO |
Si el proveedor no tiene provincia mapeada → usar 00.
P-06: CUIT del Agente de Retención — empres.cuit
Tabla empres (migration 20240823200713, level LEVEL_EMPRESA + LEVEL_SUCURSAL):
empres.cuit→varchar(13)(ej:30-66937511-1)
Se usa para el nombre del ZIP exportado y cualquier header futuro.
P-07: Anulación de Órdenes de Pago
La anulación de órdenes de pago no está implementada aún. Para la primera versión: no filtrar por anulación. Cuando se implemente, revisar si detgan necesita soft-delete propio o hereda el de la orden.
P-08: Formato del Número de Comprobante (16 chars, sin separador)
php
// PV (4 chars) + NROCOMP (8 chars) → 12 chars → rellenar con espacios hasta 16
$campo = str_pad(
str_pad($puntoVenta, 4, '0', STR_PAD_LEFT) . str_pad($nroComp, 8, '0', STR_PAD_LEFT),
16, ' ', STR_PAD_RIGHT
);
// "0001" + "00001234" → "000100001234 "P-09: Una línea por detgan
Cada registro en detgan genera exactamente una línea en retenciones.txt. Si una orden tiene 2 conceptos de ganancia → 2 registros en detgan → 2 líneas en SICORE, cada una con su código de régimen (codgan).
P-10: Base de Cálculo — PENDIENTE ⚠️
Acción requerida: Verificar si el monto base de cálculo se persiste en algún campo de detgan o ordcte.
- Si existe → usarlo directamente
- Si no existe → agregar columna
base_calculo decimal(16,5)adetganen la próxima migration - Si no se puede modificar el schema → consultar instructivo ARCA para determinar si informar
acugan.monacu(acumulado total del período) o el excedente del mínimo
P-11: Fecha de filtro — Fecha de la Orden de Pago
El filtro Mes/Año se aplica sobre ordcte.fecha (fecha en que se practicó la retención). Correcto según normativa ARCA: la retención se informa en el período en que se practicó.
P-12: Consolidado Multi-Sucursal — Un ZIP por Sucursal
Se genera un ZIP por sucursal (no uno unificado), agrupando todas las retenciones de esa sucursal bajo el mismo CUIT de empresa.
⚠️ Pendiente confirmar: si
numeradores(key:retencion_ganancia) es a nivel empresa o sucursal. Si es por sucursal, puede haber números de certificado repetidos entre sucursales, lo que ARCA no acepta. Revisar antes de implementar el consolidado.
P-13: Solo Ganancias — Extensible
Primera versión: solo Ganancias (congan/detgan, código impuesto 217, régimen 119).
La arquitectura debe diseñarse para que agregar IIBB/SUSS en el futuro (desde boniret/recret) sea una extensión mínima, no una reescritura.
Pendientes antes de implementar
| Tarea | Prioridad |
|---|---|
Confirmar columnas fecha y monto de ordcte en base de datos | 🔴 Crítico |
| Definir política para orden con múltiples comprobantes (P-03) | 🔴 Crítico |
| Resolver P-10: verificar si base de cálculo se persiste o agregar columna | 🔴 Crítico |
Confirmar nivel de numeradores (empresa vs sucursal) para P-12 | 🟡 Necesario |
Agregar codigo_afip a tabla de provincias (migration) | 🟡 Necesario |
Sistema Bautista ERP - Módulo Compras