IMPLEMENTACIONES
Page tree
Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

Solicitud de especificación de la lógica de decisión.

Importar Archivos de Conciliación

Nota

Para ejecutar el proceso de conciliación, la aplicación necesita nutrirse de datos. Estos datos se importan a través de archivos o por procesos automáticos. El proceso de import automático está parametrizado que se ejecute todos los días a las 04:00am. Por recomendación de nuestro DBA, para no cargar las BBDD durante los procesos de la diaria. Desde la Aplicación, el usuario puede ejecutar los imports manualmente también.

  • 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.

    Import transacciones 
    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)

    Import transacciones 
    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)

    Import transacciones 
    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.

    URL 
    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.

    URL 
    http://10.5.1.38:8098/pisp/v1/consulta/fic

  • Transacciones de Fic: Se importa automáticamente desde el servicio proveído por Fic.

    URL 
    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.

    URL 
    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.


Proceso de Conciliación

Nota

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.


1- Proceso de Conciliación SICOOP contra Ceibo.

1.1- 1600 como Origen y 1600 como Destino.

Transacciones Aceptadas:

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 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, 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 búsqueda. 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 CONCILIADO (CONCI_OK), tomando las descripciones de las búsquedas 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)

2- Proceso de Conciliación SICOOP contra Pronet.
2.1- Subproceso Pronet como Destino
Transacciones Aceptadas:
En este subproceso se toman todas las transacciones donde el Participante Destino sea Pronet (2603), el Participante Origen no sea Cabal (1600) y el estado de la TRX sea ACEP en el SICOOP. Esto último por que ya se ejecuta las validaciones en el subproceso 2 de la conciliación SICOOP-CEIBO. Cada Transacción se divide en 2 Busquedas, una para los valores del Origen y la otra para los valores del DESTINO.

Para el origen, 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 Origen no tenga archivo de conciliación.

Para el destino, 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.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y no existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y existe 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.

Transacciones Rechazadas:
En este subproceso se toman todas las transacciones donde el Participante Destino sea Pronet (2603), el Participante Origen no sea Cabal (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 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 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.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe 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 destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y existe 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.


3- Proceso de Conciliación SICOOP contra Infonet.
3.1- Subproceso Infonet como Destino
Transacciones Aceptadas:
En este subproceso se toman todas las transacciones donde el Participante Destino sea Infonet (2604), el Participante Origen no sea Cabal (1600) y el estado de la TRX sea ACEP en el SICOOP. Esto último por que ya se ejecuta las validaciones en el subproceso 2 de la conciliación SICOOP-CEIBO. Cada Transacción se divide en 2 Busquedas, una para los valores del Origen y la otra para los valores del DESTINO.

Para el origen, 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 Origen no tenga archivo de conciliación.

Para el destino, busca en la tabla que se poblo con el archivo de INFONET la transacción. Filtrando que el idTxDestinatario sea igual al Comprobante. Si encuentra toma el Comprobante y Descripción como datos extra para la descripcion de la busqueda.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y no existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y existe 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.

Transacciones Rechazadas:
En este subproceso se toman todas las transacciones donde el Participante Destino sea Infonet (2604), el Participante Origen no sea Cabal (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 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 en la tabla que se poblo con el archivo de INFONET la transacción. Filtrando que el idTxDestinatario sea igual al Comprobante. Si encuentra toma el Comprobante y Descripción como datos extra para la descripcion de la busqueda.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y no existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y existe 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.

4- Proceso de Conciliación SICOOP contra Bancard.
4.1- Subproceso Bancard como Origen
Transacciones Aceptadas:
En este subproceso se toman todas las transacciones donde el Participante origen sea Bancard (1602), el Participante destino no sea Cabal (1600) y el estado de la TRX sea ACEP en el SICOOP. Esto último por que ya se ejecuta las validaciones en el subproceso 2 de la conciliación SICOOP-CEIBO. Cada Transacción se divide en 2 Busquedas, una para los valores del Origen y la otra para los valores del DESTINO.

Para el Origen, 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 Descripción como datos extra para la descripcion de la busqueda.

Para el Destino, 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 Origen 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
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y no existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y existe 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.

Transacciones Rechazadas:
En este subproceso se toman todas las transacciones donde el Participante origen sea Bancard (1602), el Participante destino no sea Cabal (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 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 Descripción como datos extra para la descripcion de la busqueda.

Para el Destino, 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.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y no existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y existe 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.

4.2- Subproceso Bancard como Destino
Transacciones Aceptadas:
En este subproceso se toman todas las transacciones donde el Participante Destino sea Bancard (1602), el Participante origen no sea Cabal (1600) y el estado de la TRX sea ACEP en el SICOOP. Esto último por que ya se ejecuta las validaciones en el subproceso 2 de la conciliación SICOOP-CEIBO. Cada Transacción se divide en 2 Busquedas, una para los valores del Origen y la otra para los valores del DESTINO.

Para el Origen, 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 Origen no tenga archivo de conciliación.

Para el Destino, 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 Descripción como datos extra para la descripcion de la busqueda.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y no existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y existe 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.

Transacciones Rechazadas:
En este subproceso se toman todas las transacciones donde el Participante Destino sea Bancard (1602), el Participante origen no sea Cabal (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 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 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 Descripción como datos extra para la descripcion de la busqueda.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y no existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y existe 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.


5- Proceso de Conciliación SICOOP contra Bancard QR.
5.1- Subproceso Bancard QR como Destino
Transacciones Aceptadas:
En este subproceso se toman todas las transacciones donde el Participante Destino sea Bancard QR (4001), el Participante origen no sea Cabal (1600) y el estado de la TRX sea ACEP en el SICOOP. Esto último por que ya se ejecuta las validaciones en el subproceso 2 de la conciliación SICOOP-CEIBO. Cada Transacción se divide en 2 Busquedas, una para los valores del Origen y la otra para los valores del DESTINO.

Para el Origen, 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 Origen no tenga archivo de conciliación.

Para el Destino, 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 Descripción como datos extra para la descripcion de la busqueda.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y no existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y existe 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.

Transacciones Rechazadas:
En este subproceso se toman todas las transacciones donde el Participante Destino sea Bancard QR (4001), el Participante origen no sea Cabal (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 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 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 Descripción como datos extra para la descripcion de la busqueda.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si existe en el origen y existe en el destino
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario. ***** CONCILIADO NO OK
Si no existe en el origen y no existe en el destino
Se marca como CONCILIADO (CONCI_OK)
Si no existe en el origen y existe 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.


6- Proceso de Conciliación SICOOP contra Otros Participantes.
6.1- Subproceso Transacciones donde los participantes no tengan archivos de conciliación.
En este subproceso se toman todas las transacciones donde el Participante Origen no sea 1600 o 1602 y el Participante destino no sea 1600, 1602, 2603, 2604 ni 4001.

Lógica para marcar como Conciliada, Pendiente y Rechazada:
Si la transacción está aceptada
Se marca como CONCILIADO (CONCI_OK)
Si la transacción no está aceptada
Se marca como CONCILIADO (CONCI_OK)

7- Proceso de Conciliación TODOS contra SICOOP.
7.1- Subproceso Ceibo contra el Sicoop
En este subproceso se recorre todos los datos importados por el "Aut_Acum" y se cruza con las transacciones del Sicoop Server. Según los sgtes. criterios:
1- Existe en Ceibo y está CUPONADO - Existe en Sicoop con estado ACEP => CONCILIADO
2- Existe en Ceibo y está CUPONADO - Existe en Sicoop con estado RECH => PENDIENTE
3- Existe en Ceibo y está CUPONADO - No Existe en Sicoop => PENDIENTE
4- Existe en Ceibo y no está CUPONADO - Existe en Sicoop con estado ACEP => PENDIENTE
5- Existe en Ceibo y no está CUPONADO - Existe en Sicoop con estado RECH => PENDIENTE
6- Existe en Ceibo y no está CUPONADO - NO Existe en Sicoop => CONCILIADO

7.2- Subproceso Ceibo Pagos contra el Sicoop
En este subproceso se recorre todos los datos importados por el "2001_PAGOS" y se cruza con las transacciones del Sicoop Server. Según los sgtes. criterios:
Si la Boca de Cobranza es CABAL:
TRX NO VALIDA - Autorización Aprobada y Se encontró en el Sicoop con Estado RECH o PEND
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
TRX VALIDADA - Autorización Aprobada y Se encontró en el Sicoop
Se marca como CONCILIADO (CONCI_OK)
TRX NO VALIDA - Autorización Aprobada y NO se encontró en el Sicoop
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.

Si la Boca de Cobranza es DIMO:
TRX NO VALIDA - Autorización Aprobada y Se encontró en el Sicoop con Estado RECH o PEND
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
TRX VALIDADA - Autorización Aprobada y Se encontró en el Sicoop
Se marca como CONCILIADO (CONCI_OK)
TRX NO VALIDA - Autorización Aprobada y NO se encontró en el Sicoop
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.

Si la Boca de Cobranza es SICOOP:
TRX NO VALIDA - Autorización Aprobada y Se encontró en el Sicoop con Estado RECH o PEND
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
TRX VALIDADA - Autorización Aprobada y Se encontró en el Sicoop
Se marca como CONCILIADO (CONCI_OK)
TRX NO VALIDA - Autorización Aprobada y NO se encontró en el Sicoop
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.


7.3- Subproceso Pronet contra el Sicoop
En este subproceso se recorre todos los datos importados por el "Detalle de transacciones (Fecha Proceso)" y se cruza con las transacciones del Sicoop Server
TRX NO VALIDA - Aprobada en Pronet y Estado RECH o PEND en el Sicoop
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
TRX VALIDADA - Aprobada en Pronet y Estado ACEP en el Sicoop
Se marca como CONCILIADO (CONCI_OK)
TRX NO VALIDA - Aprobada en Pronet y No Existe en el Sicoop
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.

7.4- Subproceso Infonet contra el Sicoop
En este subproceso se recorre todos los datos importados por el "EXTRACTO" y se cruza con las transacciones del Sicoop Server
TRX NO VALIDA - Aprobada en Infonet y Estado RECH o PEND en el Sicoop
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.
TRX VALIDADA - Aprobada en Infonet y Estado ACEP en el Sicoop
Se marca como CONCILIADO (CONCI_OK)
TRX NO VALIDA - Aprobada en Infonet y No Existe en el Sicoop
Se marca como PENDIENTE (CONCI_NO_OK), para la revisión del Usuario.

  • No labels