andesmar_srt, con las transacciones, los pagos y los boletos, más
el número de liquidación con el que SAP las liquidó.
Qué es y por qué una base aparte
Aislamiento: el SRT lee, nunca escribe en lo nuestro
Para negocio
El SRT necesita saber qué cobró cada agencia para rendirle cuentas. En lugar de darle acceso a la base donde entra todo Betterez, le dejamos una copia ordenada, en producción desde el 04/08/2026, que se refresca todas las madrugadas.
Para técnica
- Base
andesmar_srten la misma instancia Cloud SQL, con dos esquemas:andesmar(lo que publicamos, solo lectura para el SRT) ysrt(objetos propios del SRT). - Roles separados: el job publica con su propio rol; el SRT entra con roles de lectura y de desarrollo.
- Contrato:
docs/integracion/SRT_CONTRATO_PUBLICACION.md. Runbook:scripts/srt_sync/RUNBOOK_SRT_PUBLISH.md.
Qué publicamos
Dos jobs, dos momentos del día
| Job | Hora (ART) | Qué publica |
|---|---|---|
andesmar-srt-publish | 02:30 | Tablas andesmar.transaction, andesmar.payment, andesmar.ticket desde public.sales / payments / tickets |
andesmar-srt-publish-liquidaciones | 05:30 | Vistas de liquidación, después de que el pipeline SAP (05:00) numeró el día |
Grano transacción
Una fila de transaction = una operación de caja, no un boleto
Por qué transacción y no boleto
El pago es de la venta, no del boleto. Si se reparte el pago por boleto, una venta con dos boletos cuenta la plata dos veces. Por eso el SRT recibe la transacción con sus pagos, y los boletos colgados de ella.
Fecha: sale_date_art
Betterez guarda la hora en UTC. Una venta de las 21:00 a las 23:59 de Argentina ya es "mañana"
en UTC. El SRT tiene que filtrar por sale_date_art, la fecha en hora argentina.
Devoluciones R-
La fila sintética y la transacción que la contiene
Cuando se cancela un boleto aparece una fila R-<boleto>. Esa fila desglosa plata que
ya está incluida en otra transacción: la cancelación o el cambio. Desde el 29/09:
source_transaction_idliga cadaR-con la transacción que la contiene (48.204 filasR-vinculadas en el SRT).sale_type = 'cancellation'marca la transacción que solo devuelve.- Para plata, sumar pagos; no sumar la
R-y su contenedor a la vez.
Vistas de liquidación
El número de liquidación SAP, visible para el SRT
| Vista | Grano | Columnas |
|---|---|---|
v_liquidacion_detalle | Boleto o ítem liquidado | transactionId, boleto, ítem, codAgencia, fecha, total, liquidación |
v_liquidacion | Liquidación | Cabecera por agencia y número |
codAgencia, liquidación): el número se repite entre agencias.
Acuerdo del 25/09: un número por agencia y día, con el día D-1 cerrado a las 03:00 y lo tardío en una
liquidación nueva. GCP hoy numera por tipo de servicio; el cambio está pendiente.El diagnóstico del 18%
La conciliación del SRT contra la vista de SAP dejaba un 18% sin cuadrar; casi todo tiene causa concreta
+90% es exactamente el seguro
81% agencias que no pasan a SAP
ventas de 21:00 a 23:59 ART
número de boleto reutilizado
| Causa | Qué pasa | Qué hacer |
|---|---|---|
| Monto | En el SRT el total incluye el seguro; en la vista SAP el seguro va aparte, como fila PI- del mismo boleto | Sumar a cada venta las filas PI- de sus boletos |
| No encontrado | El 81% son agencias que no pasan a SAP; otras 1.176 son cancelaciones cuya plata está en SAP bajo R-<boleto> | Excluir esas agencias; emparejar la R- por source_transaction_id y no sumar sale_type = 'cancellation' como venta |
| Fecha | Se tomaba sale_date (UTC): a esa hora en UTC ya es el día siguiente | Usar sale_date_art; la ventana de corte no se toca |
| Agencia | Betterez reutiliza números de boleto y una venta nueva pisaba el boleto de una vieja ya liquidada | Error de nuestro lado; corrección en curso. Cruzar por transactionId |
Pagos corregidos
Republicación del 29/09
Qué se corrigió en origen
- Pagos duplicados: 414.433 filas eliminadas.
- Importes con escala ×100.000: 48.626 filas corregidas.
Resultado
El SRT se republicó el 29/09 y los pagos publicados coinciden con el origen: 1.148.790 pagos por $78.660,2 M.
Checklist rápido
Antes de responder una consulta del SRT
- Grano de la plata = transacción; los pagos cuelgan de la transacción
- Fecha:
sale_date_art, nunca la fecha UTC - Devoluciones: la
R-está contenida en otra transacción (source_transaction_id) - Liquidación: unir por agencia + número
- Agencias excluidas de SAP no tienen liquidación: el "no encontrado" es esperado