Manual del Proceso POS

Los plazos de pago se expresan en dias habiles. Si un comercio tiene configurado un plazo de 10 dias habiles, el sistema debe descontar sabados, domingos y feriados para calcular la fecha real de pago.

• -Los feriados se cargan una vez al ano y aplican a todos los comercios del sistema.
• -El operador de backoffice puede agregar, editar y eliminar feriados.
• -El sistema soporta feriados nacionales (aplican a todos) y puede extenderse a feriados regionales.
• -Si no se cargan los feriados, los plazos se calculan sin tenerlos en cuenta, lo que puede generar diferencias.

El operador de backoffice ingresa al modulo de Feriados y agrega cada dia feriado del ano.

• -Se selecciona el ano y se agregan los feriados con fecha y nombre descriptivo.
• -Se recomienda cargar todos los feriados del ano de una sola vez al inicio de cada periodo.
• -Los feriados se pueden editar o eliminar si hubo un error de carga.
• -El sistema valida que no se dupliquen fechas.

Al dar de alta un comercio se registran sus datos identificatorios.

• -Nombre comercial (como se conoce al comercio).
• -Razon social y CUIT (datos fiscales).
• -El sistema genera un UUID unico que se usa como token de acceso al portal del comercio.
• -Cada comercio pertenece a un client_id (la empresa que opera el PSP).

Cada comercio puede operar a traves de diferentes canales de cobro (POS, QR, Links, Ecommerce). Para cada canal se configura un arancel y un plazo de pago.

• -El arancel (commission_pct) es el porcentaje que se descuenta de cada venta como comision.
• -Opcionalmente se configura una comision minima (commission_min): si el porcentaje da un monto menor, se aplica el minimo.
• -El plazo de pago (settlement_days) indica en cuantos dias habiles se le paga al comercio desde la fecha de compra.
• -Cada canal se puede habilitar o deshabilitar independientemente.

Dentro del canal POS, se pueden configurar aranceles diferentes para cada marca de tarjeta (Visa, Mastercard, Amex, etc.).

• -Si no hay arancel especifico por marca, se usa el arancel general del canal POS.
• -Si existe un arancel por marca, este tiene prioridad sobre el general.
• -Tambien se pueden configurar plazos diferentes por marca (ej: Amex paga a 15 dias, Visa a 10).
• -Los aranceles por marca se almacenan en la tabla pos_brand_commissions.

Se registran las terminales POS y codigos de establecimiento asociados al comercio.

• -El codigo de establecimiento identifica al comercio ante la procesadora de pagos.
• -Las terminales POS se identifican por un numero unico.
• -Estos datos se usan durante la importacion para asociar las transacciones al comercio correcto.
• -Un comercio puede tener multiples terminales y codigos de establecimiento.

El comercio puede consultar sus aranceles y plazos desde su portal, pero no puede modificarlos.

• -Desde el portal del comercio se pueden ver los aranceles vigentes por canal.
• -El comercio puede ver sus terminales y codigos de establecimiento registrados.
• -Cualquier cambio en aranceles o plazos debe ser solicitado al operador del backoffice.

Los archivos contienen las transacciones realizadas con tarjeta en las terminales POS del comercio.

• -Actualmente se soporta el formato de presentaciones de PRISMA/VISA en archivos de texto plano.
• -Cada linea del archivo representa una transaccion con datos como: codigo de establecimiento, numero de terminal, numero de lote, numero de cupon, fecha de compra, monto, cuotas, etc.
• -El archivo puede contener transacciones de multiples comercios y multiples fechas.
• -El sistema valida el formato del archivo antes de procesarlo.

El operador sube el archivo y el sistema lo procesa automaticamente.

• -1. El operador accede al modulo Importador y selecciona el archivo.
• -2. El sistema parsea cada linea y extrae los campos relevantes.
• -3. Se identifica el comercio a partir del codigo de establecimiento.
• -4. Se busca el arancel aplicable: primero por marca de tarjeta, luego el general del canal POS.
• -5. Se calcula la comision: monto_bruto x arancel / 100 (respetando la comision minima).
• -6. Se calcula la fecha de pago: fecha_compra + settlement_days (dias habiles, excluyendo feriados y fines de semana).
• -7. Se guarda la transaccion en pos_transactions y en settlement_transactions.
• -8. Se crea un registro de lote (import_batch) para agrupar todas las transacciones del archivo.

Al finalizar, el sistema muestra un resumen del lote importado.

• -Total de registros procesados exitosamente.
• -Total de registros con errores (y detalle de cada error).
• -Monto bruto total y neto total del lote.
• -Los datos quedan disponibles en el Reporte de Cobranzas y estan listos para ser liquidados.

El sistema busca el arancel aplicable siguiendo una jerarquia de especificidad.

• -1ro: Se busca si hay un arancel especifico para la marca de tarjeta (pos_brand_commissions).
• -2do: Si no hay arancel por marca, se usa el arancel general del canal POS (merchant_channels).
• -3ro: Si hay comision minima, se compara el resultado con la minima y se aplica la mayor.

La fecha de pago se calcula sumando los dias habiles configurados a la fecha de compra.

• -Se parte de la fecha de compra (purchase_date).
• -Se suman los dias habiles (settlement_days) configurados para el canal/marca.
• -No se cuentan sabados ni domingos.
• -No se cuentan los feriados cargados en el sistema para el ano correspondiente.
• -Si la fecha resultante cae en feriado o fin de semana, se pasa al siguiente dia habil.

Opcionalmente se pueden aplicar impuestos sobre la comision cobrada.

• -El monto de impuesto se calcula sobre la comision, no sobre el monto bruto.
• -Se almacena en el campo tax_amount de cada transaccion.
• -El monto neto final es: bruto - comision - impuestos.

Una orden de liquidacion (credit_order) agrupa un conjunto de transacciones de un comercio para un periodo determinado.

• -Cada orden pertenece a un comercio y tiene un rango de fechas (date_from - date_to).
• -Incluye todas las transacciones que tienen fecha de pago dentro de ese rango.
• -La orden calcula automaticamente: total bruto, total comision, total neto y cantidad de transacciones.
• -Se genera un numero de orden unico (ej: ORD-2026-001).

El operador crea las ordenes de liquidacion desde el modulo de Liquidaciones.

• -1. Selecciona el comercio.
• -2. Selecciona el rango de fechas a liquidar.
• -3. El sistema muestra las transacciones pendientes de liquidar en ese rango.
• -4. El operador revisa y confirma la creacion de la orden.
• -5. Las transacciones incluidas cambian su estado de PENDIENTE a LIQUIDADO.
• -6. Se puede agregar ajustes manuales a la orden (cargos extras, descuentos, devoluciones).

El comercio puede consultar sus ordenes de liquidacion desde su portal.

• -Ve la lista de ordenes con su estado (Pendiente, Acreditada).
• -Puede ver el detalle de cada orden: periodo, transacciones, montos.
• -Puede descargar el PDF de cada orden como comprobante.
• -No puede crear, modificar ni eliminar ordenes.

Las ordenes de liquidacion pueden tener ajustes positivos o negativos.

• -Un ajuste positivo suma dinero a la orden (ej: compensacion, bonificacion).
• -Un ajuste negativo resta dinero (ej: devolucion, cargo por servicio, multa).
• -Cada ajuste tiene un monto y una descripcion obligatoria.
• -Los ajustes se almacenan en credit_order_adjustments y se suman/restan al total neto.

Una acreditacion representa la transferencia real de dinero al comercio.

• -Agrupa una o mas ordenes de liquidacion que se pagan juntas.
• -Registra el medio de pago utilizado (Transferencia, Cheque, Efectivo).
• -Registra la fecha en que se realizo la acreditacion.
• -Puede incluir ajustes adicionales (descuentos, bonificaciones).
• -El total de la acreditacion es: suma de netos de las ordenes + ajustes de acreditacion.

El operador crea una acreditacion seleccionando ordenes de liquidacion pendientes.

• -1. Accede al modulo de Acreditaciones y hace clic en Nueva Acreditacion.
• -2. Selecciona el comercio.
• -3. El sistema muestra las ordenes de liquidacion disponibles (no acreditadas).
• -4. Selecciona una o mas ordenes.
• -5. Opcionalmente agrega ajustes a la acreditacion.
• -6. Confirma la creacion. La acreditacion queda en estado PENDIENTE.
• -7. Cuando se efectua el pago, el operador registra la acreditacion: ingresa fecha y medio de pago.
• -8. Las ordenes incluidas y sus transacciones pasan a estado ACREDITADO.

El comercio puede ver en su portal las acreditaciones recibidas.

• -Ve el listado de acreditaciones con fecha, monto y estado.
• -Puede ver el detalle: ordenes incluidas, ajustes, medio de pago.
• -Puede descargar el comprobante de acreditacion en PDF.
• -Los estados posibles son: Pendiente (creada, aun no pagada) y Acreditada (pago realizado).

Un adelanto es una solicitud del comercio o del operador para cobrar transacciones antes de su fecha de pago original.

• -Se seleccionan transacciones de una orden de liquidacion que aun no vencieron.
• -El sistema calcula un costo financiero basado en la tasa diaria del comercio y la cantidad de dias que se adelantan.
• -Formula: costo_adelanto = monto_neto x tasa_diaria x dias_adelantados
• -El comercio recibe: monto_neto - costo_adelanto.
• -La tasa diaria se configura por comercio en el campo advance_daily_rate (ej: 0.15% diario).

El operador puede crear solicitudes de adelanto desde el backoffice.

• -1. Accede al modulo de Adelantos y selecciona la orden de liquidacion.
• -2. Selecciona las transacciones que desea adelantar.
• -3. El sistema calcula automaticamente el costo para cada transaccion.
• -4. El operador revisa los montos y confirma la solicitud.
• -5. La solicitud queda en estado PENDIENTE hasta que se apruebe o rechace.
• -6. Al aprobarse, las transacciones quedan marcadas como adelantadas.

El comercio puede solicitar adelantos desde su portal.

• -Accede a la seccion de Liquidaciones y Adelantos.
• -Ve las transacciones disponibles para adelantar (con fecha de pago futura).
• -Puede seleccionar transacciones individuales o todas las de una orden.
• -Ve el calculo del costo en tiempo real antes de confirmar.
• -La solicitud queda pendiente de aprobacion por el operador del backoffice.

El operador del backoffice revisa y aprueba o rechaza las solicitudes de adelanto.

• -Las solicitudes pendientes se listan en el modulo de Adelantos.
• -El operador puede aprobar: las transacciones se marcan como adelantadas.
• -El operador puede rechazar: debe indicar un motivo de rechazo.
• -El comercio ve el estado actualizado en su portal.
• -Una vez aprobado, el adelanto no se puede revertir.