|
Transacciones del Pronet: Se importa desde el portal de Gestión Externa de Pronet, se descarga el Archivo "Detalle de transacciones (Fecha Proceso)" para importar los pagos hechos por medio de esta Boca de Cobranza.
Transacciones de Bancard/Infonet: Se importa el archivo "EXTRACTO" que proporciona Bancard para importar los pagos hechos por la Boca de Cobranza de Infonet, las transferencias Bancarias y las compras con QR de Infonet.
Transacciones del Sicoop: Se importa automáticamente desde las tablas del Sicoop Server.
SELECT *
FROM SICOOP.X_ORDENES xo
WHERE xo.FEC_INICIO_PROCESAMIENTO BETWEEN To_date('2024-11-21 00:00:00', 'yyyy-mm-dd hh24:mi:ss') AND To_date('2024-11-21 23:59:59', 'yyyy-mm-dd hh24:mi:ss'); |
Transacciones de Ceibo: Se importa automáticamente desde las tablas del autorizador. (tanto desde el LOG_TRANSACC_CR y desde el LOG_TRANSACC_CR_HIST para fechas anteriores)
SELECT l.MOVEXTFCH, l.EMISOR AS EMISOR, l.NRO_CUENTA AS CUENTA, CREDITOPY.FC_CRIPTO2PAN@BAPY(l.NRO_TARJETA) AS Tarjeta, NVL(T.NOMBRE_PARA_PLASTICO, ' ') AS NOMBRE_PLASTICO, l.NRO_COMERCIO AS COMERCIO,
NVL(c.DESCRIPCION, REPLACE(L.CAN_CODE, '|', '/')) AS DESC_COMERCIO, to_char(l.FECHA, 'DD/MM/YYYY') AS FECHA, to_char(l.HORA, 'HH24:MI:SS') AS HORA, ROUND(l.IMPORTE) AS MONTO,
DECODE(L.CODIGO_OPERACION, 0, 'DB', 1, 'CR', 0) AS COD_OPERACION, l.PLAN AS PLAN_VENTA, pdv.DESCRIPCION AS TIPO_VENTA, l.CUOTAS, NVL(l.TIPO_AUTORIZACION, 'R') AS RESULTADO, l.NRO_AUTORIZACION AS AUTORIZACION,
NVL(TRIM(l.NRO_TICKET), 0) AS NRO_BOLETA, l.CODIGO_ADQUIRIENTE, a.DESCRIPCION, l.NRO_RES AS COD_RESPUESTA, l.RES_INTERNO AS MOTIVO_RECHAZO,
CASE when presentacion is not null and presentacion > 0 THEN 'Cuponado' ELSE 'No Cuponado' end ESTADO_CUPON,
NVL(c.RUC, ' ') RUC_COMERCIO, NVL(c.RAMO, -1) RAMO_COMERCIO, NVL(r.DESCRIPCION, 'NULO') DESC_RAMO_COMERCIO, NVL(lc.LIMITE , 0) LIMITE_PLAN,
CASE WHEN l.TX_INTERNA = 'RETIRO' THEN CASE WHEN l.DISP_CONTADO > l.DISP_EFECTIVO THEN l.DISP_EFECTIVO ELSE l.DISP_CONTADO END WHEN l.PLAN = 9 THEN CASE WHEN l.DISP_CONTADO > l.DISP_SALUD THEN l.DISP_SALUD ELSE l.DISP_CONTADO END ELSE l.DISP_CONTADO END DISPONIBLE
--SELECT *
--SELECT COUNT(*)
FROM LOG_TRANSACC_CR_HIST l
INNER JOIN TARJETAS t ON t.TARJETA = l.NRO_TARJETA
INNER JOIN COMERCIOS c ON c.COMERCIO = l.NRO_COMERCIO
INNER JOIN PLANES_DE_VENTA pdv ON pdv.PLAN_VENTA = l.PLAN
INNER JOIN ACQUIRERS a ON a.ACQUIRER = l.CODIGO_ADQUIRIENTE
INNER JOIN RAMOS r ON r.RAMO = l.RAMO AND r.EMISOR_PROCESADOR = l.EMISOR_PROCESADOR
INNER JOIN LIMITES_CUENTAS lc ON lc.PLAN_VENTA = l.PLAN AND lc.EMISOR = l.EMISOR AND lc.NUMERO_CUENTA = l.NRO_CUENTA
WHERE l.MOVEXTFCH BETWEEN to_date('16092024000000','ddmmyyyyhh24miss') AND to_date('16092024235959','ddmmyyyyhh24miss')
AND l.NRO_TICKET = '486008714555'
AND l.CODIGO_ADQUIRIENTE IN (10000000023, 10000000017, 490508, 490509)
ORDER BY l.MOVEXTFCH; |
Transacciones de Ceibo-Pagos: Se importa automáticamente desde las tablas del autorizador.(tanto desde el LOG_TRANSACC_CR y desde el LOG_TRANSACC_CR_HIST para fechas anteriores)
SELECT l.EMISOR, CASE WHEN l.NRO_COMERCIO = '805001' THEN '1' WHEN l.NRO_COMERCIO = '115001' THEN '1' WHEN l.NRO_COMERCIO = '805505' THEN '505' WHEN l.NRO_COMERCIO = '805502' THEN '502' END SUCURSAL,
CASE WHEN l.NRO_COMERCIO = '805001' THEN 'CABAL' WHEN l.NRO_COMERCIO = '115001' THEN 'DIMO' WHEN l.NRO_COMERCIO = '805505' THEN 'SICOOP -RECEPTOR DE PAGOS' WHEN l.NRO_COMERCIO = '805502' THEN 'PRONET -RECEPTOR DE PAGOS' END BOCA_COBRANZA,
l.NRO_CUENTA AS NUMERO_CUENTA, CREDITOPY.FC_CRIPTO2PAN@BAPY(l.NRO_TARJETA) AS TARJETA, t.NOMBRE_PARA_PLASTICO AS USUARIO_TARJETA, l.MOVEXTFCH AS FECHA_MOVIMIENTO, DECODE(l.CODIGO_OPERACION, 0, 'DB', 1, 'CR') CODIGO_OPERACION, l.IMPORTE,
l.TIPO_AUTORIZACION, l.NRO_TICKET AS NUMERO_TICKET
--SELECT COUNT(*)
--SELECT *
FROM LOG_TRANSACC_CR_HIST l
INNER JOIN TARJETAS t ON t.TARJETA = l.NRO_TARJETA
WHERE l.MOVEXTFCH BETWEEN to_date('030220230000','ddmmyyyyhh24mi') AND to_date('030220232359','ddmmyyyyhh24mi')
AND l.NRO_COMERCIO IN ('805505', '805001', '805502', '115001','50001')
ORDER BY l.MOVEXTFCH; |
Transacciones de Atlas: Se importa automáticamente desde el servicio proveído por Atlas.
http://10.5.1.38:8790/api/sipap/v1/operaciones/consultar |
Transacciones de Pisp/Spi: Se importa automáticamente desde el servicio proveído por Fic.
http://10.5.1.38:8098/pisp/v1/consulta/fic |
Transacciones de Fic: Se importa automáticamente desde el servicio proveído por Fic.
https://mdw.cabal.coop.py/api/sipap/fic/v1/movimientos/listar |
Transacciones de Interfisa: Se importa automáticamente desde el servicio proveído por Interfisa.
https://mdw.cabal.coop.py/api/sipap/interfisa/v1/movimientos/listar |
Una vez cargado todos esos archivos, el usuario puede seguir con el proceso de conciliación.
El proceso de Conciliación está dividido en 12 Procesos y cada uno de estos procesos contienen otros subprocesos. A continuación se describirán los procesos ejecutados. |
En este subproceso, se recorren todas las transacciones del sicoop donde el idSesion contenga el string "REVERSA". Dependiendo si el estado de la transacción en el Sicoop es 'ACEP', entonces marca el ESTADO_CONCI = 'REVERSA_ACEP' cualquier estado distinto, marca como 'REVERSA_RECH'.
Este proceso lo que permite es no controlar 2 veces la misma transacción de reverso, puesto que se controlan en procesos posteriores, cuando se concilia la transacción original.
En este subproceso, se recorren todas las transacciones del Sicoop que cumplan los requisitos mencionados anteriormente y se divide la búsqueda entre transacciones con estado 'ACEP' en el Sicoop y estados distintos a 'ACEP'.
Transacciones Aceptadas en el Sicoop:
Para cada transacción, se divide la búsqueda por los datos del origen y destino de la transacción.
Para el origen: Busca entre las transacciones importadas de Ceibo cruzando el idTxOriginante por el nroBoleta siempre y cuando el tipo de movimiento en ceibo sea 'DB'.
Si el participante destino es alguno de estos participantes: (4003, 4004, 4005, 4006). Vuelve a validar la transacción con los datos de Bepsa, por lo tanto. Busca en la tabla del MDW (LOG_TRANSACCION) cruzando la columna ID_OPERACION_ORIGINANTE = idTxOriginante del Sicoop, recuperando el ID_OPERACION_PARTICIPANTE. y vuelve a hacer el mismo control anterior donde cruza contra el nroBoleta.
Para el destino: Controla que el tipo de Operación no sea una Compra o Adelanto de efectivo (TipoTrx= 'COMP', 'AVAN')
|
Para el destino: Controla que el tipo de Operación no sea una Compra o Adelanto de efectivo (TipoTrx= 'COMP', 'AVAN')
|
Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Si está cuponada en el origen y está cuponada en el destino
Se marca como CONCILIADO (CONCI_OK), tomando las descripciones de las busquedas como datos extras para los informes.
Si no está cuponada en el origen o en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. Haciendo una validación para saber cual de los 2 o si ambos no están cuponadas.
Si no existe en el origen y en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. Haciendo una validación para saber cual de los 2 o si ambos no están cuponadas o no existen.
FILTRO PEDIDO POR ALMADA EN FECHA 11/11/2022 pretende marcar como conciliadas las transacciones de compra QR cabal no cuponadas y con monto menor a 1.000gs
Si el tipo de Transacción es 'COMP', el monto es menor a 1000gs y uno de los estados del origen o destino sea "No Cuponado" Se marca como NO CONCILIADO (CONCI_NO_OK)
Transacciones Rechazadas:
En este subproceso, se recorren todas las transacciones del sicoop donde el Participante 1600 sea Origen y destino (TP y/o TC), y el estado de la TRX sea RECH, PEND o ERROR. Para cada transacción se divide la busqueda en 2 partes, la primera toma los datos del Origen y la segunda del Destino.
Para el Origen, busca el idTxOriginante en la tabla de las transacciones de Ceibo (poblada con los datos del Aut_Acum)(nroBoleta). Si encuentra, compara si está aprobada o no y cuponada o no, tomando la Glosa del archivo como descripción de la búsqueda. Si no encuentra, marca como que no existe en el origen.
Para el Destino, busca el idTxDestinatario en la tabla de las transacciones de Ceibo (poblada con los datos del Aut_Acum)(nroBoleta). Si encuentra, compara si está aprobada o no y cuponada o no, tomando la Glosa del archivo como descripción. Si no encuentra, busca en la tabla de Pagos (poblada con los datos del archivo 2001_PAGOS del emisor 115). Compara el idTxDestinatario con el número de ticket de la tabla filtrando las transacciones que tengan el valor de 'A' en la columna de Tipo_Autorización. Si existe, toma los datos de Nro_Boleta, Glosa y Número de ticket para la descripción de la busqueda. Si no existe en el Archivo de Aut_acum y tampoco en el archivo de pagos, se marca como que la transacción no existe en el archivo destino.
Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Si está cuponada en el origen y está cuponada en el destino
Se marca como PENDIENTE (CONCI_NO_OK), tomando las descripciones de las busquedas como datos extras para los informes.
Si no está cuponada en el origen y tampoco en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no está cuponado en el origen o en el destino
Se marca como PENDIENTE (CONCI_NO_OK). Haciendo la validación correspondiente de si es en el Origen o en el Destino.
Si no existe en el origen y tampoco existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si solamente no existe en uno de los casos, se marca como PENDIENTE (CONCI_NO_OK)
1.2- 1600 solo como Origen y XXXX como Destino.
Transacciones Aceptadas:
En este subproceso, se recorren todas las transacciones del sicoop donde el Participante Origen sea 1600 (TP y/o TC) y el Participante Destino sea distinto al 1600, y el estado de la TRX sea ACEP en el Sicoop. Para cada transacción se divide la busqueda en 2 partes, la primera toma los datos del Origen y la segunda del Destino.
Para el Origen, busca el idTxOriginante en la tabla de las transacciones de Ceibo (poblada con los datos del Aut_Acum)(nroBoleta). Si encuentra, compara si está cuponada o no, tomando la Glosa del archivo como descripción de la búsqueda. Si no encuentra, marca como que no existe en el origen.
Para el Destino, hace 1 de 5 busquedas dependiendo del participante.
Si el participante es 1602 (Bancard):
Busca en la tabla que se poblo con el archivo de Extractos la transacción. Filtrando que el idTxDestinatario sea igual al Comprobante. Si encuentra toma el comprobante y la descripcion como datos extra para la descripcion de la busqueda.
Si el participante es 2603 (Pronet):
Busca en la tabla que se poblo con el archivo de PRONET la transacción. Filtrando que el idTxDestinatario sea igual al Campo Lote + TRX. Si encuentra toma el Lote y el TRX como datos extra para la descripcion de la busqueda.
Si el participante es 2604 (Infonet):
Busca en la tabla que se poblo con el archivo de Extractos la transacción. Filtrando que el idTxDestinatario sea igual al Comprobante. Si encuentra toma el comprobante y la descripcion como datos extra para la descripcion de la busqueda.
Si el participante es 4001 (Bancard QR):
Busca en la tabla que se poblo con el archivo de Extractos la transacción. Filtrando que el idTxDestinatario sea igual al Comprobante. Si encuentra toma el comprobante y la descripcion como datos extra para la descripcion de la busqueda.
Si el participante es distinto a todo lo anterior (Cooperativas, Emuladores y Panal):
Busca sobre la tabla donde se importaron las transacciones del Sicoop. Esto es una redundancia, pero sirve para marcar como existentes las transacciones donde el Participante Destino no tenga archivo de conciliación.
Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Si está cuponada en el origen
Se marca como CONCILIADO (CONCI_OK), tomando las descripciones de las busquedas como datos extras para los informes.
Si no está cuponada en el origen
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. Ya que en este caso, en el destino no es valido el estado de la TRX
Si no existe en el origen o en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. Haciendo una validación para saber cual de los 2 no existen o si en el origen no está cuponado.
Transacciones Rechazadas:
En este subproceso, se recorren todas las transacciones del sicoop donde el Participante Origen sea 1600 (TP y/o TC) y el Participante Destino sea distinto al 1600, y el estado de la TRX sea RECH, PEND o ERROR en el Sicoop. Para cada transacción se divide la busqueda en 2 partes, la primera toma los datos del Origen y la segunda del Destino.
Para el Origen, busca el idTxOriginante en la tabla de las transacciones de Ceibo (poblada con los datos del Aut_Acum)(nroBoleta). Si encuentra, compara si está cuponada o no, tomando la Glosa del archivo como descripción de la búsqueda. Si no encuentra, marca como que no existe en el origen.
Para el Destino, hace 1 de 5 busquedas dependiendo del participante.
Si el participante es 1602 (Bancard):
Busca en la tabla que se poblo con el archivo de Extractos la transacción. Filtrando que el idTxDestinatario sea igual al Comprobante. Si encuentra toma el comprobante y la descripcion como datos extra para la descripcion de la busqueda.
Si el participante es 2603 (Pronet):
Busca en la tabla que se poblo con el archivo de PRONET la transacción. Filtrando que el idTxDestinatario sea igual al Campo Lote + TRX. Si encuentra toma el Lote y el TRX como datos extra para la descripcion de la busqueda.
Si el participante es 2604 (Infonet):
Busca en la tabla que se poblo con el archivo de Extractos la transacción. Filtrando que el idTxDestinatario sea igual al Comprobante. Si encuentra toma el comprobante y la descripcion como datos extra para la descripcion de la busqueda.
Si el participante es 4001 (Bancard QR):
Busca en la tabla que se poblo con el archivo de Extractos la transacción. Filtrando que el idTxDestinatario sea igual al Comprobante. Si encuentra toma el comprobante y la descripcion como datos extra para la descripcion de la busqueda.
Si el participante es distinto a todo lo anterior (Cooperativas, Emuladores y Panal):
Busca sobre la tabla donde se importaron las transacciones del Sicoop. Esto es una redundancia, pero sirve para marcar como NO existentes las transacciones donde el Participante Destino no tenga archivo de conciliación.
Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Si está cuponada en el origen
Se marca como PENDIENTE (CONCI_NO_OK), tomando las descripciones de las busquedas como datos extras para los informes.
Si no está cuponada en el origen
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. Ya que en este caso, en el destino no es valido el estado de la TRX
Si no existe en el origen y no existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si solo existe en el origen, está cuponado y no existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si existe en el origen, no cuponado y no existe en el Destino.
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el Origen y si existe en el Destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. Ya que en este caso, en el destino no es valido el estado de la TRX
1.3- XXXX como Destino y 1600 solo como Origen.
Transacciones Aceptadas:
En este subproceso, se recorren todas las transacciones del sicoop donde el Participante Destino sea 1600 (TP y/o TC) y el Participante Origen sea distinto al 1600, y el estado de la TRX sea ACEP en el Sicoop. Para cada transacción se divide la busqueda en 2 partes, la primera toma los datos del Origen y la segunda del Destino.
Para el Origen, hace 1 de 2 busquedas dependiendo del participante.
Si el participante es 1602 (Bancard):
Busca en la tabla que se poblo con el archivo de Extractos la transacción. Filtrando que el idTxOriginante sea igual al Comprobante. Si encuentra toma el comprobante y la descripcion como datos extra para la descripcion de la busqueda.
Si el participante es distinto a todo lo anterior (Cooperativas, Emuladores y Panal):
Busca sobre la tabla donde se importaron las transacciones del Sicoop. Esto es una redundancia, pero sirve para marcar como NO existentes las transacciones donde el Participante Origen no tenga archivo de conciliación.
Para el Destino, busca el idTxDestinatario en la tabla de las transacciones de Ceibo (poblada con los datos del Aut_Acum)(nroBoleta). Si encuentra, compara si está cuponada o no, tomando la Glosa del archivo como descripción. Si no encuentra, busca en la tabla de Pagos (poblada con los datos del archivo 2001_PAGOS del emisor 115). Compara el idTxDestinatario con el número de ticket de la tabla filtrando las transacciones que tengan el valor de 'A' en la columna de Tipo_Autorización. Si existe, toma los datos de Nro_Boleta, Glosa y Número de ticket para la descripción de la busqueda. Si no existe en el Archivo de Aut_acum y tampoco en el archivo de pagos, se marca como que la transacción no existe en el archivo destino.
Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el Origen y existe en el Destino
Si está cuponado en el Destino
Se marca como CONCILIADO (CONCI_OK)
Si no está cuponado en el Destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si existe en el Origen y No existe en el Destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si no existe en el Origen y si existe en el Destino
Si está cuponado en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si no está cuponado en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si no existe en el Origen y no existe en el del Destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Transacciones Rechazadas:
En este subproceso, se recorren todas las transacciones del sicoop donde el Participante Destino sea 1600 (TP y/o TC) y el Participante Origen sea distinto al 1600, y el estado de la TRX sea RECH, PEND o ERROR en el Sicoop. Para cada transacción se divide la busqueda en 2 partes, la primera toma los datos del Origen y la segunda del Destino.
Para el Origen, hace 1 de 2 busquedas dependiendo del participante.
Si el participante es 1602 (Bancard):
Busca en la tabla que se poblo con el archivo de Extractos la transacción. Filtrando que el idTxOriginante sea igual al Comprobante. Si encuentra toma el comprobante y la descripcion como datos extra para la descripcion de la busqueda.
Si el participante es distinto a todo lo anterior (Cooperativas, Emuladores y Panal):
Busca sobre la tabla donde se importaron las transacciones del Sicoop. Esto es una redundancia, pero sirve para marcar como NO existentes las transacciones donde el Participante Destino no tenga archivo de conciliación.
Para el Destino, busca el idTxDestinatario en la tabla de las transacciones de Ceibo (poblada con los datos del Aut_Acum)(nroBoleta). Si encuentra, compara si está aprobada o no y cuponada o no, tomando la Glosa del archivo como descripción. Si no encuentra, busca en la tabla de Pagos (poblada con los datos del archivo 2001_PAGOS del emisor 115). Compara el idTxDestinatario con el número de ticket de la tabla filtrando las transacciones que tengan el valor de 'A' en la columna de Tipo_Autorización. Si existe, toma los datos de Nro_Boleta, Glosa y Número de ticket para la descripción de la busqueda. Si no existe en el Archivo de Aut_acum y tampoco en el archivo de pagos, se marca como que la transacción no existe en el archivo destino.
Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el Origen y existe en el Destino
Si está cuponado en el Destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si no está cuponado en el Destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si existe en el Origen y No existe en el Destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si no existe en el Origen y si existe en el Destino
Si está cuponado en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
Si no está cuponado en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el Origen y no existe en el del Destino
Se marca como CONCILIADO (CONCI_OK)