accounts receivable and financial activities backend

CNT - Back End de AR (Cuentas por Cobrar) y Actividades Financieras

High-Level Design (HLD)

BSS – Accounts Receivable

© 2012 Amdocs

Este documento contiene información propietaria y confidencial de Amdocs y no debe ser reproducida ni transferida a otros documentos, divulgada a terceros, o utilizada para cualquier otro propósito distinto para el cual fue indicado, sin el consentimiento previo escrito de Amdocs. Debe ser devuelto a las empresas Amdocs correspondientes, a solicitud.

La marca registrada y las marcas de servicio de Amdocs, incluyendo la marca y el logotipo de Amdocs, son propiedad exclusiva de Amdocs y no pueden utilizarse sin permiso alguno. Todas las otras marcas mencionadas en este material son propiedad de sus respectivos dueños.

Información del documento

Versión del Software: 1.0

Fecha de Publicación: Julio de 2012

Número de Catálogo: document_center\1629934 Version0.9

Nivel de Seguridad: Nivel 1 - Confidencial

Fecha de Creación: 23 de julio de 2012

Cuenta/FOP: CNT BSS delivery

Autor: Shany Vizel

Editor: Shany Vizel

Fecha de Última Edición:

31 agosto 2012

Nombre del Archivo: CNT - FS - Accounts Receivable and Financial Activities Backend - HLD

Plantilla: Universal1Side.dot

Contenido

1. Introducción.............................................................................................1

1.1. Propósito y Alcance....................................................................................1

1.2. Documentación Relacionada.....................................................................1

1.3. Términos y Definiciones.............................................................................1

2. Cuentas por Cobrar - Aspectos Generales del Producto....................6

2.1. Módulos Principales de Cuentas por Cobrar Principales...........................6

2.1.1. Funcionalidad de Terminación del Ciclo.......................................................6

2.1.2. Administración de Pagos..............................................................................7

2.1.3. Administración de Cuentas...........................................................................7

2.1.4. Configurador de Cuentas por Cobrar...........................................................8

2.2. Interacción con Otros Componentes..........................................................8

2.2.1. Facturación Amdocs.....................................................................................8

2.2.2. Administrador de Clientes de facturación (Billing)de Amdocs.....................9

2.2.3. AmDD – Diseñador de Documentos Amdocs...............................................9

2.3. Alineación del Proceso de Negocios..........................................................9

2.3.1. Llega el dia de la facturación – Productos Postpagados (BDA)...................9

2.3.2. Cliente Paga – Productos Postpagados (CP).............................................10

2.3.3. Cliente Tiene una Pregunta – Productos Postpagados (CHQ)..................10

2.4. Supuestos................................................................................................10

3. Funcionalidad ‘Llega el Día del Bill’....................................................12

3.1. Requerimientos Relacionados.................................................................12

3.2. Supuestos................................................................................................12

3.3. Proceso de Preparación del Bill...............................................................13

3.3.1. Nombre del ‘Batch’ del Proceso.................................................................13

3.3.2. Descripción del ‘Batch’...............................................................................13

3.3.3. Tipo del Proceso.........................................................................................13

3.3.4. Frecuencia de la Ejecución (Run)...............................................................13

3.3.5. Inputs..........................................................................................................14

3.3.6. Outputs.......................................................................................................14

Nivel de Seguridad de la Información 1 - Confidencial

Información Propietaria y Confidencial de Amdocs

–

Contenido

3.3.7. Flujo por ‘Batches’......................................................................................14

3.4. Cálculo de la Tarifa por Pago Tardío.......................................................15

3.4.1. Descripción.................................................................................................15

3.4.2. Elegibilidad del Grupo de Cargos para el Cálculo del LPF.........................16

3.4.3. Fechas del Cálculo del LPF........................................................................17

3.4.4. Periodo de Gracia del LPF.........................................................................17

3.4.5. Días de Seguridad del LPF........................................................................18

3.4.6. Monto Mínimo de la Tarifa por Pago Tardío...............................................19

3.4.7. Lógica de Tarifa por Pago Tardío...............................................................19

3.5. Proceso de Recepción de la Factura.......................................................20



3.5.3. Entidad de la Factura.................................................................................22

3.5.4. Tipo de Proceso.........................................................................................23


3.5.6. Inputs..........................................................................................................23

3.5.7. Outputs.......................................................................................................23


3.6. Asuntos Abiertos – N/A............................................................................24

4. Administración de Pagos.....................................................................25


4.2. Supuestos................................................................................................26

4.3. Proceso de Recepción del Pago..............................................................27



4.3.3. Tipo del Proceso.........................................................................................28


4.3.5. Inputs..........................................................................................................28

4.3.6. Outputs.......................................................................................................28


4.4. Proceso de Posteo del Pago....................................................................28



–

Contenido



4.4.3. Cuenta de Control de Excepciones............................................................29

4.4.4. Tipo del Proceso.........................................................................................30


4.4.6. Inputs..........................................................................................................30

4.4.7. Outputs.......................................................................................................30


4.5. Crear Proceso de Pago............................................................................32

4.5.1. Flujo............................................................................................................32

4.6. Transferencia de Fondos.........................................................................33

4.6.1. Flujo............................................................................................................33

4.7. Anulación (Backout) del Pago..................................................................34

4.7.1. Flujo............................................................................................................34

4.7.2. Descripción de la Solución.........................................................................35


5. Administración de Débito Directo.......................................................37


5.2. Supuestos................................................................................................37

5.3. Proceso de Creación de la Solicitud de Débito Directo...........................39



5.3.3. Tipo del Proceso.........................................................................................39


5.3.5. Inputs..........................................................................................................39

5.3.6. Outputs.......................................................................................................39


5.4. Proceso de Extracción del Débito Directo................................................40



5.4.3. Tipo del Proceso.........................................................................................40



–

Contenido


5.4.5. Inputs..........................................................................................................40

5.4.6. Outputs.......................................................................................................40


5.4.8. Cálculo del Monto de la Solicitud de Débito Directo...................................41

5.5. Proceso de Retroalimentación del Débito Directo...................................41



5.5.3. Tipo del Proceso.........................................................................................42


5.5.5. Inputs..........................................................................................................42

5.5.6. Outputs.......................................................................................................42


5.6. Interfaces..................................................................................................44

5.6.1. Integración con CM....................................................................................44

5.6.2. Integración con Cobranzas.........................................................................44

5.6.3. Interfaz Externa..........................................................................................44


6. Aplicación del Efectivo.........................................................................45


6.2. Supuestos................................................................................................45

6.3. Saldo Anterior (Suma y sigue).................................................................46


7. Administración de Cuentas..................................................................48


7.2. Supuestos – N/A......................................................................................49

7.3. Crédito......................................................................................................50

7.3.1. Ciclo de Vida del Crédito............................................................................51

7.3.2. Crédito a Nivel de Cuenta..........................................................................51

7.3.3. Cargos y Créditos a Nivel de Factura.........................................................53



–

Contenido

7.3.4. Reversión del Crédito.................................................................................55

7.3.5. Nota de Crédito..........................................................................................56

7.3.6. Flujo de Creación de la Nota de Crédito.....................................................57

7.3.7. Información de la Nota de Crédito enviada al Diseñador de Documentos Amdocs..............................................................................................57

7.3.8. Secuencia de ID de la Nota de Crédito......................................................58

7.3.9. Número de Autorización de SRI de la CN..................................................58

7.3.10. Formato del ID de la Nota de Crédito.......................................................59

7.3.11. searchCreditNotes....................................................................................59

7.4. Reembolso...............................................................................................59

7.4.1. Reembolso del Pago..................................................................................60

7.4.2. Reversión del Reembolso del Pago...........................................................61

7.4.3. Reembolso de Sobrepagos........................................................................62

7.4.4. Reversión del Reembolso del Sobrepago..................................................63

7.4.5. Interfaces Externas.....................................................................................63

7.5. Disputa.....................................................................................................64

7.5.1. Creación de una Disputa............................................................................64

7.5.2. Justificación de una Disputa.......................................................................65

7.5.3. Rechazo de una Disputa............................................................................65

7.6. Amortización (no se utiliza en CNT).........................................................65

7.6.1. Creación de la Amortización.......................................................................66

7.6.2. Reversión de la Amortización.....................................................................67

7.6.3. Ejemplo de Amortización y Reversión de la Amortización..........................68


8. Estados Financieros.............................................................................70

8.1. Requerimientos Relacionados – N/A.......................................................70

8.2. Supuestos – N/A......................................................................................70

8.3. Visualización de los Estados Financieros................................................70




–

Contenido

9. Cargo y Pago Inmediatos.....................................................................72


9.2. Supuestos – N/A......................................................................................72

9.3. API l3createImmediateChargePayment...................................................72

9.3.1. Input...........................................................................................................73

9.3.2. Output.........................................................................................................73

9.3.3. Creación de Cargos....................................................................................73

9.3.4. Creación de Pagos.....................................................................................73

9.3.5. Creación de Notas de Débito......................................................................74

9.3.6. Desestimación del Cálculo de LPF para Facturas......................................74

9.3.7. Cargos derivados de Intereses...................................................................76

9.3.8. TimeStamp.................................................................................................76

9.4. Asuntos Abiertos – N/A...........................................................................76

10. Nota de Débito.......................................................................................77

10.1. Requerimientos Relacionados.............................................................77

10.2. Supuestos............................................................................................77

10.3. Creación de la Nota de Débito.............................................................77

10.3.1. Información de la Nota de Débito enviada al Diseñador de Documentos Amdocs..............................................................................................78

10.3.2. Secuencia de la Nota de Débito...............................................................79

10.3.3. Número de Autorización de SRI de la DN................................................79

10.3.4. Formato del ID de la Nota de Débito........................................................79

10.3.5. APIs searchInvoicesByAccountId y searchInvoices.................................79

10.4. Asuntos Abiertos..................................................................................80

11. Obtención de Montos por Cargos Especiales....................................81


11.2. Supuestos............................................................................................84

11.3. Obtención de Montos por Cargos Especiales......................................85

11.3.1. Input.........................................................................................................85

11.3.2. Output.......................................................................................................86



–

Contenido

11.3.3. Creación del Flujo de Pago Inmediato......................................................86

11.3.4. Creación del Flujo del Arreglo de Pago....................................................88

11.3.5. Impuestos sobre Tarifas...........................................................................89

11.3.6. Lógica del Cálculo de LPF Inmediato.......................................................89

11.3.7. Lógica del Cálculo de Cobro de Ley.........................................................89

11.3.8. Cálculo del Monto del Primer Abono........................................................90

11.3.9. Lógica del Cálculo de Intereses del Abono..............................................91

11.3.10. Ejemplo de Arreglo de Pago...................................................................93

11.3.11. Cancelación del Pago y PA....................................................................94

11.4. Asuntos Abiertos..................................................................................94

12. Descuento sobre Pagos Adelantados.................................................96


12.2. Supuestos............................................................................................96

12.3. Descuento sobre Pagos Adelantados..................................................96

12.4. Criterios de Pagos Adelantados...........................................................97

12.5. Asuntos Abiertos – N/A........................................................................98

13. Libros de Diario y Libro Mayor............................................................99


13.2. Supuestos – N/A...............................................................................100

13.3. Solución..............................................................................................100

13.4. Extracto del Diario..............................................................................101

13.5. Análisis del Diario...............................................................................102

13.5.1. Estructura de la Transacción del Diario..................................................102

13.5.2. Ejemplos.................................................................................................103

13.6. Acumulación en el Diario Mayor.........................................................104

13.6.1. Acumulación...........................................................................................105

13.6.2. Mapeo....................................................................................................105

13.6.3. Actualización de la Base de Datos.........................................................105

13.6.4. Definición de Criterios en el Configurador..............................................105

13.7. Extracto del Libro Mayor....................................................................106



–

Contenido

13.7.1. Descripción de la Solución.....................................................................106

13.8. LM de Cargos No Facturados............................................................106

13.8.1. Diagrama de Flujo..................................................................................106


13.9. LM para Bills no devengados.............................................................108


13.10. Emisión de Informes del LM por Provincia y Localidad......................109

13.10.1. Emisión de Informes de Actividades de Pagos.....................................109

13.10.2. Emisión de Informes de otras Actividades............................................109

13.10.3. Archivo del Extracto del LM de ARs.....................................................109

13.11. Asuntos Abiertos................................................................................109

14. Impacto de la Implementación...........................................................110

14.1. Nota de Crédito..................................................................................110

14.2. Nota de Débito...................................................................................110

14.3. Tarifas................................................................................................110

14.4. Débito Directo.....................................................................................111

14.5. Cancelar Arreglo de Pago..................................................................111

14.6. Descuento sobre Pagos Adelantados................................................111

14.7. Aplicación del Efectivo.......................................................................111

14.8. Emisor del Pago.................................................................................111

15. Aspectos no Funcionales...................................................................112

15.1. Requerimientos Relacionados - N/A..................................................112

15.2. Hardware/software de Terceros.........................................................112

15.3. Estrategia de la Prueba......................................................................112

15.4. Seguridad...........................................................................................112

15.5. Alcance y Estrategia de la Migración.................................................112

15.6. Desempeño – N/A..............................................................................112



1. INTRODUCCIÓN

1.1. Propósito y Alcance

Este documento define y describe el diseño de alto nivel (HLD) de la funcionalidad Cuentas por Cobrar para la solución de Cuentas por Cobrar de CNT.

El documento describe la funcionalidad de cada una de las aplicaciones siguientes involucradas en la solución:

■ Administración de Pagos

■ Administración de Cuentas

El documento también describe la funcionalidad mejorada, de acuerdo con los requerimientos de CNT.

1.2. Documentación Relacionada

Los documentos siguientes ayudarán al lector a obtener mayor comprensión del asunto central de este documento:

Número de Catálogo Documento

1661678 CNT - AR - Finance Institute - IDD

1661697 CNT - AR - Journal - IDD

1662090 CNT - CL - Collections Interfaces - IDD

1629957 CNT - FS - Collection Backend - HLD

1702328 CNT - FS - Invoicing - HLD

1699442 CNT - FS - facturación (Billing)Customer Management (BCM) - HLD

1630032 CNT – Amdocs Document Designer HLD

1625380 AB 8.1 – AR 8.1 SP1 – API Reference Guide

1.3. Términos y Definiciones

La siguiente es una lista de términos utilizados en este documento con los cuales debe familiarizarse el lector:



CNT - Accounts Receivable and Financial Activities Back End High-Level Design(HLD)

Capítulo ¡Error! Utilice la ficha Inicio para aplicar Heading 1 al texto que desea que aparezca aquí.. ¡Error! Utilice la ficha Inicio para aplicar Heading 1 al texto que desea que

aparezca aquí.

Término Definición

A&C (Auditoría y Control)

Módulo de la Infraestructura Amdocs que administra la transferencia de archivos entre las Aplicaciones de Amdocs. Cada aplicación que espera un archivo de input proveniente de otra aplicación entra en contacto con Auditoría y Control para determinar la viabilidad del archivo. La aplicación que envía un archivo de output a otra aplicación, llama a Auditoría y Control cuando el archivo está listo y le solicita la entrega del archivo.

Cuentas por Pagar Una aplicación externa que tramita los pagos que se emiten a los proveedores, socios y clientes. AR (Cuentas por Cobrar) contacta a Cuentas por Pagar cuando se requiere enviar un reembolso al cliente.

Ajustes Actividad financiera interna que se lleva a cabo en una cuenta como corrección técnica al saldo de la cuenta. La finalidad de un ajuste puede ser la actualización de la tasa de conversión de divisas, la cual puede haber variado ligeramente de una fecha a otra, compensar una comisión bancaria o cerrar la brecha de saldos cuando es inferior a la tolerancia definida.

Balance de Comprobación de la Antigüedad

Un informe generado por AR (Cuentas por Cobrar); el informe clasifica las deudas abiertas por rangos, de acuerdo con la antigüedad de cada deuda, a partir de su fecha de vencimiento: Rango (Buckets) de deudas de 0 – 30 días, Rango (Buckets) de 31 – 60 días, Rango (Buckets) de deudas de 61- 90 días, y así sucesivamente.

Administrador de Clientes de Facturación de Amdocs (Amdocs facturación (Billing)Customer Manager)

Componente de la Plataforma de Facturación Amdocs; contiene la información relativa a los clientes de la compañía, tales como los detalles, historial y jerarquía. Todos los atributos relacionados con el cliente son recibidos desde este módulo cuando son requeridos.

Diseñador de Documentos Amdocs (AmDD)

Módulo de Amdocs para la creación de facturas, cartas, estados o facturas destinadas a ser distribuidas vía Web, en papel o por medios electrónicos.

ARO AR en Línea – una UI basada en la web para el mantenimiento de las actividades financieras del módulo de AR (Cuentas por Cobrar).





aparezca aquí.


Saldo Anterior (Suma y sigue)

Método de Aplicación del Efectivo para los clientes que reciben el estado the cuenta (bill) ; el cliente paga todas las deudas pendientes de la cuenta. AR (Cuentas por Cobrar) asigna el dinero en efectivo a todas las facturas abiertas dentro de la cuenta, mediante las reglas de prioridad de acuerdo con la tabla (normalmente, el más antiguo de primero).

Política de Saldos Un atributo definido a nivel de cuenta financiera, después de su creación. La política define el cómo se asignan los elementos de crédito (es decir, Pago, créditos) a los ítems de deuda abiertos de la Cuenta Financiera (es decir, cargos, factura). OOB: existen dos políticas de saldos disponibles: Saldo Anterior (Suma y sigue) e Ítem Abierto.

Receptor del Estado de Cuenta (Bill)

Un cliente recibe un estado de cuenta mensual que incluye el saldo del ciclo anterior, nuevos cargos y créditos, actividades financieras realizadas desde el último mes y la cantidad total adeudada.

Acuerdo de facturación (Billing)(BA)

La entidad de la estructura de cliente que recibe una factura o Estado de cuenta (bill). Una cuenta puede tener varios BA (acuerdos de factura). Los BA (Acuerdos de factura) se utilizan para establecer la interfaz entre el Amdocs facturación (Billing)Customer Manager y Amdocs Invoicing.

Aplicación del Efectivo

Un módulo dentro de AR (Cuentas por Cobrar) que incorpora los pagos y créditos del cliente a los cargos. Cada vez que recibe un pago o crédito, lo vincula a los grupos de cargos más adecuados. Para encontrar los grupos de cargos, utiliza un algoritmo basado en la prioridad predefinida.

Acumulador de Cargos Una utilidad a la cual llama el Proceso Recepción de Factura con el fin de crear los grupos de cargos derivados de los cargos al cliente. Recepción de Factura utiliza los grupos de cargos para estructurar las facturas.





aparezca aquí.


Grupos de Cargos (CG)

Definición lógica que permite a AR (Cuentas por Cobrar) combinar cargos similares y procesarlos simultáneamente. Un grupo de cargos es una unidad de resumen de débitos que sirve como meta de la Aplicación del Efectivo: por ejemplo, un grupo de cargos por un servicio o cargos derivados de un cheque no honrado. El grupo de cargos se mantiene para ayudar a la Aplicación del Efectivo en la aplicación de pagos y créditos generales con el fin de cubrir deudas abiertas. Cada grupo de cargos tiene una prioridad y un saldo adjunto al mismo, de modo que la Aplicación del Efectivo puede ahorrar tiempo cuando se trabaja en grupos de cargos en vez de cada cargo por separado.

Cada Charge_Code que se define en el catálogo de productos está asignado a un Charge_Group_Type. Cuando un grupo de cargos se crean en AR y todos los cargos tienen la misma fecha de vencimiento y mismo Charge_Group_Type, todos estos cargos serán agrupados en una entidad Charge_Group.

El Saldo de la deuda de la cuenta, edad de la deuda y Aplicación del Efectivo se realizan contra esta entidad de Grupo de Cargos.

CN Nota de Crédito – documento legal que es emitido para presentar un crédito inmediatamente creado para la FA.

Proveedor del Servicio de Comunicación

Operador o Compañía Telefónica que suministra un vasto rango de servicios a los usuarios.

Tarjeta de Crédito (CC)

Método de Pago Recurrente – Tarjeta de Crédito

Enlace Crédito Débito Una entidad de AR (Cuentas por Cobrar) que mantiene la conexión entre los grupos de cargos y los de pagos.

Créditos Suma de dinero que es otorgada a una cuenta, ya sea de forma automática vía el sistema de Facturación ( facturación (Billing)) o bien a través de un representante de servicio al cliente, después del reclamo del cliente. Puede adjuntarse a un cargo específico, a una factura o a la cuenta. El crédito del cliente puede también ser una corrección técnica al saldo de la cuenta; por ejemplo, el cerrar una diferencia de un saldo que es menor a la tolerancia definida.





aparezca aquí.


Representante de Servicio al Cliente (CSR)

Una persona que responde a todas las llamadas del cliente y le brinda información y ayuda. El CSR es el usuario final del sistema (usuario en el front-end )

DCK Cheque no Honrado/ Pago Rechazado

Nota de Débito (DN) Documento legal que es generado para presentar un débito (cargo o lista de cargos) creado inmediatamente para el FA.

Débito Directo (DD) Método de pago mediante el cual el cliente permite que el banco o compañía de tarjeta de crédito pague directamente desde su cuenta, la cuenta telefónica (o cualquier otro estado de cuenta ( bill) mensual. El Proveedor del Servicio de Comunicación envía la solicitud de pago directamente al banco.

Tipo de Documento Atributo definido a nivel de BA (Acuerdo de Billing) al ser creado; el atributo define si el saldo del ciclo toma en consideración el saldo facturado previo (Receptor del estado de cuenta (Bill) o si solo el saldo actual de la Factura (Receptor de la Factura).

Enterprise JavaBeans (EJBs)

Arquitectura del componente del lado del servidor para escribir la lógica de negocios reutilizable y las aplicaciones portables empresariales. Los componentes del Enterprise JavaBean se escriben en Java y corren en cualquier servidor compatible con EJB. Los servidores de Enterprise JavaBean proporcionan servicios a nivel de sistema, tales como transacciones, seguridad, hilos y persistencia.

Cuenta de Control de Excepciones (ECA)

Una cuenta especial en la base de datos de AR (Cuentas por Cobrar) para pagos con cuentas de destino no identificables. Se requiere actividad manual para identificar la cuenta adecuada y trasladar el pago a ésta.

Punto de Salida Una definición lógica de personalización; es un punto de plug-in en el software, donde durante la personalización, se puede agregar una función. Esta función agrega funcionalidad al código existente sin tocar el software principal.

Cuenta Financiera

(FA)

La entidad responsable principal de las deudas y créditos; puede ser un usuario de teléfono privado, un jefe de familia responsable de muchos usuarios, o una corporación empresarial con muchas divisiones.





aparezca aquí.


Transacción Financiera Actividad en la cuenta del cliente que afecta el saldo de la cuenta; número de transacciones financieras, tales como cargos y crédito, que es generado por Facturación Amdocs; otras actividades son realizadas por el cliente, como pagos, retiros y Transferencia de Fondos.

FR Requisitos funcionales

Libro Mayor (LM) Libro Contable en el cual se acumulan todas las transacciones financieras.

Receptor de la Factura Un cliente recibe una factura mensual que incluye nuevos cargos y créditos.

Archivo de Diario (Journal)

Un archivo en el que se reportan todas las transacciones financieras del día; de acuerdo con el método de doble registro, cada transacción acredita una cuenta lógica y debita otra cuenta lógica por la misma cantidad, por lo que el saldo total siempre es cero.

Tarifa por Pago Tardío (LPF)

Una tarifa, ya sea fija o prorrateada, cargada a las cuentas que tienen una deuda abierta y cuya fecha de vencimiento ya ha pasado.

Caja de Seguridad (Lockbox)

Un servicio de cámara de compensación que distribuye los pagos efectuados por los clientes a las empresas correspondientes. El servicio incluye la provisión de un archivo (cinta magnética) que contiene los datos del pagador y el monto del pago. Algunos bancos ofrecen servicios de caja de seguridad (lockbox).

Cuentas lógicas Mecanismo de contabilidad para la clasificación de las transacciones financieras y su influencia en el saldo de la empresa. Cada transacción acredita una cuenta lógica y debita una cuenta lógica. Las cuentas lógicas, también definen los atributos de la transacción que son reportados a la contabilidad general. Algunos ejemplos de cuentas lógicas son: cuentas por cobrar, dinero en efectivo, impuestos y amortización.

NFR Requisitos no funcionales

Cargo Único (OC) Un cargo por un servicio especial de única vez o compra, como el pago de la instalación inicial o del auricular.





aparezca aquí.


Ítem Abierto El método de Aplicación del Efectivo para los clientes que reciben las facturas. El cliente paga por los cargos en una factura específica; AR (Cuentas por Cobrar) destina el dinero a los grupos con cargos abiertos relacionados con la factura; todo dinero excedente se almacena como crédito no aplicado.

Listo de Fábrica (OOB)

Se refiere a la funcionalidad del producto principal Amdocs.

Canal de Pago Forma de pago especificada que puede acatar las instrucciones de cómo pagar los servicios sobre una base regular. El término canal de pago implica que un solo abonado tiene diferentes servicios que son utilizados por diferentes razones.

Arreglo de Pago (PA) Un plan de pago en abonos convenido con el cliente para el pago de deudas antiguas.

Cuentas físicas Un grupo de transacciones financieras acumuladas; la cuenta física define los criterios de acumulación en los informes de contabilidad general, para que las transacciones financieras sean acumuladas en una sola cuenta física. La cuenta física, por ejemplo, se puede basar en el tipo de producto, tipo de servicio, forma de pago o cualquier otro atributo de la transacción seleccionado para su agregación por parte del personal de contabilidad.

Cargo Recurrente (RC) Un cargo fijo mensual por el servicio.

Monto Restringido Un atributo de una entidad de cargos que garantiza que un crédito dado no supere la cantidad de cargos original.

Corredor de Transacciones (TRB)

Un módulo de Amdocs que es responsable del intercambio de información entre los componentes. AR (Cuentas por Cobrar) utiliza este módulo para la comunicación asincrónica con otros componentes.

Cargo por Uso (UC) El cargo por la duración de las llamadas telefónicas realmente efectuadas.

Interfaz del Usuario (UI)

Una aplicación del front-end utilizada por CSR.



2. CUENTAS POR COBRAR - ASPECTOS GENERALES DEL PRODUCTO Cuentas por Cobrar (AR) es una de una serie de transacciones de contabilidad relacionada con el estado de cuenta (bill) de los clientes de postpago que deben dinero a una persona, empresa u organización por bienes y servicios que se han proporcionado al cliente. En la mayoría de las entidades de negocio, los clientes postpago normalmente son emitidos (billed) mediante la generación de una factura y envío de la misma por correo o entrega electrónica al cliente. La factura debe pagarse en un plazo establecido.Cuentas por Cobrar administra las cuentas en múltiples divisas y recibe y aplica los pagos en cualquier divisa soportada por el sistema.El sistema de AR (Cuentas por Cobrar) soporta el proceso de gestión financiera del cliente. Mantiene los saldos de la cuenta de cliente mediante la administración de las actividades que se originaron vía el sistema de Amdocs Invoicing y manejo de pagos, créditos, actividades de pago (como Anulaciones (Backouts) del Pago, transferencias de fondos) y otras actividades financieras.Los datos de las Cuentas por Cobrar también son procesados y acumulados por el módulo de Contabilidad General de Diarios (JGL), para ser manejados por los departamentos de contabilidad y teneduría de libros del cliente.Las actividades y consultas manuales de Cuentas por Cobrar son compatibles mediante la GUI En Línea de AR, que se describe en Amdocs facturación (Billing)8.1 User Guide.Todas las actividades de la AR se manejan a nivel de la entidad FA (cuentas financieras).

2.1. Módulos Principales de Cuentas por Cobrar Principales Este documento proporciona una descripción detallada de los Módulos y Funciones de Cuentas por Cobrar de Amdocs.Estos módulos incluyen lo siguiente:■ Llega el Día de la facturación (Bill day Arrives)

■ Administración de Pagos





aparezca aquí.

■ Administración de Cuentas

■ Configurador de Cuentas por Cobrar

■ Diario (Journal) y Libro Mayor

2.1.1. Funcionalidad de Terminación del Ciclo

La Funcionalidad del módulo ‘Llega el Día de la facturación (Bill day Arrives)” coordina todas las actividades de ARs en el día de la facturación ( Bill).

■ Preparación de la factura (Bill) – el proceso genera archivos que contienen la información financiera relacionada con un periodo de facturación dado correspondiente a los Acuerdos de Facturación (BA) que pertenece a la población del ciclo. Los archivos son utilizados en el Cálculo de estado de cuenta (Bill). La lista de los Acuerdos de Facturación (BA) a ser procesada es enviada desde el sistema de Amdocs Invoicing.

■ Recibo de la Factura (Confirmación) – este proceso obtiene los archivos con cargos, créditos, impuestos y facturas provenientes de Facturación después de la Confirmación de la factura ( Bill) , carga los datos en la base de datos de Cuentas por Cobrar, tramita la aplicación de descuentos y créditos incluidos en la factura y actualiza los saldos de las cuentas, de conformidad.

2.1.2. Administración de Pagos

La Administración de Pagos es responsable de recibir los pagos y gestionar estos pagos una vez que están en el sistema.

Las funciones principales de la Administración de Pagos son las siguientes:

■ Manejo de Pagos – administra los pagos provenientes de un archivo de banco, caja de seguridad (lockbox) o de la actividad en línea.

■ Débito Directo – maneja la creación y mantenimiento de las solicitudes de Débito Directo; envía las solicitudes al banco y administra las respuestas provenientes del banco.





aparezca aquí.

■ Anulaciones (Backout) – administra los pagos rechazados por los bancos y compañías de tarjetas de crédito y tramita las anulaciones (backouts) desde las pantallas en línea.

■ Transferencia de Fondos – gestiona las transferencias de pagos de una cuenta hacia otra.

■ Reembolso del Pago – maneja la devolución de todo un pago posteado, accidentalmente, en el sistema de pagos (debido a un error del cliente).

2.1.3. Administración de Cuentas

La Administración de Cuentas soporta las actividades financieras para mantener las deudas de la cuenta.

Las transacciones financieras principales son las siguientes:

■ Reembolso del Sobrepago – gestiona la devolución de dinero no aplicado al cliente, así como la determinación o recomendación de reembolso de acuerdo con criterios predefinidos.

■ Crédito – tramita los créditos inmediatos y pendientes sobre facturas emitidas que requieren ser dadas al cliente.

■ Amortización (write-off) – tramita la amortización de deudas morosas de una cuenta.

■ Asignación Manual – tramita la transferencia de créditos entre las facturas de una cuenta.

■ Disputas – gestiona las actividades por disputas cuando se abre la disputa en relación con un cliente como respuesta a un reclamo que requiere más investigación.

2.1.4. Configurador de Cuentas por CobrarEl Configurador de AR (Cuentas por Cobrar) se utiliza para llevar a cabo las siguientes tareas principales:

■ Define las políticas de negocios y operaciones, tales como:

● Códigos de Razón

● Tipo y IDs del Emisor del Pago





aparezca aquí.

■ Ingresa los datos de referencia del negocio (tales como códigos de razón) correspondientes a las Cuentas por Cobrar, cuando dicha información no es suministrada por alguna otra fuente.

■ Ingresa los datos de referencia necesarios correspondientes a los Libros de Diario (Journal) y Libro Mayor. Estos datos determinan la forma en que se traducen las actividades financieras a transacciones en el Diario (Journal) y se les registra en las cuentas correctas del Libro Mayor.

■ Habilita la definición de las validaciones de los procesos, tales como validaciones de recibo de pago por ‘Batches’.

■ Define el registro entre grupos de cargos y cargos (cada Charge_Code es registrado en un Charge_Group_Type).

2.2. Interacción con Otros Componentes

Amdocs Accounts Receivable 8.1 de Amdocs viene pre integrado con otros componentes de Amdocs. Los siguientes componentes de Amdocs interactúan con AR (Cuentas por Cobrar):

■ Amdocs Invoicing – véase CNT - FS - Collection Backend - HLD

■ Amdocs Collection – véase CNT - FS - Collection Backend - HLD

■ facturación (Billing)Customer Management – véase – CNT - FS - facturación (Billing)Customer Management (BCM) - HLD

■ AmDD – Diseñador de Documentos Amdocs - CNT - Amdocs Document Designer HLD

2.2.1. Amdocs Invoicing

La Amdocs Invoicing interactúa con AR (Cuentas por Cobrar) en las formas siguientes:

■ Preparación de la factura (Bill) – como parte de los procesos de fin de ciclo, Facturación envía a AR la población del ciclo de la facturación (billing) con el fin de obtener información, tal como saldos previos y actividades financieras relacionadas con esta población.





aparezca aquí.

■ El proceso de Confirmación de la factura (Bill) envía la información siguiente a Amdocs AR (Cuentas por Cobrar):

● Estados de la cuenta (Bill) y Estados de Facturas

● Cargos (postpago) en la factura (el Bill)

● Impuestos

■ Las solicitudes de Débito Directo son recibidas por AR desde Facturación como parte del Proceso de Recepción de la Factura. AR crea los archivos para que las entidades financieras limpien las deudas como parte de la solicitud de Débito Directo.

■ El Invoicing Transaction Listener recibe desde AR la información de creación del crédito a nivel de cargo para incluir dicha información como parte de la

creación del siguiente ciclo de cargos.

2.2.2. Amdocs facturación (Billing)Customer Manager

El repositorio completado y actualizado de la base de clientes del proveedor de servicios de comunicación es mantenido por el componente Administrador de Clientes de facturación (Billing)de Amdocs. Para mantener el seguimiento de los detalles de la cuenta, AR (Cuentas por Cobrar) ‘escucha’ las transacciones del Corredor de Transacciones enviadas por el Administrador de Clientes de Facturación Amdocs. Las transacciones contienen información acerca de los cambios en los detalles de la cuenta. AR (Cuentas por Cobrar) captura los datos pertinentes y actualiza las cuentas dentro de su base de datos. Como resultado, las tablas de AR (Cuentas por Cobrar) se sincronizan con las tablas del Amdocs facturación (Billing)Customer Manager .

Los detalles de la Cuenta, BA (Acuerdo de Billing) y Canal de Pago, tales como nombre, dirección, tipo de cuenta, método de pago, indicador de desestimación y el estado de cuenta son enviados por el Amdocs facturación (Billing)Customer Manager mediante el Corredor de Transacciones. El estado de la Cuenta permanece como Abierta durante el ciclo de vida de la cuenta.





aparezca aquí.

La Dirección de la Cuenta Financiera que se recibe de la aplicación Amdocs facturación (Billing)Customer Manager a AR incluye la Provincia y la Localidad de la FA.

2.2.3. AmDD – Diseñador de Documentos Amdocs

La aplicación AR interactúa con el AmDD con el fin de generar:

■ Notas de Débito

■ Notas de Crédito

2.3. Alineación del Proceso de Negocios

La siguiente sección ayuda al lector a comprender cuáles procesos del negocio son analizados en este.

2.3.1. Llega el dia de la facturación – Productos Postpagados (BDA)

El escenario Llega el dia de la facturación describe el proceso relacionado con los procesos de fin del ciclo y generación del estado de cuenta (Bill).

Los siguientes pasos del proceso están relacionados con el escenario BDA:

■ Preparación del estado de cuenta (Bill) – Cálculo de la Tarifa por Pago Tardío

■ Interfaz de Recepción de Factura.

2.3.2. Cliente Paga – Productos Postpagados (CP)

El escenario Cliente Paga describe los procesos relacionados con los clientes que pagan el manejo de sus deudas, incluyendo otras actividades de pago.

Los siguientes pasos del proceso están relacionados con el escenario de CPs:

■ Recepción de un pago vía archivo

■ Pago en Línea





aparezca aquí.

■ Proceso de Débito Directo

■ Aplicación del Efectivo

2.3.3. Cliente Tiene una Pregunta – Productos Postpagados (CHQ)

El Escenario Cliente Tiene una Pregunta describe los procesos relacionados con el manejo de las dudas del cliente, incluyendo otras actividades de pago.

Los siguientes pasos del proceso están relacionados con el escenario de CHQ:

■ Crédito

■ Asignación Manual de los Pagos/Créditos

■ Reembolsos

■ Disputa

■ Amortización (Write-Off; no utilizada por CNT)

■ Consulta de los estados

■ Cargo y pago inmediatos

2.4. Supuestos 1. En la invocación de las actividades de AR e interfaces de AR, el ID de la

facturación(Billing) de FA se utilizará para identificar la entidad financiera de la cuenta para la cual se realiza la actividad.

2. Sistema externo que invoca los APIs de facturación (Billing) ; utilizará el Protocolo J2EE.

3. Las Interfaces de transferencia de archivos desde el sistema de archivos de la facturación (billing) a los sistemas de archivos externos no están en el ámbito de la solución de la facturación (billing).

4. Las actividades en línea de AR se activan desde un front-end externo hacia el Sistema de facturación de Amdocs.





aparezca aquí.

5. Autorización (RBA) y autenticación para la activación de las actividades de AR desde un sistema externo se realizan a través del Administrador de Seguridad Amdocs (ASM).

6. El Configurador de ARs Amdocs admite la autenticación a través del Administrador de Seguridad Amdocs. RBA no es compatible.

7. Amdocs AR recibe como input y también envía como output, el ID de la facturación (Billing) de FA. Si es necesario, un sistema externo será responsable de la traducción de la ID de la facturación (Billing) de FA al ID externo y de traducir el ID externo al ID de la facturación (Billing) de FA.

8. Proceso de registro del Débito Directo y Tarjeta de Crédito no está dentro del alcance del sistema de facturación (Billing).



3. FUNCIONALIDAD “LLEGA EL DÍA DE LA FACTURACIÓN”

3.1. Requerimientos Relacionados

ID DEL BR Descripción del BR Abarcado por

AI#2/847 (Extracto de Cargos por pago tardío - lámina 25) Cálculo de Mora se debe enviar una nota de debito del valor y no se debe incluir el valor de mora en la factura. La nota de débito debe contener como referencia el número de la factura que la originó. La nota de débito debe contener su propio número secuencial con la respectiva autorización del SRI. La nota de débito es generada en el momento que el cliente paga la factura retrasada. El facturador deberá generar la nota de débito y el sistema de CRM extrae la información y la imprime cuando el cliente la solicite.

11.3.6 Lógica del Cálculo de LPF Inmediato

4.7.3.1.1.1. Integración con el facturador para reporte de pagos y/o generación de otros cargos (Ej.:. interés de mora, ampliación del plazo, cheques devueltos, etc.)

3 – Llega el Día de la facturación

4.7.3.5.4.5. Agrupación de cargos, eventos, etc. Para generación de reportes para el cliente.

3.5. Proceso de Recepción de la Factura

4.7.3.6.1.1.1.1.1.

Procedimientos de castigo de cartera. 3.4. Cálculo de la Tarifa por Pago Tardío

4.7.3.7.3.1.3. Cargos para conceptos de recargo, mora. 3.4. Cálculo de la Tarifa por Pago Tardío


Información Propietaria y Confidencial de Amdocs16



aparezca aquí.

3.2. Supuestos

ID Única Descripción del Supuesto

AR.AS.3.1 El cálculo y cargo de LPF debe ser realizado en forma constante durante cada ciclo de facturación (billing) y también cuando se recibe el pago inmediato; la lógica de cálculo debe ser la misma en ambos casos.

El módulo Llega el dia de la facturación maneja las transacciones financieras de cuentas postpago que se producen en AR como resultado de la Ejecución de la facturación (Billing) en el Día de la facturación (Bill).

AR extrae los datos financieros para la Facturación a utilizarse en los cálculos del estado de cuenta ( Bill) y extractos para el AmDD, y una vez que Confirmación del estado de cuenta (Bills) recibe los archivos con los cargos, créditos, descuentos, impuestos y facturas calculadas por la aplicación Facturación, AR las carga a la base de datos e invoca todas las actividades que finalmente impactan los saldos de las cuentas pertinentes del cliente.

La Funcionalidad 'Llega el Día de la facturación' consta de dos componentes principales:

1. Proceso de Preparación de la estado de cuenta (Bill)

2. Proceso de Recepción de la Factura

3.3. Proceso de Preparación del estado de cuenta (Bill)

3.3.1. Nombre del ‘Batch’ del Proceso

AR1BILINTER – el propósito del proceso de Interfaz para la Preparación del estado de cuenta (Bill) es aprovisionar el Amdocs Invoicing con la información de AR correspondiente a la población del ciclo que es requerida para la ejecución del proceso del ciclo.





aparezca aquí.

3.3.2. Descripción del ‘Batch’

El Proceso de Interfaz para Preparación del estado de cuenta (Bill) recibe un archivo proveniente de Facturación el cual contiene la población del ciclo y lleva a cabo lo siguiente para cada una de las entidades del BA (Acuerdo de Billing) en el archivo:

1. Extrae el saldo de AR (Cuentas por Cobrar) de la cuenta financiera en la fecha de corte del ciclo.

2. Recopila todas las actividades financieras de la cuenta que han ocurrido desde el último ciclo hasta la Fecha de Corte del Ciclo (esto aplica solo para las entidades del BA (Acuerdo de Billing) del Receptor de la facturación ( Billing.)

3. Calcula las multas por pago tardío correspondientes a las facturas vencidas y para los créditos pendientes del BA (Acuerdo de Billing) a la Fecha de Corte del ciclo.

4. Extrae todo crédito pendiente en el AR que exista correspondiente al BA (Acuerdo de Billing) a la Fecha de Corte del Ciclo.

En el caso de cargos inmediatos creados en el AR, la Preparación de Archivos Financieros considera los cargos como una actividad financiera y lo agrega al archivo.

3.3.3. Tipo del Proceso

El proceso puede ejecutarse como un trabajo por ‘Batches’ como parte del mapa de operación diaria o como un daemon.

3.3.4. Frecuencia de la Ejecución (Run)

Si el proceso de Interfaz de Preparación de estado de cuenta (Bills) se ejecuta como un daemon, el flujo del proceso es activado cada vez que un nuevo archivo de input esté disponible vía Auditoría y Control.

Si el proceso de Interfaz de Preparación de estado de cuenta (Bills) se ejecuta como un trabajo, procesa un archivo antes de terminar. Si no hay archivos





aparezca aquí.

disponibles, se termina el proceso. Si hay más de un archivo disponible, solo se procesa un archivo.

3.3.5. Inputs

Es la población de la entidad BA del Ciclo BA proveniente de Amdocs Invoicing basada en el formato OOB.

3.3.6. Outputs

El proceso produce cuatro o cinco archivos que contienen información correspondiente a la población del ciclo proporcionado:

■ Canales de pago correspondientes a la población de BA y saldo de la FA a la fecha.

■ Actividades financieras llevadas a cabo para la FA del ciclo durante el ciclo presente (este archivo no se extrae para las entidades del BA (Acuerdo de Billing) del receptor de la factura).

■ Cargos de LPF – contienen los cargos por LFP calculados por este proceso.

■ Ítems por crédito fiscal pendiente – contiene los ítems fiscales calculados por AR.

■ Archivo Excepcional – en caso de un registro de input que no aprobó la validación.

3.3.7. Flujo por ‘Batches’

Este proceso es un proceso multihilos y maneja los datos por ‘Batches’ por balance de la carga y aspectos de rendimiento. El proceso:

1. Organiza los archivos de input en registros; cada registro contiene la información correspondiente a un solo BA (Acuerdo de Billing) .

2. Crea ‘Batches’ de estos registros; cada ‘Batch’ contiene cierto número de archivos.

3. Utiliza el primer hilo disponible de un grupo de hilos para procesar cada ‘Batch’ de registros.





aparezca aquí.

4. Lleva a cabo la validación a nivel de registro correspondiente a cada búfer del registro.

a. Si el registro no ha sido validado, se pasa a un archivo de excepciones.

b. Si el registro es validado, se almacena en un nuevo búfer de registros para posterior procesamiento.

5. Una vez que cada hilo ha sido procesado, crea los archivos de los extractos temporales arriba mencionados.

6. Una vez que todos los registros han sido procesados, fusiona los archivos creados por cada hilo y los clasifica en el archivo final del output.

7. Registra los archivos del output, aparte del archivo de excepciones, en Auditoría y Control, para análisis posterior por parte de Facturación Amdocs.

8. Si un ‘Batch’ de registros no se procesó satisfactoriamente débito a una excepción fuera de la validación arriba indicada, crea un archivo de error y lo registra en Auditoría y Control para que el operador lo procese de forma manual.

9. Si todos los datos en los archivos son procesados de forma exitosa, los archivos son marcados como concluidos en Auditoría y Control.

3.4. Cálculo de la Tarifa por Pago Tardío

3.4.1. Descripción

Una Tarifa por Pago Tardío (LPF) es un honorario de penalización que se carga a las facturas que no han sido pagadas a tiempo (en la fecha de su vencimiento).

Las LPFs son calculadas:

■ Durante el EOC (proceso de Cierre del Ciclo) por el proceso de Interfaz de Preparación de estado de cuenta (Bills) correspondientes a las FA y grupos de cargos;

■ Cuando se recibe un pago inmediato.





aparezca aquí.

● Cuando se calculan durante el EOC, los cargos de LPF se envían a Amdocs Invoicing en el archivo de output de cargos pendientes de la Interfaz de Preparación de estado de cuenta (Billing). Cuando se calculan durante el pago inmediato, los cargos de la LPF se crean inmediatamente en AR; pueden desencadenar la creación de una Nota de Débito inmediata (según la definición de la aplicación) y se enviará a Facturación en el próximo EOC, como todas las otras actividades financieras, con el fin de que aparezcan en el próximo estado de cuenta ( Bill).

● Cuando los cargos LPF se calculan durante el EOC, el proceso de creación del cargo de facturación incluye estos cargos en la ejecución del ciclo de estado de cuenta (Bill ) actual.

● Cuando se calculan durante el EOC, entonces, después de la confirmación del ciclo, estos cargos se enviarán vía Facturación a AR, junto con todos los cargos del ciclo, como parte del extracto de confirmación de la facturacion (Billing) al proceso de AR. Los Cargos de LPF creados inmediatamente no serán remitidos a AR, dado que ya aparecen ahí.

Los cargos de LPF son creados en la moneda de la cuenta y calculados con base en los grupos de cargos abiertos de FA. Un solo cargo de Tarifa por Pago Tardío es creado para todos los grupos de cargos de una factura.

1. El proceso obtiene todos los Grupos de Cargos (CGs) que son elegibles para el cálculo de la LPF y calcula el LPF para estos cargos, tomando en consideración los pagos y créditos posteados en dichos CGs.

2. Un parámetro de referencia llamado Días de Seguridad mantiene el número de días que se deducen del periodo de LPF en casos donde el pago ha sido hecho pero aún no ha llegado. Posteriormente, cuando se recibe el pago, el LPF se calcula nuevamente para cobrar la diferencia desde la última fecha de cálculo de LPF a la fecha real del depósito.

3. Para soportar el cálculo exacto del cambio de una tasa LPF, el registro histórico de tasas LPF se guarda en la tabla AR1_INTEREST_RATES a nivel de sistema. Cuando el proceso de la LPF necesita calcular un LPF





aparezca aquí.

durante un período determinado, se comprueba si la tasa LPF fue cambiada durante este período y utiliza la antigua tasa para el período previo al cambio de la misma y la nueva tasa para el período posterior al cambio de la misma.

La tasa de LPF, a nivel de cuenta financiera, no es guardada en el sistema.

El código de cargo asignado a los cargos y créditos de la LPF es definido por la aplicación en la tabla de referencia de AR1_Policy.

El Impuesto no se calcula para los cargos LPF por AR. En su caso, Facturación calcula el impuesto para estos cargos, en la misma forma que otros cargos pendientes enviado a Facturación para que se incluyan en la ejecución de estado de cuenta (Bill).

3.4.2. Elegibilidad del Grupo de Cargos para el Cálculo del LPF

Un grupo de cargos está sujeto al Cálculo de la Tarifa por Pago Tardío si se cumplen todas las condiciones siguientes:

■ El Acuerdo de Facturación asociado con el grupo de cargos se encuentra en el archivo de input de la población del ciclo enviado por Amdocs Invoicing (la validación es relevante solo para el cálculo de LPF durante el EOC.)

■ El sistema se ha configurado para calcular las tarifas por pago tardío correspondientes al tipo de ejecución y tipo de producción de la ejecución del la facturacion ( billing) y para la entidad de negocios de la cuenta.

■ El sistema puede definir una implementación, por ejemplo, en la cual LPF es calculada el estado de cuenta ( bill) final pero no se calcula para los estados de cuenta (bills) finales revisados (la validación es relevante solo para el cálculo de LPF durante EOC).

■ Las tarifas por pago tardío no se han exonerado a nivel de cuenta.

■ El grupo de cargos per sé está configurado para el Cálculo de la Tarifa por Pago Tardío. La elegibilidad de la Tarifa por Pago Tardío a nivel de grupos de cargo se encuentra definida en los archivos XML de agregación





aparezca aquí.

de agrupamiento flexible (la configuración se efectúa vía la GUI del Configurador de AR).

■ Amdocs recomienda que se configuren los siguientes tipos de grupos de cargos como no elegibles para el cálculo de LPF:

● LPF

● Reembolso

■ Se pasó la fecha de vencimiento del grupo de cargos y el grupo de cargos está abierto o el grupo de cargos está cerrado, pero el pago o crédito se aplicó al mismo después de la fecha de vencimiento.

■ El grupo de cargos no fue marcado durante el flujo del Arreglo de Pago como ‘Incluido en PA’.

Si estos criterios se cumplen, los grupos de cargos son agrupados por la factura a la cual pertenecen y se pasan a uno de los cuatro métodos de Cálculo de la Tarifa por Pago Tardío.

3.4.3. Fechas del Cálculo del LPF

La LPF se calcula a la fecha de vencimiento del grupo de cargos +1 hasta la Fecha de Corte del Ciclo; para ver más casos, véase la siguiente tabla:

Para la LPF calculada durante EOC:

Primer cálculo Cálculos consecutivos

Calculated_LPF_start_date

Fecha de vencimiento de la factura +1

Última fecha de cálculo de LPF +1

Grupo de cargos pagado Grupo de cargos no pagado

Calculated_LPF_end_date Fecha de depósito del pago – 1 Fecha de ciclo cerrado

Para el LFP calculado durante el Pago Inmediato:

Fechas del Cálculo del LPF:

1. Primer cálculo:

a. A partir de: el día de vencimiento de la Factura +1





aparezca aquí.

b. A: día presente correspondiente al CG no pagado,A: la fecha del depósito del Pago – 1 para el CG pagado

2. Cálculos consecutivos:

a. A partir de: última fecha del cálculo de LPF +1

b. A: Día Actual para los CG no pagados,A: Fecha de depósito del pago – 1 para el CG pagado

3.4.4. Periodo de Gracia del LPF

Puede concederse un número de días de gracia para un grupo de cargos antes de considerarlo para el Cálculo de la Tarifa por Pago Tardío; esta opción puede ser controlada vía Implementación.

La diferencia entre la fecha de inicio y la fecha de finalización del Cálculo de Tarifa por Pago Tardío debe ser mayor que este período de gracia para que el Cálculo de la Tarifa por Pago Tardío proceda con respecto al grupo de cargos (en otras palabras: para un LPF que se calculará para un grupo de cargos, el número elegible de días calculado entre la fecha de inicio y fecha de corte del ciclo debe ser mayor que el LPFGRACEDAYS).

El valor se establece para una entidad de negocios en el campo LPFGRACEDAYS de la tabla AR1POLICIES. El período de gracia no se considera al determinar la fecha de inicio del grupo de cargos correspondiente al prorrateo en el Cálculo de la Tarifa por Pago Tardío. Se utiliza únicamente como una verificación de la elegibilidad de un grupo de cargos para el Cálculo de la Tarifa por Pago Tardío.

3.4.5. Días de Seguridad del LPF

En relación con LPF calculado durante el EOC:

Un parámetro de referencia llamado LPF_SAFETY_DAYS contiene el número de días que son deducidos del periodo de LPF.

Esto es para habilitar los casos de soporte cuando se ha realizado un pago pero aún no ha llegado al sistema. El número de días de Días de Seguridad se deduce del periodo de LPF. Posteriormente, cuando se reciba el pago, el LPF





aparezca aquí.

se calcula nuevamente para cobrar la diferencia desde la última fecha de cálculo de la LPF a la fecha real del depósito.

Por ejemplo, para un nuevo grupo de cargos, donde LPF se calcula por primera vez: la LPF se calcula para el período comprendido entre la fecha de vencimiento hasta la (fecha de cierre del ciclo – LPFSAFETYDAYS) de la siguiente manera:

1. Calcular el número de días del cálculo de LPF (fecha de corte del ciclo – LPF_SAFETY_DAYS – fecha de vencimiento).

2. Actualizar la ‘última fecha de cálculo de LPF’ a (fecha de corte del ciclo – LPF_SAFETY_DAYS).

La siguiente vez que se calcula el LPF, se hará a partir de la última vez que LPF fue calculado, que es (fecha de cierre del ciclo previo – LPF_SAFETY_DAYS).

Básicamente, los días de seguridad permiten al sistema calcular cada mes con cierto margen, para soportar los pagos que ingresan de forma tardía.

Por ejemplo, si la fecha de cierre del ciclo es el 31 de enero y LPF_SAFETY_DAYS = 4, el sistema permite el cálculo de LPF solo hasta el 27 de enero y el mes siguiente el sistema hará el cálculo a partir del 27 de enero hasta el 27 de febrero, y así sucesivamente.

Esto permite al sistema evitar lo siguiente:

■ Que LPF sea calculado hasta el 31 de enero

■ Que al mes siguiente llegue el pago el 1 de febrero con una fecha de depósito 30 de enero.

Esto requeriría la creación de un crédito de LPF para corregir la LPF.

Por ejemplo, si la fecha de vencimiento del grupo de cargos es 14 de marzo, la fecha de cierre del ciclo es 31 de marzo y LPF_SAFETY_DAYS = 2. El 31 de marzo, LPF será calculada para el periodo del 15-29 de marzo; el 30 de abril (ciclo siguiente), la fecha para iniciar el cálculo de LPF sería 30 de marzo.

Para el LPF calculado durante el Pago Inmediato:





aparezca aquí.

El parámetro LPF_SAFETY_DAYS no será utilizado, asumiendo que este es el día de creación del pago y no se espera que llegue el pago del ‘Batch’ al sistema.

3.4.6. Monto Mínimo de la Tarifa por Pago Tardío

El monto calculado de la Tarifa por Pago Tardío correspondiente a una factura debe ser igual o superior al monto mínimo predefinido, de lo contrario no se hace cargo de Tarifa alguno. El valor es definido por la entidad de negocio en la columna LPF_MIN_AMT de la tabla AR1_POLICIES.

3.4.7. Lógica de Tarifa por Pago Tardío

El flujo de Cálculo de la Tarifa por Pago Tardío es el siguiente:

1. Se recuperan los grupos de cargos elegibles.

2. Se calcula la cantidad total y abierta de los grupos de cargos.

3. Al calcular esta cantidad total, la cantidad de disputas podría considerarse, con base en la configuración del sistema. Si se consideran las cantidades de disputa, los grupos de cargos netos de disputa y sumas de disputas por impuestos se restan del saldo del grupo de cargos.

4. Si la cantidad total abierta es mayor que cero, entonces se calcula la Tarifa por Pago Tardío; si la cantidad total abierta es cero, entonces no se carga Tarifa por Pago Tardío alguna.

5. Si el monto resultante es mayor que el Monto Mínimo de la Tarifa por Pago Tardío, el monto es cargado al cliente.

6. El monto mínimo es un valor de referencia configurable que puede ser establecido por CNT, con el fin de otorgar cierto monto de gracia tal que, si la cantidad LPF posteriormente calculada no excede esta suma mínima, no se creará la Tarifa de LPF.

7. Días de Tasa LPF – una propiedad que define el número de días asociado con la tasa de LPF. En otras palabras, para una tasa anual, el valor de esta propiedad debe establecerse en 365; en el caso de una tasa mensual, el





aparezca aquí.

valor de esta propiedad debe establecerse en 30; la tasa LPF debe alinearse con esta propiedad.

8. Factor de Prorrateo – el número de días para el cual debe calcularse el LPF (véase la sección anterior 3.4.3, “Fechas del Cálculo del LPF” ) dividido por el valor de los días de la propiedad de Tasa LPF.

9. El monto de LPF se calcula como la cantidad de deuda abierta total de la Factura multiplicada por una tasa porcentual; esta cantidad se multiplica entonces por el factor de prorrateo.

3.5. Proceso de Recepción de la Factura

Durante la Confirmación de estado de cuenta (Bill), Amdocs invoicing notifica a AR (Cuentas por Cobrar) los cargos Postpagados creados durante la Preparación de estado de cuenta (Bill) , tales como descuentos, créditos y cargos recurrentes.

El proceso de Confirmación de estado de cuenta (Bill) envía la siguiente información a AR (Cuentas por Cobrar):

1. Factura

2. Cargos, descuentos y créditos facturados (billed)

3. Impuestos

AR (Cuentas por Cobrar) crea facturas, aplica cargos y créditos y actualiza, de conformidad, el saldo de la cuenta.


AR1INVRCT


El Proceso de Recepción de la Factura se utiliza cuando se aplican cargos y créditos nuevos a una cuenta y afectan el saldo. El proceso recibe tres archivos desde Facturación Amdocs:

1. Detalles de la Factura





aparezca aquí.

2. Cargos (RC, OC, UC), descuentos y créditos

3. Ítems de impuestos.

a. Se puede recibir un cargo específico con Ítems no relacionados a los Impuestos.

b. Por ejemplo, en caso de un cargo que es parte de un Pago en Abonos, Facturación creará los cargos pendientes del pago en abonos por el monto neto del cargo original; por lo tanto, el cargo pendiente no llevará Ítems de Impuestos.

c. El Ítem de Impuestos puede tener un monto cero mientras que el monto Tasable es el monto del cargo relacionado. Esto sucede en el escenario de la Declaración de Impuestos Sénior. Si desea más detalles sobre la Declaración de Impuestos Sénior, refiérase a CNT - FS - Invoicing – HLD.

El diagrama siguiente muestra las entidades de deuda de FA:





aparezca aquí.

Figura 3-1: Entidades de la Deuda de la Cuenta Financiera

Los principios más importantes de la carga de datos recibidos por AR provenientes de Facturación se describen a continuación:

1. Cargos Positivos sin corrección alguna (cargos por descuentos/créditos) se crean como cargos en AR, según proporcionados por Facturación.

2. Si las correcciones del cargo negativo son inferiores al monto del cargo original positivo facturado (billed), se crea un cargo por una cantidad igual a la cantidad del cargo original menos las correcciones del cargo total.

3. Si las correcciones del cargo negativo exceden la cantidad del cargo positivo original facturado (billed), un crédito de nivel de la cuenta se crea para una cantidad igual a la cantidad del cargo original menos las correcciones del cargo total.





aparezca aquí.

4. En el caso de un descuento negativo de un cargo positivo, se resumen todos los descuentos relacionados con el mismo cargo (con cargo tipo 'DSC' y el mismo número de secuencia del cargo que el cargo original) como un único cargo negativo.

5. Los cargos negativos sin corrección alguna (cargos por descuentos/créditos) se crean como créditos de nivel de cuenta en AR según proporcionados por Facturación.

6. En el caso de un cargo negativo con corrección:

7. Si las correcciones totales superan la cantidad original del cargo negativo, se crea un cargo por una cantidad igual a la cantidad del cargo original menos las correcciones del cargo total.

8. Todos los cargos y descuentos se agrupan en grupos de cargos adecuados, de acuerdo con la implementación del código de los cargos.

9. Todos estos grupos de cargos están agrupados para la Factura del tipo de Estado de cuenta = Bill.

El saldo de la factura recién creada se define como monto del cargo, reducido por los montos de descuento, montos de la corrección a nivel de cargos y montos de créditos a nivel de cuenta que se abarcan con la factura. Cualquier crédito/pago inmediato adicional que se aplica a esta factura reduce el saldo de la misma.

3.5.3. Entidad de la Factura

Una Entidad de la Factura se genera para una Cuenta y BA (Acuerdo de Billing) específicos con el fin de representar una factura enviada por Amdocs Invoicing a un BA (Acuerdo de Billing) . Esta Entidad de la Factura se utiliza para resumir los cargos, descuentos y créditos del cliente correspondientes a la factura. Una factura inmediata también puede ser generada en AR (Cuentas por Cobrar) vía la invocación desde un sistema externo; tal factura inmediata únicamente puede contener cargos.

La Entidad de la Factura tiene los siguientes atributos principales:





aparezca aquí.

Nombre del Atributo Descripción del Atributo Valores válidos

Monto de la Factura Suma total de todos los cargos asociados con la factura.

Saldo de la Factura Monto total inicial (no cubierto) de la factura

Estado de la Factura La situación actual de la factura Para Facturas de Débito:

Abierta

Cerrada

Para Notas de Crédito:

Sin Finalizar

Finalizada

Si la factura es enviada por Amdocs Invoicing al Proceso de Recepción de la Factura y contiene sólo los créditos, se crea con el tipo de factura de Nota de Crédito; de lo contrario, se crea como tipo de estado de cuenta de la factura ( bill).

Una nueva Nota de Crédito creada por Recepción de Facturas tiene estado 'Finalizado'. No se puede cambiar este estado.

Una Factura de Débito creada por el Proceso de Recepción de Facturas tiene su estado definido de la siguiente manera:

■ Si el monto total de los créditos y descuentos incluidos en esta factura es superior o igual al monto total de los cargos que se incluyen en la factura, ésta es creada con estado “Cerrado”.

■ De lo contrario, la factura es creada con estado “Abierto”

Los créditos de nivel de cuenta que están incluidos en la factura se aplican al monto de la factura abierta; cualquier monto excedente se aplica a otras deudas de conformidad con las reglas de Aplicación del Efectivo.

El estado de la Factura de Débito se cambia a 'Cerrado' cuando ésta ha sido totalmente cubierta por el pago o crédito.





aparezca aquí.

Si una actividad manual se realiza más tarde para quitar total o parcialmente la cobertura, como la reasignación manual de cubrir pago/crédito, reversar el crédito de cobertura y así sucesivamente, el estado de la factura se vuelve a cambiar a 'Abierto'.

3.5.4. Tipo de Proceso

El proceso puede ejecutarse como un trabajo en ‘Batches’ o como un daemon.


Si el Proceso de Recepción de la Factura se ejecuta como un daemon, el flujo del proceso es activado toda vez que una nueva serie de archivos de facturas, cargos e impuestos se encuentran disponibles vía Auditoría y Control.

Si el Proceso de Recepción de la Factura se ejecuta como un trabajo, maneja una serie de archivos antes de terminar; si no hay archivos disponibles, se termina el proceso y si más de una serie de archivos se encuentra disponible, procesa una serie y finaliza entonces.

3.5.6. Inputs

Este proceso recibe tres archivos, los cuales son los detalles de la factura del ciclo en ejecución:

■ Detalles de la factura

■ Cargos (RC, OC, UC), descuentos y créditos

■ Ítems fiscales

3.5.7. Outputs

Ninguno


Este proceso es un proceso multihilos y maneja los datos por ‘Batches’ por razones de balance de la carga y rendimiento. El proceso lleva a cabo los siguientes pasos:





aparezca aquí.

1. Si se ejecuta como un daemon, el proceso continuamente busca en Auditoría y Control los nuevos archivos entrantes. Si se ejecuta como un proceso, el proceso toma sólo un archivo de Auditoría y Control; si no hay un archivo disponible, el proceso termina.

2. Analiza los archivos del input en los registros; cada registro contiene toda la información de facturas, cargos e impuestos para una sola cuenta.

3. Crea ‘Batches’ de estos registros y cada ‘Batch’ contiene un número de registros.

4. Procesa cada ‘Batch’ de registros vía el primer hilo disponible en un grupo de hilos.

5. Procesa cada registro del ‘Batch’. Se crean las facturas, cargos, créditos e ítems fiscales.

6. Actualiza los saldos de las cuentas para las que se crearon las facturas, basado en factores tales como:

a. Los montos de los cargos y créditos creados.

b. Asignación de los créditos no aplicados

3.6. Asuntos Abiertos – N/A

Id Descripción Estado



4. ADMINISTRACIÓN DE PAGOS



4.7.3.1. Gestión de Recaudos. Funcionalidad que se refiere a todas las actividades y tareas requeridas para realizar la Cobranza a los clientes por la utilización de los productos y servicios prestados por CNT E.P. Para este efecto, deberá cumplir con los siguientes requerimientos:

4 – Administración de Pagos

4.7.3.1.1. Cuentas por Cobrar (A/R). 4 – Administración de Pagos

4.7.3.1.1.10.1.5.

Registrar todas las transacciones de pagos en el sistema y distribuirlas por concepto de facturación, permitiendo así la generación de los registros contables requeridos por el sistema de contabilidad.

4.4 – Proceso de Posteo del Pago

4.5 – API del pago

4.7 – Anulación (Backout) del Pago

4.6 – Transferencia de Fondos API

5.5 – Proceso de Retroalimentación del Débito Directo

4.7.3.1.1.2. Recepción de pagos de clientes de múltiples fuentes. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.2.1. Recepción de pagos en bancos. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.2.2. Recepción de pagos desde redes de cajeros. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.2.3. Recepción de pagos en oficinas de CNT E.P. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.4. Aplicación de los valores a facturas pendientes. El sistema debe:

4.3. Proceso de Recepción del Pago





aparezca aquí.


4.7.3.1.1.4.1. Recibir, validar y aplicar los pagos. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.4.1.2. Validar totales de control contra la nota crédito reportada por el banco.


4.7.3.1.1.4.2. Administrar los pagos rechazados. 4.7. Anulación (Backout) del Pago

4.7.3.1.1.4.2.1. Cuentas /facturas inexistentes. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.4.2.2. Cheques devueltos. 4.7. Anulación (Backout) del Pago

4.7.3.1.1.4.2.3. Pagos duplicados. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.4.2.4. Pagos de menor o mayor cuantía. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.4.2.5. Pagos a cuentas erradas o inexistentes. 4.3. Proceso de Recepción del Pago

4.7.3.1.1.4.5. Debe actualizar el saldo de la cuenta/cliente en línea, una vez aplicado el pago.

4.5. API de Pago

4.7.3.1.1.5. Traslados de fondos entre cuentas del cliente. 4.6. Transferencia de Fondos API

4.7.3.1.1.8.3.6. Pagos NO registrados 4.4. Proceso de Posteo del Pago

4.7.3.6.1.3.2. Aplicación del pago en la cuenta de facturación. 4. Administración de Pagos

4.7.3.6.3.8.2. Registro de pagos en línea por parte de las agencias de cobranza.

4.5 – API del pago

4.7.3.7.9. Incorporación de pagos. La solución ofertada debe aplicar pagos a nivel de número de factura.

4.3. Proceso de Posteo del Pago



SIS Arias Liliana, 30/08/12,


Añadir controles para que no se realice pagos a cuentas no existentes


un pago rechazado no es lo mismo que la anulacion del pago, si el pago es rechazado no se supone que no se procesa y se va a las inconsistencias??, para que se va a hacer anulación??




aparezca aquí.

4.2. Supuestos


AR.AS.4.1 El archivo de recibo de pago puede incluir los pagos de estado de cuenta (bill ) mensual únicamente o general (sin número de factura legal relacionado).

Una Nota de Débito que se crea inmediatamente puede pagarse manualmente o con el monto adeudado de estado de cuenta (bill) mensual. El recibo de pago no tendrá un número de factura legal para la Nota de Débito.

Los pagos son fondos monetarios que los clientes postpago pagan por los servicios que son cargados a la cuenta del cliente y que aparecen en el estado de cuenta (bill) o en la factura. Los pagos de los clientes pueden ser recibidos desde diversas Fuentes y de varias formas:

■ Archivos en ‘Batches’ (archivos de caja de seguridad (lockbox files)) – estos archivos son recibidos desde las instituciones financieras y contienen los pagos despachados por el cliente al instituto.

■ API de Pagos – transacción de pago único, por lo general cuando el cliente paga durante una interacción con CSR.

Los métodos de pago pueden ser en efectivo, cheque, tarjeta de crédito o Débito Directo bancario.

En el caso de pagos en efectivo o con cheque, los fondos se asumen como recibidos por el proveedor del servicio y el propósito de esta actividad es reflejar esta acción en el Sistema de la facturación (Billing) . En el caso de Débito Directo bancario y pagos recurrentes con tarjeta de crédito, la facturacion (Billing) interactúa, vía el archivo del ‘Batch’, con el proceso del portal de la institución financiera.


El Proceso de Recepción del Pago es el primer proceso que administra los archivos de pagos.





aparezca aquí.

Es un daemon que constantemente detecta los archivos de pagos nuevos con nombres predefinidos en los directorios predefinidos; una vez que llega un archivo, este es procesado de forma inmediata.


AR1PYMRCT – Proceso de Recepción del Pago


El Proceso de Recepción del Pago clasifica el archivo de input, realiza las validaciones a nivel de archivo y registro y genera un archivo de output con las transacciones de pago válidas a ser manejadas por Proceso de Posteo del Pago.

El archivo es clasificado de acuerdo con la moneda y el ID de la FA, por defecto, con el fin de permitir que el posteo del pago sea adecuado para diseñar las FAs y postearlo en ECAs en los casos en que la FA relevante no pueda ser identificada.

El archivo puede ordenarse por cualquier campo del registro detallado. Para este fin, debe aplicarse la propiedad de la orden de clasificación del pago en la tabla de Propiedades. La propiedad debe contener la secuencia numérica en los campos de clasificación, delimitados por una coma. Por ejemplo, si una propiedad tiene el valor 1, 2, el archivo se ordenará por el primer campo del registro detallado y luego por el segundo campo del registro detallado.

Se llevan a cabo las siguientes validaciones en los archivos de input:

1. Nombre y estructura del archivo están correctos

2. Los totales del trailer del archivo concuerdan con los registros del archivo.

3. El Emisor del Pago del archivo está sincronizado con las definiciones del Emisor del Pago en la tabla de referencia de ARs.

4. El Método de Pago de cada registro es sincronizado con la tabla de referencia del AR del Método de Pago; este método debería ser en efectivo o cheque.




No detalla como configurar el método de pago.


Que es el trailer?



aparezca aquí.

Si una de las validaciones anteriores falla, el archivo es rechazado y copiado en el directorio predefinido de Errores. El estado del archivo en Auditoría y Control se define en Rechazado.

Si el archivo es aceptado, se traslada para Posteo del Pago creando una entrada en Auditoría y Control.


El proceso puede ejecutarse como trabajo por ‘Batches’ o como un daemon.


Si el Proceso de Recepción del Pago corre como daemon, el flujo del proceso es activado siempre que haya disponible un archivo de Caja de Seguridad (Lockbox) vía Auditoría y Control.

Si el Proceso de Recepción del Pago se ejecuta como un batch, maneja un archivo antes de terminar; si no hay archivo disponible, se termina el proceso. Si hay más de un archivo disponible, procesa el primer archivo remitido mediante consulta a la base de datos.

4.3.5. Inputs

El Proceso de Recepción del Pago recibe un archivo de input del pago en formato OOB, desde un proceso de pago desde portal externo; el archivo debe ubicarse dentro del sistema del archivo de la facturacion (Billing) en el directorio $ABP_AR_ROOT/interfaces/input.

Un proceso listener del portal transfiere el archivo a un directorio de trabajo e inserta un registro con los detalles del archivo del pago en la tabla de Auditoría y Control.

La ubicación, ruta y nombres de los archivos son recuperados desde Auditoría y Control.





aparezca aquí.

4.3.6. Outputs

Cuando se completa el proceso, se crea un nuevo archivo de pago ordenado, con un nuevo registro correspondiente con el alias de archivo PYMPST creado en Auditoría y Control para el Proceso de Posteo del Pago.


El proceso realiza la validación del archivo con base en las definiciones establecidas por la implementación, ordena el archivo e inserta un registro en las tablas de Auditoría y Control para el Proceso de Posteo del Pago.

En caso de un error de validación, el archivo se marca como erróneo para que sea procesado en la tabla de Auditoría y Control y el operador lo manipulará manualmente.

4.4. Proceso de Posteo del Pago

El Proceso de Posteo del Pago es responsable de llevar el pago hacia la entidad designada correcta (Cuenta Financiera o Factura, actualizando el saldo de FA y otras actividades derivadas de una transacción de pago.


AR1PYMPST – Proceso de Posteo del Pago


El Proceso de Posteo del Pago es un daemon que identifica los archivos de pago que pasaron a Recepción del pago. Una vez que el archivo llega, se procesa de inmediato.

El proceso es un proceso multihilado, por aspectos de rendimiento.

Cada registro de pago en el archivo de input representa un pago para una sola cuenta financiera.

Cada pago es guiado a su entidad designada (cuenta o factura), basado en el ID de FA o ID de la factura que va a aparecer en el archivo de pago.




Es decir que habrá cientos de archivos a procesar dependiendo de las fechas de corte???


Cuales son las otras actividades derivadas


Registro del pago


Registro del pago



aparezca aquí.

Si un pago no ha podido ser guiado a su entidad designada, se guía a la Cuenta de Control de Excepciones (ECA).

4.4.3. Cuenta de Control de Excepciones

ECA es una entidad de Cuenta Financiera técnica que se utiliza como un Rango (Buckets) temporal de pagos mal guiados, hasta que se realice el proceso manual para guiar el pago a la cuenta financiera correcta. ECA no está relacionada con alguna otra entidad en el modelo de la entidad.

Las cuentas de ECA están definidas por los siguientes parámetros, que generalmente ayudan a ésta a rastrear la cuenta financiera correcta del pago:

1. Tipo de Emisor del Pago: se trata de una categorización de la fuente de pago; el tipo puede ser una empresa bancaria o de tarjetas de crédito, así como la ubicación - área desde la que proviene el pago.

2. ID del Emisor del Pago: una identificación única del Emisor del Pago para un tipo de fuente específico.

3. Moneda de pago – la moneda original del pago.

4. BE – entidad de negocios – la definición del mercado del pago.

El Configurador de AR se utiliza para configurar los ECAs según estos campos de desglose; estas definiciones se mantienen en una tabla de referencia denominada AR1_PAYMENT_SOURCE

EL AR1_PAYMENT_SOURCE será utilizado en CNT para definir la Provincia y Localidad del Posible Emisor del Pago

ECAs son creados como parte del proceso de migración con base en las definiciones de esta tabla.

Dichos pagos deben manejarse manualmente utilizando facilidades de API, tal como la Búsqueda del Pago con el fin de localizar la cuenta correcta. La Transferencia de Fondos se utiliza para mover un pago desde una cuenta ECA a una cuenta de cliente, al identificar la cuenta de pago relacionada.




Manualmente??? Cada cuanto tiempo??,


Repositorio



aparezca aquí.

La tabla siguiente ilustra cómo se aplican los pagos por ‘Batches’ para Aplicación del Efectivo, dependiendo de la cuenta designada, en el registro de pago en el archivo:

Cuenta Designada Aplicación del Efectivo

No se especifica en el registro del pago

Pago aplicado a ECA

Especificada en el registro del pago. Existe en la base de datos

Pago es aplicado a deudas abiertas de la cuenta designada, de acuerdo con las reglas de Aplicación del Efectivo

Se especifica en el registro del pago.

No existe en la base de datos

Pago aplicado a ECA

Asimismo, las siguientes validaciones pueden ser configuradas en el registro del pago:

■ Validación del Sobrepago – si esta validación está configurada, el pago es enviado a ECA si el monto del pago es superior a la deuda abierta de la cuenta financiera por un porcentaje predefinido.

■ Validación del estado de la cuenta – evita que las actividades del pago sean llevadas a cabo en las cuentas con el estado especificado. Los valores válidos: Abierto, Cerrado.




Si el Proceso de Posteo del Pago se ejecuta como un daemon, el flujo del proceso es activado siempre que esté disponible un nuevo archivo de Caja de Seguridad (Lockbox) vía Auditoría y Control.

Si el Proceso de Posteo del Pago se ejecuta como un trabajo por ‘Batches’, procesa un archivo antes de terminar.




Se active cada vez que se coloca un archive en el repositorio


Valida Que las cuentas esten en los estados abierto para hacer el pago y evita que las actividades sean llevadas a cabo en las cuentas con estado cerrado.



aparezca aquí.

Si no hay archivos disponibles, se termina el proceso; si hay más de un archivo disponible, procesa el primer archivo remitido por la base de datos que hace la consulta.

4.4.6. Inputs

Archivo validado y ordenado en formato OOB; para el formato de archivo de input, véase el documento CNT - Verification Phase - AR - Finance Institute –

IDD.

4.4.7. Outputs

Ninguno


El proceso lleva a cabo los siguientes pasos:

1. Si se ejecuta como un daemon, el proceso continuamente busca en Auditoría y Control los nuevos archivos entrantes. Si se ejecuta como un trabajo por ‘Batches’, el proceso toma sólo un archivo de Auditoría y Control; si no hay un archivo disponible, el proceso termina.

2. El proceso asume que el archivo de input es ordenado en forma tal que:

a. Todos los pagos de la misma moneda, ID del Emisor del Pago, tipo de Emisor del Pago, y la entidad de negocio (BE) están agrupados. Estos cuatro atributos son los criterios para seleccionar la Cuenta de Control de Excepciones a utilizarse para un pago especial.

b. Todos los pagos para la misma cuenta financiera que cae bajo el agrupamiento anterior también se agrupan.

3. El proceso lee los archivos de pago creados por el Proceso de Recepción del Pago y divide el archivo en parches de registros de pagos, de la forma siguiente:

4. Cada ‘Batch’ de registros contiene los pagos que se postearán individualmente en la misma Cuenta de Control de Excepciones en el caso de error.





aparezca aquí.

a. Todos los pagos para la misma cuenta se incluyen en el ‘Batch’ de registros.

b. El número de pagos en el ‘Batch’ de registros está limitado por un parámetro de tamaño de ‘Batch’ para balancear la carga entre los hilos del proceso. El número de pagos puede superar el tamaño del ‘Batch’, con el fin de evitar que se dividan los pagos para la misma cuenta entre ‘Batches’ de registros.

5. Al procesar un ‘Batch’ de pagos, una Cuenta de Control de Excepciones para este ‘Batch’ es pesimistamente bloqueada. Si no existe ninguna Cuenta de Control de Excepciones, el intento de re-bloquear una Cuenta de Control de Excepciones es reintentar varias veces (este número es configurable) antes de que se produzca una excepción de bloqueo para este ‘Batch’ de pagos.

6. El ‘Batch’ de los pagos es manejado por el primer hilo disponible en un grupo de hilos.

7. Para cada registro en el ‘Batch’ de los pagos, el proceso:

a. Valida el registro de pago:

i FA no ha sido amortizada

ii Otro validación basada en definiciones de la aplicación

b. Realiza la conversión de moneda, si es necesario, de la moneda de pago a la moneda de la FA.

c. Se aplica el pago utilizando las reglas de Aplicación del Efectivo definidas por la política de saldos de FA.

d. Si el pago no puede ser guiado, se dirige el pago hacia ECA, de acuerdo con la moneda, ID del Emisor del Pago, tipo de Emisor del Pago y atributos de la entidad de negocio.

e. Actualiza el saldo de la cuenta.

f. Actualiza la tabla de Registro de Transacciones con la nueva actividad de pago para fines de Libros de Diario.




El proceso batch se ejecutaria tantos hilos como archivos existan??? Como se configura la cantidad de hilos que existirán?, que criterios se deben tomar en cuenta?



aparezca aquí.

g. Si la cuenta financiera se encuentra en Cobranza, publica una transacción TRB para Cobranza correspondiente a las medidas necesarias adicionales.

8. Todos los ‘Batches’ de los pagos que no se procesaron correctamente debido a una razón aplicativa se registran en un archivo de error creado en formato XML y se registran en Auditoría y Control. Estos archivos debe manejarlos manualmente el operador.

4.5. Crear Proceso de Pago

Los pagos en línea son registrados en el sistema de la facturación (Billing) vía el API createPayment, que puede ser invocado por un sistema externo o una aplicación UI. El API postea el pago en el saldo de una cuenta financiera, cubriendo las deudas de FA con base en las reglas de Aplicación del Efectivo.

4.5.1. Flujo

El API de createPayment recibe como input varios detalles del pago, principalmente el ID de la cuenta financiera y, si es necesario, también el ID de la factura correspondiente a la factura contra la cual se hará el pago. Estos detalles de pago se validan versus la entidad empresarial en el contexto de la sesión. Si falla alguna de las comprobaciones, se produce un error en la creación del pago y se envía un mensaje de error a la aplicación caller. Posterior a la solicitud de creación del pago, se crea un evento de pago de la factura o cuenta, en particular. El proceso:

■ Valida los detalles del input:

● Las entidades de FA existen en el sistema

● FA no ha sido amortizada

■ Registra el pago en el sistema

■ Actualiza el saldo de la cuenta financiera, de conformidad.

■ Aplica el pago a grupos de cargos con base en la lógica definida para la Aplicación del Efectivo.




Cuales pueden ser las razones aplicativas , Ejemplos.



aparezca aquí.

■ Actualiza la tabla de la Bitácora de Transacciones con la actividad del nuevo pago, para fines de los Libros de Diario.

■ Si la cuenta financiera está en Cobranza, se publica una transacción TRB de Cobranza correspondiente a las acciones requeridas adicionales. Facturación

4.6. Transferencia de Fondos

4.6.1. Flujo

La Transferencia de Fondos se utiliza para transferir un pago, o parte de un pago, desde una cuenta a otra cuenta o grupo de cuentas. La necesidad de transferir un pago ocurre, por ejemplo, en los siguientes casos:

■ Un pago ha sido posteado en una cuenta equivocada.

■ Un pago ha sido posteado en una Cuenta de Control de Excepciones (ECA) y debe ser transferido a la cuenta correcta, después de haber sido identificado.

■ Un pago es enviado para cubrir los cargos de una cuenta financiera en particular, pero debe cubrir diversas deudas de las cuentas financieras; en este caso, solo parte del pago debe ser transferido.

La Transferencia de Fondos se realiza en línea.

El Representante de Servicio al Cliente efectúa lo siguiente:

1. Recupera la lista de pagos de la cuenta financiera de origen.

2. Selecciona el pago a ser transferido e ingresa la información de la transferencia. Esta información incluye lo siguiente:

a. La cuenta de destino del pago transferido.

b. El monto transferido (total o parcial).

c. Un código de razón; los códigos de razón disponibles se basan en la entidad del negocio de la cuenta de origen.




Pago parcial


Será revisado en ECA.


Solo el cliente puede darse cuenta de este inconveniente



aparezca aquí.

d. Un memorándum con texto explicativo proveniente del representante de servicio al cliente.

La actividad en línea crea una transacción de Transferencia de Fondos, la cual incluye la información de la transferencia e invoca al controlador (handler) de la Transferencia de Fondos.

El controlador de la Transferencia de Fondos divide la solicitud en dos partes:

■ Fondos-Transferir-Desde: reversa el pago a ser transferido.

■ Fondos -Transferir-A: aplica el pago a la cuenta y factura de destino y a cualquier otro pago.

La Transferencia de Fondos realiza los pasos siguientes:

1. Valida la solicitud:

a. Verifica que existan las cuentas y facturas destino.

b. Verifica que existan la cuenta de origen y el pago.

c. Verifica que el monto de ‘Transferir A’ no exceda el monto de ‘Transferir Desde’.

d. Verifica que exista la razón de la Transferencia de Fondos en la tabla de Referencia.

e. Verifica que las cuentas de origen y destino estén abiertas y no hayan sido canceladas (cobradas).

2. Actualiza la tabla de Actividad del pago para rastrear el historial del pago. El pago es marcado como transferido y una nueva entrada se genera para ‘Transferir Desde’ en la tabla de Actividad de Pagos.

3. Actualiza la tabla de la Bitácora de Transacciones con dos actividades a ser registradas, para fines de Libros de Diario (Journal).

a. Actividad Fondos-Transferir-Desde

b. Actividad Fondos-Transferir-A

4. Desenlaza todos o algunos de los enlaces de crédito-débito del pago de origen.





aparezca aquí.

5. Los enlaces de crédito-débito del pago de origen son clasificados de acuerdo con las prioridades de la Aplicación del Efectivo.

6. Reversa los enlaces crédito-débito, uno por uno, hasta que se libere el monto requerido a ser transferido.

7. Dado que cada enlace crédito-débito solo puede ser desvinculado como un todo, puede dejarse una suma excedente que deba ser re-vinculada.

8. Al terminar, si hubiera un monto no aplicado, se usa la Aplicación del Efectivo para cubrir las deudas recién abiertas con dicho monto no aplicado.

9. Solo la parte Transferir A genera un evento de pago y lo envía al Controlador de Créditos (Credit Handler). El pago es procesado por el Controlador de Pagos (Payment Handler) que llama a la Aplicación del Efectivo, tal como lo hace con cualquier otro pago que ingresa al sistema. Esto crea un nuevo pago en el sistema correspondiente a la cuenta de destino. Esto es efectuado para cada cuenta o factura en la lista de cuentas de destino.

10. Si la cuenta financiera está bajo Cobranza, se publica una transacción TRB de Cobranza correspondiente a las acciones adicionales requeridas.

4.7. Anulación (Backout) del Pago

4.7.1. Flujo

La Anulación (Backout) del Pago se lleva a cabo con el fin de reversar un pago posteado previamente. La aplicación Caller debe proporcionar el pago a ser reversado y motivo de la anulación proveniente de la tabla de referencia AR1_BACKOUT_REASON. Esta actividad crea una transacción de anulación que incluye la información relevante de la anulación y marca el pago como reversado y reversa el efecto del pago completo de la cuenta; no es posible la anulación parcial.

La tabla AR1_PAYMENT_ACTIVITY almacena la actividad de Anulación (Backout) del Pago.




Tambien es registrado en auditoria y control, en caso afirmativo seria otra table de auditoria?


Tambien se guardara en auditoria y control?


Realizado


Si la transaccion del bus para cobranza falla, donde se almacena el error?



aparezca aquí.

4.7.2. Descripción de la Solución

4.7.2.1. Parámetros de la Aplicación del Caller

Cuando la API de Anulaciones (Backout) de Pagos es invocada para una cuenta, la aplicación Caller debe proporcionar lo siguiente:

■ ID de la cuenta financiera

■ ID del pago que debe ser anulado.

■ Código de la razón de la anulación.

4.7.2.2. Flujo del Proceso

La Anulación (Backout) del Pago efectúa los pasos siguientes:

1. Valida los parámetros de input:

a. Existe el ID de la FA y no ha sido cancelada.

b. El pago existe y no es una anulación y no fue reembolsado previamente.

c. El código de la razón de la anulación es correcto y válido.

2. Si el pago fue transferido a otras cuentas, reversa toda la porción del pago original.

3. Marca el pago como revesado y crea una nueva actividad de pago de tipo anulación.

4. Actualiza el saldo de la Cuenta Financiera y desasigna el pago del grupo de cargos que cubre.

5. Si existe un sobrepago en la FA, abarca los grupos de cargos desasignados.

6. Si se define un cargo por Pago no Honrado en la razón de la anulación, el cargo se aplica.

7. Actualiza la tabla de la Bitácora de Transacciones con la nueva actividad de la Anulación, para fines de Libros de Diario (Journal).




Elimina el registro anterior o se coloca como no valido pero se mantiene en el libro?


Se puede dar el caso de que un api este abajo mientras que la aplicacion funcione correctamente ???



aparezca aquí.

8. Si la cuenta financiera está bajo cobranza, publica una transacción TRB en Cobranza, correspondiente a las acciones adicionales requeridas.

4.7.2.3. Razones de la Anulación (Backout) del Pago: Parámetros Configurables

Al configurar una razón de anulación, los siguientes campos son definidos para cada razón de anulación configurada.

■ DCK_CHARGE_INDICATOR: define si el cargo DCK debe ser calculado para este tipo de anulación; valores válidos: Y – SI y N – NO

■ OVERWRITE_DCK: Indica si la cancelación manual del DCK está permitida cuando dck_applies está definido en ‘Sí’; se utiliza en línea; valores válidos: Y – SI y N – NO

■ DCK_CHARGE_CODE: el código de cargo con el que el cargo DCK es creado; los valores válidos son tomados desde la tabla de referencia de Códigos de Cargos (AR1_CHARGE_CODE).

■ CHARGE_AMOUNT: monto de DCK, definido en la moneda del sistema.

Los atributos OOB anteriores de la tabla AR1_BACKOUT_REASON son utilizados para crear multas con base en la razón del rechazo.

Las razones adicionales de la anulación pueden ser definidas por el equipo de Implementación, utilizando el Configurador de AR.






Que es DCK?


En que casos deberia estar cerrada, es decir no se aplicaria en linea?

5. ADMINISTRACIÓN DE DÉBITO DIRECTO



4.7.3.1.1.4.1.1.

Recibir y leer los archivos de pagos de los bancos.

5. ADMINISTRACIÓN DE DÉBITO DIRECTO

4.7.3.5.3.5. Medio de pago pre-autorizado (débito automático, tarjeta de crédito, etc.). Debe permitir almacenar toda la información referida a la fuente de pago seleccionada por el cliente.

5.3. Proceso de Creación de la Solicitud de Débito Directo

AI #889 CNT pide que en el requerimiento de débito Amdocs extraiga por separado el monto neto total y el monto de los impuestos detallado.

5.4 Direct Debit Extract Process

5.2. Supuestos


AR.AS.5.1 Una solicitud de Débito Directo no considera los montos del Arreglo de Pago, sino que es creada con el monto del saldo de la AR de la cuenta.

Para las cuentas tienen arreglo de Pago, el medio de pago recurrente de Débito Directo debe ser cambiado, manualmente, por el medio de pago ‘En efectivo’.

El Débito Directo es un método de pago mediante el cual el sistema de la facturación (Billing)solicita la institución financiara que debite directamente de la cuenta bancaria del cliente o cuenta de tarjeta de crédito, en forma regular. La actividad de Débito Directo se lleva a cabo solo a solicitud del cliente.

El flujo de Débito Directo está determinado por el parámetro de modo de Débito Directo – optimista o pesimista (CNT opera bajo el modo Pesimista).





aparezca aquí.

En Modo Pesimista, el pago es posteado después que el Controlador de Retroalimentación ha recibido la retroalimentación positiva proveniente del banco o de la cámara de compensación.

El diagrama siguiente ilustra el flujo de trabajo del manejo de Débito Directo:

Figura 5-2: Flujo de Trabajo del Manejo del Débito Directo

Cada solicitud de Débito Directo pasa por las siguientes etapas:

1. Manejo de la Creación de la Solicitud de Débito Directo

La solicitud llega desde un sistema externo de la facturación ( billing) y es verificada y guardada en la base de datos.

2. Solicitud de Extracción





aparezca aquí.

Varios días antes de la fecha de vencimiento de la factura (la cual fue definida como propiedad del sistema) la solicitud es extraída de la base de datos y es enviada al banco o cámara de compensación.

3. Retroalimentación del Débito Directo

La retroalimentación del Débito Directo es recibida desde el banco o cámara de compensación. En modo pesimista, el Proceso de Retroalimentación del Débito Directo postea el pago en la cuenta cuando se recibe la configuración, o marca la solicitud de Débito Directo como rechazada, si se recibe un ‘rechazar’.

5.3. Proceso de Creación de la Solicitud de Débito Directo


AR1DDREQCRE – Creación de la Solicitud de Débito Directo


El proceso de Creación de Débito Directo recibe un archivo desde una fuente de facturación (Billing)externa (tal como Facturación Amdocs) que contiene las solicitudes de Débito Directo y crea las solicitudes de Débito Directo recurrentes en la base de datos de AR (Cuentas por Cobrar).

El medio de Pago (Método de Pago) para el proceso de Débito Directo puede ser Débito Directo o Tarjeta de Crédito.




Si el proceso de Creación del Débito Directo se ejecuta como un daemon, el flujo del proceso es activado cuando hay disponible un nuevo archivo de input vía Auditoría y Control.





aparezca aquí.

Si el proceso de Creación del Débito Directo se ejecuta como un trabajo, maneja un solo archivo antes de terminar. Si no hay archivos disponibles, el proceso se termina. Si hay más de un archivo disponible, Creación del Débito Directo procesa un archivo.

5.3.5. InputsEl Proceso de Creación de la Solicitud de Débito Directo recibe los archivos de input provenientes de Amdocs Invoicing vía Auditoría y Control. El formato de los archivos del input se define en CNT - AR - Finance Institute -

IDD.

5.3.6. Outputs

Ninguna


Como parte de la ejecución de la Confirmación del Ciclo, el proceso de Solicitud de Débito Directo recibe los archivos provenientes de Amdocs Invoicing o de algún otro sistema de la facturación (Billing)con una lista de solicitudes de Débito Directo. Estas solicitudes son de los Acuerdos de Facturación (BA)(BAs) que son parte de la población del ciclo y tienen un método de pago de Débito Directo autorizado en el módulo de Administración del Cliente Amdocs. El propósito de esta interfaz del archivo es permitir que AR de Amdocs envíe estas solicitudes a los bancos o compañías de tarjetas de crédito para que realicen el débito a la cuenta bancaria o tarjeta de crédito del cliente.

Las solicitudes de Débito Directo iniciadas por Amdocs Invoicing son designadas con el valor del campo Tipo de Solicitud definido en R (recurrente).

Para cada solicitud, el proceso crea una Solicitud de Débito Directo con estado Pendiente en el sistema.

Puede recibirse una solicitud de Débito Directo de única vez proveniente de una fuente externa utilizando el OOB createDirectDebit API. Dichas





aparezca aquí.

solicitudes son identificadas por un campo Tipo de Solicitud con un valor de O (única vez).

La solicitud es registrada en el sistema desde el cual se hará la extracción hacia la institución financiera correspondiente, con base en la fecha de vencimiento de la factura y propiedad del sistema denominado No. of Days to Extract DD Request. Esta propiedad indica el número de días previos a la fecha de vencimiento de la factura cuando la solicitud deba ser enviada a la institución financiera. El sistema permite definir un valor para los bancos y un valor para compañías de tarjetas de crédito.

5.4. Proceso de Extracción del Débito Directo


AR1DDEXT – Extracción del Débito Directo


El Proceso de Extracción del Débito Directo extrae las solicitudes de Débito Directo desde la base de datos y crea los archivos para establecer la interfaz con los bancos o cámara de compensación. Analiza la tabla de Solicitudes de Débito Directo en busca de los registros a ser extraídos, de acuerdo con la fecha de vencimiento. Se llevan a cabo las verificaciones de la validez, a registro, con el fin de garantizar que el proceso se ejecute correctamente.


Este proceso se ejecuta como un trabajo.


El proceso de Extracción del Débito Directo es un trabajo diario que se ejecuta como parte del mapa operacional del EOD.

5.4.5. Inputs

Ninguno





aparezca aquí.

5.4.6. Outputs

El proceso genera archivos:

■ Archivos que contienen las solicitudes de Débito Directo deben ser enviados a los bancos.

■ Archivos que contienen las solicitudes de Débito Directo que deben ser enviadas a las compañías de tarjetas de crédito.


Este proceso incluye tres subprocesos principales:

1. Recupera todos los archivos con método de pago bancario, realiza los cálculos del monto de la solicitud con base en las configuraciones y actualiza la base de datos.

2. Recupera todos los registros con método de pago tarjeta de crédito, realiza los cálculos con base en las configuraciones del monto de la solicitud y actualiza la base de datos.

Ambos subprocesos actualizan el número de secuencia del archivo correspondiente a todos los registros que son procesados.

■ Recupera los registros recién actualizados (de conformidad con el número de secuencia del archivo) y crea dos archivos de extractos correspondientes a los bancos y compañías de tarjetas de crédito.

5.4.8. Cálculo del Monto de la Solicitud de Débito Directo

El monto de la solicitud de Débito Directo está configurado para utilizar el monto neto del Saldo de la Cuenta Financiera, y cada importe del impuesto será extraído por separado.

Dado que no hay una clara separación entre el importe de los impuestos restantes y el monto neto restante, los importes del impuesto se calcularan en forma proporcional.





aparezca aquí.

5.5. Proceso de Retroalimentación del Débito Directo


AR1DDFEDBCK – Retroalimentación del Débito Directo


Este proceso acepta un archivo de retroalimentación (proveniente del banco o compañía de tarjeta de crédito) que contiene el estado de cada solicitud enviada (Aceptada o Rechazada). El proceso ejecuta entonces las actividades necesarias de acuerdo con la respuesta.

Entre las actividades se incluyen:

1. Posteo de un pago (en el caso de respuestas confirmadas en un sistema Pesimista);

2. Anulación (Backout) de un pago creado por el Proceso de de Posteo del Pago de Débito Directo (en el caso de respuestas rechazadas en un sistema Optimista);

3. Reemisión de la solicitud de Débito Directo;

4. Cambio del método de pago del canal de pago.

El proceso es un daemon del entramado (framework) por ‘Batches’ de AR (Cuentas por Cobrar); una vez que llega un nuevo archivo de retroalimentación, el trabajo inicia el procesamiento del mismo; el archivo puede ser procesado en diversos hilos paralelos.







aparezca aquí.


Si el Proceso de Retroalimentación del Débito Directo se ejecuta como un daemon, el flujo del proceso es activado cuando, vía Auditoría y Control, esté disponible un archivo nuevo de input.

Si el Proceso de Retroalimentación del Débito Directo se ejecuta como trabajo, se procesa un archivo antes de terminar. Si no hay archivos disponibles, se termina el proceso. Si más de un archivo están disponibles, la Retroalimentación del Débito Directo procesa un archivo únicamente.

5.5.5. Inputs

El Proceso de Retroalimentación del Débito Directo recibe los archivos de input vía Auditoría y Control.

5.5.6. Outputs

Ninguno


El Proceso de Retroalimentación del Débito Directo que se ejecuta como daemon espera que lleguen los archivos de retroalimentación provenientes de los bancos o compañías de tarjetas de crédito. Cuando llega el archivo, el proceso realiza lo siguiente:

1. Si se ejecuta como daemon, revisa constantemente la Auditoría y Control en busca de nuevos archivos entrantes; si corre como trabajo por ‘Batches’, toma un archivo únicamente de la tabla de A&C.

2. Valida el archivo a nivel de convención de nomenclaturas y estructura del archivo; asimismo, valida que el monto en el registro trailer sea igual al monto total de las solicitudes. En caso de error en la validación, crea un archivo de error y lo marca como fallido para su procesamiento en las tablas de A&C.





aparezca aquí.

3. Si la validación del archivo es satisfactoria, procesa el registro y, verifica para cada archivo que las solicitudes de Débito Directo hayan sido confirmadas o rechazadas.

4. En el modo pesimista:

a. Si la solicitud es confirmada, crea el pago, actualiza el estado de la solicitud a Pagado y postea el pago.

b. Actualiza la Tabla de la Bitácora de Transacciones con la actividad del nuevo pago para fines de Libros de Diario (Journal).

c. Si la cuenta financiera está en Cobranza, publica las transacciones TRB para Cobranza correspondientes a las acciones requeridas adicionales.

d. Si la solicitud es rechazada, no crea el pago; actualiza el estado de la solicitud a Rechazada y guarda en la base de datos la razón del rechazo de la solicitud.

5. Marca las solicitudes rechazadas para la reemisión, cuando sea pertinente, con base en la razón del rechazo, dependiendo de la implementación.

6. Después de procesar el ‘Batch’ de registros, crea una nueva entrada en la tabla AR1_BATCH_CONTROL. Esto se utiliza para evitar el reprocesamiento de los registros en el archvio en caso de recuperación.

7. Si un ‘Batch’ de registrso no fue procesado de forma exitosa, crea un archivo de error y lo registra en Auditoría y Control.

8. Si todos los datos de los archivos fueron procesados de forma exitosa, marca los archivos como concluidos en Auditoría y Control. La creación de los archivos de error se incluye como procesamiento satisfactorio de los archivos, lo que quiere decir que los archivos de errores no significan marcar automáticamente, en Auditoría y Control, los archivos que han fallado.

9. Reemisiones – una opción de configuración que permite que el Controlador de Retroalimentación intente remitir una solicitud en un rechazo.





aparezca aquí.

a. Si el registro es rechazado y si el contador de rechazos no ha excedido el límite definido con base en la razón del rechazo, el parámetro de configuración permite una reemisión automática de la solicitud.

b. El Proceso de Retroalimentación del Débito Directo define el estado actual de la solicitud del Débito Directo como Re-emitida; la copia en una nueva solicitud con estado Pendiente y calcula la fecha de vencimiento de la solicitud por Fecha Lógica; la solicitud es extraída con base en su nueva fecha de vencimiento.

Incluso cuando el número de re-emisiones automáticas es limitado, el número de re-emisiones manuales no lo es. La solicitud de Débito Directo puede, de hecho, ser re-emitida manualmente.

5.6. Interfaces

5.6.1. Integración con CM

Cuando la actividad de Cambio del Método de Pago es realizada desde CC o DD por el de Efectivo en las AR (Cuentas por Cobrar), se publica una transacción en Administración de Clientes Amdocs.

Si tal cambio ocurre, y hay una solicitud pendiente de Débito Directo, en la implementación puede definirse si el sistema puede extraer o cancelar dichas solicitudes.

5.6.2. Integración con Cobranzas

Cuando se realizan actividades de Crear y Anular (backout) Pago en AR (Cuentas por Cobrar), se publica una transacción en Cobranza Amdocs.

5.6.3. Interfaz Externa

En el sistema de archivos de billing, se crean los archivos de solicitud de OOB, Débito Directo y los archivos de retroalimentación del Débito Directo son recibidos o se espera que sean recibidos.

Se asume que es requerido que la integración sea manejada por una capa de integración externa.





aparezca aquí.





6. APLICACIÓN DEL EFECTIVO



4.7.3.1. Gestión de Recaudos. Funcionalidad que se refiere a todas las actividades y tareas requeridas para realizar la Cobranza a los clientes por la utilización de los productos y servicios prestados por CNT E.P. Para este efecto deberá cumplir con los siguientes requerimientos:

6.3 – Saldo Anterior (Suma y sigue)

4.7.3.1.1. Cuentas por Cobrar (A/R). 6.3 – Saldo Anterior (Suma y sigue)

4.7.3.1.1.4.3. Recibir y aplicar pagos parciales (menor valor del total de la factura) sobre el total de la factura o sobre el saldo de una cuenta, teniendo en cuenta que dicho pago puede ser distribuido de diferentes maneras. Como mínimo debe poder aplicar:

6.3. Saldo Anterior (Suma y sigue)

4.7.3.1.1.4.3.1.

Proporcionalmente entre todos los cargos facturados. 6.3. Saldo Anterior (Suma y sigue)

4.7.3.1.1.4.3.4.

De acuerdo con una prioridad (parametrizada en la herramienta (por ejemplo: factura más antigua primero).


4.7.3.1.1.4.4. Procesar pagos dirigidos. Estos pagos, como mínimo, deben poder realizarse así:


4.7.3.1.1.4.4.1.

Para el total de una o varias facturas, bajo el esquema de facturación abierta.


4.7.3.5.3.7. Manejo saldos de facturación: Debe permitir que los saldos de las facturas se acumulen sobre el último generado (cerrado) o se mantengan en forma separada (abierto) por cada una de las facturas emitidas.

6. Aplicación del Efectivo

4.7.3.7.7.5.2. Cargos duplicados. 6. Aplicación del Efectivo

4.7.3.1.1.4.4.2.

Para los subtotales incluidos en la factura, tales como: producto, servicio, operador, tercero.

6.3 – Saldo Anterior (Suma y sigue)





aparezca aquí.

6.2. Supuestos


AR.AS.6.1 Con el fin de garantizar que los Cargos de Tarifas (fees) sean cubiertos primero, se definirá una regla de implementación de la Aplicación del Efectivo con el fin de cubrir la deuda abierta, de acuerdo con el Tipo de Grupo y luego por Fecha de Vencimiento.

En las reglas de Aplicación del Efectivo, los Cargos de Tarifas se definirán con prioridad alta.

La Aplicación del Efectivo se utiliza para aplicar los pagos a una cuenta; este proceso identifica la mejor forma de emplear el pago para cubrir las deudas de mayor criticidad. Se genera un enlace denominado enlace crédito-débito para cada grupo de cargos cubierto por el pago.

Existen dos métodos para asignar el crédito a las deudas abiertas:

■ Saldo Anterior (Suma y sigue): este método aplica el efectivo no específico a las facturas abiertas de una cuenta utilizando un algoritmo predefinido; por ejemplo, primero el de mayor antigüedad.

■ Ítem Abierto: este método puede ser utilizado de dos formas:

● Los fondos no designados son asignados a un rango (bucket) no aplicado de la cuenta, en el cual el efectivo reside hasta que un Representante de Servicio al Cliente lo asigne explícitamente a una factura.

● Después que la factura especificada ha sido pagada, el sobrepago se asigna, a otras facturas abiertas, como un Saldo Anterior (Suma y sigue).


El propósito del método Saldo Anterior (Suma y sigue) es aplicar los pagos a deudas abiertas y cerrar las facturas no pagadas de la entidad de la cuenta financiera. El método se efectúa de la forma siguiente:





aparezca aquí.

■ Se seleccionan todos los grupos de cargos abiertos y se ordenan con base en la prioridad, de la siguiente manera:● Número específico del bill de la facturación (número legal de la

factura);

● Prioridad de Grupo de Cargos definida en las tablas de políticas;

● Fecha de Vencimiento del Grupo de Cargos.

■ Los grupos de cargos son manejados, uno por uno, con base en la prioridad de estos.

■ El efectivo es aplicado a cada grupo de cargo hasta el monto remanente adeudado, el cual es el monto total cargado reducido por los pagos y créditos ya posteados en el grupo de cargos.

■ El estado de un grupo de cargos se cambia a Cerrado cuando ya se ha pagado la totalidad del grupo de cargos.

■ Cuando se han cerrado todos los grupos de cargos aplicables, todo efectivo no aplicado se guarda como un saldo de crédito.

■ Toda vez que una factura sea posteada en una cuenta con un saldo de crédito, los sobrepagos (pagos o créditos no aplicados) se aplican automáticamente a dicha factura.





7. ADMINISTRACIÓN DE CUENTAS7.1. Requerimientos Relacionados ID DEL BR Descripción del BR Abarcado por

AI #21/ 866 La nota de crédito deberá contener su propio número de secuencia y la referencia de la factura que la originó de acuerdo con las especificaciones fiscales del SRI

7.3.5 - Nota de Crédito

4.7.3.1. Gestión de Recaudos. Funcionalidad que se refiere a todas las actividades y tareas requeridas para realizar la Cobranza a los clientes por la utilización de los productos y servicios prestados por CNT E.P.. Para este efecto deberá cumplir con los siguientes requerimientos:

7.3 – Crédito

7.4 – Reembolso

7.5 - Disputa

4.7.3.1.1. Cuentas por Cobrar (A/R). 7.3 – Crédito

7.4 – Reembolso

7.5 - Disputa

4.7.3.1.1.7. Administración de reembolsos de fondos. 7.4 – Reembolso

4.7.3.1.1.8. Administración de ajustes y créditos. 7.3 – Crédito

4.7.3.1.1.8.1. Permitir manejar diversos tipos de ajustes de acuerdo con las normas y estrategias comerciales que defina la compañía. Generalmente los tipos de ajuste se pueden tipificar dependiendo de diversas variables. Como mínimo debe poder tipificar por:

7.3 – Crédito

4.7.3.1.1.8.1.1. Segmento de cliente. 7.3 – Crédito

4.7.3.1.1.8.1.2. Producto. 7.3 – Crédito

4.7.3.1.1.8.1.3. Servicio. 7.3 – Crédito

4.7.3.1.1.8.1.4. Concepto de facturación. 7.3 – Crédito

4.7.3.1.1.8.3. Contemplar como mínimo los siguientes tipos de ajustes: 7.3 – Crédito

4.7.3.1.1.8.3.1. Cargos por consumo: consumos propios, de terceros, etc. 7.3 – Crédito

4.7.3.1.1.8.3.2. Conceptos de facturación. 7.3 – Crédito

4.7.3.1.1.8.4. Permitir que los impuestos asociados con el cargo ajustado, sean calculados de manera automática.

7.3.3.3. Cálculo del Impuesto





aparezca aquí.


4.7.3.1.1.8.5. Cualquier cargo sobre el cual se realice un ajuste debe quedar plenamente identificado para evitar su doble aplicación.

7.3.1. Ciclo de Vida del Crédito

4.7.3.1.1.8.6. Permitir aplicar ajustes como mínimo de las siguientes formas: 7.3 – Crédito

4.7.3.1.1.8.6.1. Individuales: A un cargo en particular. 7.3 – Crédito

4.7.3.1.1.8.6.2. Resumidos: Al valor total de la factura o concepto que agrupe varios cargos.

7.3 – Crédito

4.7.3.1.1.8.7. Manejar un historial de ajustes del cliente (cada una de sus cuentas y cada una de las facturas emitidas), el cual debe ser actualizado cada vez que se apruebe una transacción de ajuste. Debe existir un historial detallado durante un período de tiempo definido por la CNT E.P.

7.3 – Crédito

4.7.3.1.1.8.8. Debe actualizar el saldo de la cuenta/cliente en línea, una vez aplicado el ajuste.

7.3 – Crédito

4.7.3.2. Gestión de reclamaciones, disputas y ajustes de facturación 7.5. Disputa

4.7.3.2.1. Funcionalidades referidas a la atención que se debe dar en el front a todas las inquietudes, reclamos y ajustes que realizan los Clientes con relación a la información presentada en la Factura, que por concepto de consumos de Servicios y Productos se les entrega. Para tal efecto, la solución ofertada debe:

7.5. Disputa

4.7.3.2.2. Consultas 7.5. Disputa

4.7.3.2.4. Ajustes. La solución ofertada debe: 7.5.2. Justificación de una Disputa

4.7.3.2.4.1. Aplicar Ajustes acordados según Reclamo o Disputa. 7.5.2. Justificación de una Disputa

4.7.3.2.4.2. Seguimiento de las políticas de Ajuste definidas. 7.3 – Crédito

4.7.3.6.3.8.8. Aplicación de condonaciones de cualquier valor (total, parcial, valor mínimo) sobre las deudas.

7.3 – Crédito





aparezca aquí.


4.7.3.6.3.8.9. Aplicación de condonación de sanciones por incumplimiento de acuerdos.

7.3 – Crédito

4.7.3.7.10. Incorporación de ajustes. La solución ofertada debe aplicar ajustes, a nivel de número de factura.

7.3 – Crédito

4.7.3.7.4.4.5. Descuentos por compensación. Se utiliza como un mecanismo de retribución hacia el cliente en los casos en que la compañía no cumpla con los niveles de calidad establecidos en la prestación de los servicios ofrecidos. Se requiere definir diversas escalas de descuentos por compensación, basados sobre criterios como los siguientes:

7.3 – Crédito

4.7.3.7.4.4.5.1. Por tipo de cliente (corporativo, masivo, etc.). 7.3 – Crédito

4.7.3.7.4.4.5.2. Por producto/servicio (internet, datos, larga distancia, móviles, etc.).

7.3 – Crédito

4.7.3.7.4.4.5.3. Por concepto de facturación. 7.3 – Crédito

7.2. Supuestos – N/A


El Módulo de Administración de Cuentas es responsable de las actividades financieras de AR que mantienen el saldo de la cuenta.

El saldo de la FA se mantiene de acuerdo con la moneda de la FA; la moneda de FA se define con la creación de la FA (se pueden definir varias monedas para cuentas diferentes).

Todas las actividades de la Administración de Cuentas son gestionadas a nivel de la FA.

Las transacciones de la Administración de Cuentas son manejadas vía las APIs de OOB que pueden ser invocadas por los sistemas externos (por ejemplo, el CRM).





aparezca aquí.

Se soportan las siguientes funcionalidades principales:

■ Crédito

■ Disputa

■ Amortización (no la utiliza CNT)

■ Asignación Manual

■ Creación del Cargo y Pago Inmediato

■ Actividades relacionados con el pago (referidas en las secciones de la solución Pagos):

● Reembolso

● Transferencia de Fondos

● Anulación (Back Out)

Los detalles de la actividad Financiera son guardados en la base de datos de AR Amdocs; estos detalles pueden ser empleados para fines de Libros de Diario (Journal).

En el caso de cuentas financieras en mora, todas las actividades de la Administración de Cuentas son publicadas para que se les tome en cuenta durante el Trámite de Cobranza.

Las consultas relevantes que contienen los detalles financieros de FA son ampliados en el AR de Amdocs.

7.3. Crédito

El crédito es una suma de dinero que es asignada o aplicada a las deudas de una cuenta con el fin de reducir el saldo de la cuenta. El crédito difiere del pago en que el dinero, por lo general, no proviene del cliente, sino de CSR; por ejemplo, como compensación de llamadas distorsionadas o corrección de cargos erróneos en respuesta ante el reclamo del cliente.

El crédito aplicado a la deuda de la FA puede actualizar de inmediato el saldo o después de la ejecución de un ciclo posterior. Se emite un enlace conocido como Enlace de Crédito y Débito entre la entidad de crédito y la entidad de





aparezca aquí.

débito que cubre. Todo procesamiento adicional, incluyendo la extracción, impresión y envío de la Nota de Crédito no es responsabilidad de la facturación.

Se pueden especificar varios tipos de créditos:

■ Crédito inmediato - crédito que activa de inmediato una entidad de crédito terminado.

■ Crédito con Giro – el crédito que no ha terminado.

■ Crédito Pendiente – crédito que afectará el saldo de la cuenta después de confirmado el ciclo de la FA.

La actividad de crédito puede ser aplicada en los siguientes niveles:

■ Crédito de Nivel de Cuenta: crédito que es aplicado a una cuenta en particular con el fin de corregir el saldo de la cuenta o como promociones generales, compensaciones, etc. Estos créditos son aplicados a las deudas de la cuenta abierta de conformidad con las reglas de Aplicación del Efectivo. No hay créditos sobre impuestos a nivel de cuenta.

■ Crédito a Nivel de Cargos: crédito que es designado a un cargo facturado específico, tal como un servicios, componente de equipo o error en el billing. Cada crédito a nivel de cargo es incorporado al BA (Acuerdo de Billing) del cargo acreditado. Los cálculos del impuesto se hacen de forma proporcional a los cargos versus los cuales fue originalmente aplicado el crédito.

■ Crédito a Nivel de Factura: crédito que es asignado a una factura específica para corregir el saldo de ésta. La funcionalidad de crédito a nivel de factura crea créditos proporcionales para todos los cargos relacionados con la factura acreditada. Los cálculos de los impuestos se realizan proporcionalmente a los cargos versus lo cuales fue aplicado el crédito originalmente.

No se soportan otros niveles de crédito.





aparezca aquí.

7.3.1. Ciclo de Vida del Crédito

AR (Cuentas por Cobrar) maneja el ciclo de vida completo del crédito, de la forma siguiente:

■ Mediante la Creación de Créditos

■ Mediante la Consulta de Créditos: para recuperar los detalles de la entidad de crédito para un ID de FA dado.

■ Mediante la Reversión de Créditos: para reversar el crédito creado en caso que se haya otorgado el crédito erróneamente.

Un crédito a nivel de cargo recién creado incrementa el Monto Restringido en el cargo acreditado para evitar la creación de los créditos/disputas, en el monto de resumen, superiores al monto del cargo.

Un crédito a nivel de factura recién creado incrementa el Monto Restringido en todos los cargos de la factura acreditada para evitar la creación de los créditos/disputas, en el monto de resumen, superiores al monto de los cargos relacionados con la factura.

Un crédito de nivel de cuenta recién creado no es incorporado a cargo o factura alguno y por ende, no incrementa Monto Restringido alguno.

7.3.2. Crédito a Nivel de Cuenta

AR (Cuentas por Cobrar), listo de fábrica, soporta los créditos a nivel de cuenta, los cuales son aplicados a una cuenta en particular con el fin de corregir el saldo de la misma o como promociones generales, descuentos, compensaciones, etc. En el caso de las FAs de Saldo Anterior (Suma y sigue), estos créditos son aplicados a deudas abiertas de una cuenta, de conformidad con las reglas de Aplicación del Efectivo. Para las cuentas FAs con ítem abierto, estos créditos deben ser asignados manualmente.

El componente de Amdocs Cuentas por Cobrar proporciona una API de OOB– createCredit(), el cual permite la creación de créditos de nivel de cuenta; esta API se puede invocar desde una UI o sistema externo.

Los créditos a nivel de cuenta son aquellos créditos que no están relacionados con algún cargo o factura en particular; se aplican en el nivel de cuenta.





aparezca aquí.

No hay ningún cálculo de impuestos para el crédito de nivel de cuenta de AR (Cuentas por Cobrar).

AR (Cuentas por Cobrar) soporta la creación de créditos pendientes a nivel de cuenta que, al ser billed, llegan desde Amdocs Invoicing como parte de los montos de la factura siguiente.

En el flujo de creación del pago en abonos, FE llamará la aplicación de AR para acreditar el monto neto del cargo por los bienes comprados. Se trata de un crédito de nivel de cuenta pendiente. Para más detalles sobre el flujo de creación del pago en abonos, refiérase al documento CNT - FS - Invoicing – HLD.

El Código del Cargo correspondiente al crédito a nivel de cuenta se determina vía la implementación (basado en el código de razón del crédito).

Cuando se aplica un crédito pendiente de nivel de factura, todos los cargos de la deuda (excluyendo los cargos por créditos) bajo la factura son acreditados y enviados

a facturación como parte de la interfaz de archivo de preparación del bill.

7.3.2.1. Validaciones

Las siguientes validaciones serán aplicadas; de no cumplirse, la condición de error se registra y se emite una excepción relevante y se presentará a la aplicación Caller:

■ Todos los parámetros y campos obligatorios deben ser asignados; por ejemplo, el ID de la Cuenta Financiera, ID del BA (Acuerdo de Billing) y Razón del Crédito.

■ Se verifica que el monto del crédito no sea negativo.

■ Si se proporcionan detalles de asignación manual, se valida el monto de la factura.

■ Se verifica que el valor de la opción del tipo de crédito sea válida; por ejemplo, auto, man, pending.

7.3.2.2. Flujo

El flujo del crédito a nivel de cuenta lleva a cabo lo siguiente:

■ El saldo de la cuenta financiera se reducirá por el monto del crédito.





aparezca aquí.

■ Si el crédito a nivel de cuenta es efectuado en una factura designada, el saldo de la factura elegida será reducido por el monto del crédito. En caso que el saldo de la factura actualizada fuera llevado a cero, la factura será marcada como Cerrada.

■ Se creará un nuevo registro en la entidad de Crédito del Cliente indicando el monto del crédito.

■ Se creará un nuevo Enlace de Crédito y Débito entre el crédito creado y los grupos de cargos cubiertos por este crédito.

■ La tabla de la Bitácora de Transacciones se actualizará con la actividad del nuevo crédito para fines los Libros de Diario (Journal).

■ Si la cuenta financiera está en Cobranza, se publicará una transacción TRB para Cobranza correspondiente a las acciones adicionales requeridas.

7.3.3. Cargos y Créditos a Nivel de Factura

El componente AR (Cuentas por Cobrar) proporciona un API de OOB – createChargeLevelCredit () y createInvoiceLevelCredit () que permite que una aplicación externa cree créditos a nivel de cargo y créditos a nivel de factura, respectivamente. Los créditos a nivel de cargo son créditos que están asignados a cargos billed en particular. Los créditos a nivel de Factura son créditos que se designan para una factura billed en particular.

Cuentas por Cobrar de Amdocs soporta la creación de créditos pendientes que, al ser billed, provienen de Facturación Amdocs, como parte de los montos de la factura siguiente.


Las siguientes validaciones serán aplicadas; de no cumplirse, la condición de error se registra y se emite una excepción relevante y se presentará a la aplicación Caller:

■ Todos los parámetros y campos obligatorios deben ser asignados; por ejemplo, el ID de la Cuenta Financiera, ID del BA (Acuerdo de Billing) y Razón del Crédito.





aparezca aquí.

■ Se verifica que el monto del crédito no sea negativo.

■ Se verifica que existe el cargo que será acreditado

■ Si se proporcionan detalles de asignación manual, se valida el monto de la factura.

■ Se verifica que el valor de la opción del tipo de crédito es uno de los valores válidos.

7.3.3.2. Flujo

El flujo del crédito a nivel de cuenta lleva a cabo lo siguiente:

■ El saldo de la cuenta financiera se reducirá por el monto del crédito.

■ Si el crédito a nivel de cuenta es efectuado en una factura designada, el saldo de la factura elegida será reducido por el monto del crédito. En caso que el saldo de la factura actualizada haya sido llevado a cero, la factura será marcada como Cerrada.

■ Se creará un nuevo registro en la entidad de Crédito del Cliente indicando el monto del crédito; en caso que el crédito fuera aplicado para más de un cargo, se crearán varias entradas.

■ Se creará un nuevo Enlace de Crédito y Débito entre el crédito creado y los grupos de cargos cubiertos por este crédito.

■ La tabla de la Bitácora de Transacciones se actualizará con la actividad del nuevo crédito para fines de Libros de Diario (Journal).

■ Si la cuenta financiera está en Cobranza, se publicará una transacción TRB para Cobranza, correspondiente a las acciones adicionales requeridas.

7.3.3.3. Cálculo del Impuesto

Las entidades de ítems fiscales son entidades subordinadas de la entidad de crédito del cliente, similar a la relación entre las entidades de ítem fiscal y las entidades de cargos.





aparezca aquí.

El cálculo de impuestos de crédito en AR (Cuentas por Cobrar) se realiza con base en la proporción del monto neto de los impuestos de cada cargo al cual se le otorgó el crédito.

El crédito a nivel de factura y cargo tiene elementos fiscales asociados; por lo tanto, el impuesto se calcula sobre los créditos a nivel de factura y de cargo, a diferencia del crédito a nivel de cuenta, el cual no tiene cargo por impuesto asociado.

La aplicación Caller proporciona el monto del crédito junto con un indicador que identifica si este monto excluye los impuestos.

■ Si el monto del crédito proporcionado está indicado sin los impuestos (Impuesto excluido), el crédito del impuesto se calcula con base en el porcentaje del cargo acreditado y agregado al monto del crédito.

■ Si el monto del crédito proporcionado está indicado con el impuesto (Impuesto incluido), la porción del impuesto se calcula con base en el porcentaje del impuesto del cargo que ha sido acreditado, y se deduce del monto del crédito otorgado.





aparezca aquí.

7.3.3.3.1. Ejemplo

Un monto de cargo neto por $20,00 y un monto de impuestos por $5,00 reciben un crédito de $5,00.

Antes del crédito:

ID del Cargo

Monto Original del cargo

Monto Original del Impuesto

Monto de Restricción

Monto de Restricción del Impuesto

00001 20,00 5,00 0,00 0.00

Después del crédito, a nivel del cargo:

Monto del crédito incluye impuesto

ID del Cargo

Monto Original del Cargo

Monto de Restricción

Monto de Restricción del Impuesto

Monto neto del crédito

Monto del Impuesto del crédito

Monto total del crédito

Sí 00001 20 4 1 4.00 1.00 5.00

N 00001 20.00 5.00 1.00 5.00 1.25 6.25

7.3.4. Reversión del Crédito

AR (Cuentas por Cobrar) permite que CSR reverse los créditos creados en el sistema. Esta actividad reversa tanto los créditos originales como los impuestos relacionados con los créditos originales. Asimismo, desasigna los grupos de cargos a los cuales se aplicaron el crédito original. Las reversiones de créditos son aplicables a todos los niveles de crédito: a nivel de factura, nivel de cuenta o nivel del cargo, pendiente e inmediato.

Si un crédito Pendiente es reversado (antes que se haya facturado el crédito), no aparecerán en factura la actividad del crédito ni la reversión.

■ El componente AR (Cuentas por Cobrar) proporciona un API reverseCredit () API de OOB que permite la reversión de los créditos a desde aplicaciones externas.





aparezca aquí.

■ Este API permite la reversión del crédito e ítems fiscales relacionados a nivel de cuenta, nivel de cargo o nivel de factura.

■ La actividad Reversión del Crédito de AR (Cuentas por Cobrar) desasigna el monto del crédito para los grupos de cargos que fueron cubiertos por el crédito originalmente.


Se aplicarán las validaciones siguientes; si las validaciones no se satisfacen, la condición de error es registrada y se emitirá una excepción relevante para la aplicación caller:

■ Todos los parámetros y campos obligatorios deben ser asignados; por ejemplo, cargo, account_id, reversalReason, monto, taxAmount

■ Verificar que el monto no es negativo.

■ Verificar que el taxAmount no es negativo.

■ Verificar que el crédito a ser reversado existe en la base de datos.

■ Verificar que account_id es válido y no ha sido amortizada.

■ Verificar que la razón de la reversión es válida y existe en la tabla de referencia de AR.

7.3.4.2. Flujo

La Reversión del Crédito deriva en lo siguiente:

■ El saldo de la cuenta se incrementará en relación con el monto de la Reversión del Crédito.

■ El saldo de la factura se incrementará en relación con el monto del crédito.

■ Si el crédito creado abre el débito de la factura, el estado de la factura será actualizado por Abierta.

■ El crédito será reversado en la entidad de crédito del cliente.

■ Los enlaces crédito-débito serán desvinculados.





aparezca aquí.

■ La tabla de la Bitácora de Transacciones será actualizada con la actividad de la nueva Reversión del Crédito, para fines de Libros de Diario (Journal).

■ Si la cuenta financiera está en cobro, se publicará la transacción TRB para Cobranza correspondiente a las acciones adicionales requeridas.

7.3.5. Nota de Crédito

AR (Cuentas por Cobrar) soporta la creación de los documentos Nota de Crédito para los créditos inmediatos a nivel de cargo y nivel de factura.

La decisión de si emitir una Nota de Crédito (CN) se basa en CREDIT_REASON.

AR envía la información del crédito al Diseñador de Documentos Amdocs al Final del Día (EOD).

El ID de la Nota de Crédito es generado por AR al EOD y adjunta a la entidad de crédito en la base de datos relacionada.

7.3.6. Flujo de Creación de la Nota de Crédito

■ Un crédito a nivel de factura/cargo es creado en AR vía el front-end del sistema y se genera automáticamente un crédito de pago temprano.

■ El proceso al EOD recupera todos los créditos creados para una factura específica de cierto día en que aún no ha sido extraídos y son también elegibles para la generación de CN (con base en la razón de crédito).

■ Para cada uno de dichos grupos de créditos, el proceso calcula una ID de Nota de Crédito. Si el proceso EOD no corre en cierto día, será posible que para ciertas facturas acreditadas, se calcule más de un ID de Nota de Crédito, una vez que el proceso haya sido ejecutado.

■ Al EOD, el ID de la Nota de Crédito que se generó es capturado en la entidad de Factura de Crédito relacionada; si una Factura de Débito en particular fue acreditada varias veces el mismo día, todas las Facturas de Crédito creadas tendrán el mismo ID de Nota de Crédito. (BILLING_INVOICE_NUMBER en la tabla AR1_INVOICE)





aparezca aquí.

■ Este proceso al EOD no manejará los Créditos que fueron reversados.

■ El proceso EOD extraerá la información de las Notas de Crédito para un archivo que será procesado por el Diseñador de Documentos Amdocs con el fin de crear el diseño de la Nota de Crédito.

■ La tabla AR1_CONTROL tendrá la información relativa al último registro procesado.

7.3.7. Información de la Nota de Crédito enviada al Diseñador de Documentos Amdocs

El proceso EOD, que es responsable de crear el archivo del extracto de las Notas de Crédito hacia el Diseñador de Documentos Amdocs, extraerá la siguiente información para cada Nota de Crédito:

■ Información a Nivel de Nota de Crédito:

● ID de la Cuenta

● Detalles de la Cuenta (Nombre, Dirección)

● ID de la Factura Acreditada (BILLING_INVOICE_NUMBER en la tabla AR1_INVOICE de la factura original)

● ID de la Nota de Crédito (BILLING_INVOICE_NUMBER en la tabla AR1_INVOICE de la Nota de Crédito creada).

● Nota de Crédito - Número de Confirmación de IRS (Parámetro de Referencia)

● Monto Bruto del Crédito Total (neto + impuesto)

● Monto Total del Crédito Fiscal

● Fecha del Crédito

● Código de la Plantilla CN (parámetro de referencia en AR1_Policy)

■ Información de nivel de la Actividad de Crédito (lista de todos los Créditos Inmediatos en el mismo día correspondientes a una Factura de Débito en particular):

● Monto del Crédito (neto + impuesto)





aparezca aquí.

● Monto del Crédito Fiscal

● Razón del Crédito

● Descripción de la Razón del Crédito

Después de haberse extraído la Nota de Crédito hacia el Diseñador de Documentos Amdocs, el proceso marca el ID de la Nota de Crédito ID en las Facturas de Crédito relacionadas.

7.3.8. Secuencia de ID de la Nota de Crédito

■ La Aplicación AR mantiene dos secuencias de contadores en la base de datos; una para la Nota de Crédito y otra para la Nota de Débito. Estos contadores permiten mantener la secuencia consecutiva de CN y DN.

■ La secuencia de CN inicia con el valor 001000000001, avanza hacia 001000000002 y así sucesivamente. Al llegar a 001999999999, el número siguiente será 002000000001 y así sucesivamente.

■ Cada vez que una secuencia de CN se está generando, el ultimo ID de CN generado es recuperado desde la DB y avanza en 1. El nuevo valor es conservado en la DB.

7.3.9. Número de Autorización de SRI de la CN

■ El Número de Autorización de SRI de la CN está siendo asignado a CNT vía el Instituto de SRI para cierto periodo. Este número debe estar impreso en la CN junto con la fecha efectiva de SRI y el ID de la Nota de Crédito legal.

■ Ejemplo:

■ El Número de Autorización SRI de la CN y Fecha Efectiva son parámetros a nivel de sistema que se conservan en la tabla de referencia AR1_Policy.





aparezca aquí.

■ Habrá un valor para estos dos parámetros en cierto momento (no se conserva el histórico). Cuando se produce una Nota de Crédito, el Número de Autorización SRI de la CN y Fecha Efectiva de SRI de la CN serán tomados de la tabla AR1_Policy.

■ Para la Nota de Crédito y Nota de Débito se están usando valores separados.

7.3.10. Formato del ID de la Nota de Crédito

■ Con el fin de conservar la unicidad en el sistema para los IDs de las Notas de Crédito y Notas de Débito, se adjunta un prefijo a las secuencias calculadas.

■ El formato de la CN es: CN-001-001-999999998. Este es el formato en que el ID de la Nota de Crédito es enviado al Diseñador de Documentos Amdocs y también remitido por la API de la Lista de Crédito.

7.3.11. searchCreditNotes

■ El API Búsqueda de Notas de Crédito busca las Notas de Crédito correspondientes a una cuenta dada. Este API presenta los IDs de la Nota de Crédito (BILLING_INVOICE_NUMBER en la tabla AR1_INVOICE).

■ En AR, cuando se crea un crédito inmediato, siempre se crea una Entidad de la Factura para éste (entrada en AR1_INVOICE con tipo Nota de Crédito=CN).

■ Dado que no se imprimen todas las facturas de Nota de Crédito, no todas las entradas en la tabla AR1_INVOICE tendrán el ID de la Nota de Crédito legal. Aquellas facturas de Nota de Crédito que no se imprimen tendrán una secuencia de aplicación interna de AR como ID de la Nota de Crédito ID.

■ El API de Búsqueda de Nota de Crédito recupera todos los tipos de Facturas de Nota de Crédito; esta lista puede incluir registros con ID Legal así como registros con un ID interno.





aparezca aquí.

■ El front end del sistema podrá recuperar del Diseñador de Documentos Amdocs el archivo de pdf de la Nota de Crédito (usando el API del Diseñador de Documentos Amdocs) al enviarle al Diseñador de Documentos Amdocs el ID de la Nota de Crédito correspondiente.

7.4. Reembolso

La actividad de reembolso se utiliza para devolver dinero al cliente y eliminarlo del sistema.

AR (Cuentas por Cobrar) soporta dos clases de actividades de reembolso:

■ Reembolso del Pago – esta clase de reembolso se usa cuando un pago fue enviado por error al proveedor del servicio y el monto del pago debe ser devuelto al cliente. Como tal, el pago debe ser devuelto usualmente por completo (puede ser controlado por la aplicación). Esta actividad es considerada una actividad del pago y debe activarse desde la UI o un sistema externo.

■ Reembolso de Sobrepagos – este tipo de reembolso se refiere a los montos no aplicados que no son asignados para una deuda. Dichas sumas pueden estar relacionadas con los pagos o créditos. Este reembolso puede ser activado de la forma siguiente:

● De forma manual desde una UI o un sistema externo.

● De forma automática, con base en la configuración de la aplicación por medio del proceso de recomendación del reembolso.

Los fondos pueden ser remitidos al cliente manualmente, vía CSR: en este caso, CSR entrega el monto del reembolso manualmente al cliente y CSR registra la actividad del reembolso en el sistema de facturación.

■ Un reembolso puede ser reversado vía la API de OOB, invocada a través de la UI o sistema externo.





aparezca aquí.

7.4.1. Reembolso del Pago

AR (Cuentas por Cobrar) proporciona una API para reembolsar los pagos vía UI o sistema externo.

Las siguientes validaciones son aplicadas; de no ser cumplidas, la condición de error se registra y se emite una excepción relevante y es presentada a la aplicación caller:

■ Todos los parámetros obligatorios y campos deben ser asignados (por ejemplo, la razón del reembolso, monto del reembolso y método del reembolso) y son validados versus los datos de referencia.

■ La cuenta no puede ser cerrada, amortizada o transferida a una Cuenta de Control de Excepciones.

■ El monto del reembolso debe ser menor o igual al monto del pago.

■ El monto a reembolsar debe ser menor o igual al monto máximo correspondiente a un reembolso; este monto, definido por la política del sistema, se mantiene en MAXIMUM_DEFINED_AMOUNT_OVERPAYMENT en la tabla de referencia de Recomendaciones de Reembolso.

■ El monto a reembolsar debe ser mayor o igual al monto mínimo correspondiente a un reembolso; este monto, definido por la política del negocio, se mantiene en MINIMUM_DEFINED_AMOUNT_OVERPAYMENT.

■ Con el fin de tener la oportunidad de crear un reembolso en la misma fecha en que un pago fue realizado, REFUND_ISSUE_PARAMETER debe estar definido en cero. Este parámetro define los días de intervalo permitidos entre la fecha de depósito del pago y cuando la actividad de reembolso sea cero.

■ Si el valor de PARTIAL_REFUND_PRFN de la tabla de Políticas es PARTIAL, entonces se permite tanto el reembolso parcial como total. Si

el valor de PARTIAL_REFUND_PRFN de la tabla de Políticas es FULL, solo se permite el reembolso total. Este parámetro es un parámetro a nivel de sistema y debe ser establecido como PARTIAL por defecto para permitir el Reembolso del Pago parcial.





aparezca aquí.

■ El pago a ser reembolsado no debe haber sido anulado o transferido a otra cuenta.

La API de Reembolso del Pago crea una solicitud de reembolso correspondiente a un pago específico.

7.4.1.1. Flujo

Las acciones realizadas por la API de Reembolso del Pago son las siguientes:

■ Los parámetros proporcionados son validados con el fin de garantizar que existe la cuenta financiera y no ha sido amortizada y que el pago no ha sido anulado aún.

■ Una nueva solicitud de reembolso es creada para el reembolso.

■ El pago que es reembolsado se actualiza para evidenciar que fue reembolsado.

■ Si se procesa una versión de un pago parcial, se llama a una utilidad general para clasificar los enlaces crédito-débito del pago, de acuerdo con la secuencia en que se supone que deben ser desvinculados (con base en el nivel de destitución del grupo de cargos).

■ Se genera una nueva actividad del pago con un código de actividad de reembolso en la tabla de Actividades de Pago. Esta entrada es indicada por la entrada del pago.

■ Ahora, queda abierto el pago reembolsado que cubrió la deuda; si existen algunos créditos no aplicados, entonces se utiliza la Aplicación del Efectivo para cubrir las deudas recién abiertas con el monto no aplicado en la cuenta, dependiendo del tipo de cuenta y las reglas de Aplicación del Efectivo.

■ La tabla de la Bitácora de Transacciones es actualizada con la nueva actividad de Reembolso para fines de los Libros de Diario (Journal).

■ Si la cuenta financiera está en Cobranza, se publica una transacción TRB para Cobranza correspondiente a las acciones adicionales requeridas.





aparezca aquí.

7.4.2. Reversión del Reembolso del Pago

Un Reembolso del Pago puede ser reversado por el representante de servicio al cliente.

AR de Amdocs proporciona una API que permite la Reversión del Reembolso del Pago vía AR En Línea u otros sistemas externos.

A continuación se indican los pasos para el procedimiento de Reversión del Reembolso del Pago:

■ Validar la Reversión del Reembolso:

● Verificar que el Reembolso se encuentra en un estado que permite la reversión (los estados permitidos son configurables)

● Verificar que el reembolso no ha sido reversado previamente.

● Validar la razón de la reversión versus las tablas de referencia.

■ Actualizar el estado del reembolso por Reversado.

■ Reducir el saldo de la cuenta e incrementar el monto del pago con la suma reversada.

■ Cubrir las deudas abiertas con los montos no aplicados, de haberlos.

■ Actualizar la tabla de la Bitácora de Transacciones con la nueva actividad de Reversión del Reembolso para fines de Libros de Diario (Journal).

■ Si la cuenta financiera está en Cobranza, se publica una transacción TRB para Cobranza correspondiente a las acciones requeridas adicionales.

7.4.3. Reembolso de Sobrepagos

Cuentas por Cobrar de Amdocs proporciona una API que permite los reembolsos de sobrepagos a ser efectuados por CSR en línea desde el AR En Línea Amdocs.

Las siguientes validaciones son aplicadas; de no cumplirse, la condición de error es registrada y se emite una excepción relevante y es presentada a la aplicación caller:





aparezca aquí.

■ La cuenta no puede ser cerrada, amortizada o transferida a una Cuenta de Control de Excepciones.

■ El monto del reembolso no puede ser negativo.

■ La cuenta debe tener un estado de sobrepago; AR_Balance es inferior a cero.

■ El monto del fondo debe ser menor o igual al saldo de la cuenta.

■ El monto del reembolso debe cumplir las siguientes condiciones:

● EL monto del reembolso debe ser menor o igual al monto máximo para un reembolso. Este monto se define en la política del negocio MAXIMUM_DEFINED_AMOUNT_OVERPAYMENT.

● El monto del reembolso debe ser mayor o igual que el monto mínimo para un reembolso. Este monto se define en la política del negocio en MINIMUM_DEFINED_AMOUNT_OVERPAYMENT.

■ Después de verificarse todas las validaciones, se lleva a cabo la actividad de Reembolso del Sobrepago.

■ El Reembolso del Sobrepago se realiza a nivel de cuenta.

■ El Reembolso del Sobrepago puede ser creado con el monto del crédito total de la cuenta (monto de AR_Balance) o por el monto parcial del saldo de la cuenta.

7.4.3.1. Flujo

Las acciones llevadas a cabo por la API de Reembolso del Sobrepago son las siguientes:

■ Se validan los detalles de la solicitud de reembolso provenientes de la UI externa.

■ Se genera una solicitud de reembolso y la razón del reembolso debe aprovisionarse; la razón del reembolso se valida versus una lista predefinida de razones, que se definen en la tabla de referencia de Razón del Reembolso.





aparezca aquí.

■ Se genera una factura ficticia con un grupo de cargos asociados que se vincularán con el monto del sobrepago.

■ Todos los créditos que son parte del monto del sobrepago son enviados al Controlador de Créditos y son designados a la factura ficticia, uno por uno. El Controlador de Créditos llama la Aplicación del Efectivo para enlazar los créditos completos o parciales con el grupo de cargos.

■ Actualiza la tabla de la Bitácora de Transacciones con la nueva actividad de Reembolso del Sobrepago para fines de los Libros de Diario (Journal)

■ Si la cuenta financiera está en Cobranza, se publica una transacción TRB para Cobranza correspondiente a las acciones requeridas adicionales.

7.4.4. Reversión del Reembolso del Sobrepago

Dependiendo del estado de la solicitud de reembolso y método del reembolso, el reembolso puede ser reversado por el representante de servicio al cliente.

De estar permitido, el Reembolso del Sobrepago es reversado adjuntando un crédito técnico al grupo de Cargos del Reembolso.

AR Amdocs proporciona una API que permite la Reversión del Reembolso del Sobrepago vía AR En Línea u otro sistema externo.

7.4.4.1. Flujo

Los pasos para la Reversión del Reembolso son:

■ Se valida la Reversión del Reembolso.

■ Se comprueba la razón de la reversión; el sistema verifica que exista la razón en la tabla de referencia Razones de Reembolso.

■ El estado de la solicitud de reembolso se define como Reversado.

■ El saldo de la cuenta se disminuye con el monto de la reversión:

● Para la reversión del Reembolso de un Sobrepago, se crea un crédito técnico por el monto de la solicitud de reembolso y el crédito se vincula a una factura ficticia para el reembolso.





aparezca aquí.

● Para la reversión del Reembolso del Pago, se crea una nueva actividad de pago que incrementa el monto del pago con el monto de la reversión.

■ La Aplicación del Efectivo se emplea para cubrir las deudas abiertas con el monto no aplicado.

7.4.5. Interfaces Externas

7.4.5.1. Interfaz con el Sistema de A/P

Al crear una solicitud de reembolso con método de reembolso de A/P, la solicitud se extrae al sistema A/P (ERP) como una notificación para enviar un cheque o efectivo al cliente, con base en los detalles registrados en el registro de solicitudes de reembolso.

Esta interfaz, lista de fábrica, con el sistema A/P consta de un archivo que contiene los detalles requeridos de las solicitudes de reembolso.

7.5. Disputa

La actividad Disputa proporciona al proveedor del servicio la habilidad para registrar los reclamos del cliente y posponer la resolución de los mismos en una etapa posterior. El CSR puede marcar algunas de las deudas del cliente como en disputa y verificar que dichos ítems en disputa no son parte de la deuda calculada para el trámite de cobranza.

Una disputa puede ser aplicada en los niveles siguientes:

■ Disputa a Nivel de Factura: disputa sobre una factura específica o parte de la misma.

■ Disputa a nivel de Cargos: disputa sobre un cargo específico o parte del mismo.

Dentro de las actividades de disputa soportadas se incluyen:

■ Creación de una disputa

■ Justificación de una disputa





aparezca aquí.

■ Rechazo de una disputa

El Configurador de AR (Cuentas por Cobrar) se utiliza para definir las propiedades de la Disputa; las propiedades de la disputa se almacenan en la tabla de Razones de Crédito de AR (Cuentas por Cobrar).

7.5.1. Creación de una Disputa

Se puede crear una disputa vía la API de Creación de Disputas de una cuenta financiera a nivel de cargo, a nivel de factura o a nivel de cuenta.

7.5.1.1. Flujo

Esta API crea la disputa para una cuenta; si el método de llamada es válido, se crean una disputa y Nota de Crédito no finalizada asociada, así como un crédito al cliente. Se remite el ID de la disputa creada.

El nivel de designación de la disputa será uno de los siguientes valores válidos:

■ INV – Factura

■ DEB – Grupo de cargos

Cuando el nivel de designación es Factura, el campo contiene el ID de la factura; cuando el nivel es Grupo de Cargos, el campo contiene el ID del débito.

La fecha de resolución esperada se calcula al tomar la fecha lógica y agregarle el número de días especificado en una propiedad en la tabla de Propiedades.

Ejemplo:

■ Número de días en la tabla Propiedades para calcular la fecha de resolución esperada = 3

■ Fecha de Vencimiento de la Factura/Factura: 15-abril-2012

■ La Fecha de Resolución Esperada es: 18-abril-2012.





aparezca aquí.

7.5.2. Justificación de una Disputa

La API de Justificación de una Disputa se utiliza para justificar una disputa abierta pera un monto de la disputa especificada.

7.5.2.1. Flujo

Esta API se emplea para justificar el monto especificado de una disputa del usuario. Si la llamada del método es válida, el estado de la disputa es actualizado a J (Justificado), y el cliente es acreditado con el monto justificado. También se crea la solicitud de servicio de comunicación del cliente. Para las disputas totalmente justificadas, donde el monto iguala el monto de la disputa abierta, se finaliza la Nota de Crédito existente no finalizada. En caso de disputas parcialmente justificadas, donde el monto es inferior al monto de la disputa abierta, la Nota de Crédito no finalizada original es reversada y se crea una nueva Nota de Crédito finalizada por el monto justificado.

7.5.3. Rechazo de una Disputa

El API de Rechazo de una Disputa se utiliza para rechazar el monto completo de una disputa.

7.5.3.1. Flujo

Esta API se utiliza para rechazar una disputa abierta correspondiente a un ID de disputa externa especificada, de modo que se rechaza el monto completo de la disputa. Como alternativa, el ID de la disputa puede emplearse para especificar la diputa a rechazar. La razón del crédito es especificada para rechazar la Nota de Crédito relacionada con la disputa. Si la llamada del método es válida, el estado de la disputa es actualizado a R (Rechazado).

7.6. Amortización (no se utiliza en CNT)

La función Amortización actualiza la cuenta para reflejar la cancelación del saldo de la cuenta.

La función realiza las siguientes actividades:





aparezca aquí.

1. Verifica el estado de la cuenta; un parámetro configurable especifica los estados de la cuenta para los cuales se permite la amortización. Los estados listos de fábrica, por defecto, son Abierto y Cancelado, lo cual significa que solo las cuentas abiertas y canceladas pueden ser amortizadas.

2. Valida el monto no aplicado de la cuenta; si la cuenta tiene un monto pendiente no aplicado, se prueba el parámetro de configuración para determinar el comportamiento requerido.

Puede ser uno de los siguientes:

a. Emisión de una excepción que indique que todos los montos no aplicados deben aplicarse, de forma manual, antes de presentar una solicitud de amortización. En caso de una cuenta de Saldo Anterior (Suma y sigue), el monto no aplicado es aplicado utilizando las reglas de Saldo Anterior (Suma y sigue). En caso de la cuenta de Ítems Abiertos, se muestra un mensaje de error que notifica al Representante de Servicio al Cliente acerca del monto no aplicado que debe ser re-aplicado manualmente previo a la actividad de amortización.

b. Mediante el bloqueo de la actividad de amortización.

3. Verifica si la cuenta tiene alguna disputa abierta; si la cuenta tiene una disputa abierta, el parámetro de configuración es probado para determinar el comportamiento requerido. Este puede ser uno de los siguientes:

a. Cancelación de la disputa: la disputa se cancela automáticamente como parte de la actividad de amortización.

b. Bloqueo de la actividad de amortización y emisión de una excepción. Esto significa que el usuario debe cancelar de forma manual la disputa o bien justificarla antes de llevar a cabo la amortización.

4. Crear un nuevo registro de amortización para registrar la actividad de amortización.

5. Generación de una entrada en la Bitácora de Transacciones de la amortización para fines de los Libros de Diario (Journal).





aparezca aquí.

6. Para cada factura abierta de la cuenta genera un crédito a nivel de factura. El crédito a nivel de factura es creado sobre el monto de la deuda abierta de la factual y contiene los montos netos y fiscales relacionados.

7. Define el estado de la cuenta en Amortizada y registra el código de razón con la razón apropiada de amortización.

7.6.1. Creación de la Amortización

El componente AR (Cuentas por Cobrar) proporcionará una API que permite la realización de las amortizaciones desde un sistema externo.

7.6.1.1. Flujo

La API de Amortización lleva a cabo las operaciones siguientes:

Cuando la actividad de amortización es efectuada en una cuenta, las actividades siguientes se llevarán a cabo:

1. Se definirá el indicador de Amortización en la tabla AR1_ACCOUNT para que sea Y, lo que significa que la Cuenta está en estado de Amortización.

2. Los créditos de amortización técnica serán aplicados a la deuda abierta de la cuenta e impuestos relacionados y la información se almacenará en las tablas AR1_CUSTOMER_CREDIT y AR1_TAX_ITEM.

3. El monto e impuestos amortizados serán calculados de conformidad con las facturas abiertas y se almacenarán como créditos en la tabla AR1_CUSTOMER_CREDIT que contiene la información relevante del ingreso. Esto constituirá la base del informe del LM correspondiente a la actividad de Amortización.

4. La información pertinente a los impuestos relacionados con las deudas que están siendo amortizadas se guardará, de conformidad, en la tabla AR1_TAX_ITEM y formará también la base del informe de LM correspondiente a la actividad de amortización.





aparezca aquí.

5. El saldo de AR (Cuentas por Cobrar) no se verá afectado por la actividad de Amortización.

Las actividades financieras (Crédito, Cargo, Pago, Anulación y Transferencia de Fondos) relacionadas con una cuenta de amortización pueden ser reversadas cuando sea necesario.

7.6.2. Reversión de la Amortización

Se puede reversar una operación de amortización; por ejemplo, en caso de una cuenta que fue amortizada por error o si una cuenta que fue amortizada envía un pago. Si la cuenta que ha sido amortizada es activada de nuevo, se reversa la operación de amortización descrita anteriormente:

1. Se marca la entrada de la amortización como Reversada.

2. Una entrada de Reversión de la Amortización en la tabla de la Bitácora de Transacciones se genera para fines de los Libros de Diario (Journal).

3. Todos los créditos que fueron generados por la amortización son reversados.

4. El saldo y estado de la cuenta son restaurados.

7.6.2.1. Flujo

Cuando la actividad de Reversión de la Amortización se lleva a cabo en una cuenta, las siguientes actividades serán realizadas:

1. El indicador de Amortización en la tabla AR1_ACCOUNT se definirá en N, lo que indica que es una cuenta Regular.

2. Los créditos de Reversión de la Amortización serán aplicados a la deuda abierta de la cuenta y los impuestos relacionados y la información se almacenarán en las tablas AR1_CUSTOMER_CREDIT y AR1_TAX_ITEM. Los créditos se configurarán para que no tengan efecto alguno sobre el saldo de la cuenta. Los créditos también serán configurados para que no tengan efecto sobre la restricción de débitos dado que los Cargos y Créditos a Nivel de Factura se permitirán únicamente para las cuentas amortizadas.





aparezca aquí.

3. El monto de la amortización e impuestos será calculado de acuerdo con las facturas abiertas y se almacenarán como créditos en la tabla AR1_CUSTOMER_CREDIT que contiene la información relevante del ingreso. Esto será la base del informe de LM de la actividad de amortización.

4. La información relativa a los impuestos pertinentes a las deudas que están siendo amortizadas se guardarán en la tabla AR1_TAX_ITEM, de conformidad y también constituirán la base del informe de LM correspondiente a la actividad de amortización.

5. El saldo AR (Cuentas por Cobrar) no se afectará con la actividad de reversión de la amortización.

7.6.3. Ejemplo de Amortización y Reversión de la Amortización

Asumamos que una cuenta tiene la siguiente deuda abierta:

Cargo Monto netoMonto del Impuesto

A 130 13B 50 5

Saldo total de la cuenta: $198,00

Asumamos que la cuenta fue amortizada; en este caso, se crearán dos créditos de Amortización (WO), de conformidad:

CréditoRelacionado con el cargo Monto neto Monto del Impuesto

AA A 130,0 13,00

BB B 50,00 5,0

Los créditos no cambiará el saldo de la cuenta, el cual sigue siendo $198,00.





aparezca aquí.

La amortización se reflejará en Libros como débito a la cuenta lógica WO por $180,00 EE.UU. (suma del monto neto) y la cuenta lógica TAX-WO por $18,00 EE.UU. (suma del monto del impuesto).

Asumamos que la cuenta paga $100,00 EE.UU. y el dinero es aplicado por igual a ambos cargos; las deudas abiertas de la cuenta serán entonces:

Cargo Monto Neto Monto del Impuesto

A 84,5 8,5

B 4,5 0,5

El saldo de la cuenta en dicho caso será $98 EE.UU.

Asumamos ahora que se está reversando la amortización de la cuenta; con el fin de reportar la reversión en el libro mayor, se crearán dos WO correspondientes a la deuda abierta arriba indicada:

Crédito Relacionado con el cargo Monto NetoMonto del Impuesto

AA A 84,5 8,5

BB B 4,5 0,5

El saldo de la cuenta seguirá siendo $98,00 EE.UU.

La Reversión de la Amortización será registrada en libros como acreditación a la cuenta lógica de WO por $89,00 EE.UU. (suma del monto neto), y acreditación al a cuenta lógica TAX-WO por $ 9,00 EE.UU. (suma del monto del impuesto).


ID Descripción Estado



8. ESTADOS FINANCIEROS

8.1. Requerimientos Relacionados – N/A




A menudo, es necesario ver todas las actividades financieras, tales como Factura, Pago o Anulación de una cuenta correspondientes a un periodo. AR (Cuentas por Cobrar), listo de fábrica, soporta una API que proporciona estos detalles en formato de página definida por el usuario. Este capítulo describe la API de Visualización de Estados de las AR (Cuentas por Cobrar), que se emplea para ver las actividades financieras de la cuenta.

8.3. Visualización de los Estados Financieros

AR (Cuentas por Cobrar) proporciona una API de OOB para ver las actividades financieras de una cuenta correspondientes a un periodo especificado por el usuario. Los valores válidos de las actividades financieras son:

■ INV – Factura

■ PYMTD – Pago

■ BCK – Anulación

■ FTF – Transferencia de Fondos desde

■ FTT – Transferencia de Fondos hacia

■ RFND – Reembolso

■ RFNDR – Reversión del Reembolso





aparezca aquí.

■ CREDIT – Crédito

■ CREDITR – Reversión del Crédito

■ WO – Amortización

■ WOR – Reversión de la Amortización

El usuario debe aprovisionar un ID de cuenta válido y el periodo para el cual son requeridas las actividades financieras como input.

API proporciona las actividades financieras de la cuenta en formato de página especificado por el usuario. El usuario define el tamaño de la página y la cantidad de detalles en el input. Si hay alguna actividad financiera en el período especificado, estas se muestran al usuario. Si no existen actividades financieras durante el período, se muestra la información de la cuenta básica como el número de cuenta y el saldo.

La API de visualización de los estados recupera un estado financiero de las actividades relacionadas con una cuenta durante un período determinado de tiempo, tanto de la información de la cuenta básica como del saldo de la cuenta. Si la llamada a la API es válida, se devuelven detalles de la transacción correspondientes a la cuenta. Si no existen transacciones válidas, se remite una matriz (array) vacía, y se muestra información de la cuenta básica, como el número de cuenta y saldo.

8.3.1.1. Flujo

Las siguientes validaciones son aplicadas en API; de no cumplirse, la condición de error es registrada y se emite una excepción relevante:

■ Todos los parámetros y campos obligatorios deben ser asignados.

■ Una cuenta proporcionada en el input de existir en el sistema AR (Cuentas por Cobrar).

■ Si se proporciona fromStatementDate como input, fromStatementDate debe ser antes de la fecha actual (que siempre es usada como toStatementDate).

Si la llamada API es exitosa, se muestran los detalles del periodo proporcionado por el usuario correspondientes a la actividad financiera.





aparezca aquí.





9. CARGO Y PAGO INMEDIATOS



AI #21/ 866 La nota de crédito deberá contener su propio número de secuencia y la referencia de la factura que la originó de acuerdo con las especificaciones fiscales del SRI

7.3.5 - Nota de Crédito

4.7.3.7.3.1.5. Cargos de ajustes DB/CR. 9. Cargo y Pago Inmediatos

4.7.3.7.3.1.6. Otros cargos de acuerdo con las normas y las necesidades del negocio.

9. Cargo y Pago Inmediatos



9.3. API l3createImmediateChargePayment

La solución brinda la habilidad de Creación de Cargos y aplicar pagos a los mismos de inmediato. Realiza las siguientes funciones:

1. El sistema front end envía el monto del cargo y una matriz de impuestos del cargo y los pagos como parte del flujo de Crear un Pago Inmediato del Cargo.

2. El API Crear un Pago Inmediato del Cargo ofrece un punto de salida para la personalización para integrarlo con una cámara de compensación para cualquier validación, como por ejemplo tarjeta de crédito, Débito Directo, etc. Este API no se encuentra pre-integrado a cámara de compensación alguna.

3. Si los cargos no son proporcionados en el input y no se asigna pago alguno del input a alguna factura, entonces el pago es creado a nivel de la cuenta.





aparezca aquí.

4. Este API soporta cargos inmediatos tanto en OC como RC; si se crea un cargo RC en las Cuentas por Cobrar de Amdocs, entonces la implementación correspondiente debe ser manejada en la Facturación para no crear un cargo RC de nuevo en el mismo ciclo.

5. El monto del pago puede ser menor a su cargo; pero si no debe serlo, entonces la validación debe efectuarla una aplicación del front end.

6. Si los cargos son suministrados y el pago es designado a alguna otra factura, entonces se emite una excepción a la validación.

El Cuentas por Cobrar de Amdocs recibe montos de cargos únicos relacionados con la orden de compra y crea cargos únicos inmediatos y facturas, que impactan el saldo de la cuenta de forma inmediata. Para cada cargo inmediato, se crea un grupo de cargos y una Entidad de la Factura.

La fecha de pago para la factura inmediata es la fecha de creación de la factura.

9.3.1. Input

■ Time Stamp de la Cuenta (según fue recibido por el API ‘Obtención de Montos por Cargos Especiales’)

■ Cuenta Financiera

■ Matriz o cargos e impuestos (en el caso de Cargos derivados de Intereses, el número de secuencia de los abonos es obligatorio para cada cargo)

■ Matriz de pagos

■ PA Ind (a ser utilizado cuando se crea un cargo LPF como parte de un flujo de creación PA)

■ Tipo de Grupo de Cargo (para aplicar un pago a un producto específico)

9.3.2. Output■ Número de la Factura Legal (BILLING_INVOICE_NUMBER in

AR1_INVOICE)

■ Montos de la Factura e Impuestos





aparezca aquí.

■ ID de la Matriz de Pagos

El Número de la Factura Legal devuelto debe ser utilizado por el front end del sistema como input para el API Crear Arreglo de Pago (Cobranza).

9.3.3. Creación de Cargos

Amdocs Cuentas por Cobrar recibe los montos de los cargos únicos e impuestos a los cargos, de ser aplicables. El API crea cargos, grupos de cargos y facturas que impactarán de inmediato el saldo de la cuenta. Para cargos múltiples, se crea uno o más grupos de cargos con base en las reglas flexibles de agrupamiento de cargos y una única Entidad de la Factura.

La fecha de pago para la factura inmediata es la fecha de creación de la factura. Se definen dos códigos nuevos de cargos, uno para los cargos OC y otro para los cargos RC, en la tabla AR1_CHARGE_CODES. Se define un nuevo grupo de cargos para los OCs y RCs inmediatos en la tabla AR1_CHARGE_GROUP_TYPE y en la tabla AR1_CHARGE_GROUP_PRIORITY.

En el caso de la creación de Cargos derivados de Intereses, el Número de Secuencia de Abonos relacionado es capturado en cada cargo.

9.3.4. Creación de Pagos

El API puede aceptar múltiples pagos con varios métodos de pago y cada pago puede ser asignado a una factura diferente.

Como valor predeterminado, todos los pagos en el input son designados a los cargos inmediatos creados y se da la factura a la que se debe aplicarse el pago; luego, el pago es aplicado a esa factura.

Un indicador obligatorio del cargo global, definido una vez en AR3AccountInfoDt para todos los pagos en el input, es utilizado para determinar si se debe crear un cargo inmediato aún si falla la validación del pago (por ejemplo, validación CC).





aparezca aquí.

Si este indicador es fijado en ‘Y’, entonces aún cuando la validación del pago falla, se crea un cargo inmediato y otros pagos válidos, si están disponibles, son posteados en este cargo.

Si este indicador es fijado en ‘N’, entonces si uno de los pagos suministrados en el input falla con un error de validación, entonces no se crea pago alguno ni se postea pago alguno.

9.3.5. Creación de Notas de Débito

Cuando se crean un cargo inmediato y una factura en la aplicación AR, se puede producir un documento de Nota de Débito al enviar los detalles de (Nota de Débito) al Diseñador de Documentos de Amdocs para su formateo.

Refiérase al Capítulo Error: Reference source not found, “Error: Reference source not found” para más detalles.

9.3.6. Desestimación del Cálculo de LPF para Facturas

Cuando la API l3createImmediateChargePayment es utilizada como parte del flujo del Arreglo de Pago, marca todas las facturas abiertas y vencidas (grupos de cargo) con una indicación especial; ‘Incluido en PA’.

Esta indicación será utilizada en cualquier momento en que el LPF sea calculado durante el periodo en que un PA está activo. El LPF no sería calculado para esas facturas. A las facturas nuevas que fueron creadas después de la configuración del PA se les seguirá cobrando el LPF (durante el EOC y cuando el pago es creado de forma usual).

Cuando el PA es completado, cancelado o incumplido, esta indicación es borrada y a esas facturas se les seguirá cobrando el LPF en el caso de que no fueran pagadas. La siguiente vez que el LPF sea calculado para la cuenta, a estas facturas se les cobrará desde la última fecha en la que se les cobró,

Ejemplo

1. El 1-Abr-2012, existen tres facturas abiertas para la cuenta + 1 factura que no está vencida:





aparezca aquí.

ID de la Factura Monto Abierto

Fecha de Vencimiento

Fecha del último calc del LPF

Incluido en PA

1 100,00 15-Ene-2012 1-Abr-2012 N

2 100,00 15-Feb-2012 1-Abr-2012 N

3 100,00 15-Mar-2012 1-Abr-2012 N

4 100,00 15-Abr-2012 N/A N

2. El 2-Abr-2012, se crea un PA por 400,00. Todas las facturas abiertas vencidas son marcadas Incluidas en el PA

3. Se realiza un pago de 100,00 para el primer abono

Secuencia de Abonos Monto de la Abono

Fecha de Vencimiento del abono

1 100,00 2-Abr-2012

2 100,00 2-Mayo-2012

3 100,00 2-Jun-2012

4 100,00 2-Jul-2012

4. El 1-Mayo-2012, se crea una factura nueva.

Durante EOC, se crea LPF para las Facturas con ‘Incluido en PA’=N que están vencidas: LPF calculado para la Factura #4: 100.00 * (15/30)* 5%=2.50

ID de la Factura

Monto Abierto


Última fecha de calc LPF

Monto LPF

Incluido en PA

1 0 15-Ene-2012 1-Abr-2012 S

2 100,00 15-Feb-2012 1-Abr-2012 S

3 100,00 15-Mar-2012 1-Abr-2012 S

4 100,00 15-Abr-2012 1-Mayo-2012 2,50 N





aparezca aquí.

ID de la Factura

Monto Abierto



Monto LPF

Incluido en PA

5 100,00 15-Mayo-2012 N/A N

5. El 2-Mayo-2012 no se recibe el segundo pago para el PA. El PA es incumplido. Todas las facturas son marcadas Incluidas en el PA (=‘N’)

ID de la Factura

Monto Abierto



Monto LPF

Incluido en PA

1 100,00 15-Ene-2012 1-Abr-2012 N

2 100,00 15-Feb-2012 1-Abr-2012 N

3 100,00 15-Mar-2012 1-Abr-2012 N

4 100,00 15-Abr-2012 1-Mayo-2012 2,5 N

5 100,00 15-Mayo-2012 N/A N

6. El 1-Jun-2012 se crea una factura nueva. Durante EOC, se crea un LPF para las facturas con Incluido en el PA (=‘N’) que están vencidas:

ID de la Factura

Monto Abierto



Monto LPF

Incluido en PA

1 100,00 15-Ene-2012 1-Jun-2012 10,00 N

2 100,00 15-Feb-2012 1-Jun-2012 10,00 N

3 100,00 15-Mar-2012 1-Jun-2012 10,00 N

4 100,00 15-Abr-2012 1-Jun-2012 5,00 N

5 100,00 15-Mayo-2012 N/A 2,50 N

6 100,00 15-Jun-2012 N/A N

9.3.7. Cargos derivados de Intereses

Cuando se crean Cargos derivados de Intereses, la API debe marcar el número de abono relevante en el cargo.





aparezca aquí.

9.3.8. TimeStamp

La API validará el timestamp de la cuenta contra el timestamp de la entrada. En el caso de existir cualquier diferencia, se devolverá una excepción.

Esto previene casos de creación de cargos por tarifas (LPF, Intereses, Legal) con montos que ya no son válidos debido a cambios en el estado de la cuenta.



AR.OI.9.1 En el flujo de creación del Pago Inmediato -

¿De qué forma se integrará el FE con el facturación (Billing)para crear el pago y el cargo LPF?

1. Un paso - FE llamará a la API de Creación del Pago Inmediato del Cargo para crear tanto el Pago como el Cargo LPF

2. Dos pasos - FE llamará a la API de Creación del Pago Inmediato del Cargo dos veces consecutivas – una vez para la Creación del Pago y otra vez para la creación del cargo de la Tarifa

AR.OI.9.2 En el flujo de creación del PA -

¿De qué forma se integrará el FE con el facturación (Billing)para crear el pago del 1er abono y los cargos por Tarifas?

1. Un paso - FE llamará a la API de Creación del Pago Inmediato del Cargo para crear el pago del 1er abono así como los cargos por tarifas (LPF, Legal e Intereses)

2. Dos pasos - FE llamará a la API de Creación del Pago Inmediato del Cargo dos veces consecutivas – una vez para la creación del pago del 1er abono y otra vez para la creación de los cargos por Tarifas



10. NOTA DE DÉBITO



AI #2/847 (Extracto de Cargos por pago tardío - lámina 25) Cálculo de Mora se debe enviar una nota de debito del valor y no se debe incluir el valor de mora en la factura. La nota de débito debe contener como referencia el número de la factura que la originó. La nota de débito debe contener su propio número secuencial con la respectiva autorización del SRI. La nota de débito es generada en el momento que el cliente paga la factura retrasada. El facturador deberá generar la nota de débito y el sistema de CRM extrae la información y la imprime cuando el cliente la solicite.

10.3. Creación de la Nota de Débito

10.2. Supuestos


AR.AS.10.1

En caso que no todos los Cargos Inmediatos requieran la creación de DN, habrá facturas Inmediatas en el sistema para las que el Número de Factura no se calcula con base en la secuencia IRS, pero que es en cambio una secuencia AR interna.

Estas Facturas serán tratadas igual que cualquier otra factura en el sistema. Se les creará un LPF y serán recuperadas por la búsqueda de facturas.

10.3. Creación de la Nota de Débito

Cuando se crea un cargo inmediato y una factura en AR se puede producir un documento de Nota de Débito al enviar los detalles de la factura (nota de Débito) creada al Diseñador de Documentos de Amdocs para su formateo.

La decisión es tomada de acuerdo con el CHARGE_CODE de los cargos facturados.

Una indicación del nivel de CHARGE_GROUP_TYPE define si un Charge_Group_Type es válido para su impresión inmediata. Una vez creada





aparezca aquí.

una factura inmediata y que uno de los grupos de cargos incluidos en esta factura tiene esta indicación, la factura completa será impresa como una Nota de Crédito.

Se recomienda que se defina que el tipo de grupo del cargo para el LPF Inmediato, Intereses Inmediatos y Cargos por Tarifas Legales requiere la impresión de la Nota de Crédito. En el flujo de la creación del Arreglo de Pago, los tres tipos de cargos (LPF, Intereses Inmediatos y Tarifas Legales) serán incluidos en la misma Entidad de la Factura en la aplicación AR y compartirán la misma ID de la Nota de Débito.

Cuando se requiere el DN, AR llamará a la API del Diseñador de Documentos de Amdocs para imprimir el DN de inmediato. Al darse un retorno exitoso desde el Diseñador de Documentos de Amdocs, la actividad AR es completada y comprometida.

El ID de la Nota de Débito ID es calculado por AR únicamente para Facturas (Notas de Débito) que siéndose envían al Diseñador de Documentos de Amdocs para su impresión. Por lo tanto, las Facturas Inmediatas que no se imprimen, el ID de la Nota de Débito (ID de la Factura Legal en BILLING_INVOICE_NUMBER) no será calculado desde la secuencia de la Nota de Débito. En su lugar, será una secuencia de la aplicación AR interna.

La ID de la Nota de Débito Legal (BILLING_INVOICE_NUMBER en AR1_INVOICE) es devuelta como output de API l3createImmediateChargePayment además de la ID Única de la factura técnica (INVOICE_ID en AR1_INVOICE).

El front end del sistema puede en ese momento solicitar el PDF al llamar a la API del Diseñador de Documentos de Amdocs.

Actualmente, DN es generado para el LPF Inmediato, las Tarifas Legales y la tarifa por intereses del PA, de acuerdo con la definición en el charge_group_type.





aparezca aquí.

10.3.1. Información de la Nota de Débito enviada al Diseñador de Documentos Amdocs

■ Información a nivel de la Nota de Débito (factura):

● ID de la Cuenta

● Detalles de la Cuenta de facturación (Billing)(Nombre, Dirección)

● ID Legal de la Nota de Débito (BILLING_INVOICE_NUMBER en la tabla AR1_INVOICE)

● Número de Autorización IRS de la Nota de Débito (Parámetro de referencia)

● Monto Bruto Total del Débito (neto + impuesto)

● Monto Total del Débito por Impuestos

● Fecha de creación del DN

● Código de la Plantilla de DN (parámetro de referencia en AR1_Policy)

■ Información del nivel del cargo (matriz de todos los cargos incluidos en el DN):

● Monto del cargo (neto + impuestos)

● Monto del Cargo por Impuestos

● Código del Cargo

● Descripción del Código del Cargo

● ID de Lista de la Factura Legal (BILLING_ INVOICE_NUMBER en AR1_INVOICE) para la que se calculó el LPF

10.3.2. Secuencia de la Nota de Débito

■ La aplicación AR mantiene dos secuencias como contadores de la base de datos; una para la Nota de Crédito y una para la Nota de Débito. Estos contadores permiten mantener las secuencias CN y DN sin brechas.





aparezca aquí.

■ La secuencia DN comienza con un valor de 001000000001, pasa a 001000000002, etcétera. Al llegar a 001999999999, el siguiente número será 002000000001, etcétera.

■ Cada vez que se genera una secuencia DN, se recupera la última ID CN generada desde la DB, con un 1 por delante y el valor nuevo es guardado en la DB.

10.3.3. Número de Autorización de SRI de la DN ■ El Número de Autorización de SRI de la DN está siendo asignado a CNT

por el instituto SRI para un periodo determinado. Este número debe estar impreso en la DN junto con la fecha efectiva de SRI y la ID de la Nota de Débito Legal.

■ Ejemplo:

■ El Número de Autorización de SRI de la DN y la Fecha Efectiva de SRI de la DN son parámetros a nivel del sistema que se guardan en la tabla de referencia AR1_Policy.

■ Habrá un valor para estos dos parámetros en cualquier momento en el tiempo (no se guarda ningún historial). Cuando se produce un débito, el Número de Autorización DN-SRI y la Fecha Efectiva DN-SRI serán tomados de esta tabla AR1_Policy.

■ Se utilizan valores separados para la Nota de Crédito y la Nota de Débito.

10.3.4. Formato del ID de la Nota de Débito

■ Con el fin de mantener singularidad en el sistema de IDs de las Notas de Crédito y Notas de Débito se coloca un prefijo a las secuencias generadas.

■ El formato DN es: DN-001-001-999999998: este es el formato en que la ID de la Nota de Débito es enviada al Diseñador de Documentos de Amdocs y devuelta por las APIs de Búsqueda de Facturas.





aparezca aquí.

10.3.5. APIs searchInvoicesByAccountId y searchInvoices

■ Las APIs de Búsqueda de Facturas busca todas las Facturas de una cuenta dada.

■ Estas APIs recuperan tanto las Facturas Mensuales como las Facturas Inmediatas por Notas de Débito.

■ Se presenta la ID Legal de la Factura (BILLING_INVOICE_NUMBER en la tabla AR1_INVOICE) y puede tener diferentes tipos de valores:

● Factura Mensual – 999999999999

● Nota de Débito – DN impreso -999-999999999

● Nota de Débito – no impreso – secuencia interna AR

■ El front end podrá recuperar el archivo pdf de la Nota de Débito del Diseñador de Documentos de Amdocs (utilizando la API de Diseñador de Documentos de Amdocs) al enviar la ID de la Nota de Débito relevante al Diseñador de Documentos de Amdocs.

10.4. Asuntos Abiertos


AR.OI.10.1 CNT debe definir si el DN debe ser creado únicamente para el tipo de cargo LPF o para cualquier otra tarifa (Legal e Intereses PA)

AR.OI.10.2 CNT debe definir si la lista de todas las Facturas para las que se calculó LPF debe ser presentado en la Nota de Débito LPF



11. OBTENCIÓN DE MONTOS POR CARGOS ESPECIALES



AI#2/847 (Extracto de Cargos por pago tardío - lámina 25) Cálculo de Mora se debe enviar una nota de debito del valor y no se debe incluir el valor de mora en la factura. La nota de débito debe contener como referencia el número de la factura que la originó. La nota de débito debe contener su propio número secuencial con la respectiva autorización del SRI. La nota de débito es generada en el momento que el cliente paga la factura retrasada. El facturador deberá generar la nota de débito y el sistema de CRM extrae la información y la imprime cuando el cliente la solicite.

11.3.6 Lógica del Cálculo de LPF Inmediato





aparezca aquí.


4.7.3.1.1.8.3.5.

AI #26/ 871

Valor de intereses.

Arreglo de Pago

No todos los cargos pueden participar en el Arreglo de Pago

Dependiendo de la codificación, algunos cargos son financiables y otros no.

Solamente los cargos financiables pueden obtener Arreglo de Pago (PA).

El Arreglo de pago se puede hacer solamente en el monto vencido.

Al iniciar el Arreglo de Pago, se debe realizar el cálculo siguiente:

1) Calcular y añadir LPF (interés por mora) al total del monto vencido.

2) Añadir y calcular % del financiamiento sobre el valor financiable en Arreglo de Pago + LPF (interés por mora)

3) En algunos casos se debe añadir el porcentaje legal (honorarios profesionales, gastos judiciales) sobre el valor financiable en Arreglo de Pago.

4) El monto total de abonos = saldo financiero + LPF (interés por mora) + porcentaje de financiamiento + porcentaje legal (en algunos casos)

5) El primer pago debe ser:

5.1) >= el total de impuestos del

11.3. Obtención de Montos por Cargos Especiales





aparezca aquí.


AI #2/847 (Extracto de Cargos por pago tardío - lámina 25) Cálculo de Mora se debe enviar una nota de debito del valor y no se debe incluir el valor de mora en la factura. La nota de débito debe contener como referencia el número de la factura que la originó. La nota de débito debe contener su propio número secuencial con la respectiva autorización del SRI. La nota de débito es generada en el momento que el cliente paga la factura retrasada. El facturador deberá generar la nota de débito y el sistema de CRM extrae la información y la imprime cuando el cliente la solicite.


4.7.3.6.2.2.3. Generación intereses de mora. 11.3. Obtención de Montos por Cargos Especiales

4.7.3.6.3.8.3. Establecimiento del Plan de Pagos. Debe permitir definir y administrar, entre otras, las siguientes acciones:


4.7.3.6.3.8.4. Administración y liquidación de gastos judiciales..


4.7.3.6.3.8.7. Aplicación de sanciones, recargos o cualquier otro valor monetario definido por el negocio y pactado con el cliente.


4.7.3.7.3.1.3. Cargos para conceptos de recargo, mora.

11.3.7.Registro de Cálculos LPF Inmediatos

4.7.3.7.3.1.4. Cargos para conceptos de sanciones. 11.3. Obtención de Montos por Cargos Especiales





aparezca aquí.


4.7.3.7.3.2. La solución ofertada debe permitir configurar y mantener procedimientos especiales para el manejo de cargos, que se deben ejecutar una vez se cumplan condiciones establecidas por las normas del negocio. La solución debe manejar, entre otros, los siguientes procedimientos:


4.7.3.7.3.2.1. Generación de cargos basados en el cálculo de intereses de mora por los valores no cancelados oportunamente. Los intereses de mora se generan por cada uno de los conceptos dejados de cancelar por el cliente y prorrateados, de acuerdo con los días en que el cargo estuvo en estado de deuda dentro del período facturado.


4.7.3.9.2. Permitir que el financiador calcule los abonos, genere el vector de éstas y las incluya en la cuenta del cliente correspondiente.


4.7.3.9.3. Manejar los abonos separando en ellos los valores de capital e intereses para su presentación en la factura, si así lo define el negocio y para su contabilización.






aparezca aquí.


4.7.3.9.4. Permitir refinanciar cargos que están siendo cancelados en abonos, bajo un esquema de financiación previamente establecido. La refinanciación de cargos consiste en el cambio de las condiciones de financiación inicialmente pactadas con el cliente para el pago de un cargo. La solución debe permitir obtener el valor del saldo pendiente del cargo (capital e intereses) por el esquema inicial y asignar el nuevo esquema de financiación (refinanciación) a partir de este saldo. El nuevo esquema de financiación debe efectuarse con las mismas características del numeral anterior y tener en cuenta las políticas para este procedimiento.


11.2. Supuestos


AR.AS.11.1 La Tarifa por Pago Tardío debe calcularse tanto en EOC como cuando se crea un Pago Inmediato o un Arreglo de Pago.

Cuando se crea un pago Batch, no dará lugar a un cargo LPF.

Si un pago ‘batch’ cubre una factura vencida, el LPF para esa factura será cobrado como parte del proceso EOC y será parte de la factura mensual.

AR.AS.11.2 La Tarifa por Pago Tardío no debe llevar impuestos.





aparezca aquí.


AR.AS.11.3 Cuando se crea un Arreglo de Pago y se crean tarifas especiales para la cuenta (LPF, Legal, Intereses) se requiere una Nota de Débito para todos los tipos de tarifas creadas.

AR.AS.11.4 El cambio en las Tasas de Interés no aplicará en los Cargos derivados de Intereses existentes (PA o Abono). Aplicará solamente para Abonos/planes PA nuevos.

AR.AS.11.5 La solicitud de Débito Directo no toma en consideración los montos del Arreglo de Pago. Al contrario, es creado con el monto del saldo AR de la cuenta.

Para las cuentas con un Arreglo de Pago, los medios recurrentes de pagos del Débito Directo deben ser cambiados manualmente a medios de pago ‘En Efectivo’.

AR.AS.11.6 Los intereses sobre el PA o abonos es mensual y el monto del abono debe ser el mismo todos los meses. El usuario puede decidir el monto total del PA/Abono y la cantidad de abonos.


A continuación están los tipos de cálculo de tarifas soportados por la aplicación AR:

■ Tarifa por Pago Tardío – requerido durante los flujos de creación de un pago inmediato y de creación de un Arreglo de Pago

■ Tarifa Legal – requerida durante el flujo de creación del Arreglo de Pago

■ Intereses – requerido durante la creación de un Arreglo de Pago.

Estos cálculos son suministrados por la API ‘Obtención de Montos por Cargos Especiales’.

Además la API calcula el monto del primer abono del PA.

El flujo funcional dispara el inicio de esta API cuando se deben calcular tarifas.





aparezca aquí.

11.3.1. Input

■ ID de la Cuenta (para los flujos de pago y PA)

■ Calc LPF Ind – Y en los flujos de Pago y PA

■ Calc Legal – Y en el flujo de PA

■ Cantidad Total de Abonos– una cantidad mayor a 0 para el flujo PA

■ Monto del PA – para los flujos de PA y Abonos

■ Monto solicitado para el 1er abono

11.3.2. Output

■ Timestamp de la Cuenta (para los Flujos de Pago y PA)

■ Código del Cargo LPF

■ Monto del Cargo LPF

■ Código del Cargo Legal

■ Monto del Cargo Legal

■ Rango de abonos; para cada abono:

● Secuencia del Abono (1,2..)

● Monto del Abono

● Monto Restante

● Monto por Intereses

■ Monto Min para el Primer Abono (para PA)





aparezca aquí.

11.3.3. Creación del Flujo de Pago Inmediato

1. Antes de crear un Pago Inmediato, la aplicación AR debe brindarle al front end información respecto a si el cliente se le debe cobrar un LPF (Tarifa por Pago Tardío).

El front-end debe llamar a la API ‘Obtención de Montos por Cargos Especiales’ con modo ‘Calc’ para obtener el monto LPF requerido y obtener la aprobación del cliente para crear el cargo LPF.

3. El Monto LPF y el Código del Cargo es devuelto al front end por AR. El Timestamp de la Cuenta también es devuelto.

4. Una vez aprobado el monto LPF y que toda la información del pago fue recibido del usuario, el front end llama a la aplicación AR de nuevo (API





aparezca aquí.

l3createImmediateChargePayment) con el fin de crear el pago así como el cargo LPF en el sistema (el front end envía tanto la información de pago como el monto por el cargo LPF a la API l3createImmediateChargePayment). Adicionalmente, el front end debe enviar el timestamp de la cuenta para validar si el estado de la cuenta no ha cambiado.

5. La API l3createImmediateChargePayment es responsable de las siguientes actividades:

a. Validar timestamp

b. Crear la entidad de pago

c. Crear el Cargo LPF y la Factura

d. Mantener una lista de todas las facturas (ID de la Factura Legal) para las que se calculó la LPF (que se requiere sea impreso en la DN)

e. Si se requiere una Nota de Débito, se generará la ID de la Nota de Débito y la información de la Nota de Débito es enviada hacia AmDD para el formateo.

f. Una vez que AmDD ha creado la Nota de Débito de forma exitosa, la transacción es completada y comprometida. La ID de la Nota de Débito (INVOICE_ID en AR1_INVOICE) es devuelta al front end.

g. Front end utiliza la ID de la Nota de Débito devuelta para recuperar el pdf de la Nota de Débito del archivo AmDD. Para más detalles sobre AmDD refiérase a CNT - Amdocs Document Designer HLD..





aparezca aquí.

11.3.4. Creación del Flujo del Arreglo de Pago

1. El front end llama dos APIs del facturación (Billing)para obtener información referente a la política del PA y las tarifas relacionadas a ser generadas:

a. Obtener la API de la política del Arreglo de Pago. Para más detalles sobre los Arreglos de Pago, refiérase a CNT - FS - Collection Backend – HLD.





aparezca aquí.

b. API ‘Obtención de Montos por Cargos Especiales’

6. Las dos APIs devuelven el posible plan del PA para el cliente y las tarifas que serán cobradas (LPF, Tarifa Legal e Intereses) al front end. Adicionalmente, el monto del primer abono del PA.

7. El front end podrá cambiar el monto PA solicitado y la cantidad de abonos. Una vez hecho, el front end obtiene las nuevas tarifas relacionadas al volver a llamar a la ‘Obtención de Montos por Cargos Especiales’.

8. Una vez que el usuario está satisfecho con el plan y tarifas sugeridos para el PA, el front end deberá llamar al AR ‘l3createImmediateChargePayment’ para crear:

a. Un Pago Inmediato del monto del primer abono

b. Las tarifas calculadas

c. Generar la Nota de Débito relacionada, si se requiere

9. Una vez que AmDD ha creado con éxito la Nota de Débito, el proceso es completado y comprometido. La ID de la Nota de Débito es devuelta al front end.

10. Front end utiliza la ID de la Nota de Débito devuelta para obtener el pdf de la Nota de Débito del archivo AmDD; para más detalles sobre el AmDD refiérase a CNT - Amdocs Document Designer HLD.

11. Después de completado el primer pago, los cargos por tarifas y la Nota Débito con éxito, el front end debe llamar a la API de Cobranza para crear el PA.

a. El monto del PA solicitado originalmente debe reducirse en el monto del pago recibido

b. La cantidad original de abonos debe reducirse en 1 ya que el primer abono ya fue cubierto con el pago inmediato

12. El front end vuelve a llamar a la creación del PA, si falla la creación del PA.





aparezca aquí.

11.3.5. Impuestos sobre Tarifas

No se cobran impuestos sobre las Tarifas Legales, Intereses o LPF.

Nota: Las tarifas se calculan con base en montos abiertos y vencidos que incluyen montos por impuestos.

11.3.6. Lógica del Cálculo de LPF Inmediato

El cálculo del LPF y la creación del cargo LPF para la cuenta son activados en los siguientes flujos del sistema:

■ Flujo de Pago Inmediato – el cálculo y creación se activan desde el front end.

■ Flujo de creación del Arreglo de Pago – el cálculo y la creación se activan desde el front end.

■ Proceso de la Factura Mensual – el cálculo y la creación son activados por el AR y las aplicaciones de Facturación.

La lógica del cálculo del monto LPF en todos los casos es la misma; véase los detalles en la Sección 3.4, “Cálculo de la Tarifa por Pago Tardío”.

11.3.7. Lógica del Cálculo de Cobro de Ley

Todos los cargos creados en el sistema pueden ser clasificados en ‘financiable’ y ‘no-financiero’.

Se definirá una nueva indicación L9_FINANCEABLE_IND en AR1_CHARGE_GROUP_TYPE para los cargos ‘Financiables’.

Adicionalmente, se definirán dos parámetros nuevos a nivel de sistema para los cargos legales: Tarifa del Cargo Legal y Código del Cargo Legal (en AR1_POLICY).

El monto del Cargo Legal se calcula como sigue:

(Monto total abierto y vencido de todos los grupos de cargos ‘Financiables’) * Tarifa del cargo legal.

Ejemplo:





aparezca aquí.

■ Existen tres Grupos de Cargos Abiertos en la cuenta

■ Tarifa del Cargo Legal – 0.5%

ID del Grupo de Cargos

Monto Vencido L9_FINANCEABLE_IND

1 20,00 N

2 500,00 S

3 1 200,00 S

Monto del cargo legal = 1 700,00*0,5% = 8,50

11.3.8. Cálculo del Monto del Primer Abono

Cuando la API ‘Obtención de Montos por Cargos Especiales’ es llamada durante la creación del Arreglo de Pago, obtiene la cantidad total del PA como input.

Un nuevo parámetro a nivel de sistema en AR1_Policy definirá el porcentaje para el monto mínimo del primer abono.

El monto mínimo para el primer abono del PA es el mayor entre los siguientes:

1. Un porcentaje del monto total del PA

2. El total del Tax_Amount de todas las deudas abiertas para los cargos Financiables + Total de todas las deudas abiertas para los cargos No-Financiables

a. El Total del Tax_Amount = total del monto por Impuestos abierto para los grupos de cargos definidos con L9_FINANCEABLE_IND = ‘Y’ en la Tabla AR1_CHARGE_GROUP_TYPE.

b. El Total del monto No-Financiable = el total de la deuda abierta de los grupos de cargos definidos con L9_FINANCEABLE_IND = ‘N’ en la Tabla AR1_CHARGE_GROUP_TYPE.





aparezca aquí.

El monto por impuestos abierto se calcula de forma proporcional para cada Grupo de Cargos, de acuerdo con la tarifa de impuestos del grupo de cargos.

El monto mínimo para el primer abono se compara después con el monto de input solicitado para el primer abono. Si el monto ingresado es menor al monto mínimo, se regresará una excepción con el siguiente mensaje:

“El monto del primer abono debe ser igual o mayor a <monto mínimo calculado >”

Ejemplo:

Monto del PA $4 000,00

Porcentaje del primer abono: 20%

Los siguientes son Grupos de Cargos Abiertos para la Cuenta:

CG ID L9_FINANCEABLE_IND

Monto Total de los Cargos (Neto)

Monto Total de Impuestos

Monto Abierto

Monto Abierto Calculado de Impuestos

1 S 100,00 10,00 55,00 10/110*55=

5,00

2 S 200,00 20,00 110,00 20/220*110=

10,00

3 N 300,00 30,00 165,00 N/A

4 N 400,00 40,00 440,00 N/A

Total de todos los montos de impuestos sobre deudas abiertas para cargos Financiables = 5,00+10,00=15,00

Total de todas las deudas abiertas para cargos No-Financiables = 165,00 + 440,00= 605,00

El monto mínimo para el 1er abono es el monto mayor entre:

1. 15,00 + 605,00 = $620,00





aparezca aquí.

2. 20% * 4 000,00 = $800,00

El monto mínimo para el primer abono es $800,00

■ Si el monto de input solicitado para el primer abono es mayor/igual que $800,00 el monto regresado para el primer abono será $1 000,00

■ Si el monto de input solicitado para el primer abono es menor que $800,00 la excepción será devuelta con el siguiente mensaje:

“El monto del primer abono debe ser igual o mayor que $800,00”

11.3.9. Lógica del Cálculo de Intereses del Abono

La API utilizará la tarifa mensual de intereses como el parámetro a nivel de sistema en la tabla AR1_POLICY.

El Código del Cargo por Intereses también se definirá como un parámetro a nivel de sistema en la tabla AR1_POLICY.

El monto del Abono y el monto por intereses se calculan con base en el input:

■ Monto del PA

■ PA Cantidad de Abonos

La lógica para el cálculo es la siguiente (fórmula de “Abono Financiero”): Pago Mensual Único =

Monto *[tarifa mensual *(1+ tarifa)^abonos]/[(1+tarifa)^abons-1]

Ejemplo:

Monto Total = 9 660,67

Número de Abonos = 12

Tarifa Mensual = 0,695%

Pago Mensual Único =

9660,67* [0,00695*(1+ 0,00695)^12]/[(1+0,00695)^ 12-1]=841,89





aparezca aquí.

Monto Restante por pagar =

Monto restante del mes anterior – pago del mes anterior + intereses del mes anterior

Monto de los Intereses Mensuales =

Monto Restante por Pagar * Tarifa Mensual

Abono Mensual (Neto) =

Pago Mensual Único – Monto de los Intereses Mensuales

Monto Restante por PagarMonto de los Intereses Mensuales Abono Mensual (Neto)

Pago Mensual (Neto + Intereses)

9660,67 67,14 774,7459682 841,89

8885,925688 61,76 780,1259682 841,89

8105,796904 56,34 785,5459682 841,89

7320,246224 50,88 791,0059682 841,89

6529,235967 45,38 796,5059682 841,89

5732,728189 39,84 802,0459682 841,89

4930,684681 34,27 807,6159682 841,89

4123,066972 28,66 813,2259682 841,89

3309,836319 23 818,8859682 841,89

2490,953713 17,31 824,5759682 841,89

1666,379873 11,58 830,3059682 841,89

836,0752452 5,81 836,0759682 841,89





aparezca aquí.

El Monto Total que el proceso está utilizando para el cálculo de intereses (en el anterior ejemplo 9 660,67) y la cantidad de abonos (12 en el anterior ejemplo) son:

Monto Total para el cálculo de intereses:

Monto del PA – Monto del primer abono + Monto Total del LPF + Monto de la Tarifa Legal

Cantidad de Abonos para el cálculo de intereses:

PA Cantidad de Abonos – 1

11.3.10. Ejemplo de Arreglo de Pago

■ El cliente quiere crear un PA por $10 000,00 con 10 abonos

■ Intereses mensuales - 0,00695 (0,695%)

■ LPF a ser cobrado - $250,00

■ Tarifa Legal a ser cobrada - $150,00

■ Monto del primer abono - $2 050,00

■ Máximo entre:

● 20% de (10 000,00 + 250,00) = $2 050,00

● Monto Total de Impuestos Abiertos + Cargos No-Financiables = $2 000,00

■ Monto Total para el cálculo de intereses:

Monto del PA – Monto del primer abono + Monto Total del LPF

10 000,00 - 2 050,00 + 250,00 + 150 = 8 450,00

■ Cantidad de abonos para el cálculo de intereses:

PA Cantidad de Abonos – 1

10 – 1 = 9

■ Cálculo de Intereses:





aparezca aquí.

Monto Restante por PagarCantidad de los Intereses Mensuales Abono Mensual (Neto)

Pago Mensual (Neto + Intereses)

8 450,00 58,73 913,0865501 971,82

7536,91095 52,38 919,4365501 971,82

6617,475931 45,99 925,8265501 971,82

5691,650838 39,56 932,2565501 971,82

4759,391262 33,08 938,7365501 971,82

3820,652481 26,55 945,2665501 971,82

2875,389465 19,98 951,8365501 971,82

1923,556872 13,37 958,4465501 971,82

965,1090423 6,71 965,1065501 971,82

Además de los anteriores Cargos derivados de Intereses:

■ El cliente debe pagar el primer abono por $2 050,00

■ LPF a ser cobrado - $250,00

■ Tarifa Legal a ser cobrada - $150,00

11.3.11. Cancelación del Pago y PA

1. Una Reversión del Pago (Anulaciones) o cancelación/incumplimiento del PA no impactará la LPF y cargos Legales; una vez que se ha creado la LPF/cargos legales y se han aplicado a la cuenta, no serán reversados.

2. Cuando un PA es incumplido, cancelado o completado, Cobranza activa el AR (por medio de la API de Facturación interna) para que maneje el impacto de esta actividad en la aplicación AR:





aparezca aquí.

a. AR Cancela los intereses que fueron cobrados por los meses restantes del arreglo de pago.

Todos los Cargos derivados de Intereses relacionados con abonos futuros del PA que no fueron cumplidos son acreditados utilizando un crédito inmediato a nivel del cargo.

Cuando Cobranza está llamando a AR deberá brindar el número de secuencia de intereses a partir del cual los intereses deben ser reversados y la ID de la Factura relacionada con los Cargos derivados de Intereses.

La razón del crédito para el crédito a nivel del cargo se define como un parámetro en la tabla AR1_policy.

Si el PA fue completado, no se reversará ninguno de los cargos por intereses.

a. AR también eliminará la excepción temporal de LPF en las facturas que formaban parte del plan del PA. Todos los grupos de cargos que fueron marcados con la indicación ‘Incluido en el PA’ están siendo eliminados de esta indicación.



AR.OI.11.1 Monto Total para el cálculo de intereses:

Monto del PA – Monto de 1er abono + Monto Total de la LPF + Monto por la Tarifa Legal

O

Monto del PA – Monto de 1er abono + Monto Total de la LPF + Monto de la Tarifa Legal





aparezca aquí.


AR.OI.11.2 En el flujo de creación del Pago Inmediato -

¿De qué forma se integrará el FE con el facturación (Billing)para crear el pago y el cargo LPF?

Un paso - FE llamará a la API de Creación del Pago Inmediato del Cargo para crear tanto el Pago como el Cargo LPF

Dos pasos - FE llamará a la API de Creación del Pago Inmediato del Cargo dos veces consecutivas – una vez para la Creación del Pago y otra vez para la creación del cargo de la Tarifa.

AR.OI.11.3 En el flujo de creación del PA -

¿De qué forma se integrará el FE con el facturación (Billing)para crear el pago del 1er abono y los cargos por Tarifas?

Un paso - FE llamará a la API de Creación del Pago Inmediato del Cargo para crear el pago del 1er abono así como los cargos por tarifas (LPF, Legal e Intereses)

Dos pasos - FE llamará a la API de Creación del Pago Inmediato del Cargo dos veces consecutivas – una vez para la creación del pago del 1er abono y otra vez para la creación de los cargos por Tarifas.

Descuento sobre Pagos Adelantados Requerimientos Relacionados ID DEL BR Descripción del BR Abarcado por

4.7.3.7.4.4.2.

Por pagos anticipados. 12. Descuento sobre Pagos Adelantados

4.7.3.7.4.4.2.

Por pronto pago. 12. Descuento sobre Pagos Adelantados





aparezca aquí.

Descuento sobre Pagos Adelantados Requerimientos Relacionados ID DEL BR Descripción del BR Abarcado por

AI #17/862 (Asignación de Pago) CNT requiere que Amdocs implemente en el sistema de facturación descuento o tiempo al aire por pronto pago. Este tipo de funcionalidad no existe listo de fábrica.

12. Descuento sobre Pagos Adelantados

11.5. Supuestos


AR.AS.12.1

Los Descuentos sobre Pagos Adelantados (Pago Anticipado) serán calculados para los pagos inmediatos hechos a través del front end

AR.AS.12.2

Todas las cuentas son definidas como Receptoras de Facturas (los pagos son aplicados con el método Saldo Anterior (suma y sigue)

AR.AS.12.3

No se deben crear Notas de Crédito para los Descuentos sobre Pagos Adelantados (Crédito)

11.6. Descuento sobre Pagos Adelantados

Cuando se recibe un pago Inmediato para la cuenta y cubre las facturas de la cuenta previas a la fecha de vencimiento de la factura, esta cuenta puede ser elegible para un descuento. Este descuento es otorgado automáticamente como un crédito a nivel de las facturas pendientes, con base en un conjunto de parámetros predefinidos.





aparezca aquí.

Los créditos pendientes son extraídos a la facturación en la fecha de facturación y reflejados en la factura. No impactan el saldo de inmediato.

La razón del crédito para el Descuento sobre Pagos Adelantados se define como un parámetro en la tabla AR1_policy.

Se aplicará un crédito para cada factura abierta por separado y será un Crédito Pendiente – no se creará/imprimirá una Nota de Crédito. Este crédito afectará el saldo en el siguiente Bill mensual.

Si la factura se vuelve a abrir más adelante (por ejemplo como el resultado de una Anulación del Pago o Reversión del Crédito a nivel del cargo/factura), todos los créditos por pagos adelantados aplicados a la cuenta como resultado del pago adelantado serán reversados de manera automática.

La ID del pago adelantado será ingresada en la entidad crediticia a nivel de la factura y en la factura para fines del monitoreo y Reversión automática del Crédito.

11.7. Criterios de Pagos Adelantados

El Crédito por Pago Adelantado será aplicado únicamente si un pago inmediato cubre el monto completo del saldo de la cuenta y únicamente si ninguna de las facturas de esta cuenta está vencida.

Normalmente, habrá una posible factura que cumple con estas condiciones.

Una nueva tabla de referencia - AR9_Early_Pym_Credit_Criteria – define la condición y la tarifa crediticia relevante para cada factura elegible.

La razón del crédito para un pago adelantado debe definirse en AR1_Policy.

Ejemplo:





aparezca aquí.

Monto Min de la Factura

Monto Max de la Factura

Mín. Días por Adelantado

Max Días por Adelantado

Porcentaje de Crédito

Criterios de Descripción

$0,00 $10,00 1 999 0 No se otorga un crédito por un pago adelantado menor a $10,00

$11,00 $99,00 1 5 0,5% Crédito de 0,5% por pagos adelantados en 1-5 días de hasta $99,00

$11,00 $99,00 6 999 1% Crédito de 1% para Pagos Adelantados, más de 6 días

$100,00 $999 999 999,00 1 999 2% Crédito del 2% para Pagos Adelantados mayores a $100,00

Si no se cumple ninguna de las condiciones, no se otorgará crédito alguno.

Si la cuenta es elegible para un crédito por pago adelantado, el monto del crédito se calculará para cada factura abierta por separado con base en su fecha de vencimiento y el monto abierto (cubierto).

El flujo:

1. Se crea un pago utilizando la API l3createImmediateChargePayment.

2. Si el pago no cubre el monto completo del AR_Balance o la cuenta tiene facturas vencidas, el pago es ingresado de forma regular (con la creación de la LPF como se describió anteriormente) sin crédito alguno por pago adelantado.

13. Si se debe aplicar un crédito, la API buscará todas las facturas abiertas y calculará el monto del crédito a ser aplicado según la tabla de decisión descrita arriba.





aparezca aquí.

14. Se creará un crédito a nivel de las facturas pendientes para cada factura.

15. No se creará una Nota de Crédito para estos créditos (ya que están pendientes y aparecerán en la siguiente factura).

16. Los montos del crédito reducirán el monto a pagar del Bill siguiente creado para la cuenta.

El proceso mantendrá l ID del pago en cada crédito y cada factura como referencia.





12. LIBROS DE DIARIO Y LIBRO MAYOR



AI - #869 (24) (G/L) Contabilización por área geográfica. Parámetros de estructura de interfaz de recaudación por agencia de recaudo y por provincia de origen de la facturación.

14.11. Emisión de Informes del LM por Provincia y Localidad

4.7.3.1.1.10. Contabilización (Journalization). 14. Libros de Diario y Libro Mayor

4.7.3.1.1.10.1. Generación asientos contables. La solución debe: 14. Libros de Diario y Libro Mayor

4.7.3.1.1.10.1.1.

Para cada Producto/Servicio debe permitir parametrizar la forma en que se contabilizarán los valores generados por su utilización, por parte de los Clientes.

14.6. Acumulación en el Diario Mayor

4.7.3.1.1.10.1.5.

Registrar todas las transacciones de pagos en el sistema y distribuirlas por concepto de facturación, permitiendo así la generación de los registros contables requeridos por el sistema de contabilidad.


4.7.3.1.1.11. Proveer un mecanismo para el registro contable de los descuentos subproceso de Servicios y Especificación de los Casos de Tarificación (por sus siglas en inglés, Service & Specific Instance Rating), en los cuales se pueda realizar distribuciones proporcionales o específicas a las cuentas de los servicios afectados o contabilizando el descuento totalizado.


4.7.3.1.1.12. Envío al sistema de contabilidad general del movimiento generado. Todo el movimiento contable deberá ser enviado al sistema financiero que utilice la entidad. Para este envío la solución debe:






aparezca aquí.


4.7.3.6.4. Administración, Contabilización de la Gestión 4.6.4. Definición de Criterios en el Configurador

4.7.3.6.4.1. Administración de reglas de contabilización de los eventos. A efectos de llevar el registro financiero de las actividades realizadas en el proceso de cobranza, la solución ofertada debe:

4.6.4. Definición de Criterios en el Configurador

4.7.3.6.4.1.1. Definir los códigos de las cuentas contables a ser utilizadas en la contabilización de, al menos las siguientes situaciones:


4.7.3.6.4.1.1.1. Recuperaciones (pagos). 4.6.4. Definición de Criterios en el Configurador

4.7.3.6.4.1.1.2. Castigo de cartera. 4.6.4. Definición de Criterios en el Configurador

4.7.3.6.4.1.3. Definir los controles a ejercer en la generación de la contabilización de, al menos las siguientes situaciones:


4.7.3.6.4.1.3.1. Recuperaciones (pagos). 4.6.4. Definición de Criterios en el Configurador

4.7.3.6.4.1.3.2. Castigo de cartera. 4.6.4. Definición de Criterios en el Configurador

4.7.3.6.4.1.4. Generación de interfaz contable. Se debe ejecutar la generación de la interfaz contable en, al menos las siguientes formas:

14.5. Extracto del Diario

4.7.3.6.4.1.4.1. Manual. La ejecuta alguien. 14.5. Extracto del Diario





aparezca aquí.


4.7.3.6.4.1.4.2. A través de una programación por hora (scheduler). 14.5. Extracto del Diario

4.7.3.7.3.3.5. Generar el registro contable por cada concepto de facturación.

14.6.2. Mapeo

4.7.3.7.7.2.3. Conjunto de información contable: datos relacionados con códigos contables (LG), asignados por cada uno de los conceptos de facturación que requiera cada producto. A partir de estos códigos se genera la interfaz contable.


4.7.3.7.8.1.2.6. Código contable (LG). 14.6. Acumulación en el Diario Mayor

4.7.3.8.4. Gestión de Cuentas. Genera toda la información referente a la contabilización de los valores incluidos en la factura, para cada Cliente/Suscriptor.




12.3. Solución

El objetivo del proceso de los Libros de Diario es volver a postear todas las actividades financieras en las Cuentas por Cobrar en el Libro Mayor de CNT.

El proceso mapea cada actividad financiera en un número de Cuenta en el Libro Mayor, definido por el departamento de contabilidad de CNT.

El mapeo es realizado por características predefinidas que están disponibles en cada actividad financiera.

El proceso comienza en Cuentas por Cobrar con un extracto de la información de la actividad financiera en un archivo.





aparezca aquí.

El proceso continúa con un análisis detallado de este archivo. Los Libros de Diario y Libro Mayor traducen luego las actividades financieras en transacciones acumuladas en el Libro Mayor.

Cada transacción en el Libro Mayor incluye un conjunto de atributos derivado de la actividad financiera original. Los ejemplos de estos atributos incluyen el monto de la actividad, el tipo de cuenta, el sub-tipo de la cuenta y el Emisor del Pago. Estos atributos son utilizados para mapear cada actividad financiera hacia la cuenta general correcta del libro físico de contabilidad general.

Las siguientes actividades financieras son soportadas por el proceso de los Libros de Diario:

■ Anulación

■ Cancelar Disputa

■ Creación de una Disputa

■ Crédito

■ Reversión del Crédito

■ Transferencia de Fondos Desde

■ Transferencia de Fondos Hacia

■ Factura

■ Justificación de una Disputa

■ Detalle de Pagos

■ Reembolso

■ Reversión de un Reembolso

■ Rechazo de una Disputa

■ Amortización en Libros

■ Reversión de la Amortización en Libros

La lista puede ser ampliada o reducida, según se requiera.





aparezca aquí.

12.4. Extracto del Diario

El proceso de Extracto del Diario es un proceso de ‘Batch’ diario que está siendo activado como parte del mapa EOD.

El proceso extrae toda la información de la actividad financiera hacia el archivo del Extracto del Diario.

La información que es requerida para cada actividad financiera se define en el archivo de implementación JGL. Para cada actividad financiera se pueden definir varios campos de datos y cada campo puede luego ser utilizado como campo de desglose para el mapeo físico de la cuenta de LM o como campo informativo en el archivo LM extraído al Libro Mayor (SAP)

Este archivo es utilizado luego como input para el proceso de Análisis del Diario. La información de la actividad financiera contiene datos de todas las actividades financieras que ocurrieron desde la última corrida del Extracto del Diario.

De esta manera, el proceso de Análisis del Diario no necesita interactuar como la base de datos de las Cuentas por Cobrar de Amdocs para obtener los datos requeridos. Al contrario, todos los análisis se realizan con base en la información incluida en el archivo de Extracto del Diario.

El proceso realiza los siguientes pasos:

1. Escanea la tabla AR1_TRANSACTION_LOG para identificar todas las actividades financieras que ocurrieron desde la última vez que se corrió el proceso.

2. Recupera todos los datos relevantes para cada actividad financiera.

3. Registra el rango de actividades extraídas en la base de datos.

4. Crea un archivo de output y lo registra con Auditoría y Control.

12.5. Análisis del Diario

El proceso de Análisis del Diario traduce cada actividad financiera incluida en el archivo Extracto del Diario en transacciones del Diario (journal).





aparezca aquí.

Comienza revisando las reglas de clasificación para identificar el tipo de actividad financiera. El proceso continúa identificando las cuentas lógicas y sus atributos que deben ser asignados a cada tipo de actividad. Finalmente, el proceso activa la regla de cálculo, si existe, sobre el monto de la actividad y le suma el resultado a la transacción en el Diario (Journal).

Las transacciones del Diario (journal) son guardadas en el archivo del Diario (journal), que es posteriormente cargado en la Acumulación en el proceso del Diario Mayor.

12.5.1. Estructura de la Transacción del Diario

La estructura de la Transacción del Diario (Journal) es como sigue:

■ Actividad financiera

■ Tipo de actividad

■ Tipo de cuenta lógica en el Libro Mayor (crédito o débito)

■ Cuenta lógica en el Libro Mayor

■ Fecha de posteo

■ Monto

■ Todos los atributos relevantes del desglose

La transacción del diario (journal) también puede incluir campos de información (dependiendo de la configuración del sistema).

En algunos casos, una actividad financiera genera múltiples registros en el diario (journal). Por ejemplo, la actividad financiera del Grupo del Cargo puede ser traducida en varias transacciones en el diario (journal) si acumula cargos con diferentes códigos de cargo y cada código de cargo es un campo de desglose para los ingresos en los Libros de Diario.

12.5.2. Ejemplos

A continuación ejemplos de cómo las actividades financieras se traducen en transacciones del Diario (journal).

Ejemplo 1: Nuevo Grupo de Cargos





aparezca aquí.

Este ejemplo utiliza lo siguiente:

■ Fecha 01-Feb-2012

■ Monto del grupo de cargos de $100,00 con un IVA de 20%

■ Códigos de los cargos:

● SERVICE_CHG (monto 40)

● MONTHLY_ACCESS (monto 60)

■ Tipo de cuenta es residencial

La siguiente tabla muestra las entradas en el Diario (Journal):

Cuentas por Cobrar Ingresos IVA

DR CR DR CR DR CR

60 48 12

40 32 8

Se crean las siguientes transacciones en el Diario (Journal):

■ CHGGRP; Billing; debit; AR; 01.02.2004; 60; residential

■ CHGGRP; Billing; credit; REVENUE; 01.02.2012; 48; SERVICE_CHG

■ CHGGRP; Billing; credit; VAT; 01.02.2012; 12

■ CHGGRP; Billing; debit; AR; 01.02.2012; 40; residential

■ CHGGRP; Billing; credit; REVENUE; 01.02.2012; 32; MONTHLY_ACCESS

■ CHGGRP; Billing; credit; VAT; 01.02.2012; 8

Ejemplo 2: Crédito a Nivel del Cargo


■ Fecha 01-Feb-2012

■ Monto del crédito 40 con un IVA 20%





aparezca aquí.

■ Razón del crédito BAD_CALL

■ Tipo de cuenta residencial

La siguiente tabla muestra las entradas en el diario (journal):

Cuentas por Cobrar Ingresos IVA

DR CR DR CR DR CR

60 48 12

Se crean las siguientes transacciones en el diario (journal):

■ CREDIT; Charge level; credit; AR; 01.02.2012; 60; residential

■ CREDIT; Charge level; debit; REVENUE; 01.02.2012;48; BAD_CALL

■ CREDIT; Charge level; debit; VAT; 01.02.2012; 12

Ejemplo 3: Pago


■ Fecha del 01-Feb-2012

■ Monto de pago de 100

■ Método de pago de tarjeta de crédito, sub-método de pago de Visa

■ Tipo de cuenta residencial

La siguiente tabla muestra las entradas en el diario (journal):

Cuentas por Cobrar Ingresos

DR CR DR CR

100 100

Se crean las siguientes transacciones en el diario (journal):

■ PYM; CC Payment; credit; AR; 01.02.2004; 100; residential

■ PYM; CC Payment; debit; CASH; 01.02.2004; 100; cc; visa





aparezca aquí.


El proceso de Acumulación en el Diario Mayor acumula las transacciones del diario (journal) en transacciones en el Libro Mayor. Estas transacciones son cargadas en la tabla AR1_GL_DATA, desde donde pueden ser extraídas y cargadas en el Libro Mayor del proveedor de servicios de comunicación.

El proceso de Acumulación en el Diario Mayor realiza los siguientes pasos:

■ Acumulación

■ Mapeo

■ Informes Detallados (si se requieren)

■ Actualización de la Base de Datos

12.6.1. Acumulación

Cada transacción en el diario (journal) del archivo de diario (journal) se compara con todas las otras transacciones del libro mayor que ya están en la memoria. Si todos los valores de los atributos del desglose, excluyendo el monto, coinciden con cualquier otra transacción del libro mayor, el monto de esta transacción específica en el diario (journal) se agrega a la transacción ya creada en el libro mayor. De lo contrario, se crea una nueva transacción en el libro mayor.

12.6.2. Mapeo

Una regla de desglose consiste de una cuenta física en el libro mayor y un conjunto de valores aceptables que conforman los atributos de desglose. Una transacción en el libro mayor para la que todos los atributos del desglose coinciden con una de las reglas es mapeada a la cuenta física de la regla en el libro mayor. Si no hay ninguna regla disponible, la transacción es mapeada a una cuenta física predeterminada del libro mayor como se define en el implementador.





aparezca aquí.

12.6.3. Actualización de la Base de Datos

Las salidas del libro mayor son guardadas en una base de datos. Los datos se guardan en una tabla llamada AR1_GL_DATA, con una columna para la cuenta física, fecha, cuenta lógica y monto y una columna para cada atributo de desglose.

Las salidas detalladas de los informes son guardadas en la misma base de datos. Estos datos se guardan en una tabla llamada AR1_GL_DETAILED_DATA, tiene columnas para la cuenta física, fecha, cuenta lógica y regla de clasificación y una columna para cada atributo de información.


El Configurador es una aplicación GUI que le permite a los implementadores configurar los criterios utilizados por los Libros de Diario y el Libro Mayor para determinar cómo traducir las actividades financieras a transacciones en el Diario (Journal) y mapearlas a las cuentas correctas del Libro Mayor.

El flujo de trabajo de la configuración de los Libros de Diario y el Libro Mayor consiste de las siguientes etapas principales:

El implementador puede definir los criterios utilizados por los Libros de Diario y el Libro Mayor para determinar cómo traducir las actividades financieras en transacciones en el diario (journal) y mapearlas a las cuentas correctas del libro mayor. Se pueden definir los siguientes criterios:

■ Reglas de Clasificación – Una actividad financiera debe satisfacer las reglas de clasificación definidas para la misma para que pueda ser considerada para el mapeo a una cuenta física. Cada actividad financiera que pasa una regla de clasificación debe ser ingresada en el Libro Mayor como un crédito y como un débito.

■ Nombres de las cuentas lógicas: la cuenta lógica en las que se deben registrar las entradas de la actividad financiera. Hay una para entradas de crédito y una para entradas de débitos.





aparezca aquí.

■ Campos de desglose: para cada cuenta lógica, una serie de desgloses definen cómo las actividades financieras son agrupadas y acumuladas.

■ Monto a ser acumulado: para cada cuenta lógica, el monto de la actividad financiera a ser acumulado.

■ Cuenta física predeterminada: la cuenta física predeterminada que sirve como garantía en el caso que no se encuentre ninguna regla de desglose que coincida.

■ Reglas de cálculo: una regla simple para el cálculo que se realiza sobre el monto.

■ Cuentas físicas: identificadores de la cuenta real que son utilizados al reportar las entradas en el Libro Mayor.

■ Reglas de desglose: para cada cuenta física del Libro Mayor, las reglas de desglose definen cómo se enrutan las transacciones del diario (journal) a las cuentas físicas correctas.

Es posible mantener estos datos de implementación del Libro Mayor en una hoja de trabajo de Excel, la cual puede ser cargada directamente al Configurador.

12.7. Extracto del Libro Mayor


LM extrae las transacciones del libro mayor a un archivo; extrae la información de la tabla AR1_GL_DATA y la guarda en un archivo del Libro Mayor. Para más información sobre este archivo, refiérase a CNT - AR - Journal - IDD

12.8. LM de Cargos No Facturados

12.8.1. Diagrama de Flujo

Los informes de Ingresos Ganados No Facturados se producen sobre una base mensual.





aparezca aquí.

Los datos son sumados y mapeados en cuentas físicas según las reglas del Libro Mayor.

El siguiente flujo muestra la generación del informe:

Figura 14-3: Figura del Flujo de la Generación de Informes


1. Los Datos de OC y RC No facturados relevantes para el mes calendario actual son extraídos de la Facturación de Amdocs.

2. El UC No Billed es extraído del Tarificador.

3. Los archivos son enviados a las Cuentas por Cobrar de Amdocs, que carga los archivos a una tabla interna. Los datos, con cualquier información adicional requerida, son luego extraídos a un archivo utilizando el proceso de Extracto del Diario.

4. Los procesos LM son activados con los archivos de input del Tarificador y Facturación. El LM agrupa y mapea los datos a la tabla LM según las reglas LM definidas en la etapa de implementación.





aparezca aquí.

5. El informe extrae toda la información relevante hacia lo no billed desde la tabla LM.

6. Cuando un archivo de extractos es enviado desde Facturación y el Tarificador, un proceso nuevo carga la información a una tabla interna de las Cuentas por Cobrar de Amdocs y crea el input necesario para el proceso de Extracto del Diario. El proceso de Extracto del Diario está configurado para recuperar la información referente a ingresos no billed desde la tabla y recuperar información adicional desde otras tablas si fuera necesario, y crear un input para los procesos LM.

7. Se definen actividades financieras para ingresos no billed.

8. Un proceso de extracción extrae la información no billed al final del mes en un formato CSV para ser utilizado como un informe o como un extracto para una fuente externa.

17. Se extraen los siguientes campos:

Nombre del CampoTipo de Campo

Cuenta física G/L Secuencia

BE Número

Moneda Secuencia

Monto del Débito Número

Monto del Crédito Número

Monto Neto Número

12.9. LM para Bills no devengados


Se define una nueva regla de cálculo para los cargos recurrentes no devengados billed.

La regla calcula la porción del monto que corresponde al mes actual y divide los cargos recurrentes en dos meses consecutivos.





aparezca aquí.

La regla de cálculo utiliza el siguiente cálculo:

{Monto calculado} = {días entre la fecha de inicio de cobertura y el final del mes}/{cantidad total de días cubiertos} * {monto de los cargos}

■ Para utilizar la regla de cálculo, se utilizan dos campos de fechas (Fecha de Inicio de la Cobertura y Fecha Final de la Cobertura) para calcular el monto del mes actual y el siguiente.

■ Un proceso ‘batch’ divide el monto no devengado billed entre meses de la manera siguiente:

● Cuando se realizan los procesos LM y toda la información acumulada ha sido ingresada a la tabla AR1_GL_DATA, se ejecuta un proceso de ‘batch’ adicional y este recupera los cargos RC que cubren más de un mes en delante (la fecha de cobertura de los cargos va más allá del final del siguiente mes).

● Cada fila es dividida en varias filas según la cantidad de meses efectivos y el campo Mes Efectivo se llena con el mes respectivo. En este caso, se borra la fila original.

● Para diferenciar los cargos que ya fueron divididos y aquellos cuya división está pendiente, el campo Estado (en AR1_GL_DATA) es actualizado con el estado Completado una vez que el registro es procesado (hasta ese momento el estado es nulo)





aparezca aquí.

■ Por razones de desempeño, el estado de los otros registros (no registros RC) también es actualizado por el trabajo (sin procesamiento adicional).

12.10. Emisión de Informes del LM por Provincia y Localidad

12.10.1. Emisión de Informes de Actividades de Pagos

Todas las actividades relacionadas con el pago – Pagos, Anulaciones, Reembolsos, Reversiones de Reembolsos, Transferencia de Fondos Desde y Transferencia de Fondos Hacia – pueden ser mapeadas a la cuenta Física de LM según la Provincia y Ubicación del Emisor del Pago.

La tabla AR1_Payment_Source será utilizada para definir un ID del Emisor del Pago para cada combinación de Provincia y Ubicación. Los campos de Provincia y Ubicación serán agregados a esta tabla.

La Implementación de la Generación de Informes LM será configurada para que en cada actividad relacionada con el pago, se recuperen la Provincia y Ubicación de la tabla AR1_Payment_Source según el Payment_Source_Type y Payment_Source_ID que aparecen en la entidad AR1_Payment_Details.

Para los Pagos que son recibidos en el sistema sin el Payment_Source_Type y el Payment_Source_ID (por ejemplo Pago Inmediato) el desglose LM será de acuerdo con la Provincia y Ubicación de la Cuenta en la entidad AR1_Address_Name.





aparezca aquí.

12.10.2. Emisión de Informes de otras Actividades

Todas las actividades que son reportadas a LM incluyendo las actividades relacionadas con el pago serán reportados de acuerdo con la Provincia y Ubicación de la Cuenta en la entidad AR1_Address_Name.

12.10.3. Archivo del Extracto del LM de ARs

Una actividad financiera se define en los archivos XML de las Cuentas por Cobrar de Amdocs (estructura, relaciones y enlaces) en la tabla de referencia AR1_XML_DISTRIB.

Se define una propiedad AR1_PROPERTIES.UNBILLED_FIN_ACT. Esta propiedad determina la actividad financiera que es relevante para los ingresos no facturados.



AR,OI,14.1 CNT deberá definir si las actividades relacionadas con el pago deben ser mapeadas a la Cuenta LM de acuerdo con la Provincia y Ubicación del Emisor del Pago así como la Provincia y Ubicación de la dirección de la Cuenta



13. IMPACTO DE LA IMPLEMENTACIÓN

13.1. Nota de Crédito

■ La decisión de emitir o no una Nota de Crédito se basa en la CREDIT_REASON.

■ El Código de la Plantilla CN se define en AR1_Policy.

■ El Número de Autorización CN-SRI y la Fecha Efectiva SRI son parámetros a nivel de sistema que son guardados en la tabla de referencia AR1_Policy.

13.2. Nota de Débito

■ El Código de la Plantilla de la Nota de Débito se define en AR1_Policy.

■ El Número de Autorización CN-SRI y la Fecha Efectiva SRI son parámetros a nivel de sistema que son guardados en la tabla de referencia AR1_Policy.

■ Una indicación de nivel CHARGE_GROUP_TYPE define si un Charge_Group_Type es válido para comenzar la impresión inmediata. Una vez creada una factura inmediata y uno de los grupos de cargos incluido en esta factura tiene esta indicación, la factura completa es impresa como una Nota de Crédito.

Se recomienda que el tipo de grupo de cargo para el LPF Inmediato y los cargos por Tarifas Legales sean definidos según lo requerido para la impresión de la Nota de Crédito.

13.3. Tarifas

■ Se definirá una nueva indicación L9_FINANCEABLE_IND en el AR1_CHARGE_GROUP_TYPE para los cargos ‘Financiables’.

■ Adicionalmente, se definirán dos nuevos parámetros a nivel de sistema para los cargos legales: Tarifa para el Cargo Legal y Código para el Cargo Legal (en AR1_POLICY).





aparezca aquí.

■ La API utilizará la tasa de interés mensual como un parámetro a nivel de sistema en la tabla AR1_POLICY.

■ El Código del Cargo por Intereses también será definido como un parámetro a nivel de sistema en la tabla AR1_POLICY.

■ La razón para el crédito para un crédito por un cargo por intereses es definido como un parámetro en la tabla AR1_policy. Es un crédito a nivel de cargo.

■ Un nuevo parámetro a nivel de sistema en la tabla AR1_Policy definirá el porcentaje para el monto inicial del abono de la PA.

13.4. Débito Directo

Modo pesimista – x días antes de la fecha de vencimiento de la factura se envía una solicitud de pago al banco. El pago es aplicado a la cuenta en el sistema después de recibir aprobación del banco en el archivo de Retroalimentación DD.

13.5. Cancelar Arreglo de Pago

La razón del crédito para el crédito por el cargo de intereses es definido como un parámetro en la tabla AR1_policy. Es un crédito a nivel del cargo.

13.6. Descuento sobre Pagos Adelantados

■ La razón del crédito para el Descuento sobre Pagos Adelantados es definida como un parámetro en la tabla AR1_policy. Es un crédito a nivel de factura.

■ Nuevos criterios de la tabla de referencia AR9_Early_Pym_Credit_Criteria:

● Cantidad Mínima de la Factura

● Cantidad Máxima de la Factura

● Mínimo Días de Adelanto





aparezca aquí.

● Máximo Días de Adelanto

● Porcentaje de Crédito

● Descripción de los Criterios

● Prioridad

13.7. Aplicación del Efectivo

Los tipos de grupos de los Cargos de Tarifas serán definidos con la mayor prioridad para las reglas de Aplicación del Efectivo.

13.8. Emisor del Pago

La tabla AR1_PAYMENT_SOURCE será utilizada en CNT para definir la provincia y ubicación del posible Emisor del Pago.

Los siguientes campos nuevos serán agregados a la tabla:

■ Provincia

■ Ubicación



14. ASPECTOS NO FUNCIONALES

14.1. Requerimientos Relacionados - N/A


14.2. Hardware/software de Terceros

Se entregará una descripción del hardware y software de terceros en un documento independiente.

14.3. Estrategia de la Prueba

Se entregará una descripción de la Estrategia de la Prueba en un documento independiente.

14.4. Seguridad

Se entregará una descripción de procesos y mecanismos de seguridad en un documento independiente.

14.5. Alcance y Estrategia de la Migración

El alcance y la estrategia del proceso de migración serán entregados en un documento independiente, incluyendo:

14.6. Desempeño – N/A



Información de la Liberación del Documento

Versión del Software Editor

Fecha de Edición (mm/dd/yyyy Comentarios

Enviado al Sitio

Aprobado Por

Ver. Del Doc.

8.1 Rachel Shimoni

07/22/2012 Versión Original N 0.1–0.5

8.1 Alex Mandel

07/23/2012 Formateo TW revisado N 0.6

8.1 David Brownstein, Rachel Tsrouya, Stuart Shirley

07/24/2012 Edición TW N 0.7

8.1 Rachel Shimoni

07/24/2012 Aceptar edición TW N Menahem Yaniv

0.8

8.1 Rachel Shimoni

07/25/2012 Agregar todos los AI en español

S Menahem Yaniv

0.9



accounts receivable and financial activities backend

Documents

amdocs y

facturacin amdocs

documentos amdocs

marca y

cuentas por cobrar principales

facturacin billingde

tarifa por pago tardo

propsito y alcance