informe de análisis funcional - automatización de recaudación bancaria

ANALISIS DE REQUISITOS DEL SISTEMA

Cliente: REPSOL COMERCIAL SAC Proyecto: Automatización de Recaudación Bancaria

Actualización: 1.0Autor:

Centro de Calidad de Aplicaciones

document.doc Pág. 1 de 55

Revisiones

Versión Fecha Responsable Descripción del cambio

Tabla de Contenido

1. OBJETIVOS Y ALCANCE.............................................................................................................4

2. DESCRIPCION DE LA SITUACION ACTUAL..............................................................................5

2.1. PROBLEMATICA................................................................................................................................... 5

3. ANALISIS DE LA SITUACION ACTUAL......................................................................................6

3.1. MODELOS DE PROCESO DE NEGOCIO ACTUAL.............................................................................63.1.1. MODELO ACTUAL DE COBRANZA EN TERMINALES PARA VENTA A CREDITO.....................63.1.2. MODELO ACTUAL DE COBRANZA EN TERMINALES PARA VENTA AL CONTADO.................83.1.3. MODELO ACTUAL DE COBRANZA EN EESS PARA VENTA A CREDITO.................................103.1.4. MODELO ACTUAL DE COBRANZA EN EESS PARA VENTA ADELANTADA............................14

3.2. RELACION DE REQUERIMIENTOS POR NEGOCIO.........................................................................17

3.3. REQUISITOS NO FUNCIONALES......................................................................................................20

3.4. INTERFAZ DE USUARIO....................................................................................................................20

3.5. IDENTIFICACION DE GAPS...............................................................................................................20

4. ALTERNATIVAS DE SOLUCION...............................................................................................22

4.1. RELEVAMIENTO DE OPERATIVA DE RECAUDACION CON ENTIDADES......................................22

4.2. MODELO DE NEGOCIO FUTURO......................................................................................................224.2.1. MODELO DE COBRANZA EN TERMINALES PARA VENTA A CREDITO..................................234.2.2. MODELO DE COBRANZA EN TERMINALES PARA VENTA AL CONTADO...............................254.2.3. MODELO DE COBRANZA EN EESS PARA VENTA A CREDITO................................................274.2.4 MODELO DE COBRANZA EN EESS PARA VENTA ADELANTADA............................................30

4.3. BENEFICIOS Y PREMISAS DENTRO DEL MODELO FUTURO........................................................334.3.1 BENEFICIOS.................................................................................................................................. 334.3.2 PREMISAS..................................................................................................................................... 33

4.4. ALTERNATIVAS PROPUESTAS.........................................................................................................34

5. CASOS DE USO DEL MODELO PROPUESTO.........................................................................36

5.1 CASOS DE USO PARA CONFIGURACION.........................................................................................365.1.1. CASO DE USO 01 – CONFIGURAR CATALOGOS....................................................................36

5.2 CASOS DE USO PARA PROCESOS...................................................................................................365.2.1. CASO DE USO 02 – GENERAR LOS DOCUMENTOS POR COBRAR.......................................365.2.2. CASO DE USO 03 – CONSULTAR INFORMACION DE TRANSACCION...................................375.2.3. CASO DE USO 04 – EFECTUAR TRANSACCION Y APLICAR DEPOSITO...............................375.2.4. CASO DE USO 05 – ENVIAR TRANSACCION DE PAGO A ENVOY..........................................39

5.3 CASOS DE USO PARA REPORTES...................................................................................................405.3.1. CASO DE USO 07 – REPORTE DE RECAUDACION..................................................................40

6 RECOMENDACIONES.................................................................................................................41



7 CONCLUSIONES.........................................................................................................................41

8 GLOSARIO DE TERMINOS.........................................................................................................41

9 ANEXOS.......................................................................................................................................43

9.1 MATRIZ DE RELEVAMIENTO CON LOS NEGOCIOS........................................................................43

9.2 MATRIZ DE RELEVAMIENTO CON ENTIDADES BANCARIAS..........................................................525.3.1. INTERBANK.................................................................................................................................. 525.3.2. SCOTIABANK............................................................................................................................... 535.3.3. BCP............................................................................................................................................... 545.3.4. CONTINENTAL BBVA................................................................................................................... 55



1. OBJETIVOS Y ALCANCE

El objetivo del proyecto es implementar procesos automáticos de recaudación en línea desde las entidades bancarias hasta las áreas recaudadoras del grupo de forma tal que soporten toda la funcionalidad requerida por cada uno de los negocios involucrados en el proceso de comercialización de los productos que generan la deuda a ser recaudada. El alcance de la propuesta es el siguiente:

Cubrir toda la recaudación bancaria en línea de los negocios pertenecientes a las empresas de RECOSAC y REMARSAC a través de las entidades bancarias del BCP, Scotiabank, Interbank y Banco Continental BBVA.

Cubrir la funcionalidad asociada a los pagos totales, parciales, adelantados, con cartas de transferencia y al contado, efectuadas en estas entidades bancarias.

Asegurar los mecanismos de seguridad e integridad de información que respalden la integridad de las transacciones generadas durante los procesos de recaudación.



2. DESCRIPCION DE LA SITUACION ACTUAL

Las diversas empresas del grupo efectúan la recaudación de sus cobranzas a través de las entidades bancarias mediante las siguientes soluciones:

1. Cobranza en bancos con identificación parcial.- El banco registra por cada depósito la identificación del cliente y valida el número de RUC ó DNI con la correspondiente razón social o nombre. Esta información es almacenada en un archivo de depósitos por cada entidad bancaria y enviada en forma diaria a las empresas propietarias de la deuda. Esta modalidad es utilizada por REMARSAC y RECOSAC

2. Cobranza en bancos con identificación específica.- El banco identifica el documento por cobrar. Los datos requeridos son enviados en forma diaria por las empresas a cada banco de acuerdo a su estructura. Las entidades bancarias almacenan la recaudación en un archivo que es enviado en forma diaria a las empresas propietarias de la deuda. Esta modalidad es utilizada por RYCOPESA.

2.1. PROBLEMATICA

Si bien la información recibida es procesada en el SAP en forma diaria, esta funcionalidad actual no cubre los requerimientos ni del negocio de REMARSAC y RECOSAC ni de las áreas comerciales asociadas debido a la siguiente problemática:

Los saldos de los clientes no se actualizan en el momento del pago y esto es necesario en casos en los cuales se requiere contar con un saldo a favor como condición para hacer efectivo el pedido y el despacho correspondientes. Estos casos representan un 90% de los casos totales de los clientes de RECOSAC y REMARSAC.

En los casos de identificación parcial si bien el banco valida la existencia del RUC o DNI no es posible identificar la factura a ser pagada por el cliente generando operativas adicionales de contacto con los clientes para aplicar el pago a las facturas en deuda.

La solución actual no cubre la funcionalidad de pagos adelantados y pagos de clientes crédito (pagos parciales aplicados o recaudación mediante carta de transferencia)



3. ANALISIS DE LA SITUACION ACTUAL

A continuación se presenta el análisis de la situación actual, exponiendo en primer lugar los modelos del proceso de negocio dentro del alcance de las empresas RECOSAC y REMARSAC correspondiente a la recaudación en bancos para los siguientes escenarios:

Cobranza en Terminales al Crédito. Cobranza en Terminales al Contado/Venta Adelantada. Cobranza en EESS al Crédito. Cobranza en EESS al Venta Adelantada.

Luego se presentará la relación de requerimientos relevados por área de negocio involucrada en el alcance.

3.1. MODELOS DE PROCESO DE NEGOCIO ACTUAL

3.1.1. MODELO ACTUAL DE COBRANZA EN TERMINALES PARA VENTA A CREDITO

El proceso se inicia con la solicitud del pedido por parte del cliente.

La terminal genera el pedido y efectúa el control de crédito del cliente.

Si el cliente tiene saldo entonces la terminal efectúa el despacho. Si no se indica al cliente que efectúe el depósito a fin de que cubra el saldo requerido por el pedido.



Una vez efectuado el despacho se emite la factura en SAP-SD y se envía al cliente para que efectúe el depósito correspondiente de acuerdo a la fecha de vencimiento de la factura.

En este escenario el cliente tiene la opción de abonar en el banco en la cuenta recaudadora identificándose con su RUC ó DNI. Para cubrir esta funcionalidad las empresas de REPSOL envían periódicamente al banco la relación de clientes activos con los datos de RUC y Razón Social, ó DNI y Nombre, según se trate de Empresa ó Persona Natural respectivamente. Este tipo de cobranza no permite rebajar un documento específico pero sí aplicar el abono a cuenta en la cartera del cliente.

De acuerdo a la información indicada por el cliente del pago de la deuda, la terminal solicita la confirmación del depósito a la Central de Cobranza.

La Central de Cobranza confirma el depósito y con esta confirmación la terminal registra el depósito y aplica la cobranza en SAP-FI a la factura generada.

Al final de la jornada Tesorería genera un reporte de recaudo o extracto bancario con toda la información de lo cobrado en el día y efectúa la carga de esta información en SAP. Los medios a través de los cuales se obtiene esta información son:

o Fax / mail de abono del cliente.o Reporte de bancos.o Reporte de cobranzas en caja.

Una vez identificado el abono el área de Cobranzas procede a compensar la cuenta por cobrar del cliente. Esta misma información le sirve al conciliador del área de Contabilidad para efectuar la conciliación de los movimientos de ingreso de bancos en la cuenta recaudadora de cada sociedad.

Contabilidad efectúa la conciliación bancaria basándose en la información que ha sido cargada en SAP por Tesorería y en las aplicaciones que efectúa la terminal. El conciliador del área de Contabilidad inicia el proceso de conciliación de los ingresos en bancos en la cuenta recaudadora de cada línea de negocio y de las cuentas por cobrar que aún permanecen “abiertas” (pendientes de pago). También se encarga de aplicar los abonos identificados compensando las cuentas por cobrar del cliente en el sistema.



3.1.2. MODELO ACTUAL DE COBRANZA EN TERMINALES PARA VENTA AL CONTADO

El proceso se inicia con la información de que el cliente ha efectuado un depósito por una venta al contado.

La terminal recibe el voucher del cliente con el depósito efectuado en el banco.

La terminal solicita la confirmación del depósito a Central de Cobranza.

Central de Cobranza confirma el depósito y con esta confirmación la terminal efectúa el despacho y genera la factura por venta adelantada en SAP-SD.

La terminal registra el depósito y aplica la cobranza en SAP-FI a la factura generada. Si se trata de clientes contado que han efectuado abonos por adelantado en bancos, al momento de emitirles la factura se emite también el comprobante de percepción.

La terminal envía la factura ya pagada al cliente.






Contabilidad efectúa la conciliación bancaria basándose en la información que ha sido cargada en SAP por Tesorería y en las aplicaciones que efectúa la terminal. El conciliador del área de Contabilidad inicia el proceso de conciliación de los ingresos en bancos en la cuenta recaudadora de cada línea de negocio y de las cuentas por cobrar que aún permanecen “abiertas” (pendientes de pago). También se encarga de aplicar los abonos identificados compensando las cuentas por cobrar del cliente en el sistema.



3.1.3. MODELO ACTUAL DE COBRANZA EN EESS PARA VENTA A CREDITO

En este modelo se deben considerar 2 grupos de clientes:

Clientes Locales: Aquellos clientes que hacen pedidos en sus respectivas EESS Clientes Centralizados: Aquellos clientes que hacen el pedido a los representantes comerciales los

cuales gestionan estos pedidos con la Red de EESS.

El proceso se inicia con la solicitud del cliente de un despacho.

La ES efectúa el control de crédito del cliente.

Si el cliente tiene saldo entonces la ES efectúa el despacho. Si no se indica al cliente que efectúe el depósito a fin de que cubra el saldo requerido por el pedido.

El cliente puede hacer el depósito en la entidad bancaria o efectuar el mismo en la ES. En el primer caso sigue el flujo definido para el depósito. En el segundo caso, la ES registra el depósito en los sistemas ENVOY ó SICOM y aplica la cobranza correspondiente. La ES efectúa el depósito a través de un depositario (por ejemplo Hermes) en la entidad bancaria en forma conjunta con todos los pagos de ES pero identifica el pago de los clientes crédito en un grupo aparte mediante un remito. Se tienen 2 a 3 casos de estos por mes en toda la Red de EESS.

Una vez efectuado el despacho, la ES emite la factura en ENVOY (documento tipo FE) ó SICOM (documento tipo DR)

Una vez emitida la factura, esta se envía al cliente para que efectúe el pago correspondiente de acuerdo a la fecha de vencimiento del documento. Luego se envía manualmente al HO de ENVOY ó SICOM.



Esta factura es enviada manualmente (migrada al SAP) en un archivo cada 2 días.


De acuerdo a la información indicada por el cliente del pago de la deuda, la ES solicita la confirmación del depósito a Central de Cobranza.

Central de Cobranza confirma el depósito y con esta confirmación la ES aplica el depósito a la factura generada en ENVOY ó SICOM.

o Hay casos en los cuales Las EESS no centralizadas para los clientes con venta al crédito pueden efectuar la aplicación del pago sin consultar a la Central de Cobranza. Se tienen 40 a 50 casos mensuales (4 a 5 por terminal en 10 terminales por mes).

La aplicación del depósito migra al SAP en un archivo al final del día.




Contabilidad efectúa la conciliación bancaria basándose en la información que ha sido cargada en SAP por Tesorería y en las aplicaciones que efectúa la ES. El conciliador del área de Contabilidad inicia el proceso de conciliación de los ingresos en bancos en la cuenta recaudadora de cada línea de negocio y de las cuentas por cobrar que aún permanecen “abiertas” (pendientes de pago). También se encarga de aplicar los abonos identificados compensando las cuentas por cobrar del cliente en el sistema.



El proceso se inicia con la solicitud del cliente de un despacho al representante comercial y este gestiona el pedido con la Red de EESS.

La Red de EESS efectúa el control de crédito del cliente.


El cliente puede hacer el depósito en la entidad bancaria siguiendo el flujo definido para el depósito.

Una vez efectuado el despacho, la ES emite la factura en ENVOY (documento tipo FE) ó SICOM (documento tipo DR)

Una vez emitida la factura, esta se envía al cliente por el representante comercial para que el cliente efectúe el pago correspondiente de acuerdo a la fecha de vencimiento del documento. Luego se envía manualmente al HO de ENVOY ó SICOM.



De acuerdo a la información del cliente indicada a través de su representante comercial acerca del pago de la deuda, la Red de EESS solicita la confirmación del depósito a Central de Cobranza.

Central de Cobranza confirma el depósito y con esta confirmación la ES aplica el depósito a la factura generada en ENVOY ó SICOM.



o Hay casos (línea en rojo en el proceso) en los cuales en Central de Cobranza se hace la aplicación del pago en el Head Office de ENVOY (H.O.) sin embargo esta se debe hacer en el Back Office (B.O.)

o Hay casos en los cuales Las EESS no centralizadas para los clientes con venta al crédito pueden efectuar la aplicación del pago sin consultar a la Central de Cobranza. Se tienen 40 a 50 casos mensuales (4 a 5 por terminal en 10 terminales por mes).

La aplicación del depósito migra al SAP en un archivo al final del día.







3.1.4. MODELO ACTUAL DE COBRANZA EN EESS PARA VENTA ADELANTADA

En este modelo al igual que el anterior se deben considerar 2 grupos de clientes:



El proceso se inicia con la información de que el cliente ha efectuado un pago por venta adelantada.

El cliente puede hacer el depósito en la entidad bancaria o efectuar el mismo en la ES. En el primer caso sigue el flujo definido para el depósito. En el segundo caso, la ES registra el depósito en los sistemas ENVOY ó SICOM y aplica la cobranza correspondiente. La ES efectúa el depósito a través de un depositario (por ejemplo Hermes) en la entidad bancaria en forma conjunta con todos los pagos de ES pero identifica el pago de los clientes crédito en un grupo aparte mediante un remito. Se tienen 2 a 3 casos de estos por mes en toda la Red de EESS.

En el caso del depósito bancario, la ES recibe el voucher del cliente con el depósito y solicita la confirmación del depósito a Central de Cobranza.

Central de Cobranza confirma el depósito y con esta confirmación la ES genera la factura en ENVOY (documento tipo FE) ó SICOM (documento tipo DR). Solo para los 3 distribuidores: Redcol, Petrothor, C&M Servicentros) aplican percepciones (el cliente hace 2 depósitos)

La terminal aplica el depósito a la factura generada en ENVOY ó SICOM. Luego se envía manualmente al HO de ENVOY ó SICOM.

La terminal envía la factura ya pagada al cliente.








El proceso se inicia con la información de que el cliente ha efectuado un pago por venta adelantada. Esta acción se informa a través de su representante comercial.

El cliente hace el depósito en la entidad bancaria siguiendo el flujo definido para el depósito.

La ES a través del representante comercial recibe el voucher del cliente con el depósito y solicita la confirmación del depósito a Central de Cobranza.

Central de Cobranza confirma el depósito y con esta confirmación la ES genera la factura en ENVOY (documento tipo FE) ó SICOM (documento tipo DR). Solo para los 3 distribuidores: Redcol, Petrothor, C&M Servicentros) aplican percepciones (el cliente hace 2 depósitos)

La terminal aplica el depósito a la factura generada en ENVOY ó SICOM. Luego se envía manualmente al HO de ENVOY ó SICOM.



o Hay casos (línea en rojo en el proceso) en los cuales en Central de Cobranza se hace la aplicación del pago en el Head Office de ENVOY (H.O.) sin embargo esta se debe hacer en el Back Office (B.O.)

La terminal envía la factura ya pagada al cliente a través del representante comercial.








3.2. RELACION DE REQUERIMIENTOS POR NEGOCIO



3.3. REQUISITOS NO FUNCIONALES

Clasificación: Envío en línea de la deuda.

Detalle del Requisito:

Entidad Bancaria,La entidad efectúa la consulta de la deuda en línea.Empresa,La empresa propietaria de la deuda entrega la información de la deuda en línea.

Clasificación: Recaudación en línea de la deuda.

Detalle del Requisito:

Entidad Bancaria,La entidad efectúa la recaudación de la deuda en línea.Empresa,La empresa propietaria de la deuda recibe el pago de la deuda en línea.

3.4. INTERFAZ DE USUARIO

Para la operativa transaccional no será necesaria la implantación de interfaz nueva alguna ya que los procesos de envío y recepción de deuda serán automáticos. El control del estado de las transacciones deberá ser llevado por los sistemas actuales de la misma forma en que se controla el envío y la recepción de los archivos de recaudación de identificación total.

Para el caso de la consulta de la deuda, el saldo y los límites de crédito del cliente, la interfaz será la misma con la que operan los sistemas actuales (SAP, ENVOY y SICOM).

3.5. IDENTIFICACION DE GAPS

Los GAPs identificados en esta etapa del proyecto son:

ID GAP

ID Requisito

Descripción del gap y solución prevista Prioridad Impacto

CU04 1

No se cubre la recaudación por corresponsalía es decir la recaudación efectuada por las entidades bancarias a través del Banco de la Nación en aquellos puntos donde las diversas entidades bancarias no tienen cobertura. Estas transacciones representan un promedio de 20 transacciones diarias de RECOSAC, REMARSAC y 40 de RYCOPESA.

CU04 2

Están fuera de alcance las detracciones o pagos de impuestos efectuados en el Banco de la Nación (por servicios de rodaje, transporte y alquileres) que representan un promedio de 200 transacciones mensuales. Se deberá seguir con la operativa actual.

CU04 3

La cobranza en entidades bancarias en el extranjero quedan fuera de alcance de la propuesta. El tratamiento de estas transacciones deberá seguir la operativa actual.



CU04 4

Para el caso del Banco de Crédito todas las transacciones que representan transferencia entre cuentas (Telecrédito y carta de transferencia) quedarán fuera del alcance de la propuesta de automatización de la recaudación. Debido a esto debe identificarse este grupo de clientes a fin de que sean excluidos de la propuesta e informar a estos que el único medio de pago disponible para ellos será Telecrédito.



4. ALTERNATIVAS DE SOLUCION

Para plantear este esquema primero se presentará el resultado del relevamiento con las entidades bancarias. Luego el modelo de negocios futuro, así como los beneficios y premisas que deben ser considerados y finalmente las alternativas de solución.

4.1. RELEVAMIENTO DE OPERATIVA DE RECAUDACION CON ENTIDADES

Para la elaboración del modelo propuesto se ha efectuado el relevamiento de la información con los negocios y las entidades bancarias el cual se encuentra resumido en el siguiente cuadro:

El modelo propuesto cubre los siguientes requerimientos:

Consulta de la deuda en línea. Pagos totales. Pago de más de una factura Pagos parciales. Pagos adelantados. Transferencia de fondos.

4.2. MODELO DE NEGOCIO FUTURO

A continuación se expone el modelo del proceso de negocio futuro correspondiente a las acciones involucradas en la automatización de la recaudación bancaria. Esta propuesta representa cambios en la labor operativa por lo que las áreas involucradas en los mismos deberán estar de acuerdo con la propuesta y lo que esta implica.

Este modelo cubre lo correspondiente a la Cobranza Automática en bancos para los siguientes escenarios:

Cobranza en Terminales al Crédito. Cobranza en Terminales al Contado/Venta Adelantada. Cobranza en EESS al Crédito. Cobranza en EESS al Venta Adelantada.



4.2.1. MODELO DE COBRANZA EN TERMINALES PARA VENTA A CREDITO

El proceso se inicia con la solicitud del pedido por parte del cliente.

La terminal genera el pedido y efectúa el control de crédito del cliente.

Si el cliente tiene saldo entonces la terminal efectúa el despacho. Si no se indica al cliente que efectúe el depósito a fin de que cubra el saldo requerido por el pedido.

Una vez efectuado el despacho se emite la factura en SAP-SD y se envía al cliente para que efectúe el depósito correspondiente de acuerdo a la fecha de vencimiento de la factura.

El modelo propone que el cliente efectúe el pago en la entidad bancaria identificándose por medio de su RUC y que mediante una consulta en línea la entidad bancaria extraiga la información de la deuda del cliente que se encuentra en el sistema SAP.

Una vez consultada la deuda, el cliente procede a seleccionar la factura que requiere pagar.

El cliente efectúa el depósito correspondiente al pago y este es abonado a la cuenta recaudadora definida para tal propósito. Este tipo de cobranza permite rebajar la factura y aplicar el abono a cuenta en la cartera del cliente.

La entidad bancaria enviará conjuntamente el depósito correspondiente al pago de la factura, la factura propiamente dicha y toda la información relacionada al pago hacia el SAP.



El depósito será aplicado en SAP en forma automática y esta información servirá a la terminal para efectuar el control del límite de crédito.

Al final de la jornada Tesorería genera un reporte de recaudo o extracto bancario con toda la información de lo cobrado en el día y efectúa la carga de esta información en SAP.

La conciliación bancaria se efectúe en base a la información que ha sido cargada en SAP por Tesorería y en las aplicaciones automáticas. El conciliador del área de Contabilidad inicia el proceso de conciliación de los ingresos en bancos en la cuenta recaudadora de cada línea de negocio.



4.2.2. MODELO DE COBRANZA EN TERMINALES PARA VENTA AL CONTADO

El proceso se iniciará cuando el cliente informe que va a efectuar un depósito por una venta al contado.

Con la información de la intención de pago la terminal debe emitir una factura por venta adelantada en SAP e informar al cliente del número o identificación de la factura para que pueda efectuar el depósito correspondiente indicando el número proporcionado por la terminal.

El modelo propone que el cliente efectúe el pago en la entidad bancaria identificándose por medio de su RUC y que mediante una consulta en línea la entidad bancaria identifique la factura a ser pagada la misma que se encuentra en el sistema SAP.



El depósito será aplicado en SAP en forma automática.

La entidad bancaria entrega el voucher del depósito al cliente y con este voucher el cliente informa a la terminal del depósito efectuado.

La terminal consultará el depósito en SAP-FI, despachará el pedido y entregará la factura pagada al cliente. Si se trata de clientes contado que han efectuado abonos por adelantado en bancos, al momento de emitirles la factura se emite también el comprobante de percepción.



4.2.3. MODELO DE COBRANZA EN EESS PARA VENTA A CREDITO




El proceso se inicia con la solicitud del cliente de un despacho.



El cliente puede hacer el depósito en la entidad bancaria o efectuar el mismo en la ES. En el primer caso sigue el flujo definido para el depósito. En el segundo caso, la ES debe efectuar el depósito en la entidad bancaria.

De contar con saldo el cliente, la ES hace el despacho del pedido emite la factura en ENVOY (documento tipo FE) ó SICOM (documento tipo DR) Esta factura migrará al SAP en línea.

Una vez emitida la factura se envía al cliente para que efectúe el depósito correspondiente de acuerdo a la fecha de vencimiento.

El modelo propone que el cliente o la ES de ser el caso efectúen el pago en la entidad bancaria identificándose por medio de su RUC y que mediante una consulta en línea la entidad bancaria extraiga la información de la deuda del cliente que se encuentra en el sistema SAP.






El depósito será aplicado en SAP en forma automática. La aplicación del depósito migrará a ENVOY ó SICOM en línea y se aplicará el mismo a la factura

correspondiente en forma automática.



El proceso se inicia con la solicitud del cliente de un despacho a través de su representante comercial.



El cliente efectuará el depósito en la entidad bancaria siguiendo el flujo definido para el depósito.

Si el cliente cuenta con saldo, la ES hace el despacho del pedido emite la factura en ENVOY (documento tipo FE) ó SICOM (documento tipo DR) Esta factura migrará al SAP en línea.



Una vez emitida la factura se envía al cliente por medio de su representante comercial para que efectúe el depósito correspondiente de acuerdo a la fecha de vencimiento.

El modelo propone que el cliente efectúe el pago en la entidad bancaria identificándose por medio de su RUC y que mediante una consulta en línea la entidad bancaria extraiga la información de la deuda del cliente que se encuentra en el sistema SAP.




El depósito será aplicado en SAP en forma automática. La aplicación del depósito migrará a ENVOY ó SICOM en línea y se aplicará el mismo a la factura

correspondiente en forma automática.





4.2.4 MODELO DE COBRANZA EN EESS PARA VENTA ADELANTADA




El proceso se iniciará cuando el cliente informe que va a efectuar un depósito por una venta adelantada.

Con la información de la intención de pago la terminal debe emitir una factura por venta adelantada en ENVOY ó SICOM e informar al cliente del número o identificación de la factura para que pueda efectuar el depósito correspondiente indicando el número proporcionado por la ES. Esta factura migrará al SAP en línea.

El cliente podrá hacer el depósito en la entidad bancaria o efectuar el mismo en la ES. En el primer caso sigue el flujo definido para el depósito. En el segundo caso, la ES debe efectuar el depósito en la entidad bancaria.

El modelo propone que el cliente efectúe el pago en la entidad bancaria identificándose por medio de su RUC y que mediante una consulta en línea la entidad bancaria identifique la factura a ser pagada la misma que ya se encuentra en el sistema SAP.




La aplicación del depósito migrará a ENVOY ó SICOM en línea y se aplicará el mismo a la factura correspondiente en forma automática.



La entidad bancaria entrega el voucher del depósito al cliente y con este voucher el cliente informa a la ES del depósito efectuado.

La ES consulta el depósito en ENVOY ó SICOM, efectúa el despacho correspondiente y entrega la factura pagada al cliente. Si se trata de clientes contado que han efectuado abonos por adelantado en bancos, al momento de emitirles la factura se emite también el comprobante de percepción.



El proceso se iniciará cuando el cliente a través de su representante comercial informe que va a efectuar un depósito por una venta adelantada.

Con la información de la intención de pago la Red de EESS debe emitir una factura por venta adelantada en ENVOY ó SICOM e informar al representante comercial del número o identificación de la factura para que el cliente pueda efectuar el depósito correspondiente indicando el número proporcionado por la ES. Esta factura migrará al SAP en línea.

El cliente podrá hacer el depósito en la entidad bancaria o efectuar el mismo en la ES. En el primer caso sigue el flujo definido para el depósito. En el segundo caso, la ES debe efectuar el depósito en la entidad bancaria.

El modelo propone que el cliente efectúe el pago en la entidad bancaria identificándose por medio de su RUC y que mediante una consulta en línea la entidad bancaria identifique la factura a ser pagada la misma que ya se encuentra en el sistema SAP.






La aplicación del depósito migrará a ENVOY ó SICOM en línea y se aplicará el mismo a la factura correspondiente en forma automática.

La entidad bancaria entrega el voucher del depósito al cliente y con este voucher el cliente informa a su representante comercial para que este indique a la Red de EESS del depósito efectuado.

La Red de EESS consulta el depósito en ENVOY ó SICOM, efectúa el despacho correspondiente y entrega la factura pagada al cliente. Si se trata de clientes contado que han efectuado abonos por adelantado en bancos, al momento de emitirles la factura se emite también el comprobante de percepción.





4.3. BENEFICIOS Y PREMISAS DENTRO DEL MODELO FUTURO

4.3.1 BENEFICIOS

Los beneficios del modelo son los siguientes:

Lograr la atención inmediata del cliente ya que tanto la aplicación de la deuda, como la actualización de la misma se encontrará en línea con las actividades de pago del cliente asegurando la liberación de los pedidos con un saldo real y actualizado.

Evitar la exposición innecesaria y riesgosa de la cartera de clientes de REPSOL ya que permanece en los sistemas de la Empresa propietaria de la deuda y las entidades bancarias podrán disponer solo de la información de la deuda actualizada del cliente que efectúa la transacción de pago.

Contar con seguridad en las transacciones al eliminarse las operativas manuales de recepción del depósito y aplicación de los pagos. Esto va de la mano con las políticas de seguridad y auditoría de la información requerida por la corporación.

Facilitar el control de la recaudación ya que se contará con un solo formato de información de cara a todas las entidades bancarias.

Reducir la operativa manual de validación y aplicación de los depósitos (duplicidad de pagos, ejecución de normas contables, aplicación manual de la deuda y conciliación bancaria) Esta capacidad operativa podrá destinarse a funciones de análisis y explotación de la información generada.

Cabe indicar que estos beneficios son aplicables solo para aquellas transacciones cuya solución se encuentre dentro del alcance de la propuesta.

4.3.2 PREMISAS

Para que el modelo propuesto pueda operar de acuerdo a lo requerido, se debe cubrir las siguientes operativas. Toda aquella condición mostrada a continuación que no pueda ser cubierta por los negocios y áreas involucradas representa funcionalidad que quedará fuera del alcance de la propuesta por lo que deberá ser controlada a través de operativa manual.

1. No se contará con el número de transacción bancaria como identificador de las operaciones de recaudación. En su lugar cada transacción se identificará unívocamente mediante la fecha de pago y la factura/documento de anticipo asociados a la deuda.

2. Las notas de crédito y notas de débito deberán ser aplicadas manualmente a las facturas respectivas a fin de asegurar que cuando se consulte la deuda, solo se muestren los montos sin créditos o débitos pendientes.

3. Las normas contables que se venían ejecutando con el parámetro del número de operación deberán ser ejecutadas con un valor que corresponda a:Fecha de pago (8 dígitos - DDMMYYYY) + (número de factura/documento anticipo) (10 dígitos)

4. La operativa de la consulta y aplicación de la deuda en las Terminales, EESS y Central de Cobranza deberán considerar lo siguiente:

a. La Central de Cobranza deberá reducir la consulta de los depósitos bancarios a aquellos pagos de detracciones y recaudación por corresponsalía ya que se encuentran fuera del alcance de la propuesta. Las transacciones incluidas en la propuesta no serán consultadas a la Central de Cobranza debido a que la aplicación de los pagos será automática.

b. Las Terminales solo requerirán de efectuar las consultas de los depósitos bancarios para aquellas transacciones que se encuentran fuera de la propuesta. Las transacciones incluidas en la propuesta solo requerirán validar el saldo del cliente o pago en el SAP o ENVOY, pero no la aplicación de los depósitos porque esta operación será automática.



c. Las EESS deberán efectuar el mismo tratamiento que las Terminales. Para el caso de las transacciones generadas en ENVOY se construirá una interfaz en línea entre ENVOY y la trama de pago que viene desde la entidad bancaria.

5. A fin de automatizar en forma integral los procesos de recaudación es necesario generar el documento de deuda y luego aplicar el pago correspondiente. Esto asegura que los pagos se asocien a la deuda desde que retornan de la entidad bancaria, evitando la aplicación manual de los pagos y los consiguientes problemas que conlleva. En el caso de ventas adelantadas debe considerarse la siguiente funcionalidad:

a. ENVOY: Se deberá generar la factura por venta adelantada en el BackOffice de ENVOY antes de que el cliente efectúe el pago en el banco. Esta factura deberá tener solo un día de vigencia. En caso de que esta factura no sea pagada se deberá anular automáticamente. Esto implica crear o adecuar los procesos en línea de generación de facturas por venta adelantada y anulación de documento por venta adelantada. Para lograr esto la interfaz ENVOY HO – SAP deberá enviar las facturas por venta adelantada en línea sin esperar el cierre de la EESS. (Esto afecta la operativa de la EESS, se supone que ellos ejecutan un cierre diario para controlar saldos, correlatividad de documentos, etc. Pero esta alternativa tendríamos que revisarla con JCE).

b. SAP: Para el caso de ventas adelantadas en SAP deberá generarse una factura por venta adelantada con la misma funcionalidad: si no es pagada en el día deberá ser anulada en forma automática. (Esto debería de evaluarlo Adrian Alvarez)

4.4. ALTERNATIVAS PROPUESTAS

Esta alternativa tiene las siguientes características:



Contratación de un servicio mensual de 1200 dólares por el uso de un canal único de comunicación (BANCARED)

Ancho de banda escalable, es decir que puede crecer dependiendo de la necesidad del negocio. Altos niveles de seguridad. Certificación contra hackers. El control de la seguridad está respaldado por el servicio del canal de

comunicación de BANCARED. El nivel de servicio contratado es de soporte 7x24 / 365 días con personal especializado provisto por

el servicio. Se cuenta con un solo canal de comunicación con todas las entidades bancarias reduciendo el

lapso entre coordinaciones con cada una de estas entidades. Se tiene el respaldo de una entidad externa con altos niveles de eficiencia (99.98%) en el transporte

de la información del recaudo. El servicio de comunicación cuenta con procedimientos de contingencia como canales de

comunicación alternos en caso de caídas de red.

Esta alternativa tiene las siguientes características:

Los costos de comunicación deben ser calculados en cada conexión que se requiera contar con las entidades bancarias siendo el caso extremo de 4 conexiones (aproximadamente 2400 dólares mensuales) El no contar con una conexión a alguna de las entidades se traduce en correr el riesgo de comunicarse en una red abierta con la consiguiente amenaza de seguridad que esto implica.

El nivel de eficiencia de las comunicaciones dependerá exclusivamente de la empresa. En caso se presenten contingencias deben establecerse controles como conexiones alternas lo que se traduce en más inversión por parte de los negocios.

Respol debe proveer el control de la seguridad y asegurar que las transacciones comerciales se encuentren protegidas contra ataques externos.

En caso de requerir mayor ancho de banda se necesitará una mayor inversión.



5. CASOS DE USO DEL MODELO PROPUESTO

El alcance de la solución que soporta el modelo presentado abarca los siguientes procesos:

Configuración Configurar catálogos de bancos, tipos de transacciones, tipos de documento de pago, clientes y

usuarios.Procesos Generar documentos por cobrar (facturar deuda). Consultar la información de la transacción a ser ejecutada. Efectuar transacción y aplicar depósito. Enviar transacción de pago a ENVOY.Reportes Generar reporte de recaudación (modificado)

5.1 CASOS DE USO PARA CONFIGURACION

5.1.1. CASO DE USO 01 – CONFIGURAR CATALOGOS

Objetivo del Caso de Uso:

Efectuar la configuración de entidades bancarias, tipos de transacciones, tipos de documento de pago, clientes y usuarios.

Actores que intervienen:

Administración Comercial,El usuario de Administración Comercial, efectúa la configuración.

Resumen de la funcionalidad:

El usuario crea y actualiza, los registros de las siguientes maestras: Bancos con sus respectivas cuentas bancarias y contables por empresa. Tipos de transacciones Tipos de documentos de pago (efectivo, cheque, carta transferencia. Clientes con su respectivo número de RUC. Usuarios.

Se efectúan las siguientes funcionalidades en cada uno de estos catálogos:1. Ingresar un nuevo registro.2. Modificar los datos del banco, terminal, cliente, o usuario.3. Consultar los datos.

Requisitos no funcionales:

5.2 CASOS DE USO PARA PROCESOS

5.2.1. CASO DE USO 02 – GENERAR LOS DOCUMENTOS POR COBRAR

Este caso de uso reemplazará al que corresponde a la gestión de cobranza del modelo de negocio actual.


Generar los documentos por cobrar. Se consideran los documentosSAP tipo FR (factura), DD (Nota de débito manual), DF (Nota de débito y BV (Boleta de venta). de IP2 mandante 300 para las sociedades 0876 (RECOSAC) y 1063 (REMARSAC)

FE(ENVOY) y DR(SICOM)

Los documentos generados en ENVOY se cargarán en SAP.


Gestor Comercial (de la línea de negocio)




El gestor comercial de cada línea de negocio se encarga de generar la deuda producto de la comercialización de los productos que negocia la terminal o EESS.

Para el caso de la deuda generada por las terminales, esta es facturada en el Sistema SAP y se calculan los importes correspondientes al IGV y detracciones si hubiera. Este proceso se viene efectuando actualmente.

Para el caso de la deuda generada por las EESS esta es facturada en SICOM ENVOY. Esta debe ser enviada automáticamente al SAP con los importes correspondientes.

En caso de generar notas de crédito o débito estas también son generadas y facturadas en los sistemas correspondientes.


5.2.2. CASO DE USO 03 – CONSULTAR INFORMACION DE TRANSACCION


Ofrecer el servicio de mostrar la deuda en línea de los clientes a través de SAP.


Cliente


El cliente se acerca a la entidad bancaria a efectuar la transacción requerida utilizando su RUC

Con esta información se extraerá la información de las facturas en deuda.

De todas las entidades solo una (Banco de Crédito) no soporta la consulta de más de una factura en deuda con la misma fecha de vencimiento, por lo que con el fin de que no existan restricciones por este tipo de consultas la información de la fecha de vencimiento para esta entidad no será enviada como parte del campo de validación si no como parte de un campo descriptivo en la trama de respuesta y en el campo de fecha de vencimiento se enviará un dato correlativo que permita diferenciar las facturas.

Se mostrarán 6 facturas con más antigüedad de deuda del cliente como respuesta a la consulta de la deuda.

En caso de contar con más deuda esta será enviada posteriormente una vez pagadas las facturas más antiguas.

Las facturas deberán tener como premisa que el usuario deberá haber aplicado la nota de crédito correspondiente o afectado con la nota de débito respectiva en caso existan a fin de asegurar la consulta de la deuda real sin créditos o débitos pendientes.


La deuda deberá estar disponible en el sistema SAP

5.2.3. CASO DE USO 04 – EFECTUAR TRANSACCION Y APLICAR DEPOSITO


Registrar la transacción de pago en línea sobre SAP en los sistemas de los diversos canales de cobranza REPSOL.

Actores que Cliente



intervienen:


El cliente procederá a efectuar el pago respectivo dependiendo de la transacción requerida:

Pago total de deuda:

Se selecciona la factura a ser pagada del total de facturas que se muestran en la consulta de la sucursal del banco.

Se procede con el depósito respectivo por el monto total de la deuda seleccionada incluyendo el IGV.

La entidad bancaria en forma automática envía el pago en línea con la factura aplicada hacia REPSOL

Se aplica la factura correspondiente en forma automática en SAP.

Pago parcial de deuda:

Se selecciona la factura a ser pagada depositando el monto parcial.

En caso la entidad bancaria requiera enviará a REPSOL la solicitud de autorización de pago parcial (*).

La entidad en forma automática envía el pago en línea con la factura aplicada hacia REPSOL e inmediatamente se aplica en SAP a la factura correspondiente.

El proceso interno del SAP deberá recalcular la nueva deuda a fin de que aparezca en una nueva consulta.

Pago adelantado:

Se debe considerar que esta funcionalidad puede ser cubierta de forma tal que asegure no solo la automatización completa sino también la solución de la problemática de aplicación y conciliación de pagos no aplicados.

Hay 2 alternativas:

1. Pago adelantado no aplicado (sin documento de deuda identificado): Esta alternativa es la menos compleja pero no cubre la automatización en forma integral ya que si bien el depósito viaja en línea hacia los sistemas de REPSOL este luego tiene que ser asociado y a su documento correspondiente en forma manual conllevando los problemas de identificación de los documentos de deuda. Los pasos son los siguientes:

La entidad bancaria utiliza la opción de identificación parcial de la deuda para las entidades BCP y Continental. Scotiabank e Interbank si cuentan con este servicio dentro de la opción de pago en línea.

Se indica el cliente que efectuará el pago adelantado.

Se efectúa el depósito requerido.

El depósito viaja en línea hacia SAP.

Debido a que no existe un documento identificado, cuando este se genere va a requerir una asociación manual al depósito efectuado.

2. Pago adelantado aplicado (con documento de deuda identificado): Esta alternativa provee una solución de automatización integral pero requiere efectuar cambios en la operativa y la creación de nuevos procesos entre los sistemas SAP y ENVOY (el detalle de esta alternativa se encuentra en el punto 5) Los pasos son los siguientes:



Se selecciona la factura de venta adelantada a ser pagada del total de facturas que se muestran en la consulta de la sucursal del banco.

Se procede con el depósito respectivo por el monto total de la factura seleccionada incluyendo el IGV.

La entidad bancaria en forma automática envía el pago en línea con la factura aplicada hacia REPSOL


Pago con Carta de Transferencia:

Se debe uniformizar el formato utilizado en las cartas de transferencia de fondos a fin de que en estos figure la deuda a ser pagada. Los pasos son los siguientes:

El Cliente genera un documento con el formato de la carta de transferencia el cual envía a la entidad bancaria. En este figurarán las facturas a ser pagadas y el RUC del cliente.

La entidad bancaria aplica las transacciones de pago según lo indicado en la carta transferencia. Y estas se envían en forma automática envía el pago en línea con la factura aplicada hacia REPSOL


Tratamiento Especial con el Banco de Crédito

Para el caso del Banco de Crédito todas las transacciones que representan transferencia entre cuentas (Telecrédito y carta de transferencia) tiene la particularidad de que los movimientos generados no viajan por el canal de servicio de recaudación transaccional por lo que los clientes que efectúen el pago por estos medios de pago quedarán fuera del alcance de la propuesta de automatización de la recaudación. Debido a esto debe identificarse este grupo de clientes a fin de que sean excluidos de la propuesta e indicarles que el único medio de pago disponible para ellos será Telecrédito.


Es necesario que exista un control de transacciones que debe ser administrado desde el SAP.

(*) La respuesta de la autorización de pago parcial siempre será afirmativa.ya que no existe un proceso de gestión

5.2.4. CASO DE USO 05 – ENVIAR TRANSACCION DE PAGO A ENVOY


Ofrecer el servicio de transportar la transacción de pago desde SAP hacia ENVOY.


Sistema SAP


Para el caso de los pagos de deuda total y parcial, una vez que se aplican los documentos en SAP serán identificados automáticamente por el tipo de documento para determinar aquellos que han sido migrados desde ENVOY.

Los pagos efectuados sobre los documentos y pagos aplicados de deuda total y parcial de aquellos clientes que provienen de ENVOY



serán trasladados en línea desde SAP con el documento asociado a fin de asegurar la aplicación automática en ENVOY.

ENVOY recibirá y aplicará el pago a la factura correspondiente.

En caso de ser un pago adelantado, el tratamiento dependerá de la alternativa seleccionada en el Caso de Uso 04.

1. Si se opta por la generación de un pago adelantado no aplicado se requerirá efectuar el proceso manual de aplicación dentro del ENVOY y también dentro del SAP ya que la deuda se encontrará pendiente en ambos sistemas.

2. En caso de decidir la alternativa de pago adelantado aplicado el tratamiento será el mismo que se utiliza en el pago total.


5.3 CASOS DE USO PARA REPORTES

5.3.1. CASO DE USO 07 – REPORTE DE RECAUDACION


Mostrar la relación de pagos


Terminal,El usuario, solicita la generación del reporte de recaudación.


El usuario selecciona los siguientes criteros de consulta:

Entidad bancaria. Sucursal Rango de fechas de depósito. Rango de montos de depósito. Rango de números de operación. RUC del cliente. Moneda. Tipo de operación.

Se genera un reporte de acuerdo a criterios ingresados ordenado por entidad bancaria, sucursal, fecha de depósito y monto.

Este reporte se utilizará como sustento de los depósitos y del estado de los mismos el cual puede ser generado a solicitud del usuario.


Se mostrará una pantalla con los filtros indicados a fin de que se puedan mostrar los pagos requeridos

En el reporte se mostrarán los siguientes campos:

Factura. Fecha de vencimiento. Fecha de pago. Entidad Bancaria Cuenta Bancaria de depósito. Cuenta Contable de depósito.



Nº Sucursal Referencia Número de operación bancaria. Tipo de operación Importe. Moneda. Número de documento de pago. RUC del cliente Razón social del cliente

6 RECOMENDACIONES

A fin de que tanto el modelo presentado como las alternativas expuestas cumplan con los requerimientos de las áreas y negocios involucrados en el alcance de la solución, debe asegurarse lo siguiente:

Que no existan variantes o caminos alternos a las operativas sugeridas como por ejemplo la aplicación de pagos directamente en el SAP o ENVOY sin haber efectuado la consulta a la Central de Cobranza.

Adecuar la operativa a lo propuesto en las premisas como por ejemplo la aplicación obligatoria de las notas de crédito y débito una vez identificada la factura a la cual pertenecen.

Conservar la operativa actual solo para aquellos casos que se encuentren fuera del alcance de la solución propuesta.

El proceso de aplicación de depósitos para todos los clientes que efectúen el pago directamente en las Terminales debe respetar la operativa que se sigue si el cliente efectúa el pago.

La operativa de venta adelantada (ES) o pago al contado (terminal) debe ser adecuado a fin de que la entidad bancaria cuente con la información del monto en los sistemas de la empresa antes de efectuar la transacción de pago (adecuarse al proceso del modelo futuro)

Para los clientes de ES Los pagos deben efectuarse exclusivamente en el Back Office de ENVOY. El Head Office no debe ser utilizado para aplicar los depósitos.

Es recomendable bloquear la aplicación por pantalla de las facturas por venta adelantada y venta al crédito en los sistemas ENVOY y SICOM ya que todos los pagos según la propuesta viajarán directamente desde SAP.

7 CONCLUSIONES

El modelo presentado cubre la automatización de los procesos de recaudación a través de las entidades bancarias pasando por los sistemas utilizados por las empresas propietarias de la deuda. Este soporta la funcionalidad de recaudación solicitada por los negocios que participan en la actividad comercial.La siguiente propuesta cubre:

100% de la operativa de recaudación de REMARSAC:o 89% Cobranza con depósitos bancarios.o 11% Cobranza con carta transferencia.

79% de la operativa de RECOSAC:o 25%Cobranza con depósitos bancarios.o 54% Cobranza al contado/venta adelantada.

8 GLOSARIO DE TERMINOS

Pago Adelantado: Es el pago anticipado de una venta.



Pago Parcial: Es el pago de parte de la factura.

Venta Adelantada: Es la venta de productos o servicios a aquellos clientes que han efectuado depósitos

anticipados o pagos adelantados.

Central de Cobranza: Es el área donde se da la conformidad de los depósitos y que tiene acceso de

consulta a todas las transacciones bancarias relacionadas con las cuentas de los Negocios.



9 ANEXOS

9.1 MATRIZ DE RELEVAMIENTO CON LOS NEGOCIOS



9.2 MATRIZ DE RELEVAMIENTO CON ENTIDADES BANCARIAS

5.3.1. INTERBANK



5.3.2. SCOTIABANK



5.3.3. BCP



5.3.4. CONTINENTAL BBVA



informe de análisis funcional - automatización de recaudación bancaria

Documents