Proyecto Facturacion Electronica

INV/ Primer- Bloque Ingeniería de software I – Grupo I
Proyecto facturación electrónica
Presentado por:
Baquero Baquero Hector Javier
Hernadez Gomez Nelson Mauricio
Rodríguez Coca Andrés Felipe
Presentado a:
Herrera Jimenez Simar Enrique
Bogotá D.C. Colombia 11/03/2019

2
Tabla de contenido
Introducción .................................................................................................................................... 4
Planteamiento del problema ............................................................................................................ 5
Justificación .................................................................................................................................... 5
Objetivos ......................................................................................................................................... 6
General ........................................................................................................................................ 6
Específicos .................................................................................................................................. 6
Alcance ........................................................................................................................................... 6
Estado del arte ................................................................................................................................. 6
Antecedentes normativos ............................................................................................................ 7
Ley 223 de 1995. ..................................................................................................................... 7
Artículo 617 del Estatuto Tributario. ....................................................................................... 7
Decreto 1094 de 1996. ............................................................................................................. 8
Ley 962 de 2005. ..................................................................................................................... 8
Resolución DIAN 14465 de 2007. .......................................................................................... 9
Ley 1231 de 2008 – Factura Comercial................................................................................. 10
Antecedentes operativos ............................................................................................................ 10
Antecedentes CERTIFACTURA .............................................................................................. 10
Marco teórico ................................................................................................................................ 11
Modelo de desarrollo (Modelo incremental) ............................................................................. 11
Facturación electrónica ............................................................................................................. 13
Proceso actual ............................................................................................................................ 14
Proceso con la solución ............................................................................................................. 14
Metodología propuesta .............................................................................................................. 15
SCRUM. ................................................................................................................................ 15
Historias de usuario ................................................................................................................... 18
Requerimientos.......................................................................................................................... 21
Requerimientos de negocio ................................................................................................... 21
Requerimientos de usuario .................................................................................................... 21
Requerimientos funcionales .................................................................................................. 21
3
Requerimientos no funcionales ............................................................................................. 22

Casos de uso .............................................................................................................................. 22
CDU-001 ............................................................................................................................... 22
CDU-002 ............................................................................................................................... 23
CDU-003 ............................................................................................................................... 26
CDU-004 ............................................................................................................................... 27
CDU-005 ............................................................................................................................... 28
CDU-006 ............................................................................................................................... 29
Diagrama de clases .................................................................................................................... 30
Diagrama de secuencia .............................................................................................................. 30
Diagrama de estados.................................................................................................................. 31
Diagrama de despliegue ............................................................................................................ 32
Marco conceptual .......................................................................................................................... 33
Factura electrónica .................................................................................................................... 33
UML .......................................................................................................................................... 33
PYMES...................................................................................................................................... 33
Modelo incremental................................................................................................................... 33
SCRUM ..................................................................................................................................... 33
SPRINT ..................................................................................................................................... 33
Conclusión .................................................................................................................................... 34
Referencias .................................................................................................................................... 35
4
Introducción
El presente documento tiene como objetivo sustentar el proyecto de software para la
generación de facturas electrónicas, esto con el animo de conocer la facturación electrónica y un
modelo de desarrollo que permita llegar realizar este proyecto de la forma más adaptable posible
a los diversos cambios que pueden ocurrir en el desarrollo de software, así como establecer la
metodología que se va a utilizar en el desarrollo del mismo.

5
Planteamiento del problema

Se requiere crear un software que permita gestionar la facturación electrónica para PYMES
(pequeñas y medianas empresas), esto debido a que en Colombia se implementó la facturación
electrónica en respuesta a la modernización de los procesos que manejan las pymes en Colombia
ya que muchas de estas manejan sistemas que se consideran viejos y en muchos casos estos
serían obsoletos (El Tiempo, 2018)
Justificación
Se hace necesario contar con un sistema que permita a las pymes gestionar su facturación
electrónica para que al tener todo en un sistema y este a su vez este en línea disminuya el riesgo
en el manejo de información.
Implementar la facturación electrónica tiene los siguientes beneficios según el periódico El
Tiempo:
1. “Inmediatez en el proceso de entrega de la factura: esto va a redundar en un mejor flujo
de caja para todas las compañías, y un menor costo operativo.
2. Acceso a un mercado financiero y de crédito: al tener todas las facturas aprobadas y
aceptadas por los clientes se va a generar todo un esquema de factoring que ayudará
también con el flujo de caja de las compañías.
3. Disminución de costos de papel y almacenamiento físico de documentos.
4. Seguridad total de la información y la disponibilidad de la misma, debido a la
transparencia entre clientes y proveedores.
5. Propiciar ambientes de colaboración electrónica entre clientes y proveedores.

6
Tener todo sistematizado y en línea, agilizará el proceso de contabilización de facturas, la
disminución del riesgo, y garantizará que los sistemas de contabilidad y de información, tanto del
cliente como el proveedor, tengan la misma información0.” (El Tiempo, 2018)
Objetivos
General
Realizar un sistema de información que permita a empresas (pymes) acceder a este para que
puedan realizar la facturación electrónica de forma sencilla sin incurrir en los gastos que la
generación de un sistema propio pueda ocasionar.
Específicos
Realizar el levantamiento de información acerca de la facturación electrónica.
Listar los requerimientos de la solución que se va a brindar.
Generar los diagramas de UML (Unified Modeling Language).
Realizar los ajustes en las respectivas iteraciones de las entregas.
Alcance
El sistema de generación de facturas electrónicas pretende alcanzar a las pequeñas y medianas
empresas (PYMES) del sector financiero a nivel Bogotá.
Estado del arte

La factura electrónica nace como una iniciativa jurídica, apoyada en las herramientas
tecnológicas vigentes (Certificación digital basada en tecnología PKI), brindando respuesta a una
necesidad de competitividad, control, ahorro de insumos y simplificación de procesos. En este
orden de ideas, el presente análisis se desarrollará de acuerdo con un conjunto de términos que
exponen el estado del arte de la facturación electrónica en Colombia y en la región
(Latinoamérica) y ubican al lector en el contexto legal, normativo y tecnológico sobre el cual se
implementan los procesos de facturación electrónica.

7
Antecedentes normativos
A continuación, se enumeran un conjunto de antecedentes normativos de acuerdo con la
legislación colombiana y los cuales aportaron las bases para lograr definir los procesos de
Facturación Electrónica en Colombia:
Ley 223 de 1995.

Mediante esta ley 223 de 1995 se modificó el artículo 616-1 (factura o documento equivalente)
el cual define:
“La factura de venta o documento equivalente que se expida, en las operaciones que se realicen
con comerciantes, importadores o prestadores de servicios o en las ventas a consumidores
finales; son documentos equivalentes a la factura de venta: El tiquete de máquina registradora, la
boleta de ingreso a espectáculos públicos, la factura electrónica y los demás que señale el
Gobierno Nacional.” (Ley 223, 1995)
Artículo 617 del Estatuto Tributario.

Este artículo define principalmente los requisitos que se deben cumplir en el momento de
generar una factura de venta y los cuales se enumeran a continuación:
1. Estar denominada expresamente como factura de venta.
2. Apellidos y nombre o razón y NIT del vendedor o de quien presta el servicio junto con la
discriminación del IVA pagado.
3. Llevar un número que corresponda a un sistema de numeración consecutiva de facturas
de venta.
4. Fecha de su expedición.
5. Descripción específica o genérica de los artículos vendidos o servicios prestados.
6. Valor total de la operación.

8
7. El nombre o razón social y el NIT del impresor de la factura.
8. Indicar la calidad de retenedor del impuesto sobre las ventas
Cuando el contribuyente utilice un sistema de facturación por computador o máquinas
registradoras, con la impresión efectuada por tales medios se entienden cumplidos los requisitos
de impresión previa. El sistema de facturación deberá numerar en forma consecutiva las facturas
y se deberán proveer los medios necesarios para su verificación y auditoria. (Artículo 617)
Decreto 1094 de 1996.

Este decreto reglamenta el Art 616-1 del Estatuto Tributario, define la factura electrónica
como: “Documento computacional que soporta una transacción de venta de bienes o, prestación
de servicios, transferido bajo un lenguaje estándar universal denominado Edifact de un
computador a otro.”; y establece los parámetros de la factura electrónica como documento
equivalente a la factura de venta. (Decreto 1094, 1996)
Ley 962 de 2005.

El artículo 26 de la presente ley define: “la factura electrónica podrá expedirse, aceptarse,
archivarse y en general llevarse usando cualquier tipo de tecnología disponible, siempre y
cuando se cumplan todos los requisitos legales establecidos y la respectiva tecnología que
garantice su autenticidad e integridad desde su expedición y durante todo el tiempo de su
conservación”.
Factura electrónica.
Es el documento que soporta transacciones de venta de bienes y/o servicios, que para efectos
fiscales debe ser expedida, entregada, aceptada y conservada por y en medios y formatos
electrónicos.
9
Obligado a facturar.
Es la persona natural o jurídica que conforme a las normas tributarias tiene la obligación de
facturar y que, tratándose de la factura electrónica, la expide, generándola y numerándola por
medio de un sistema de facturación por computador.
Adquirente.
Es la persona natural o jurídica que como adquirente de bienes o servicios debe exigir factura
o documento equivalente y, que, tratándose de la factura electrónica, la acepta y conserva para su
posterior exhibición.
Tercero.
Es la persona natural o jurídica que presta al obligado a facturar y/o al adquirente, los
servicios inherentes al proceso de facturación, tales como: expedición, entrega, aceptación,
conservación y exhibición, y debe en consecuencia cumplir todos los requisitos y condiciones
exigidos en el presente decreto.
Número de la factura electrónica.

Es el número que obedece a un sistema de numeración consecutivo autorizado por la
Dirección de Impuestos y Aduanas Nacionales y corresponde al mismo autorizado para la factura
por computador. Tratándose de las empresas de servicios públicos domiciliarios deberá
solicitarse la respectiva autorización.
(Ley 962, 2005)
Resolución DIAN 14465 de 2007.

En esta resolución 14465 se exige que quienes expidan y acepten facturas electrónicas tengan
que estar haciendo reportes bimensuales a la DIAN con el consolidado de sus operaciones, y se
especifican los procedimientos para la generación del contenido técnico de control de las facturas
y de las notas crédito en general. (Resolución DIAN 14465, 2007)

10
Ley 1231 de 2008 – Factura Comercial

En esta ley se reglamenta la factura como título valor y como mecanismo de financiación para
los empresarios. (Ley 1231, 2008)
Antecedentes operativos
Las arquitecturas de Facturación Electrónica hasta la Ley 962 y el Decreto 1929 de 2007,
presentaban las siguientes características:
1. Las facturas generadas solamente eran válidas como documentos equivalentes a las
facturas físicas de venta si se transmite en una red de valor agregado.
2. Aplicaba para la factura de venta que no equivale a la factura cambiaria de compraventa.
3. Se debía utilizar el buzón electrónico (aunque resulte cuestionable su uso pues la red de
valor agregado genera su contenido y se mantiene actualizado)
4. Servía de soporte fiscal a las transacciones.
Es por ello por lo que se habilita en Colombia, tanto la factura de venta como la factura
cambiaria de compraventa; la cual permite mejorar del control financiero de la organización, la
capacidad de disponer de información precisa sobre el estado de las facturas emitidas y recibidas,
incrementa el control sobre los flujos financieros dentro de la organización y optimiza los
procesos de cobro mediante la integración con los medios de pago/entidades financieras,
reduciendo tiempos y automatizando las acciones de validación.
Antecedentes CERTIFACTURA
Bajo la perspectiva que ofrece Certicámara en el mercado Colombiano en donde su premisa es la
utilización de medios electrónicos como soporte transaccional para las compañías, se visualizó la
necesidad de obtener un producto que permita un mejoramiento de procesos y ahorro de costos
en la organización. Certicámara hizo una evaluación a una serie de compañías con el fin de
11
determinar el tipo de proceso que podría aportar con su nuevo producto utilizando como base un
esquema tecnológico, después de este estudio encontró una oportunidad en el proceso de
facturación. Una vez definida esta directriz estratégica Certicámara inició su proceso de
búsqueda de alternativas en el mercado mundial que ofrecieran este tipo de soluciones, después
de un exhausto proceso en donde se definieron parámetros de selección que garantizarán un alto
nivel de conocimiento en la solución se decidió que la mejor alternativa erala que ofrecía
AZURIAN S.A. con su herramienta DTE Plus.
Azurian es una de las primeras empresas certificadas por SII (Servicio de Impuestos Internos)
para ofrecer su solución de DTE. La primera empresa que utilizó esta solución fue la 13
Embotelladora Andina, quien a su vez fue el primer cliente aceptado por SII para operar con
Documentos Tributarios Electrónicos con fecha 23 de Abril del 2003 (www.sii.cl).
Actualmente más de 120 empresas son clientes de DTE Plus de Azurian solo en Chile, siendo
además la solución con mayor experiencia del mercado, ya que fue la primera solución
electrónica implementada en Chile. Hoy esta solución es responsable de la emisión del 48% de
total de documentos recepciones por el Servicio, sobre un total de 39.9 Millones de documentos
recepcionados por el SII (Servicio de Impuestos Internos).
Marco teórico
Modelo de desarrollo (Modelo incremental)
El modelo incremental propone una línea intermedia entre la modelo cascada y el modelo
evolutivo en donde se pretende que cada fase de este modelo tenga un ciclo completo y a medida
que este ciclo por fase se complete se pueda realizar una entrega que aporte valor al producto
final. (Politécnico Grancolombiano,2019)

12
En la figura 1 se observa que en cada fase (Entrega No #) se toman conceptos del modelo en
cascada pero que se realizan para la entrega de una parte del producto final; también se puede
observar que se realizan varias fases o ciclos en las que sus salidas se van agregando al producto
final.
Elaboración propia
Figura 1. Modelo incremental
Este modelo pretende trabajar directamente con el cliente ya que de esta manera se puede
expresar en cada fase la visión que tiene el cliente lo cual evitara que existan reprocesos al
realizar algo que no aporte valor a la visión general del producto propuesta por el cliente.
13
Se elige este modelo para el desarrollo del proyecto ya que en la materia de ingeniería de
software se divide por entregas que van generando valor al producto final, de estas entregas
saldría una retroalimentación por parte del profesor las cuales serán implementadas en la
siguiente iteración que se realizara para cada entrega.
También vemos en este modelo la oportunidad de mejorar el proyecto después de cada
entrega y aplicar las correcciones en el tiempo estimado en pro de que el producto final sea lo
solicitado por la materia.
Facturación electrónica
Sigue siendo un documento que soporta la compra y venta de artículos, bienes o servicios,
pero se maneja de forma electrónica a través de sistemas de información que validan y envían
está factura a la DIAN para su respectivo control. (Dian, 2019)
Dian (2019) Modelo de operación de la factura electrónica. [Ilustración]. Recuperado de

https://www.dian.gov.co/fizcalizacioncontrol/herramienconsulta/FacturaElectronica/Presentacion
/Paginas/Queesfacturaelectr%C3%B3nica.aspx
Figura 2. Modelo del funcionamiento de la facturación electrónica
14
En la Figura 2 se puede apreciar como funcionaria la facturación electrónica según lo
establecido por la DIAN, en donde la empresa genera la factura y a través de un medio propio o
por un proveedor tecnológico aprobado por la DIAN hacen él envió a esta entidad para el
respectivo control de esta factura.
Proceso actual
Elaboración propia
Proceso con la solución
Elaboración propia
15
Metodología propuesta
Para la realización de este proyecto se propone utilizar SCRUM como marco de trabajo, ya
que esta nos permite cumplir con el objetivo del modelo incremental que centra su objetivo en la
entrega de partes del producto que tengan valor sobre la entrega final.
SCRUM.
Scrum es un marco de trabajo el cual permite realizar entregas de formas iterativas e
incrementales sobre la base de un producto final, este proceso iterativo permite el manejo y
control de errores. (Deemer, 2012).
En la figura 3 se puede dar un vistazo al funcionamiento que propone el marco de trabajo
SCRUM.
Deemer (2012). Visión General de Scrum. [Ilustración] Recuperado de

http://scrumprimer.org/primers/es_scrumprimer20.pdf
Figura 3. Proceso del marco de trabajo SCRUM
16
Scrum propone roles, eventos e instrumentos que pretenden llevar el control del desarrollo del
proyecto de una forma transparente ante todos los miembros del equipo y demás entes
interesados en este.
En el desarrollo del proyecto de facturación electrónica se propone hacer uso de estas
herramientas para poder cumplir con las actividades propuestas para el desarrollo del mismo.
Teniendo en cuenta lo anterior utilizaremos los sprints para realizar cada uno de los objetivos
específicos propuestos previamente en este documento; cada uno de estos sprints realizara las
fases del proceso incremental las cuales enmarcan el análisis, diseño, desarrollo y pruebas de la
parte del producto que se requiere entregar.
Los sprints que se realicen durante el desarrollo y culminación del proyecto deberían cumplir
con la estructura en marcada en la Figura 4.
Elaboración propia
Figura 4. Sprint del proyecto facturación electrónica
17
Junto con la figura 4 se establece un plan de acción que se cumplirá con el fin de poder hacer
las entregas que se establecen como meta en el desarrollo del sprint.
Estas son las siguientes:
1. Reunión con el cliente para definir requerimientos.
2. Contextualización de los requerimientos con el equipo de desarrollo.
3. Establecer el mínimo producto viable a entregar al cliente, teniendo en cuenta los
requerimientos recibidos.
4. Establecer la cantidad de tiempo a emplear para la entrega del mínimo producto viable.
5. Reuniones diarias con el fin de detectar impedimentos para el desarrollo del producto en el
tiempo establecido.
6. Dado el caso de recibir un nuevo requerimiento después de haber establecido un mínimo
producto viable a entregar, se debe evaluar si este nuevo requerimiento afectaría los
tiempos de la entrega actual; si es así, dicho nuevo requerimiento se postergaría para una
entrega posterior.
7. Demostración al cliente del desarrollo realizado; recibiendo retroalimentación por parte del
cliente y las partes interesadas.
8. Ajustes según la retroalimentación recibida.
9. Y dado que es un modelo incremental e iterativo; regresamos a la primera acción la cual es
“Reunión con el cliente para definir requerimientos”.
Aunque en el desarrollo de scrum y la obtención de requerimientos agiles es de costumbre omitir
casos de usos o diseños documentales avanzados en nuestra adaptación se pretenden crear estos
diseños ya que son parte fundamental de lo solicitado como entregables por parte de la materia
de ingeniería de software.
18
Historias de usuario
Para el desarrollo de las actividades que se necesitan en la implementación del sprint definido
anterior mente se definieron las siguientes historias de usuario y sus respectivas tareas para llevar
a cabo un trabajo controlado que nos lleve a cumplir con el objetivo planteado en el módulo de
ingeniería de software y con los objetivos específicos definidos en este documento.
ID Historia de Usuario HU-01
Rol Como profesor del módulo de ingeniería de software
Característica/Funcionalidad Necesito la creación de los requerimientos del sistema
Razón/ Resultado Entender las necesidades del cliente y guardar el registro de
estas
Criterios de aceptación Requerimientos de negocio, requerimientos de usuario,
requerimientos funcionales y no funcionales
Asignado a Andrés Felipe Rodríguez Coca
ID Tarea T-01
Descripción Realizar el listado de los requerimientos del sistema y
clasificarlos en requerimientos de negocio, requerimientos
de usuario, requerimientos funcionales y no funcionales

19
Característica/Funcionalidad Necesito el caso de uso extendido
Razón/Resultado Comprender el diagrama de caso de uso
Criterios de aceptación Formato de casos de uso extendido basados en el que se
expuso en el transcurso del modulo
Asignado a Andrés Felipe Rodríguez Coca
ID Tarea T-01
Descripción Realizar el formato de caso de uso extendido describiendo
los escenarios posibles de cada caso de uso
Característica/Funcionalidad Necesito el diagrama de clases
Razón/Resultado Validar las clases que se utilizaran en el sistema
Criterios de aceptación Diagrama de clases
Asignado a
ID Tarea T-01
Descripción Realizar el diagrama de clases

20
Característica/Funcionalidad Necesito el diagrama de secuencia de la solución
Razón/Resultado Para ver la interacción de los objetos que se gestionaran en la
solución
Criterios de aceptación Diagrama de secuencia
Asignado a Nelson Mauricio
ID Tarea T-01
Descripción Realizar el diagrama de secuencia mostrando la interacción
de los diferentes sistemas que intervienen en la solución
Característica/Funcionalidad Necesito el diagrama de estados
Razón/Resultado Validar los estímulos de los objetos dentro del sistema
Criterios de aceptación Diagrama de estados
Asignado a Héctor Javier
ID Tarea T-01
21
Descripción Realizar el diagrama de estados
Requerimientos
De acuerdo a lo establecido en el módulo de ingeniería de software y la investigación que se
realizo para la facturación electrónica se establecieron los siguientes requerimientos.
Requerimientos de negocio
1. El servicio debe poder permitir la transferencia de la factura que realicemos en las
diferentes tiendas o puntos de facturación
2. El servicio debe notificar si se realizó o no el proceso de facturación electrónica
3. El servicio debe funcionar en los horarios de las tiendas o puntos de facturación
Requerimientos de usuario
1. Generar la factura a través de la aplicación que maneja el punto de facturación
2. Recibir la respuesta de la DIAN
3. Guardar la respuesta de la DIAN
4. Enviar correo al cliente del proceso
Requerimientos funcionales
1. Recibir la información de la factura desde la aplicación del cliente
2. Validar la información enviada
3. Envió de la factura al servicio de la DIAN
4. Recibir respuesta de la DIAN
5. Envió de correo al cliente(empresa) de la respuesta de la DIAN
6. Almacenar en base de datos

22
Requerimientos no funcionales
Seguridad
El servicio debe contar con autenticación esto por medio de usuario y contraseña únicos para
cada empresa, esta contraseña debe estar cifrada para brindar mayor seguridad y debe pedir
actualización cada 30 días.
Disponibilidad
El servicio debe estar activo las 24 horas del día escuchando las peticiones que envié el cliente y
las respuestas que generé la DIAN para que se puedan enviar los resultados de estas
transacciones lo más pronto posible.
Extensibilidad
Se requiere que el sistema reciba a futuro modificaciones que puedan ser aplicadas en el menor
tiempo posible esto debió a que la DIAN cambia sus normas constantemente y esto ocasiona
cambios como envíos de nuevos campos de la factura o reducción de estos.
Escalabilidad
El servicio debe poder adaptarse a las demandas de las distintas empresas esto con el ánimo de
que este soporte la cantidad de envíos facturas que se puedan realizar en el transcurso del día.
Casos de uso
Los siguientes son los casos de uso en formato extendido que explican el funcionamiento que
debe tener el sistema de facturación.
CDU-001
ID caso de CDU- Nombre Recibir información de la factura
uso 001
23
Objetivo en contexto El servicio debe recibir la información de la factura realizada
(Resumen) por el cliente
Actores participantes Aplicación del cliente, servicio facturación
Pre - Condiciones La aplicación del cliente debe tener usuario y contraseña
Condiciones de éxito El servicio recibe la información de la factura del cliente.
Flujo normal
El cliente envía la factura junto con las credenciales
El servicio valida las credenciales
Si las credenciales son incorrectas (Extensión 1)
El servicio valida que la información obligatoria no esté vacía o sea nula
Si hay información vacía o nula (Extensión 2)
Extensiones
1. El sistema retorna un error de autenticación
2. El sistema retorna un error de información
CDU-002
ID caso de CDU- Nombre Validar información de la factura
uso 002
Objetivo en contexto Validar las reglas de negocio que se aplican sobre la
(Resumen) información de la factura.
Actores participantes Servicio facturación
Pre - Condiciones La información ha sido recibida por el servicio
Condiciones de éxito La información enviada es correcta

24
Flujo normal
Se valida el número y serie de la factura
Si no es válida (Extensión 1)
Se valida que la fecha de expedición tenga el formato dd/mm/yyyyy hh:mm:ss
Si no es válida (Extensión 2)
Se valida el NIF del emisor
Si no es válido (Extensión 3)
Se valida el NIF del receptor
Dirección del emisor con formato (calle, carrera, diagonal, transversal) / numero /
numero - numero
Dirección del receptor con formato (calle, carrera, diagonal, transversal) / numero /
numero - numero
Se valida el departamento del emisor
Se valida la ciudad del emisor
Se valida el departamento del receptor
Se valida la ciudad del receptor

25
Se valida correo electrónico del emisor
Se valida correo electrónico del receptor
Se valida el número telefónico del emisor
Se valida el número telefónico del receptor
Se validan los valores de la factura
Si no son válidos (Extensión 15)
Extensiones
1. El sistema retorna error con el mensaje “Número de factura no valido”
2. El sistema retorna error con el mensaje “Fecha de la factura no valida”
3. El sistema retorna error con el mensaje “NIF del emisor no valido”
4. El sistema retorna error con el mensaje “NIF del receptor no valido”
5. El sistema retorna error con el mensaje “Dirección del emisor no valida”
6. El sistema retorna error con el mensaje “Dirección del receptor no valida”
7. El sistema retorna error con el mensaje “Departamento del emisor no valido”
8. El sistema retorna error con el mensaje “Ciudad del emisor no valido”
9. El sistema retorna error con el mensaje “Departamento del receptor no valido”
10. El sistema retorna error con el mensaje “Ciudad del receptor no valido”
11. El sistema retorna error con el mensaje “Correo del emisor no valido”
12. El sistema retorna error con el mensaje “Correo del receptor no valido”
26
13. El sistema retorna error con el mensaje “Teléfono del emisor no valido”
14. El sistema retorna error con el mensaje “Teléfono del receptor no valido”
15. El sistema retorna error con el mensaje “Valores de la factura no validos”
CDU-003
ID caso de CDU- Nombre Envío de la factura a la DIAN
uso 003
Objetivo en contexto El servicio debe enviar a la DIAN la información de la
(Resumen) factura
Actores participantes Servicio facturación, DIAN
Pre - Condiciones La información fue validada y es correcta
Condiciones de éxito El servicio envía la información a la DIAN
Flujo normal
El servicio se autentica ante la DIAN con usuario y contraseña
Se crea el XML que se va a enviar a la DIAN
Se hace él envió del XML a la DIAN
Si no se conecta con el servicio (Extensión 2)
Si se hace el envío y no retorna algún error se muestra el mensaje “Se envió la factura a
la DIAN”
Si retorna algún mensaje de error (Extensión 3)
Extensiones
1. El sistema retorna un error de autenticación de la DIAN

27
2. El sistema retorna un error con el mensaje “No se puede conectar a la DIAN en
este momento”
3. El sistema retorna el mensaje que envió la DIAN
CDU-004
ID caso de CDU- Nombre Recibir respuesta de la DIAN
uso 004
Objetivo en contexto El servicio debe recibir la respuesta que genere la DIAN
(Resumen)
Actores participantes DIAN, servicio facturación
Pre - Condiciones La aplicación del cliente debe tener usuario y contraseña
Condiciones de éxito El servicio recibe la respuesta de la DIAN.
Flujo normal
El servicio debe estar escuchando las respuestas de la DIAN
El servicio recupera el XML de respuesta que envía la DIAN
Si no lo recupera en un plazo de 48 horas (Extensión 1)
El servicio registra en el log la respuesta de la DIAN
El servicio envía la respuesta de la DIAN a la aplicación del cliente
Extensiones
1. El sistema retorna un error con el mensaje “La DIAN no retorno respuesta a la
factura #00000”
28
CDU-005
ID caso de CDU- Nombre Enviar correo
uso 005
Objetivo en contexto El servicio debe enviar un correo al cliente con la respuesta
(Resumen) de la DIAN
Actores participantes Servicio de facturación
Pre - Condiciones El servicio está activo
Condiciones de éxito El servicio envía el correo al cliente
Flujo normal
El servicio valida que tenga los datos de conexión a un servidor de correo
Si no tiene o no son válidos (Extensión 1)
El servicio crea el cuerpo del correo con el XML de la respuesta de la DIAN y el mensaje
de “Respuesta recibida”
El servicio adjunta la información de la factura que se había enviado previamente
El servicio envía el correo
Si el servicio no envía el correo (Extensión 2)
Extensiones
1. El servicio registra en el log un mensaje “El servidor de correo es invalido”
2. El servicio registra en un log el mensaje “No se pudo enviar el correo electrónico
al cliente”
2.1.El servicio guarda los datos del correo en un documento en el servidor

29
CDU-006
ID caso de CDU- Nombre Guardar en base de datos
uso 006
Objetivo en contexto El servicio debe guardar la información en la base de datos
(Resumen) para una posterior consulta
Actores participantes Servicio de facturación
Pre - Condiciones El servicio está activo
Condiciones de éxito El servicio guarda la información de la respuesta y la factura
en la base de datos.
Flujo normal
El servicio envía la información a la base de datos provista por el cliente.
Si no la registra (Extensión 1)
Extensiones
1. El servicio registra en el log un mensaje “No se pudo conectar a la base de datos”

30
Diagrama de clases
Elaboración propia
Figura 5. Diagrama de clases
Diagrama de secuencia
Elaboración propia
Figura 6. Diagrama de secuencia
31
El diagrama de secuencia presentado, se basa en las interacciones que tiene el sistema con los
stakeholders (clientes, el proveedor de facturación electrónica y la DIAN), siendo el sistema el
interlocutor entre todas las partes interesadas en el flujo de trabajo. Queda en evidencia que el
sistema actúa como intermediario o medio de transporte de la factura simple, hasta transformarse
en factura electrónica con la consecución del CUFE (código único de facturación electrónica).
Diagrama de estados
Elaboración propia
Figura 7. Diagrama de estados
32
Diagrama de despliegue
Elaboración propia
Figura 8. Diagrama de despliegue
33
Marco conceptual
Aunque a través del documento se han hecho referencias y definiciones a los conceptos que se
verán a continuación se hace necesario hacer una breve especificación de los mismos, esto con el
ánimo de que se pueda aclarar el término y pueda brindar al lector una visión clara y concisa de
lo que es cada uno de estos.
Factura electrónica
Este es un documento que al igual que la factura física soporta las transacciones que se realizan
en la compra y venta de bienes y/o servicios pero que se maneja a través de medios electrónicos.
(Bancolombia, 2018).
UML
El lenguaje unificado de modelado o UML consisten en una cantidad de diagramas que pretende
modelar la arquitectura, el diseño y la implementación soluciones de software complejas.
(Lucidchart, 2019).
PYMES
Son las empresas que son consideradas como pequeñas o medianas.
Modelo incremental
Modelo intermedio entre el modelo en cascada y el evolutivo en donde se pretenden realizar
entregas de funcionalidades que agreguen valor al producto final, esto mediante iteraciones en
las cuales se ejecutan los componentes definidos para el correcto desarrollo de la funcionalidad.
(Politécnico Grancolombiano, 2019)
SCRUM
Marco de trabajo ágil para el desarrollo y mantenimiento de productos complejos a través de
procesos iterativos incrementales. (Schwaber y Sutherland, 2013)
SPRINT
Ciclos de trabajo dentro de SCRUM en los cuales se realiza el desarrollo de lo planeado y se
intenta cumplir la meta definida para el entregable.
34
Conclusión
El diseño del documento de arquitectura de software marca las pautas para un correcto y
adecuado desarrollo de un sistema de información que utiliza dicho software, este documento
específica a nivel técnico lo necesario para llevar a cabo la idea que tiene el cliente y poder
plasmarla para que los desarrolladores y analistas comprendan que es lo que se necesita hacer y
cómo se va a trabajar para lograr estos objetivos.
Para lograr plasmar la idea del cliente y llevarla a un nivel técnico se necesita escoger un modelo
de desarrollo, una metodología y tener un conocimiento amplio del negocio del cliente y como
este funciona en la actualidad además se debe tener una visión a futuro de como impactara esta
nueva implementación el desarrollo normal de las actividades que realiza la empresa en su labor
cotidiana.
35
Referencias
Articulo 617 Requisitos de la factura de venta. Estatuto Tributario Nacional. Recuperado de
https://estatuto.co/?e=436
Bancolombia. (2018). Qué es la factura electrónica: beneficios y retos en Colombia.
Recuperado de https://www.grupobancolombia.com/wps/portal/negocios-
pymes/actualizate/administracion-y-finanzas/factura-
electronica?gclid=CjwKCAiAiJPkBRAuEiwAEDXZZUySqVmT2wp40Yz8xPD3Y2Ih2Iid4Czr
tu2dt_ZQNkKH_-ml_v6AXxoCAtEQAvD_BwE
Decreto 1094. Diario Oficial 42814. 21 de junio de 1996. Recuperado de
http://www.funcionpublica.gov.co/eva/gestornormativo/norma.php?i=7457
DIAN. (2019). ¿Qué es la factura electrónica? Recuperado de
https://www.dian.gov.co/fizcalizacioncontrol/herramienconsulta/FacturaElectronica/Presentacion
/Paginas/Queesfacturaelectr%C3%B3nica.aspx
El Tiempo. (15 de febrero de 2018). ¿Por qué será obligatoria la factura electrónica en
Colombia? El Tiempo. Recuperado de https://www.eltiempo.com/colombia/por-que-sera-
obligatoria-la-factura-electronica-en-colombia-182834
Ken Schwaber y Jeff Sutherland. (2013). La guía de Scrum. Recuperado de
https://www.scrumguides.org/docs/scrumguide/v1/scrum-guide-es.pdf
Ley 223. Diario Oficial No. 42.160. 22 de diciembre de 1995. Recuperado de
http://www.secretariasenado.gov.co/senado/basedoc/ley_0223_1995.html
Ley 962. Diario Oficial No. 46.023. 06 de septiembre de 2005. Recuperado de
http://www.secretariasenado.gov.co/senado/basedoc/ley_0962_2005.html
Ley 1231. DIARIO OFICIAL. AÑO CXLIV. N. 47053. 17 de julio de 2008. Recuperado de
https://co.groupseres.com/images/d/rs/Ley-1231-2008.pdf
Lucidchart. (2019). Qué es el lenguaje unificado de modelado (UML). Recuperado de
https://www.lucidchart.com/pages/es/que-es-el-lenguaje-unificado-de-modelado-uml
Politécnico Grancolombiano. LECTURA UNO: PROCESOS DE INGENIERÍA DE
SOFTWARE. HISTORIA Y PRINCIPALES PROPUESTAS. Politécnico Grancolombiano
Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde. (2012). Una introducción
básica a la teoría y práctica de Scrum Versión 2.0. Recuperado de
http://scrumprimer.org/primers/es_scrumprimer20.pdf
Resolución DIAN 1446. 28 de noviembre de 2007. Recuperado de
https://co.groupseres.com/images/d/rs/RESOLUCION-14465-2007.pdf

Proyecto Facturacion Electronica

Cargado por

Copyright:

Formatos disponibles

Proyecto Facturacion Electronica

Cargado por

Información del documento

Descripción original:

Título original

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

Proyecto Facturacion Electronica

Cargado por

Copyright:

Formatos disponibles

INV/ Primer- Bloque Ingeniería de software I – Grupo I

Proyecto facturación electrónica

Baquero Baquero Hector Javier

Hernadez Gomez Nelson Mauricio

Rodríguez Coca Andrés Felipe

Herrera Jimenez Simar Enrique

Bogotá D.C. Colombia 11/03/2019

Requerimientos no funcionales ............................................................................................. 22

El presente documento tiene como objetivo sustentar el proyecto de software para la

generación de facturas electrónicas, esto con el animo de conocer la facturación electrónica y un

metodología que se va a utilizar en el desarrollo del mismo.

Planteamiento del problema

(pequeñas y medianas empresas), esto debido a que en Colombia se implementó la facturación

serían obsoletos (El Tiempo, 2018)

Implementar la facturación electrónica tiene los siguientes beneficios según el periódico El

1. “Inmediatez en el proceso de entrega de la factura: esto va a redundar en un mejor flujo

de caja para todas las compañías, y un menor costo operativo.

2. Acceso a un mercado financiero y de crédito: al tener todas las facturas aprobadas y

también con el flujo de caja de las compañías.

3. Disminución de costos de papel y almacenamiento físico de documentos.

4. Seguridad total de la información y la disponibilidad de la misma, debido a la

transparencia entre clientes y proveedores.

5. Propiciar ambientes de colaboración electrónica entre clientes y proveedores.

Tener todo sistematizado y en línea, agilizará el proceso de contabilización de facturas, la

cliente como el proveedor, tengan la misma información0.” (El Tiempo, 2018)

generación de un sistema propio pueda ocasionar.

empresas (PYMES) del sector financiero a nivel Bogotá.

Estado del arte

necesidad de competitividad, control, ahorro de insumos y simplificación de procesos. En este

exponen el estado del arte de la facturación electrónica en Colombia y en la región

(Latinoamérica) y ubican al lector en el contexto legal, normativo y tecnológico sobre el cual se

implementan los procesos de facturación electrónica.

Facturación Electrónica en Colombia:

Ley 223 de 1995.

con comerciantes, importadores o prestadores de servicios o en las ventas a consumidores

finales; son documentos equivalentes a la factura de venta: El tiquete de máquina registradora, la

Gobierno Nacional.” (Ley 223, 1995)

Artículo 617 del Estatuto Tributario.

generar una factura de venta y los cuales se enumeran a continuación:

1. Estar denominada expresamente como factura de venta.

discriminación del IVA pagado.

3. Llevar un número que corresponda a un sistema de numeración consecutiva de facturas

5. Descripción específica o genérica de los artículos vendidos o servicios prestados.

6. Valor total de la operación.

7. El nombre o razón social y el NIT del impresor de la factura.

8. Indicar la calidad de retenedor del impuesto sobre las ventas

Cuando el contribuyente utilice un sistema de facturación por computador o máquinas

Decreto 1094 de 1996.

de servicios, transferido bajo un lenguaje estándar universal denominado Edifact de un

computador a otro.”; y establece los parámetros de la factura electrónica como documento

equivalente a la factura de venta. (Decreto 1094, 1996)

Ley 962 de 2005.

archivarse y en general llevarse usando cualquier tipo de tecnología disponible, siempre y

garantice su autenticidad e integridad desde su expedición y durante todo el tiempo de su

facturar y que, tratándose de la factura electrónica, la expide, generándola y numerándola por

medio de un sistema de facturación por computador.

o documento equivalente y, que, tratándose de la factura electrónica, la acepta y conserva para su

servicios inherentes al proceso de facturación, tales como: expedición, entrega, aceptación,