DAp 509090 Cobrar Licencis Unif

Definición Alcance y Arquitectura
Cobrar acciones de gestión de cobro a

productos retirados
Producto: Open Smartflex
Grupo funcional: Gestión de cobro
Definición de Alcance y Arquitectura
Gestión de cobro
Este documento está sujeto a cambios.
Fecha solicitud: 24-Feb-2020

Tipo de Orden : Requerimiento
Número Orden: 501525
Fecha Autor Versión Referencia de Cambios

24-Feb-2020 Johanna Antolinez 1.0 Definición
12-Mar-2020 Diego F. Flórez M. 2.0 Evaluación
18-Mar-2020 Esteban R. Triviño Guerra
Copyright © 2010/09 Open

All Rights Reserved
Versión 15.0
Página 1 de 17
TABLA DE CONTENIDO
1 DEFINICIÓN..........................................................................................................4
1.1 Descripción de la situación a resolver.....................................................................4

1.2 Glosario....................................................................................................................... 4
1.3 Alcance funcional esperado......................................................................................5
1.3.1 Cobro de acciones de gestión de cobro..................................................................5
1.3.2 Consulta de atributos dinámicos en gestión de cobro.............................................5
1.4 Documentos adjuntos................................................................................................6

1.4.1 Impacto en MDP...................................................................................................... 6
1.4.2 Otros documentos................................................................................................... 6
2 EVALUACIÓN.......................................................................................................7
2.1 Alcance Funcional......................................................................................................7

2.1.1 Flujo de negocio “Gestión de cobro”........................................................................7
2.1.2 Constructora de liquidación de gestión de cobro.....................................................7
2.1.3 Verificar si el producto es facturable........................................................................7
2.1.4 Generación de factura en gestión de cobro.............................................................7
2.1.5 Solicitud “Gestión de cobro”....................................................................................7
2.1.6 Consulta de atributos dinámicos en gestión de cobro.............................................7
2.2 Arquitectura Funcional..............................................................................................8

2.3 Funcionalidades Impactadas....................................................................................8
2.4 Descripción de la Funcionalidad Impactada............................................................9
2.4.1 Flujo de negocio “Gestión de cobro”........................................................................9
2.4.2 Constructora de liquidación de gestión de cobro...................................................10
2.4.3 Verificar si el producto es facturable......................................................................10
2.4.4 Generación de factura en gestión de cobro...........................................................10
2.4.5 Solicitud “Gestión de cobro”..................................................................................11
2.4.6 Consulta de atributos dinámicos en gestión de cobro...........................................11
2.5 Consideraciones Especiales...................................................................................12

2.6 Tipo de Desarrollo....................................................................................................12
2.7 Vigencia.................................................................................................................... 12
3 DISEÑO...............................................................................................................14
3.1 Detalle de la operatividad........................................................................................14

3.2 Modelo Entidad Relación.........................................................................................14
3.2.1 Diagrama Entidad Relación...................................................................................14
3.2.2 Entidades de Base de Datos.................................................................................14
3.3 Modelo de Clases.....................................................................................................15

3.3.1 Diagrama de Clases.............................................................................................. 15
3.3.2 Descripción de las Clases.....................................................................................16
3.4 Diagramas de Comportamiento..............................................................................17

3.4.1 Diagramas de Secuencia.......................................................................................17

All Rights Reserved
Versión 15.0
Página 2 de 17
3.4.2 Diagramas de Actividades.....................................................................................17

3.4.3 Paquetes, Funciones o Procedimientos Almacenados..........................................18
3.5 Consideraciones para Migración............................................................................18

All Rights Reserved
Versión 15.0
Página 3 de 17
1 DEFINICIÓN
1.1 Descripción de la situación a resolver

Cuando el cliente incumple con el pago de sus facturas, las empresas realizan diferentes acciones
para tratar de recolectar el saldo adeudado, incluso después de que el servicio ha sido desconectado.
Actualmente, Open Smartflex permite que la empresa realice un cobro al cliente por las acciones que
ha tenido que realizar, sin embargo, este cobro solo es permitido mientras el servicio se encuentre
activo.
Con base en lo anterior, se requiere que Open Smartflex permita realizar el cobro de las actividades
de gestión de cobro, aun cuando el servicio sobre el cual se realizó la acción se encuentre retirado.
Adicionalmente, para poder eximir algunas cuentas con características particulares de los procesos de
gestión de cobro, se debe permitir realizar la consulta de los atributos dinámicos desde las reglas de
estos procesos.
1.2 Glosario
NA

All Rights Reserved
Versión 15.0
Página 4 de 17
1.3 Alcance funcional esperado
1.3.1 Cobro de acciones de gestión de cobro

REQ-1 En el proceso de liquidación de la solicitud “Gestión de cobro” el sistema debe generar los
cobros por las actividades realizadas, incluso si el servicio asociado se encuentra en un
estado no facturable.
Ilustración 1. Flujo actual de la solicitud de "Gestión de cobro"
REQ-2 Luego de generar los cobros sobre el producto seleccionado, el sistema debe validar si el
estado de corte del producto es facturable, de forma que:
a. Si el estado es facturable, el proceso de liquidación debe dejar los cobros sin factura
asociada, para ser incluidos en el proceso de facturación recurrente, tal como se soporta
actualmente.
b. Si el estado es no facturable, el proceso de liquidación debe generar una factura,

asociada a la cuenta del producto, de forma inmediata.
REQ-3 Para soportar el comportamiento descrito en los REQ-1 y REQ-2, el sistema debe contar
con un nuevo tipo de unidad, asociada al flujo de negocio de la solicitud “Gestión de
cobro”, que tenga la lógica para generar los cargos a productos no facturables, validar el
estado de corte del producto y generar la factura en caso de ser requerida.
Ilustración 2. Flujo sugerido de la solicitud de "Gestión de cobro"
1.3.2 Consulta de atributos dinámicos en gestión de cobro

REQ-4 Se debe publicar la función constructora “Obtener el atributo personalizado” para ser
usada en las reglas de acciones de gestión de cobro.
NOTA: la función constructora Obtener el atributo personalizado fue entregada en el

sao 420887.
All Rights Reserved
Versión 15.0
Página 5 de 17
1.4 Documentos adjuntos
1.4.1 Impacto en MDP

NA
1.4.2 Otros documentos

NA

All Rights Reserved
Versión 15.0
Página 6 de 17
2 EVALUACIÓN
2.1 Alcance Funcional
2.1.1 Flujo de negocio “Gestión de cobro”

Se modificará el flujo de negocio “Gestión de cobro”, el cual permitirá realizar el cobro de las
actividades de gestión de cobro para servicios que se encuentren en estado de corte facturable o no
facturable.
Ver operatividad de la opción.
2.1.2 Constructora de liquidación de gestión de cobro

Se creará la nueva constructora Liquidar solicitud de gestión de cobro(), la cual tendrá el mismo
comportamiento de la constructora Liquidar solicitud(), con la diferencia de que permitirá generar los
cobros por las actividades realizadas, incluso si el servicio asociado se encuentra en un estado no
facturable.
2.1.3 Verificar si el producto es facturable

Se creará la función constructora Verificar si el producto es facturable() que podrá ser utilizada a
nivel de la solicitud Gestión de cobro, con el fin de verificar si el producto es facturable o no. Si el
producto es facturable la función retornará el valor uno (1); en caso contrario retornará cero (0).
2.1.4 Generación de factura en gestión de cobro

Con el fin de generar factura para la cuenta en caso de que el producto procesado en la solicitud
tenga un estado de corte no facturable, se utilizará las función constructora existente Generar
facturas(). Adicionalmente, se utilizará la función Validar factura() con el fin de realizar la facturación
electrónica para los países que la requieren bajo el alcance actual de Open Smartflex.
2.1.5 Solicitud “Gestión de cobro”

Se modificará la solicitud “Gestión de cobro”, en la cual se adicionará el parámetro por tipo de solicitud
“Formato de extracción y mezcla para impresión de factura por solicitud”, con el fin de imprimir
facturación no recurrente.

Con el fin de cumplir con el REQ-04 se publicará la función constructora Obtener el atributo
personalizado() para ser usada en las reglas de acciones de gestión de cobro.

All Rights Reserved
Versión 15.0
Página 7 de 17
Requisito Se soportará mediante

REQ-001 Flujo “Gestión de cobro”
REQ-002 Solicitud “Gestión de cobro”
REQ-003
REQ-004 Tipo de configuración “Otras condiciones para la gestión de cobro”
2.2 Arquitectura Funcional
DOMINIOS MÓDULOS FUNCIONALIDADES PLUS

Dominio de la Compañía
Venta y
atención a
clientes
Venta
Punto Único de Atención
Solicitudes Posventa 1
Garantías Comerciales
Dominio del Cliente
Gestión de
ingresos
Recaudos Individuales
Gestión de cobro
Corte y Reconexión
Recaudos Masivos
Financiaciones
Cajas
2.3 Funcionalidades Impactadas

 Flujo “Gestión de cobro” (Modificación)
 Solicitud “Gestión de cobro” (Modificación)

All Rights Reserved
Versión 15.0
Página 8 de 17
2.4 Descripción de la Funcionalidad Impactada
2.4.1 Flujo de negocio “Gestión de cobro”
2.4.1.1 Prototipo Interfaz Gráfica de Usuario
Ilustración 3. Modificación en el flujo de gestión de cobro.
Nota: En la evaluación se puede presentar un prototipo que implica la propuesta de formas o pantallas. Tal propuesta es
susceptible de cambios en la etapa de diseño, que no impactan el alcance funcional comprometido, sino la forma de presentar
la información.
2.4.1.2 Operatividad de la opción

Se modificará el flujo de negocio “Gestión de cobro”, en el cual el proceso de Liquidación de gestión
de cobro genera los cobros sobre el producto seleccionado, incluso si el servicio asociado se
encuentra en un estado no facturable, luego el flujo de negocio valida el estado de corte, de forma
que: si el producto es facturable, el proceso de liquidación debe dejar los cobros sin factura asociada,
para ser incluidos en el proceso de facturación recurrente, tal como se soporta actualmente; en caso
de que el producto se encuentre no facturable, se debe generar una factura, asociada a la cuenta del
producto, de forma inmediata que agrupará estos cobros.
 Se adicionará la actividad “Liquidar gestión de cobro”, la cual tendrá la lógica para generar los
cargos, tanto a productos facturables como a no facturables.
 Se utilizará la constructora “Liquidar solicitud de gestión de cobro” en la regla de la actividad

“Liquidar gestión de cobro” para realizar liquidación a productos con estado de conexión tanto
facturable como no facturable.
 Se adicionará la actividad “Validar el estado de conexión del producto”, la cual valida si el

servicio se encuentra en estado facturable o no facturable.
 Se utilizará la constructora “Validar si el producto tiene un estado de conexión facturable” en la

regla de la actividad “Validar el estado de conexión del producto” con el fin de determinar si el
estado de conexión del producto asociado a la solicitud es facturable o no.
 Se adiciona la actividad “Generar factura”, la cual generará la factura de forma inmediata.

All Rights Reserved
Versión 15.0
Página 9 de 17
 Se implementa el servicio existente para generar la factura de forma inmediata, el cual se

utilizará en la regla de la actividad “Generación de factura”.
 Se implementa el servicio existente “Validar factura” para realizar el proceso de facturación

electrónica, se utilizará en la regla de la actividad “Generar factura”.
2.4.2 Constructora de liquidación de gestión de cobro

No aplica.

Se creará la nueva constructora Liquidar solicitud de gestión de cobro(), la cual tendrá el mismo
comportamiento de la constructora Liquidar solicitud(), con la diferencia de que permitirá generar los
cobros por las actividades realizadas, incluso si el servicio asociado se encuentra en un estado no
facturable.
Esta nueva constructora utilizará los mismos servicios de la constructora Liquidar solicitud(); sin
embargo, tendrá en cuenta los productos con estados de corte no facturables en su ejecución.
Esta constructora será publicada en el módulo Gestión de cobro con el tipo de configuración “Reglas
para flujos de negocio”.
2.4.3 Verificar si el producto es facturable

No aplica.

Se creará la función constructora Validar si el producto tiene un estado de conexión facturable(),
que podrá ser utilizada a nivel de la solicitud Gestión de cobro, con el fin de verificar si el producto es
facturable o no. Si el producto es facturable, la función retornará el valor uno (1); en caso contrario
retornará cero (0).
2.4.4 Generación de factura en gestión de cobro

No aplica.

Con el fin de generar factura para la cuenta cuando el producto a procesar en la solicitud tenga un
estado de corte no facturable, se utilizará la función constructora existente Generar facturas().
Adicionalmente, se utilizará la función Validar factura() con el fin de realizar la facturación electrónica
para los países que la requieren bajo el alcance actual de Open Smartflex.

All Rights Reserved
Versión 15.0
Página 10 de 17
2.4.5 Solicitud “Gestión de cobro”

No aplica.

Se modificará la solicitud “Gestión de cobro”, en la cual se adicionará el parámetro por tipo de solicitud
“Formato de extracción y mezcla para impresión de factura por solicitud”, con el fin de imprimir
facturación no recurrente.

No aplica.

Con el fin de cumplir con el REQ-04, se publicará la función constructora Obtener el atributo
personalizado() para ser usada en las reglas de acciones de gestión de cobro. Para esto, se
relacionará la constructora con el tipo de configuración “Otras condiciones para la gestión de cobro”.
Ilustración 4. Tipos de configuración de la función
Al agregar este tipo de configuración a la constructora, esta podrá ser utilizada en las reglas de
acciones de gestión de cobro como se ilustra a continuación:

All Rights Reserved
Versión 15.0
Página 11 de 17
Ilustración 5. Acciones por plan de gestión de cobro.
Ilustración 6. Reglas de acciones por plan de gestión de cobro.
2.5 Consideraciones Especiales

N/A
2.6 Tipo de Desarrollo

Producto.
2.7 Vigencia
La Evaluación entregada en este documento tiene una vigencia de 45 días después de los cuales es
posible que el alcance o los tiempos estimados requieran ser modificados debido a la evolución del
producto.
All Rights Reserved
Versión 15.0
Página 12 de 17
3 DISEÑO
Diligenciamiento opcional
Para el caso de un requerimiento que tiene SAO Entrega, debe indicarse el código del SAO entrega y
una breve descripción del mismo. Para el caso de un requerimiento que es el SAO Entrega, debe
indicarse los códigos de los SAOS que está cubriendo.
3.1 Detalle de la operatividad

Diligenciamiento opcional
Se diligencia cuando se requiere adicionar o modificar parámetros al producto para que el desarrollo
funcione correctamente. Especifique qué datos se deben definir en las tablas del producto para que el
requerimiento a implementar funcione satisfactoriamente
3.2 Modelo Entidad Relación
3.2.1 Diagrama Entidad Relación

Diligenciamiento Opcional
Se diligencia cuando se adicionan Entidades o cuando se adicionan o eliminan relaciones entre
entidades. Se debe diagramar el modelo entidad relación mostrando las nuevas tablas o las
relaciones creadas a partir de las nuevas llaves foráneas.
3.2.2 Entidades de Base de Datos

Se debe diligenciar cuando:
 Se adiciona o elimina una Entidad
 Se adicionan, eliminan o modifican columnas de una entidad existente
 Se adicionan, eliminan o modifican constraints (llaves primarias, foráneas o check)
 Se adicionan, eliminan o modifican índices
Entidad : <NOMBRE> – <Comentario>

Tipo Escal
Atributos Precisión Nulidad Llave Descripción
Dato a
Campo01 (PK/UK)
Campo02
Campo NN
Llave foránea: <Nombre Llave Foránea>

Entidad: <NOMBRE ENTIDAD> Entidad Referencia: <NOMBRE ENTIDAD>
Atributo Atributo Referencia
Campo01 Campo 01
Campo 02 Campo 02
Campo NN Campo NN

Indice : <NOMBRE> – <Comentario> Tipo de índice : <TIPO>
All Rights Reserved
Versión 15.0
Página 13 de 17
Atributos Nulidad Descripción

Campo01
Campo02
CampoNN
Se diligencia para detallar las relaciones de la tabla.
 Tipo: Define el tipo de relación.
- Foránea: Cuando es relación a otra tabla
- Tacita: Cuando se relaciona lógicamente con otra tabla pero no existe una relación física o
Llave.
- Cíclica: Cuando se relaciona con ella misma identificando un árbol n-ario o define un grafo.
 Origen: Nombre del campo origen de la tabla
 Referencia a: Nombre de la tabla destino
 Destino: Nombre del campo en la tabla destino
 Cardinalidad: Describe el tipo de relación si es uno a muchos o muchos a uno.
- 1 - 1: Relación de uno a uno
- 0..1 - 1: Relación de opcional en un lado de uno a uno.
- 0..* - 0..*: Relación opcional en ambos lados y de muchos a muchos.
- 1 - 1..*: Relación de uno a muchos
 Detalle: Describe el tipo de relación o amplia información sobre la misma.

Relaciones
Tipo Origen Referencia a Destino Cardinalidad Detalle
Foránea Campo01 NombreTabla01 Campo01 1 1 Nombre Llave Foránea
Tacita Campo02 NombreTabla02 Campo02 0..1 1 Detalle Relación lógica
Cíclica Campo03 NombreTabla03 Campo03 1 1..* Tipo de árbol o grafo.
3.3 Modelo de Clases
3.3.1 Diagrama de Clases

Se diligencia en caso de utilizar un diseño orientado a objetos, específicamente a Clases del lenguaje
de .NET que es orientado a objetos. Esto se encuentra discriminado así porque la arquitectura es
diferente para objetos (paquetes) PL/SQL. Se debe realizar el diagrama de clases que el diseño
plantee.

All Rights Reserved
Versión 15.0
Página 14 de 17
3.3.2 Descripción de las Clases

Se describe para las clases del numeral anterior (Diagrama de Clases). Se usa la plantilla de Clase
Nueva para cuando se adicionan objetos nuevos y se usa la plantilla de Clase Modificada, para
detallar los cambios de las clases que se alteran. Para las clases que se referencian en el Diagrama
pero no se alteran, no es necesario usar ninguna plantilla, pero si se deben referenciar en el
diagrama.
<Nombre Clase Nueva>

Objetivo <Describir el objetivo de la clase y su funcionalidad principal>
<Describir el espacio de nombres detallando la capa a la que
Espacio de Nombres
pertenece (UI, BL, DAL, Entities, etc.) >
Propiedades
Nombre Descripción
<Propiedad 1> : <Tipo> <Describir el objetivo de la propiedad 1>
… …
Métodos
<Método 1>([Parámetros:Tipo]): <Tipo>
Objetivo <Describir el objetivo y funcionamiento principal del método>
Parámetros
Nombre Descripción
<Parámetro 1>: <Tipo> <Describir el objetivo del parámetro y su posible contenido>
… …
Retorno
Nombre Descripción
<Retorno> <Tipo> <Describir lo que se retorna y su posible contenido>
Objetivo <Describir el objetivo y funcionamiento principal del método>
Parámetros
Nombre Descripción
… …
Retorno
All Rights Reserved
Versión 15.0
Página 15 de 17
Nombre Descripción
<Retorno> <Tipo> <Describir lo que se retorna y su posible contenido>
<Nombre Clase Modificada>

Propiedades
Nombre Cambio Descripción
<Propiedad 1> : <Tipo> Adición <Describir objetivo o razón del cambio>
<Propiedad 2> : <Tipo> Modificación <Describir objetivo o razón del cambio>
<Propiedad 3> : <Tipo> Eliminación <Describir objetivo o razón del cambio>
… … …
Métodos
Detalle <Describir el nuevo objetivo o detalle del cambio>
Parámetros
<Parámetro 1>: <Tipo> A-Adición <Describir objetivo o razón del cambio>
<Parámetro 2>: <Tipo> M-Modificación <Describir objetivo o razón del cambio>
<Parámetro 3>: <Tipo> E-Eliminación <Describir objetivo o razón del cambio>
… … …
Retorno
<Retorno> <Tipo> A/M/E <Describir objetivo o razón del cambio>
3.4 Diagramas de Comportamiento
3.4.1 Diagramas de Secuencia

Se especifica cuando se adicionan o modifican las relaciones entre elementos (Objetos o
componentes, procedimientos, funciones o paquetes de la base de datos o clases) creados o
modificados para la implementación del requerimiento o la solución del error y que interactúan en el
tiempo. Se deben usar para .Net y para PL/SQL. Use diagramas de secuencia del modelo UML.
3.4.2 Diagramas de Actividades

Se especifica cuando se requiera modelar el flujo de trabajo, paso a paso, de las actividades
necesarias para realizar la implementación del requerimiento o la solución del error. Use diagramas
de actividades del modelo UML.

All Rights Reserved
Versión 15.0
Página 16 de 17
3.4.3 Paquetes, Funciones o Procedimientos Almacenados

Se especifica cuando se adicionan o modifican procedimientos, funciones o paquetes de la base de
datos. Se describe el funcionamiento de los procedimientos, funciones o paquetes de la base de datos
creados o modificados para cumplir el requerimiento o solución de error.
EjemploDAA.xlsx
3.5 Consideraciones para Migración

Se especifica cuando la implementación del requerimiento involucra migración de datos. Especifique
las consideraciones de migración que se deben tener, como orden de tablas, aplicación de scripts,
archivos de datos, exports e imports de datos a la base de datos y/o Archivos de Sql*Loaders.

All Rights Reserved
Versión 15.0
Página 17 de 17

DAp 509090 Cobrar Licencis Unif

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DAp 509090 Cobrar Licencis Unif

Cargado por

Copyright:

Formatos disponibles

Definición Alcance y Arquitectura

Cobrar acciones de gestión de cobro a

Fecha solicitud: 24-Feb-2020

Fecha Autor Versión Referencia de Cambios

Copyright © 2010/09 Open

1.1 Descripción de la situación a resolver.....................................................................4

1.4 Documentos adjuntos................................................................................................6

2.1 Alcance Funcional......................................................................................................7

2.2 Arquitectura Funcional..............................................................................................8

2.5 Consideraciones Especiales...................................................................................12

3.1 Detalle de la operatividad........................................................................................14

3.3 Modelo de Clases.....................................................................................................15

3.4 Diagramas de Comportamiento..............................................................................17

Copyright © 2010/09 Open

3.4.2 Diagramas de Actividades.....................................................................................17

3.5 Consideraciones para Migración............................................................................18

Copyright © 2010/09 Open

1.1 Descripción de la situación a resolver

Copyright © 2010/09 Open

1.3 Alcance funcional esperado

1.3.1 Cobro de acciones de gestión de cobro

Ilustración 1. Flujo actual de la solicitud de "Gestión de cobro"

b. Si el estado es no facturable, el proceso de liquidación debe generar una factura,

Ilustración 2. Flujo sugerido de la solicitud de "Gestión de cobro"

1.3.2 Consulta de atributos dinámicos en gestión de cobro

NOTA: la función constructora Obtener el atributo personalizado fue entregada en el

1.4 Documentos adjuntos

1.4.1 Impacto en MDP

1.4.2 Otros documentos

Copyright © 2010/09 Open

2.1 Alcance Funcional

2.1.1 Flujo de negocio “Gestión de cobro”

Ver operatividad de la opción.

2.1.2 Constructora de liquidación de gestión de cobro

Ver operatividad de la opción.

2.1.3 Verificar si el producto es facturable

Ver operatividad de la opción.

2.1.4 Generación de factura en gestión de cobro

2.1.5 Solicitud “Gestión de cobro”

Ver operatividad de la opción.

2.1.6 Consulta de atributos dinámicos en gestión de cobro

Ver operatividad de la opción.

Copyright © 2010/09 Open

Requisito Se soportará mediante

2.2 Arquitectura Funcional

DOMINIOS MÓDULOS FUNCIONALIDADES PLUS

2.3 Funcionalidades Impactadas

Copyright © 2010/09 Open

2.4 Descripción de la Funcionalidad Impactada

2.4.1 Flujo de negocio “Gestión de cobro”

2.4.1.1 Prototipo Interfaz Gráfica de Usuario

Ilustración 3. Modificación en el flujo de gestión de cobro.

2.4.1.2 Operatividad de la opción

 Se utilizará la constructora “Liquidar solicitud de gestión de cobro” en la regla de la actividad

 Se adicionará la actividad “Validar el estado de conexión del producto”, la cual valida si el

 Se utilizará la constructora “Validar si el producto tiene un estado de conexión facturable” en la

 Se adiciona la actividad “Generar factura”, la cual generará la factura de forma inmediata.

Copyright © 2010/09 Open

 Se implementa el servicio existente para generar la factura de forma inmediata, el cual se

 Se implementa el servicio existente “Validar factura” para realizar el proceso de facturación

2.4.2 Constructora de liquidación de gestión de cobro

2.4.2.1 Prototipo Interfaz Gráfica de Usuario

2.4.2.2 Operatividad de la opción

2.4.3 Verificar si el producto es facturable