Montalvan MSA-SDinterbacional

FACULTAD DE INGENIERÍA
ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE

SISTEMAS
Sistema web para la facturación electrónica centralizada en la empresa

CUETO S.A.C.
TESIS PARA OBTENER EL TÍTULO PROFESIONAL DE

Ingeniero de Sistemas
AUTOR:
Br. Montalvan Merino, Samuel Antony (ORCID: 0000-0002-4160-0200)
ASESOR:
Ing. Pérez Farfán, Iván Martin (ORCID: 0000-0001-5833-9400)
LÍNEA DE INVESTIGACIÓN:
Sistemas de Información y Comunicaciones
LIMA - PERÚ
2019
DEDICATORIA
El siguiente trabajo está dedicado a mi

familia, por todo el apoyo brindado a lo
largo de los 5 años de estudio. Este apoyo
ha sido de mucha ayuda para poder llevar
a cabo mi carrera profesional.
ii
AGRADECIMIENTO
Gracias a Dios por permitirme
tener el tiempo y las fuerzas
para llevar a cabo mi carrera
profesional.
A mi familia, por la ayuda
emocional y económica
brindada a lo largo de este
camino.
Y a mis asesores y docentes
que a lo largo de mi carrera
han sido de mucha ayuda
para mi desarrollo
profesional.
iii
PÁGINA DEL JURADO
iv
DECLARATORIA DE AUTENTICIDAD
v
PRESENTACIÓN
Señores miembros del Jurado:
Dando cumplimiento a las normas establecidas en el Reglamento de Grados y

Títulos sección de Pregrado de la Universidad César Vallejo para la experiencia
curricular de Desarrollo del Proyecto de Investigación, presento el trabajo de
investigación pre-experimental denominado: “Sistema Web para la Facturación
Electrónica Centralizada en la empresa CUETO S.A.C.”.
La investigación, tiene como propósito fundamental: determinar cómo influye un

Sistema Web en la facturación electrónica centralizada en la empresa CUETO
S.A.C.
La presente investigación está dividida en siete capítulos:

En el primer capítulo se expone el planteamiento del problema: incluye formulación
del problema, los objetivos, la hipótesis, la justificación, los antecedentes y la
fundamentación científica. En el segundo capítulo, que contiene el marco
metodológico sobre la investigación en la que se desarrolla el trabajo de campo de
la variable de estudio, diseño, población y muestra, las técnicas e instrumentos de
recolección de datos y los métodos de análisis. En el tercer capítulo corresponde a
la interpretación de los resultados. En el cuarto capítulo trata de la discusión del
trabajo de estudio. En el quinto capítulo se construye las conclusiones, en el sexto
capítulo las recomendaciones y finalmente en el séptimo capítulo están las
referencias bibliográficas.
Señores miembros del jurado espero que esta investigación sea evaluada y
merezca su aprobación.
vi
ÍNDICE
DEDICATORIA .................................................................................................................... ii
AGRADECIMIENTO .......................................................................................................... iii
PRESENTACIÓN ............................................................................................................... vi
PÁGINA DEL JURADO .......................................................................................................v
DECLARATORIA DE AUTENTICIDAD ..............................................................................vi
ÍNDICE ................................................................................................................................ vii
ÍNDICE DE TABLAS........................................................................................................... x
ÍNDICE DE FIGURAS ........................................................................................................ xi
RESUMEN .......................................................................................................................... xii
ABSTRACT ....................................................................................................................... xiii
I. INTRODUCCIÓN .......................................................................................................... 1
1.1. Realidad Problemática .......................................................................................... 1
1.2. Trabajos previos ..................................................................................................... 2
1.3. Teorías relacionadas al tema .............................................................................. 5
1.3.1. Sistema Web ..................................................................................................... 5
1.3.2. Lenguaje de Programación .......................................................................... 6
1.3.3. ASP...................................................................................................................... 6
1.3.4. Servidor Web .................................................................................................... 7
1.3.5. Servidor IIS........................................................................................................ 7
1.3.6. Base de Datos .................................................................................................. 7
1.3.6.1. MYSQL ........................................................................................................ 7
1.3.6.2. SQL Server ................................................................................................. 8
1.3.6.3. PostgreSQL ............................................................................................... 8
1.3.6.4. Cuadro comparativo de Sistemas Gestores de base de datos ... 9
1.3.7. Metodología de desarrollo de software ................................................... 10
1.3.7.1. RUP ............................................................................................................ 10
1.3.7.2. ICONIX ....................................................................................................... 11
1.3.7.3. SCRUM ...................................................................................................... 12
1.3.7.4. Validación de Metodología de Desarrollo de Software................ 13
1.3.8. Facturación Electrónica Centralizada...................................................... 13
1.4. Formulación del problema ................................................................................. 19
1.4.1. Problema Principal........................................................................................ 19
1.4.2. Problemas secundarios ............................................................................... 19
1.5. Justificación del estudio .................................................................................... 19
1.5.1. Justificación Tecnológica ........................................................................... 19
vii
1.5.2. Justificación Económica ............................................................................. 20
1.5.3. Justificación Institucional ........................................................................... 20
1.5.4. Justificación Operativa ................................................................................ 21
1.6. Hipótesis ................................................................................................................. 21
1.6.1. Hipótesis General .......................................................................................... 21
1.6.2. Hipótesis Específicas ................................................................................... 21
1.7. Objetivo ................................................................................................................... 21
1.7.1. Objetivo General ............................................................................................ 21
1.7.2. Objetivos Específicos .................................................................................. 21
II. MÉTODO ..................................................................................................................... 22
2.1. Diseño de investigación ..................................................................................... 22
2.1.1. Tipo de Estudio .............................................................................................. 22
2.1.2. Diseño de Estudio ......................................................................................... 22
2.1.3. Método de Investigación ............................................................................. 23
2.2. Variables y operacionalización ......................................................................... 24
2.2.1. Definición Conceptual.................................................................................. 24
2.2.2. Definición Operacional ................................................................................ 25
2.3. Población y muestra ............................................................................................ 27
2.3.1. Población ......................................................................................................... 27
2.3.2. Muestra ............................................................................................................ 27
2.3.3. Muestreo .......................................................................................................... 28
2.4. Técnicas e instrumentos de recolección de datos, validez y
confiabilidad ..................................................................................................................... 29
2.4.1. Técnica de Recolección de datos ............................................................. 29
2.4.2. Instrumento de Recolección de datos ..................................................... 29
2.4.3. Validez y confiabilidad ................................................................................. 30
2.5. Métodos de análisis de datos............................................................................ 32
2.6. Aspectos éticos .................................................................................................... 34
III. RESULTADOS........................................................................................................ 34
3.1. Análisis Descriptivo ......................................................................................... 34
3.2. Análisis Inferencial ........................................................................................... 37
3.3. Prueba de Hipótesis ......................................................................................... 42
IV. DISCUSIÓN ............................................................................................................. 50
V. CONCLUSIONES ................................................................................................... 52
VI. RECOMENDACIONES.......................................................................................... 53
viii
VII. REFERENCIAS ...................................................................................................... 54
ANEXOS ............................................................................................................................. 61
ANEXO 01 – MATRIZ DE CONSISTENCIA ................................................................. 62
ANEXO 02 – ENTREVISTA............................................................................................. 63
ANEXO 03 – CARTA DE ACEPTACIÓN ...................................................................... 65
ANEXO 04 – ESPINA DE ISHIKAWA ........................................................................... 66
ANEXO 05 – PRE-TEST INDICADOR PORCENTAJE DE INCIDENCIAS EN
EMISIONES ........................................................................................................................ 67
ANEXO 06 – PRE-TEST INDICADOR IMPACTO DE GASTOS
OPERACIONALES ........................................................................................................... 68
ANEXO 07 – POST-TEST INDICADOR PORCENTAJE DE INCIDENCIAS EN
EMISIONES ........................................................................................................................ 69
ANEXO 08 – POST-TEST INDICADOR IMPACTO DE GASTOS
OPERACIONALES ........................................................................................................... 70
ANEXO 09 – VALIDACIÓN DE EXPERTOS DE METODOLOGÍA DE
DESARROLLO DE SOFTWARE ................................................................................... 71
ANEXO 10 – VALIDACIÓN DE EXPERTO DE INDICADORES .............................. 74
ANEXO 11 – Desarrollo de Metodología SCRUM .................................................... 80
ix
ÍNDICE DE TABLAS
Tabla 01 Cuadro comparativo de sistemas gestores de base de datos ........... 9

Tabla 02 Validación de expertos de metodología de desarrollo de software 13
Tabla 03 Matriz Operacional de la variable ....................................................... 25
Tabla 04 Indicadores ........................................................................................... 26
Tabla 05 Población .............................................................................................. 27
Tabla 06 Muestra ................................................................................................. 28
Tabla 7 Validación de expertos Indicador Impacto de gastos operacionales 30
Tabla 08 Validación de expertos Indicador Porcentaje de incidencias en
emisiones ............................................................................................................. 30
Tabla 09 Correlación de Pearson Indicador Porcentaje de incidencias en
emisiones ............................................................................................................. 31
Tabla 10 Correlación de Pearson Indicador impacto de gastos operacionales
.............................................................................................................................. 31
Tabla 11 Medidas descriptivas del Impacto de Gastos Operacionales antes y
después de implementar el Sistema Web ......................................................... 35
Tabla 12 Medidas descriptivas del Porcentaje de incidencias en emisión en la
facturación electrónica centralizada antes y después de implementar el
Sistema Web ........................................................................................................ 36
Tabla 13 Prueba de Normalidad del impacto de gastos operacionales antes y
después de la implementación del Sistema Web ............................................. 38
Tabla 14 Prueba de Normalidad del porcentaje de gastos operacionales antes
y después de la implementación del Sistema Web .......................................... 40
Tabla 15 Prueba de T-Student para el impacto de gastos operacionales en la
Sistema Web ........................................................................................................ 43
Tabla 16 Prueba de T-Student para el porcentaje de incidencias en emisión de
la facturación electrónica centralizada antes y después de implementar el
Sistema Web ........................................................................................................ 47
x
ÍNDICE DE FIGURAS
Figura 1 Fórmula Indicador Impacto de Gastos Operacionales...................... 16

Figura 2 Fórmula Indicador Porcentaje de incidencias en emisión ................ 18
Figura 3 Fórmula Diseño Pre Experimental ...................................................... 23
Figura 4 Fórmula Muestra Población Conocida ............................................... 27
Figura 5 Impacto de Gastos Operacionales antes y después de implementar el
Sistema Web ........................................................................................................ 36
Figura 6 Porcentaje de Incidencias en Emisión antes y después de
implementar el Sistema Web .............................................................................. 37
Figura 7 Prueba de Normalidad del Impacto de Gastos Operacionales antes de
implementar el Sistema Web .............................................................................. 39
Figura 8 Prueba de Normalidad del Impacto de Gastos Operacionales después
de implementar el Sistema Web......................................................................... 39
Figura 9 Prueba de Normalidad del Porcentaje de Incidencias en Emisión antes
de implementar el Sistema Web......................................................................... 41
Figura 10 Prueba de Normalidad del Porcentaje de Incidencias en Emisión
después de implementar el Sistema Web ......................................................... 41
Figura 11 Prueba T-Student – Impacto de Gastos Operacionales .................. 45
Figura 12 Prueba T-Student – Porcentaje de Incidencias en Emisión ............ 49
xi
RESUMEN
La presente tesis detalla el desarrollo de un Sistema Web para la facturación

electrónica centralizada de la empresa CUETO S.A.C., debido a que la situación
empresarial previa a la aplicación del sistema presentaba deficiencias en cuanto a
la disminución de los impactos operacionales y el porcentaje de incidencias en
emisión. El objetivo de esta investigación fue determinar la influencia de un Sistema
Web para la facturación electrónica centralizada de la empresa CUETO S.A.C.
Por ello, se describe previamente aspectos teóricos de lo que es la facturación
electrónica centralizada, así como las metodologías que se utilizaron para el
desarrollo del Sistema Web. Para el desarrollo del Sistema Web, se empleó la
metodología SCRUM, por ser una metodología ágil que se adapta fácilmente a este
tipo de proyectos.
El tipo de investigación es aplicada, el diseño de la investigación es preexperimental

y el enfoque es cuantitativo. La población para el impacto de gastos operacionales
y el porcentaje de incidencia en emisión se determinó a 556 facturas emitidas
agrupados en 6 fichas de registro. El tamaño de la muestra estuvo conformado por
228 facturas emitidas, estratificados por 6 días. El muestreo es el aleatorio
probabilístico simple. La técnica de recolección de datos fue el fichaje y el
instrumento fue la ficha de registro, los cuales fueron validados por expertos.
La implementación del Sistema Web permitió disminuir el impacto de gastos
operacionales de un 8.737% al 1.285%, del mismo modo, se disminuyó el
porcentaje de incidencias en emisión de 37.611% al 19.027%. Los resultados
mencionados anteriormente, permitieron llegar a la conclusión que el Sistema Web
mejora la facturación electrónica centralizada de la empresa CUETO S.A.C.
Palabras clave: sistema web, facturación electrónica centralizada, SCRUM
xii
ABSTRACT
This thesis details the development of a Web System for the centralized electronic
invoicing of the company CUETO SAC, due to the fact that the business situation
prior to the application of the system presented deficiencies regarding the reduction
of operational impacts and the percentage of incidents in issue. The objective of this
investigation was to determine the influence of a Web System for the centralized
electronic invoicing of the company CUETO S.A.C.
Therefore, theoretical aspects of what is centralized electronic billing, as well as the
methodologies that were used for the development of the Web System, are
previously described. For the development of the Web System, the SCRUM
methodology was used, as it is an agile methodology that easily adapts to this type
of project.
The type of research is applied, the research design is preexperimental and the
approach is quantitative. The population for the impact of operational expenses and
the percentage of incidence in issuance was determined to 556 invoices issued
grouped in 6 record sheets. The sample size consisted of 228 invoices issued,
stratified for 6 days. Sampling is the simple probabilistic random. The data collection
technique was the signing and the instrument was the registration form, which were
validated by experts.
The implementation of the Web System allowed to reduce the impact of operational
expenses from 8,737% to 1,285%, in the same way, the percentage of incidents in
emission was reduced from 37,611% to 19,027%. The results mentioned above,
allowed to conclude that the Web System improves the centralized electronic
invoicing of the company CUETO S.A.C.
Keywords: web system, centralized electronic billing, SCRUM
xiii
I. INTRODUCCIÓN
1.1. Realidad Problemática

Actualmente, la tecnología contribuye en el desarrollo económico y financiero
diferentes países en todo el mundo, ello lo vemos a través de los sistemas
de facturación electrónica que han sido empleados. Barreix y Zambrano
(2018), menciona lo siguiente, sistemas de facturación electrónica ya han
sido implementados en toda América latina, teniendo grandes resultados.
Argentina, Brasil, Chile, Ecuador, México, Perú y Uruguay son aquellas
naciones dentro de este sector en el cual ya se han desarrollado estos
sistemas y disfrutan del beneficio de los mismos (p. 193). Esto hace
referencia a la necesidad de cada país de mantener un control tributario de
una manera organizada, que de no ser respaldado por un sistema de
información sería difícil de lograr.
En el Perú, la SUNAT ha tomado a las TIC como parte de su estrategia para

poder alcanzar sus objetivos y de esta manera los procesos puedan ser más
agiles y se reduzcan costos a nivel de todos los contribuyentes. La empresa
CUETO S.A.C. sabiendo ello busca adaptarse a estos cambios de manera
que siga los lineamientos impuestos. La empresa CUETO S.A.C. juntamente
con sus clientes empezó a utilizar este método de facturación, pero ellos
tenían que volver a digitar todas sus ventas nuevamente para poder ser
facturados por el portal SUNAT. Ello trae como problema que algunas ventas
sean mal digitadas y emitidas con datos erróneos lo que conllevaba una
anulación posterior del documento, según CUETO S.A.C. (2019), nuestra
empresa mensualmente emite un promedio de 1500 a 2300 facturas, de
estos documentos emitidos el porcentaje de incidencias en emisiones se
encuentra entre el 30% y el 35%, que hace referencia a documentos mal
emitidos, errores en la digitación de los documentos o documentos emitidos
fuera de plazo. Según lo mencionado por la empresa alrededor de 90
1
documentos están siendo anulados, lo que no es beneficioso para la empresa
por todos los recursos utilizados para el registro de los mismos a SUNAT.
Además, se debe tener en cuenta los costos que conlleva el mantenimiento
de los comprobantes físicos de acuerdo al uso dado. Ya que es necesario el
almacenamiento del comprobante respectivo, el envió al cliente de manera
presencial además de costos adicionales que involucren la impresión del
comprobante, tales como, tinta para impresora, papel, mantenimiento de
impresora. Según CUETO S.A.C. (2019), el costo total de que nos conlleva
a emitir nuestros comprobantes de manera física y todos los procedimientos
que lo involucra asciende mensualmente entre 1500 y 1700 soles como
impacto de gastos operacionales. Esto conlleva gastos significativos a la
organización que afecta en el progreso de la organización en general, debido
a que el dinero que se utiliza para esto puede ser invertido en otra área de la
empresa y al mismo tiempo permita su crecimiento y desarrollo.
1.2. Trabajos previos
Negrete Bonilla Jairo Camilo en el año 2016, Desarrollo de un sistema web

de facturación electrónica con comunicación al servicio de rentas internas,
aplicado a la empresa expertweb cia. ltda., en la ciudad de Quito. Debido a
disposiciones legales que el Servicio de Rentas Internas ha impuesto en el
ámbito de comprobantes electrónicos la institución en cuestión tiene que
brindar a sus clientes una solución tecnológica que le permita acoplarse a
ello. En este proyecto se ha utilizado la metodología DSDM para la
realización del sistema propuesto. En conclusión, el cambio de método de
emisión de facturas debe ser promovido por la misma organización, pero se
presentan factores como poca información al respecto y falta de soporte para
la misma implementación de sistemas que incrementan la dificultad a la hora
de desarrollar estos proyectos, de esta manera se redujo la imposición de
gastos de en $1000 lo que beneficio directamente a la empresa. Esta
investigación me ayuda en la sustentación de mi problemática ya que
comparte la misma problemática que mi investigación.
2
Herrera Carranza Brenda en el año 2015, Diseño e Implementación de la
Factura Electrónica como mecanismo para hacer más eficiente el proceso de
facturación en Certicámara S.A. Hoy en día la mayoría de las facturas
generan elevados costos para la empresa, además que se implementan
nuevas leyes y normativas en el entorno tributario constantemente, es por
ello que el uso de una modalidad electrónica en el ámbito tributario aumenta
la eficiencia en cada operación que involucre el proceso de facturación, de
esta manera se pueda contar con un control adecuado y se tenga acceso a
la información de una manera inmediata y directa. El método utilizado para el
desarrollo de su solución fue basado en el Team Software Process. En
conclusión, gracias al desarrollo de este sistema, la institución podrá contar
con un modelo de negocio más ágil y eficiente, en un ámbito cambiante este
tipo de sistemas es de mucha ayuda, de esta manera se aumentó la
productividad del proceso de un 60% a un 74%, además de aumentar la
satisfacción del cliente de un 45.345 a un 58.98%. Esta investigación
sustenta la problemática planteada en mi investigación.
Bendezu Figueroa Freddy en el año 2017, Implementación de sistema de

facturación electrónica con transferencia de comprobantes a la SUNAT en
las Mypes Ayacucho 2017. Las empresas ferreteras no emiten las facturas
electrónicas por falta de conocimiento y manejo de tecnologías, y en su
mayoría emiten facturas manuales. También indica que ha detectado que la
SUNAT viene realizando auditorías este tipo de empresas en el distrito de
Ayacucho por la evasión de impuestos las cuales son multadas de acuerdo
al cuadro de infracciones dada por la SUNAT, que en su mayoría perjudica
económicamente a los propietarios. La metodología de desarrollo usaba fue
RUP para el desarrollo del sistema. En conclusión, el resultado fue la correcta
estructuración de los archivos electrónicos solicitados por SUNAT, el cual
permitió disminuir los costes operacionales, contando con un orden
adecuado de los documentos que se generan, todo ello contribuyó a mejorar
3
el impacto de gastos operacionales dentro del proceso disminuyendo de un
25.89% a un 18.9%. Esta investigación me aporta dimensiones para mi
variable y indicadores.
Amaro Quispe Kennidy en el año 2017, Sistema de emisión de comprobantes

de pago electrónicos en el proceso de facturación de Contasis SAC. Se
cuenta con problemas en el proceso mencionado, ya que este conlleva
grandes gastos en cuanto a lo que es la distribución de los comprobantes y
al mismo tiempo los gastos realizados en los materiales utilizados en el
desarrollo del proceso y ello conlleva un gran impacto en las utilidades de la
organización, teniendo presente que se emiten una gran cantidad de
comprobantes. En conclusión, el sistema desarrollado logro un efecto
positivo en el proceso en estudio, debido a que se logró una disminución del
76,3% en promedio en cada indicador, tanto en el porcentaje de incidencias
emisiones como del impacto de gastos operacionales.
Alcántara Rodríguez Jorge en el año 2017, Sistema Easy Bill en la Gestión

de Ventas en la Empresa Security & Trade Company S.A.C., 2017. La
gerencia general de la institución busca alcanzar una mejora con respecto a
la gestion de sus ventas, para ello se busca el desarrollo de una aplicación
que gestione, mejore y almacene lo referente a la emisión de una factura
electrónica, debido a que actualmente ese control se registra en archivos de
excel. La metodología de desarrollo utilizada fue AUP. En conclusión, se
implementó el aplicativo que logre el mantenimiento de las facturas dentro de
la empresa, de tal manera que el proceso de ventas mejoro siendo así más
sencillo y ágil de llevar a cabo, de esta manera las incidencias de emisión del
proceso se redujeron de un 25.8% a un 14.87%. El aporte brindado por esta
investigación son indicadores para mi variable.
Ordaya Lock Rita en el año 2015, Implementación de un sistema de

información para una mype comercial con componentes de libros y
4
facturación electrónica. La empresa pierde dinero a causa de malos cálculos
realizados en las transacciones, lo que conlleva a sanciones tributarias por
parte de las autoridades y estas ascienden hasta S/. 720. La metodología de
desarrollo usada fue XP para el desarrollo del sistema en cuestión y SCRUM
para la gestión del proyecto. En conclusión, se implementó un módulo de
facturación que realizaba la labor del mantenimiento de los comprobantes
electrónicos. Y estos a su vez lograron que se pueda llevar un control
correcto, fácil y de acuerdo a las normativas establecidas. Esta investigación
me aporta información sobre la metodología de desarrollo que se va a
emplear en mi proyecto.
1.3. Teorías relacionadas al tema

1.3.1. Sistema Web
• Cardador (2014) define lo siguiente, este tipo de sistemas al igual que
otros son desarrollados sobre un lenguaje definido, él cual es sostenido
por los navegadores de internet los cuales logran que el usuario pueda
llevar a cabo una conexión directa con el servidor en el que se encuentra
el sistema. (p. 15).
• Berzal, Cortijo, Cubero (2014) comenta lo siguiente:

Son aplicaciones donde a partir de páginas web es construida la interfaz
gráfica. La cuales son archivos de texto en el formato estándar, el cual es
HTML. El usuario puede acceder a ellos mediante el protocolo HTTP, ya
que es un servidor web el que almacena estos archivos. (p. 105).
El autor define claramente lo que corresponde a un sistema web,
indicándonos que son archivos que necesitan de un servidor web para su
almacenamiento y respectivo procesamiento de tal manera que este
sistema pueda funcionar de acuerdo los requerimientos dados o
impuestos.
5
Al mismo tiempo se debe tener en cuenta que en base a esto se necesita
del manejo de diferentes aspectos relacionados a lo que es un sistema
web, a su diseño, desarrollo, implementación y mantenimiento del mismo.
• Molina (2014) define lo siguiente, el sistema web es un sistema

informático donde el usuario se hace uso de internet o una intranet como
medio para acceder al servidor web. (p. 230).
1.3.2. Lenguaje de Programación

Quero (2015), define lo siguiente, es un conjunto de símbolos y caracteres
combinados entre sí de acuerdo con un orden ya establecido que permite
indicarle acciones al CPU. (p. 128). Conocer esta definición es de suma
importancia debido a que sobre ello se lleva a cabo el desarrollo del
sistema a realizar ya que todo sistema se debe desarrollar en un lenguaje
de programación en específico y la elección del mismo va a depender de
preferencias o necesidades que se van a cubrir con el sistema a
desarrollar.
1.3.3. ASP
López, Peñalba, Caballero (2014) comenta, Esta tecnología contempla un
mecanismo robusto y sencillo de aprender para el desarrollo se
aplicaciones Web. En lugar de desarrollar sistemas web estáticos, se
creará páginas en las que los usuarios interactúen de una forma más
cercana. (p. 7). Esta es la tecnología que se va a utilizar para el desarrollo
del sistema, ya que brinda una alta facilidad de desarrollo y adaptabilidad.
Esto quiere decir que permitirá un fácil desarrollo del sistema y al mismo
tiempo permitirá que este pueda ser amigable hacia el usuario.
Se hará uso de esta tecnología debido a que la empresa cuenta con la
licencia respectiva para su utilización y desarrollo. Además, esta
tecnología es usada por la empresa desde principios del año 2018 donde
se adquirió la licencia respectiva.
6
1.3.4. Servidor Web
Villada (2014) indica que, es un sistema el cual tiene la capacidad de
recibir peticiones por parte de los usuarios ya sea desde una red local o
una conexión a internet. Las cuales son creadas y enviadas mediante un
navegador. (p. 80).
1.3.5. Servidor IIS

Villada (2014) define lo siguiente, Internet Information Services (IIS) es el
servidor de páginas web avanzado de la plataforma de Windows.” (p.
100).
Debido a que se utilizara ASP, el servidor web a utilizar es ISS, ya que es
este el servidor que permitirá el almacenamiento y procesamiento de las
paginas creadas.
1.3.6. Base de Datos

Quero (2015), define lo siguiente, es un conjunto de símbolos y caracteres
combinados entre sí de acuerdo con un orden ya establecido que permite
indicarle acciones al CPU. (p. 128).
1.3.6.1. MYSQL
Cobo, Gómez, Rocha (2014) comenta, sistema de administración y
control de base de datos de tipo relacional que cuenta con las
características de ser rápido, firme y adaptable. Idóneo para la
elaboración de acceso vía web y para sistemas OLTP. (p. 339).
Este sistema es el más recomendable cuando se trabaja en
aplicaciones web, por su rapidez y flexibilidad frente al desarrollo web
ya que permite una fácil integración y desarrollo del mismo. Esto es
muy conveniente ya que facilitara la implementación del sistema en
cuestión.
7
1.3.6.2. SQL Server
Sistema de base de datos relacional elaborado por la compañía
Microsoft que está diseñado para funcionar como una extensión del
SO Windows.
Asegura una fácil administración a través de un entorno grafico
amigable. Brinda facilidad de uso y cuenta con funciones de
almacenamiento las cuales solo comparten sistemas como Oracle o
otros grandes sistemas encargados de la administración de base de
datos. (EcuRed, 2016).
1.3.6.3. PostgreSQL
Este sistema es orientado a objetos, derivado de Postgres. Es open
Source, además de permitir concurrencia multi-version ya que trabaja
con grandes cantidades de datos.
Posee características significativas como subconsultas, asignación de
valores por defecto y restricciones en campos y disparadores.
(EcuRed, 2015).
8
1.3.6.4. Cuadro comparativo de Sistemas Gestores de base de datos
Tabla 01 Cuadro comparativo de sistemas gestores de base de datos
Fuente: Instituto Tecnológico Superior de Lerdo (2014)
9
El sistema para la administración de datos a utilizar en el desarrollo
propuesto será MySql, debido a brinda seguridad plena de la
información y al mismo tiempo un alto rendimiento en cuanto a su
funcionamiento. Es decir, permitirá al sistema una conexión segura
hacia la información requerida, integridad de los datos registrados,
carga rápida de la información, del lado del servidor grandes opciones
de administración y utilidades de mejora. Adicional a ello es Open
Source de tal manera que no genere un gasto adicional para su uso.
1.3.7. Metodología de desarrollo de software
1.3.7.1. RUP
Basada en la utilización de componentes y interfaces. Una de sus
características es que se puede utilizar en todos los proyectos de
software, independiente del área de aplicación, organización o
tamaños de proyecto.
Las características de su ciclo de vida son:
 Dirigido por casos de uso: Estos representan las necesidades
que los usuarios buscan satisfacer.
 Centrado en la arquitectura: Esto se debe a que es la
arquitectura la que indica a donde se quiere llegar con el
proyecto propuesto.
 Iterativo e Incremental: Se enfoca en todas las actividades del
flujo de trabajo establecido.
Sus flujos de trabajo principales son:
 Modelo del Negocio
 Requerimiento
 Análisis y Diseño
 Implementación
 Prueba (Testeo)
 Instalación o despliegue
 Administración del proyecto
 Administración de configuración y cambios
10
 Ambiente
Las fases que conforman esta metodología son:
 La fase de inicio
 La fase de elaboración
 La fase de construcción
 La fase de transición
La diferencia esencial de esta metodología frente a las demás es que
los casos de uso cuentan con un rol primordial dentro de ella, ya que
son parte de la guía para el avance del proyecto. (EcuRed, 2016,
agosto 12).
1.3.7.2. ICONIX
Metodología hibrida que combina las aplicaciones de la metodología
RUP y la metodología XP. Esta metodología une un grupo de métodos
que buscan establecer un debido control y administración de la vida
útil del proyecto que se desea llevar a cabo.
Sus características son:
 Iterativo e Incremental: se van realizando cada una de las
actividades planteadas.
 Trazabilidad: Todo está enfocado a los requisitos ya extraídos.
 Dinámica del UML: Hace uso de los diagramas que considera
más relevantes para el desarrollo del producto.
Las fases de esta metodología son:
 Revisión de los requisitos/ Análisis de Requisitos:
 Revisión del diseño preliminar /Análisis y Diseño Preliminar
 Revisión crítica del diseño/Diseño
 Implementación
Esta metodología se presenta como una opción adicional para
comunidades de desarrolladores enfocados en pequeños y medianos
proyectos buscando asegurar la calidad del producto que se desea
desarrollar. (EcuRed, 2014, abril 18).
11
1.3.7.3. SCRUM
Proceso basado en un conjunto de buenas prácticas que buscan el
correcto trabajo en equipo y lograr cumplir con la mayor parte de lo
planificado en un proyecto.
En esta metodología se llevan a cabo entregas parciales y regulares
del producto. Por ello, está orientado a tipos de proyecto con cierto
grado de complejidad donde se busca obtener rápidos resultados,
además de contar con requerimientos en todo momento cambiantes.
Scrum se ha convertido en un modelo que brinda las mejores prácticas
y roles para establecer el proceso de desarrollo que se llevara a cabo
durante le ejecución del un proyecto.
Los roles en SCRUM son:
 Roles Cerdo:
o Product Owner
o ScrumMaster
o Equipo
 Roles Gallina:
o Usuarios
o Managers
Los documentos de SCRUM son:
 Product backlog
 Sprint backlog
 Burn down
(EcuRed, 2014, setiembre 5).
12
1.3.7.4. Validación de Metodología de Desarrollo de Software
Tabla 02 Validación de expertos de metodología de desarrollo de software
Fuente elaboración Propia (Ver Anexo 8)
En base a la evaluación de expertos de la metodología de desarrollo

de software (ver Anexo 8) se elige la metodología SCRUM que será
utilizada en el desarrollo del sistema propuesto en la presente
investigación de tal manera que el software a desarrollar puede
implementarse en corto tiempo y se garantice la calidad del mismo, de
tal manera que se cumplan con cada uno de los requisitos impuestos
por los interesados. Esta metodología permitirá que el cliente pueda
participar del progreso del sistema, permitiendo que se puedan
imponer cambios en el progreso del sistema sin que estos afecte al
producto final y se alcancen los objetivos propuestos en la planificación
del proyecto.
1.3.8. Facturación Electrónica Centralizada

• Leuro y Oviedo (2016) definen lo siguiente:
“Es aquella donde todo el equipo de facturación se encuentra ubicado
en una oficina central y es allí donde se liquida la cuenta, se genera la
pre-factura y posteriormente se emite la factura. Se asignan uno o
varios facturadores responsables por cada una de las unidades
funcionales por cama o por convenio, quienes deben realizar la carga
13
diaria de las prestaciones y la liquidación de las mismas, asegurando
así la información actualizada, completa y oportuna para la liquidación
de los servicios prestados al usuario en cualquier momento, ya sea una
pre-liquidación, estado de cuenta, pre-factura o factura. […]” (p.201).
• Independientemente de la factura permite seleccionar diferentes tipos y

porcentajes de descuento, de rappels, comentarios. La numeración de las
mismas se realiza en automático y al mismo tiempo es centralizada para
cada puesto de trabajo con el que se cuenta dentro de una organización,
permitiendo siempre que la numeración sea correlativa y automática
(Arktec, s.f., “Gestión centralizada de todas las facturas”, párr. 1).
• Es un procedimiento más eficiente que se lleva a cabo siguiendo una serie

de acciones, tales como, emisión de facturas procedentes de contratos,
emisión de facturas a terceros, archivar historiales de facturas, listado de
facturas con reclamos (Universidad Miguel Hernández de Elche, s.f.,
“Facturación”, par. 1).
Este proceso se encuentra conformado por tres etapas, según define Leuro
y Oviedo (2016):
a. Liquidación de cuenta
Este es el primer paso para llevar a cabo el proceso, ya que en esta
etapa se conoce valor total que corresponde a todas las facturas que
se van a emitir. Contablemente es importante, porque aquí se indica
tanto lo que ha salido de la empresa como bien hacia los clientes, y
en el caso de devoluciones o inconsistencias se indica y muestra lo
que debería retornar a la empresa especificando los valores tanto a
nivel de cantidades físicas como de cantidad monetaria.
Según la encuesta llevada a cabo en CUETO S.A.C. (2019), esta fase
del proceso se trabaja de manera muy detallada dentro de la
organización debido a que es importante la validación de las salidas y
entradas traducidas en cantidades y costos de cada pedido registrado.
14
b. Generación de Pre-factura
Esta etapa permite generar el documento llamado pre-factura, que no
es más que una factura con todos los datos respectivos, pero sin la
validez fiscal de la misma. Además, a diferencia de la factura este
documento puede editarse sin ningún límite, modificándose en el
tiempo que se requiera con el fin de brindárselo al cliente en el caso
requiera un comprobante de su venta antes que lo cancele y se le
genere la factura correspondiente.
Según la encuesta llevada a cabo en CUETO S.A.C. (2019), la
empresa no genera el documento de Pre-factura como tal, es decir la
empresa hace uso de este documento para poder realizar las
modificaciones respectivas al documento tal como lo menciona el
autor, pero no lleva un control estricto y documentado del mismo por
un tema de operatividad dentro del proceso.
c. Emisión de Factura
El paso final del proceso es la emisión directa de la factura, que esta
sea realiza mediante una conexión al sistema tributario del país o lugar
donde se emite el documento. De esta manera, este documento
cuenta con una legalidad tributaria a través de la cual la entidad
reguladora se encarga del cobro de los impuestos. Una vez emitido el
documento no puede ser alterable directamente, al contrario, si se
quiere modificar es necesario seguir normas tributarias ya definidas
que permiten ello.
Según la encuesta llevada a cabo en CUETO S.A.C. (2019), la emisión
de la factura involucra diversas acciones y procedimientos complejos,
pero ello a nivel interno ya que lo que se busca es que a través de una
acción se realice la emisión directamente, ya que de haber
validaciones estas deben ser automáticas o ya haberse aplicado en
las fases anteriores.
15
 Indicador para la dimensión Generación de Pre-Factura
Impacto de Gastos operacionales
Chang, C., et al. (2015), indica que los gastos que involucran la gestión
de las facturas comprenden tanto la impresión, la distribución y el
mantenimiento de las mismas. Al mismo tiempo, García (2014),
comenta que los gastos que genera la emisión tradicional de la factura
son de preocupación para toda empresa, ya que estos no se definen
en su totalidad.
Por ello el indicador que será medido será el impacto de gastos
operacionales dentro de la facturación electrónica centralizada, el cual
se calcula con la siguiente formula:
Figura 1 Fórmula Indicador Impacto de Gastos Operacionales
Fuente: Martínez, Humberto (2015)

Dónde:
IGO: Impacto de gastos operacionales
GO: Gastos operacionales
VN: Ventas netas
Adicional a ello, Chang, et al. (2016) añade lo siguiente, el desarrollo

de este tipo de sistema permite a las organizaciones disminuir los
gastos que generan la emisión tradicional de estas. Además,
Gonzáles, et al. (2015, p. 484), indica que contar con facturas en papel
tradicional provoca un aumento de costos y difícil gestión de las
mismas, que tiene como resultado un proceso no eficiente y que no
permite a la empresa migrar a un ambiente electrónico.
Teniendo en cuenta ello, existe un gasto en la recaudación de los

impuestos y la inspección de los mismos que se rigen en base a los
16
documentos emitidos por la empresa, de tal manera que si existe
irregularidad en algún documento esto conlleva a una supervisión de
todos los que se han emitido. Además, los documentos que se
imprimen en papel hacen uso de muchos recursos y no permiten
cumplir con los requisitos de conservación de energía que se está
promoviendo (Tsinghua University, 2014).
Barreix, Zambrano (2018) indican que, la implementación de un

sistema de estas características supone ventajas importantes, como
la posibilidad de mejorar su eficiencia gracias a la reducción de costos.
La disminución de estos costos se aprecia en el ahorro de papel,
espacio físico para almacenar los documentos generados y el ahorro
en la acción de realizar el envió de los documentos a los respectos
clientes. Teniendo presente que se minimizan los gastos, ello permite
realizar una mejora de los propios procesos, por ejemplo, mejorar el
registro contable, pagos a proveedores y gestión de inventarios y
hasta la posibilidad de interoperar con otros contribuyentes. (p. 8).
 Indicador para la dimensión Emisión de Factura

Porcentaje de incidencias en emisiones
Este indicador representa el porcentaje de documentos emitidos que
están siendo anulados, por las incidencias presentadas. Estas
incidencias van desde problemas en los datos registrador o no del
receptor de la factura, problemas en las cantidades registradas o no
de los bienes brindados, problemas en los precios registrados o no de
los bienes, problemas en el registro o no de los bienes recibidos por
el cliente, problemas en los cálculos del subtotal y total de la factura.
La fórmula para medir el indicador es la siguiente:
17
Figura 2 Fórmula Indicador Porcentaje de incidencias en emisión
Fuente: Cuylen, Kosch y Breitner (2016)

Dónde:
PIE: Porcentaje de incidencias en emisiones
TA: Total de documentos anulados
TE: Total de documentos emitidos
La implementación de un sistema de facturación electrónica brinda un

ahorro en lo referido a costos y tiempo para la organización, ello se
debe que evitan la realización del trabajo manual lo que trae consigo
evitar problemas de entrada en la emisión (Cuylen, Kosch y Breitner,
2016).
A su vez Raths (2014), mencionó que si se adapta un sistema

automatizado de facturación lograra que algunas acciones que se
realizan al momento de llevar a cabo el proceso de manera tradicional
se puedan eliminar contando con un control adecuado de ello,
teniendo todo correctamente actualizado y organizado.
Barreix, Zambrano (2018) añaden que, el sistema de Facturación

Electrónica permite detectar comportamientos o patrones inusuales e
irregulares, lo cual permite obtener una mayor efectividad en la
emisión misma. Debido a que la deficiencia en la calidad de datos que
se registran es de los mayores riesgos que pueden existe en esta
gestión. Por ello, los procesos de validación en la recepción de
información original son el mejor punto de control para la obtención de
datos de suficiente calidad. Ya que si esto no se cumple hacen que
los documentos sean inutilizables.
18
Este aspecto es importante tanto en el aspecto físico como
electrónico, ya que en ambos aspectos se debe cumplir con la calidad
mencionada, por ello las incidencias que se puedan generar en la
posible deben ser mínimos o por lo menos no graves en el sentido de
hacer que el documento tenga que anularse. Los datos que se
registrar, ya se información del emisor, del receptor o propios del bien
o servicio que se está brindando deben pasar por un filtro o un proceso
que asegure la validez y calidad de los mismos, de esta manera se
permitirá llevar a cabo el proceso de manera óptima tal como la
empresa lo espera. (p. 28)
1.4. Formulación del problema

1.4.1. Problema Principal
¿Cuál es la influencia de un sistema web para la facturación electrónica
centralizada de la empresa CUETO S.A.C.?
1.4.2. Problemas secundarios
• ¿Cuál es el efecto de un sistema web en el impacto de gastos
operacionales de la facturación electrónica centralizada en la empresa
CUETO S.A.C.?
• ¿Cuál es el efecto de un sistema web en el porcentaje de incidencias
en emisiones de la facturación electrónica centralizada en la empresa
CUETO S.A.C.?
1.5. Justificación del estudio

1.5.1. Justificación Tecnológica
Según Raths (2014), la presencia de aplicaciones que automaticen
procesos es muy relevante dentro de este ámbito debido a que logran la
optimización y control de los documentos con los que se cuenta. (p. 112).
La presente investigación lleva como finalidad el desarrollo y la
implementación de un sistema web para la facturación electrónica
centralizada en la empresa CUETO S.A.C., el cual va a permitir la
comunicación directa con el sistema de SUNAT, de tal manera que la
19
empresa pueda realizar el envió de sus comprobantes, acceder a ellos y
consultarlos en tiempo real. Esto permitirá que la empresa pueda realizar
sus laboras de manera más ágil y directa, de tal manera que la calidad de
su servicio mejore.
1.5.2. Justificación Económica

El desarrollo del sistema se llevará a cabo bajo la plataforma de Visual
Studio, plataforma la cual la empresa cuenta actualmente con una
licencia. Ello permitirá un fácil acceso a los componentes necesarios para
la implementación del Sistema web. Adicional a ello, la aplicación web
desarrollada permitirá que el dinero utilizado en la facturación física, que
oscila entre S/. 1500 a S/. 1700, pueda ser utilizado en otras áreas o para
otros fines. Ya que, permite ahorrar gastos en las operaciones que los
involucran y el tiempo que ello conlleva, al mismo tiempo evita labor
manual y por consiguiente errores en la información de entrada, impresión
física y gastos de distribución (Cuylen, Kosch y Breitner, 2016).
1.5.3. Justificación Institucional

Este sistema ayudara a que la empresa pueda seguir de una manera
correcta la normativa impuesta por SUNAT, la cual consiste en la emisión
de sus documentos de venta de manera electrónica. El sistema no
afectara al proceso que se lleva a cabo, sino al contrario este se adaptara
a la forma de manejar el proceso, ello lograra que los resultados que se
esperan se obtengan de una manera directa, rápida y sencilla. Adicional
a ello, Angeli y Antonio (2016), mencionan lo siguiente, el desarrollo de
estos sistemas permite a la empresa elevar su nivel de competitividad
frente a otras. (p. 50).
20
1.5.4. Justificación Operativa
Según Hernández y Jiménez (2016, p.15), optar por esta modalidad de
emisión evita gastos operativos, disminuye fallos en la administración y
retrasos postales.
El sistema en cuestión ayudara a que el proceso se pueda llevar a cabo
de una manera más eficiente. Es decir, a través del sistema no cambiar
la modalidad del proceso que realiza la empresa sino este pueda
respaldar dicho proceso brindando mayor accesibilidad y facilidad en
cuanto a cada acción que se realiza. Se evitará el uso de papel y todo lo
que lo involucra, como uso de la impresora o mantenimiento de la misma,
y al mismo tiempo permitir que el servicio brindado hacia los clientes
pueda mejorar en cuanto a su calidad.
1.6. Hipótesis
1.6.1. Hipótesis General
Ha: El Sistema Web mejora la facturación electrónica centralizada en la
empresa CUETO S.A.C.
1.6.2. Hipótesis Especificas
H1: El Sistema Web disminuye el impacto de gastos operacionales de la
facturación electrónica centralizada en la empresa CUETO S.A.C.
H2: El Sistema Web disminuye el porcentaje de incidencias en emisiones
de la facturación electrónica centralizada en la empresa CUETO S.A.C.
1.7. Objetivo
1.7.1. Objetivo General
 Determinar la influencia de un sistema web en la facturación
electrónica centralizada en la empresa CUETO S.A.C.
1.7.2. Objetivos Específicos
 Determinar el efecto de un Sistema Web en el impacto de gastos
operacionales de la facturación electrónica centralizada en la empresa
CUETO S.A.C.
21
 Determinar el efecto de un Sistema Web en el porcentaje de
incidencias en emisiones de la facturación electrónica centralizada en
la empresa CUETO S.A.C.
II. MÉTODO
2.1. Diseño de investigación

2.1.1. Tipo de Estudio
Según Landeau (2016), El tipo de estudio aplicado se encuentra orientado
a resolver problemas dados alrededor. Es decir, la investigación se aplica
a problemas descritos en circunstancias y aspectos específicos (p. 55).
El tipo de investigación realizado es Aplicado, ya que se implementará un
Sistema web para la facturación electrónica centralizada, el cual logrará
solucionar la problemática con la que cuenta la empresa CUETO S.A.C.
referente a sus comprobantes electrónicos.
2.1.2. Diseño de Estudio

Gómez (2014), define lo siguiente, “[…] Los preexperimental se les
denomina de esa forma debido a que cuenta con un mínimo grado de
control. No existe un grupo de control adicional para comparar los
resultados obtenidos […]” (p. 99).
En el diseño Preexperimental con preprueba y posprueba se cuenta con

un grupo al que se le realiza la prueba antes de la aplicación del
tratamiento a realizar y al final al siguiente grupo se le realizada el
tratamiento respectivo. Es decir, existe un punto de partida para saber
cuál es el nivel que tenía el grupo antes de la aplicación del estímulo.
(Gómez, 2014, p. 99).
El diseño de la investigación realizada es Preexperimental con preprueba

y posprueba debido a que se realizara una observación antes de la
implementación del Sistema web para la facturación electrónica
22
centralizada y después de la implementación misma. De tal manera que
podamos verificar y corroborar en qué medida fue beneficioso la
implementación del sistema.
La fórmula de este diseño es el siguiente:
Figura 3 Fórmula Diseño Pre Experimental
Fuente: Introducción a la metodología de la investigación científica, 2016
Donde:
G: Grupo de sujetos
𝑶𝑶𝟏𝟏 : Variable dependiente Facturación electrónica centralizada antes de
la implementación del Sistema Web en la empresa CUETO S.A.C.:
Se recopilará información de la variable dependiente antes de ser
aplicado el sistema, de tal manera que se pueda conocer el estado de
los indicadores antes de implementar la solución propuesta.
X: Variable Independiente: Sistema Web
𝑶𝑶𝟐𝟐 : Variable dependiente Facturación electrónica centralizada después
de la implementación del Sistema Web en la empresa CUETO S.A.C.:
Se recopilará información de la variable dependiente después de ser
aplicado el sistema, de tal manera que se pueda conocer el estado de
los indicadores después de implementar la solución propuesta y
compararlos con el estado anterior en el que se encontraban y verificar
el efecto que produjo la aplicación de la variable independiente.
2.1.3. Método de Investigación

Hernández et al. (2018) comenta lo siguiente del método Hipotético-
deductivo “[…] parte de conocimientos, teorías o leyes que explican el
fenómeno o problemática propuesta y que en la práctica se proceden a
confirmar […]” (p. 95).
23
El método de investigación utilizado es el Hipotético-deductivo ya que
este método permitirá que a través de la implementación de un Sistema
web para facturación electrónica centralizada en la empresa CUETO
S.A.C. se puedan confirmar las teorías anteriormente ya planteadas en
otras investigaciones.
2.2. Variables y operacionalización

2.2.1. Definición Conceptual
• Variable Independiente: Sistema Web
Cardador (2014) define lo siguiente, este tipo de sistemas al igual
que otros son desarrollados sobre un lenguaje definido, él cual es
sostenido por los navegadores de internet los cuales logran que el
usuario pueda llevar a cabo una conexión directa con el servidor
en el que se encuentra el sistema. (p. 15).
• Variable Dependiente: Facturación Electrónica Centralizada

Martínez (2016) define lo siguiente, “Es aquella donde todo el
equipo de facturación se encuentra ubicado en una oficina central
y es allí donde se liquida la cuenta, se genera la pre-factura y
posteriormente se emite la factura. Se asignan uno o varios
facturadores responsables por cada una de las unidades
funcionales por cama o por convenio, quienes deben realizar la
carga diaria de las prestaciones y la liquidación de las mismas,
asegurando así la información actualizada, completa y oportuna
para la liquidación de los servicios prestados al usuario en
cualquier momento, ya sea una pre-liquidación, estado de cuenta,
pre-factura o factura. […]” (p.201).
24
2.2.2. Definición Operacional
• Variable Independiente: Sistema Web
Es una aplicación que facilita el ingreso, procesamiento y salida de
datos dentro de la empresa CUETO S.A.C. de tal manera que la
problemática planteada en esta investigación pueda ser
solucionada o contribuya directamente en el logro de esa solución.
• Variable Dependiente: Facturación Electrónica Centralizada
Es una forma de llevar a cabo el proceso de facturación dentro de
la empresa de tal manera que pueda ser más eficiente y se
obtengan mejores resultados en cuento a la emisión de los
documentos electrónicos.
Tabla 03 Matriz Operacional de la variable
Fuente: Elaboración propia
25
Tabla 04 Indicadores
26
2.3. Población y muestra
2.3.1. Población
Según Bisquerra (2015), es la suma de todos los individuos a los que se
le realizara la investigación en cuestión. Definir la población permitirá
lograr en mayor medida mejores y claros resultados de la investigación a
realizar. (p. 143).
En este caso se tomó para los indicadores impacto de gastos
operacionales y porcentaje de incidencias en emisión la población de 556
facturas emitidas en un periodo de 6 días, lo que es equivalente a una
semana laboral en la empresa, la cual será estratificada líneas abajo.
Tabla 05 Población
INDICADOR POBLACIÓN TIPO PERÍODO

IMPACTO DE GASTOS
OPERACIONALES
FACTURAS
556 6 DÍAS
PORCENTAJE DE INCIDENCIAS EN EMITIDAS
EMISIÓN
2.3.2. Muestra
Según Bisquerra (2015), es el conjunto de casos obtenidos dentro un
grupo específico utilizando un muestreo. (p. 143).
Para calcular la muestra se aplicará la formula con población conocida
que es la siguiente:
Figura 4 Fórmula Muestra Población Conocida
Fuente: Bisquerra, 2015
27
Donde:
N = Total de la población
Zα= nivel de confianza que es 1.96 al cuadrado (si la seguridad es del
95%)
p = proporción esperada (en este caso 5% = 0.05)
q = probabilidad de fracaso 1 – p (en este caso 1-0.05 = 0.95)
d = precisión (Error máximo admisible en términos de proporción, en su
investigación use un 5%).
Aplicando la formula nos da como resultado del tamaño de nuestra
muestra el siguiente valor: 228
Es decir, el tamaño de la muestra para los indicadores de la presenta
investigación la conforman 228 facturas, estratificadas en 6 días. Por lo
tanto, la muestra está conformada por 6 fichas de registro con 228
facturas.
Tabla 06 Muestra
INDICADOR POBLACIÓN TIPO PERÍODO

IMPACTO DE GASTOS
OPERACIONALES
FACTURAS
228 6 DÍAS
PORCENTAJE DE INCIDENCIAS EN EMITIDAS
EMISIÓN
2.3.3. Muestreo
Según Del Rio (2015) es un, “[…] proceso que se realiza una vez
realizada la obtención de la muestra correspondiente a una población
finita. […] Contando con el tamaño de nuestra muestra, se lleva a cabo la
selección sus elementos siguiendo un proceso representativo. (p. 100).
Vivanco (2015), indica lo siguiente, El muestreo aleatorio simple es un

procedimiento que permite elegir de manera autónoma y continua para
cada unidad teniendo como base una lista donde se lleve a cabo la
elección al azar. (p. 69).
28
2.4. Técnicas e instrumentos de recolección de datos, validez y
confiabilidad
2.4.1. Técnica de Recolección de datos
Según Villareal J. (2014) define a “la palabra técnica, como un conjunto
de pasos de una ciencia e instrumento de recolección de datos, que
permitan al investigador aproximarse al fenómeno estudiado y recolectar
los datos necesarios.” (p. 17).
El fichaje
Hernández, Fernández y Baptista (2016, p. 260) define lo siguiente, es un
procedimiento que permite la recolección y el almacenamiento de
información de tal manera que cada ficha registrada contenga un valor
único. Esta técnica logra el registro de datos de fuentes variadas.
2.4.2. Instrumento de Recolección de datos
Ficha de Registro
Es un instrumento que permitirá el registro de los datos recolectados, de
tal manera que nos ayuden a medir los indicadores y así representarlo en
un formato en específico. Para la toma de datos del indicador Impacto de
gastos operacionales se hizo uso de la ficha de registro, de tal manera
que se registre la información del estado del indicador antes de la
aplicación del Sistema Web (Ver anexo 6) y de igual manera del indicador
Porcentaje de incidencias en emisión (Ver anexo 5).
29
2.4.3. Validez y confiabilidad
VALIDEZ
Validación de Expertos de indicadores
INDICADOR 01: “Impacto de gastos operacionales”
Tabla 7 Validación de expertos Indicador Impacto de gastos operacionales
PUNTUACIÓN
Fuente elaboración propia (Ver anexo 9)

INDICADOR 02: “Porcentaje de incidencias en emisiones”
Tabla 08 Validación de expertos Indicador Porcentaje de incidencias en
emisiones
PUNTUACIÓN
Fuente elaboración propia (Ver anexo 9)
CONFIABILIDAD
Según Huamán, la medición de la confiabilidad necesita un solo análisis
o procesamiento del instrumento utilizado en la medición y el resultado es
un valor entre 0 y 1. La ventaja de ello es que se realiza la aplicación a la
medición y se calcula el valor de confiabilidad directamente.
Clifford y Stephenson describen el coeficiente de correlación de Pearson
como el valor de correlación producto-momento, que es la medida de
asociación más comúnmente utilizada para datos meristicos y continuos;
30
diseñado para medir la asociación entre pares de variables como el peso
y la altura (p. 51, 2015).
Indicador Porcentaje de Incidencias en Emisiones
Tabla 09 Correlación de Pearson Indicador Porcentaje de incidencias en
emisiones

Realizando el análisis de correlación de Pearson de los datos registrados
tanto en el Pre-Test como en Re-Test del indicador Porcentaje de
Incidencias en emisiones, se obtiene el resultado de 1 y 0,976 que nos
indica la correcta relación del indicador en estudio.
Indicador Impacto de Gastos operacionales

Tabla 10 Correlación de Pearson Indicador impacto de gastos operacionales
Fuente: Elaboración Propia

Realizando el análisis de correlación de Pearson de los datos registrados
tanto en el Pre-Test como en Re-Test del indicador Porcentaje de Gastos
31
operacionales, se obtiene el resultado de 1 y 0,972 que nos indica la
correcta relación del indicador en estudio.
2.5. Métodos de análisis de datos

HIPÓTESIS ESTADÍSTICA
 Hipótesis General
o Hipótesis 𝐇𝐇𝟎𝟎 : El sistema web no mejora la facturación
o Hipótesis 𝐇𝐇𝐚𝐚 : El sistema web mejora la facturación
 Hipótesis Especificas:
o 𝐇𝐇𝐇𝐇𝟏𝟏 = Hipótesis especifica 1
Hipótesis 𝐇𝐇𝟎𝟎 : El sistema web no disminuye el impacto de
gastos operacionales de la facturación electrónica
centralizada en la empresa CUETO S.A.C.
𝐇𝐇𝟎𝟎 : 𝐈𝐈𝐈𝐈𝐈𝐈𝐝𝐝 ≥ 𝐈𝐈𝐈𝐈𝐈𝐈𝐚𝐚
Donde:
𝐈𝐈𝐈𝐈𝐈𝐈𝐚𝐚 : Impacto de gastos operacionales antes de aplicar el
Sistema Web.
𝐈𝐈𝐈𝐈𝐈𝐈𝐝𝐝 : Impacto de gastos operacionales después de aplicar
el Sistema Web.
Hipótesis 𝐇𝐇𝐚𝐚 : El sistema web disminuye el impacto de

gastos operacionales de la facturación electrónica
𝐇𝐇𝐚𝐚 : 𝐈𝐈𝐈𝐈𝐈𝐈𝐝𝐝 < 𝐈𝐈𝐈𝐈𝐈𝐈𝐚𝐚
Donde:
𝐈𝐈𝐈𝐈𝐈𝐈𝐚𝐚 : Impacto de gastos operacionales antes de aplicar el
Sistema Web.
𝐈𝐈𝐈𝐈𝐈𝐈𝐝𝐝 : Impacto de gastos operacionales después de aplicar
el Sistema Web.
32
o 𝐇𝐇𝐇𝐇𝟐𝟐 = Hipótesis especifica 2
Hipótesis 𝐇𝐇𝟎𝟎 : El sistema web no disminuye el porcentaje
de incidencias en emisiones de la facturación electrónica
𝐇𝐇𝟎𝟎 : 𝐏𝐏𝐏𝐏𝐏𝐏𝐝𝐝 ≥ 𝐏𝐏𝐏𝐏𝐏𝐏𝐚𝐚
Donde:
𝐏𝐏𝐏𝐏𝐏𝐏𝐚𝐚 : Porcentaje de incidencias en emisiones antes de
aplicar el Sistema Web.
𝐏𝐏𝐈𝐈𝐄𝐄𝐝𝐝 : Porcentaje de incidencias en emisiones después de
Hipótesis 𝐇𝐇𝐚𝐚 : El sistema web disminuye el porcentaje de

incidencias en emisiones de la facturación electrónica
𝐇𝐇𝐚𝐚 : 𝐏𝐏𝐏𝐏𝐏𝐏𝐝𝐝 < 𝐏𝐏𝐏𝐏𝐄𝐄𝐚𝐚
Donde:
𝐏𝐏𝐏𝐏𝐏𝐏𝐚𝐚 : Porcentaje de incidencias en emisiones antes de
𝐏𝐏𝐏𝐏𝐏𝐏𝐝𝐝 : Porcentaje de incidencias en emisiones después de
PRUEBA t-student
Según Moncada (2015), Las pruebas t-student se utilizan con el fin de
establecer una diferencia entre los promedios obtenidos por dos grupos
u observaciones, o también se utiliza para realizar una comparación entre
los promedios de dos observaciones que se realizaron a una misma
persona. (p. 14). Esta prueba nos servirá para realizar la comparación del
pre-test ya realizado a nuestra muestra ante el post-test que será
realizado una vez aplicada la variable independiente de tal manera que
podamos determinar la validez de nuestra hipótesis.
33
2.6. Aspectos éticos
La presente investigación se basa en aspectos éticamente profesionales,
tales como, confidencialidad de la información obtenidos de la
organización en cuestión de tal manera que no se brinde información con
otros fines, veracidad en cuanto a la información obtenida es decir la
información recopilada de la empresa no es alterada, respeto de autoría
ya que la información que no es propia se encuentra correctamente citada
y integrada en cuanto a los análisis realizados con los datos que se
cuenta.
III. RESULTADOS
3.1. Análisis Descriptivo
En la presente investigación se aplicó un Sistema web para evaluar el
impacto de gastos operacionales y el porcentaje de incidencias en
emisión en la facturación electrónica centralizada de la empresa CUETO
S.A.C.; para ello se elaboró un Pre-Test con el propósito de conocer el
estado inicial en el que se encuentran los indicadores respectivos. Luego
se aplicó el Sistema web y se elaboró un Post-Test en el cual se registró
nuevamente el estado de los indicadores, para determinar el efecto que
la aplicación del Sistema web tuvo en ellos.
34
 INDICADOR 01: Impacto de Gastos Operacionales
Los resultados descriptivos obtenidos del indicador Impacto de gastos
operacionales se observan a continuación:
Tabla 11 Medidas descriptivas del Impacto de Gastos Operacionales antes y
después de implementar el Sistema Web
Estadísticos descriptivos
Desviación
N Mínimo Máximo Media estándar
IGO_PRETEST 6 7,882 10,656 8,81433 ,956363
IGO_POSTTEST 6 ,687 3,605 1,70667 1,080103
N válido (por lista) 6
En el Impacto de gastos operacionales, en el pre-test se obtuvo un

8,814%, mientras que en el post-test un 1,706%. Los resultados obtenidos
muestran una diferencia del estado del indicador antes y después de ser
aplicado el Sistema Web. Además, el impacto de gastos operacionales
mínimo fue 7,882% antes, y 0,687% después de la aplicación del Sistema
web.
En la dispersión del indicador impacto de gastos operacionales, en el pre-
test se obtuvo una variabilidad de 0,956%; pero, en el post-test se obtuvo
el valor de 1,080%.
35
Figura 5 Impacto de Gastos Operacionales antes y después de implementar el
Sistema Web
Impacto de gastos operacionales
8.737
1.285
IGO_PRETEST IGO_POSTTEST
 INDICADOR 02: Porcentaje de Incidencias en Emisión

Los resultados descriptivos obtenidos del indicador Porcentaje de
incidencias en emisión se observan a continuación:
Tabla 12 Medidas descriptivas del Porcentaje de incidencias en emisión en la
Sistema Web
Estadísticos descriptivos
Desviación
N Mínimo Máximo Media estándar
PIE_PRETEST 6 32,353 47,059 37,51700 5,677406
PIE_POSTTEST 6 11,111 30,000 19,75067 6,828720
N válido (por lista) 6
En el Porcentaje de incidencias en emisión, en el pre-test se obtuvo un

37,517%, mientras que en el post-test un 19,750%. Los resultados
obtenidos muestran una diferencia del estado del indicador antes y
después de ser aplicado el Sistema Web. Además, el porcentaje de
incidencias en emisión mínimo fue 32,353% antes, y 11,111% después
de la aplicación del Sistema web.
36
En la dispersión del indicador porcentaje de incidencias en emisión, en el
pre-test se obtuvo una variabilidad de 5,677%; pero, en el post-test se
obtuvo el valor de 6,828%.
Figura 6 Porcentaje de Incidencias en Emisión antes y después de implementar
el Sistema Web
Porcentaje de incidencias en emisión
37.611
19.027
PIE_PRETEST PIE_POSTTEST

3.2. Análisis Inferencial
Prueba de Normalidad
Se realizaron las pruebas de normalidad en los indicadores impacto de
gastos operacionales y porcentaje de incidencias en emisión por medio
del método Shapiro-Wilk, ya que el tamaño de nuestra muestra
estratificada la conforman 6 fichas de registro valor que es menor a 50,
tal como lo indica Hernández, Fernández y Baptista (2014, p. 376). Dicho
análisis se llevó a cabo utilizando los datos del Pre-Test y Post-Test de
cada indicador en el software estadístico SPSS 24.0, empleando un nivel
de confiabilidad del 95%, siguiendo estas condiciones:
Si:
Sig. < 0.05 adopta una distribución no normal.
Sig. ≥ 0.05 adopta una distribución normal.
37
Dónde:
Sig.: P-valor o nivel crítico del contraste.
Los resultados fueron los siguientes:
 INDICADOR 01: Impacto de gastos operacionales

Para obtener la prueba de hipótesis; los datos fueron sometidos a la
verificación de su distribución, con el fin de validar que los datos obtenidos
del indicador impacto de gastos operacionales generados contaban con
distribución normal.
Tabla 13 Prueba de Normalidad del impacto de gastos operacionales antes y
después de la implementación del Sistema Web
Pruebas de normalidad
Shapiro-Wilk
Estadístico Gl Sig.
IGO_PRETEST ,799 6 ,058
IGO_POSTTEST
,853 6 ,165
a. Corrección de significación de Lilliefors
En el gráfico se aprecia lo siguiente, el Sig. del indicador impacto de

gastos operacionales en el Pre-Test fue de 0.058, cuyo valor es mayor
que 0.05. Por lo tanto, el impacto de gastos operacionales cuenta con
distribución normal. Los resultados del Post-Test indican que el Sig. del
indicador impacto de gastos operacionales fue de 0.165, cuyo valor es
mayor que 0.05, por lo que indica que el impacto de gastos operacionales
cuenta con distribución normal. A continuación, se muestra un gráfico en
el que se puede apreciar la distribución normal de ambos datos de la
muestra:
38
Figura 7 Prueba de Normalidad del Impacto de Gastos Operacionales antes de
implementar el Sistema Web
Figura 8 Prueba de Normalidad del Impacto de Gastos Operacionales después de

implementar el Sistema Web
39
 INDICADOR 02: Porcentaje de incidencias en emisión
Para obtener la prueba de hipótesis; los datos fueron sometidos a la
verificación de su distribución, con el fin de validar que los datos obtenidos
del indicador porcentaje de incidencias en emisión generados contaban
con distribución normal.
Tabla 14 Prueba de Normalidad del porcentaje de gastos operacionales antes y

después de la implementación del Sistema Web
Pruebas de normalidad
Shapiro-Wilk
Estadístico Gl Sig.
PIE_PRETEST ,868 6 ,219
PIE_POSTTEST ,976 6 ,929
a. Corrección de significación de Lilliefors
En el gráfico se aprecia lo siguiente, el Sig. del indicador porcentaje de

incidencias en emisión en el Pre-Test fue de 0.219, cuyo valor es mayor
que 0.05. Por lo tanto, el porcentaje de incidencias en emisión cuenta con
distribución normal. Los resultados de la prueba del Post-Test indican que
el Sig. del indicador porcentaje de incidencias en emisión fue de 0.929,
cuyo valor es mayor que 0.05, por lo que indica que el porcentaje de
incidencias en emisión cuenta con distribución normal. A continuación, se
muestra un gráfico en el que se puede apreciar la distribución normal de
ambos datos de la muestra:
40
antes de implementar el Sistema Web

después de implementar el Sistema Web
41
3.3. Prueba de Hipótesis
Hipótesis de Investigación 1:
• H1: El Sistema Web disminuye el impacto de gastos operacionales en
la facturación electrónica centralizada de la empresa CUETO S.A.C.
• Indicador: Impacto de gastos operacionales
Hipótesis Estadísticas
Definición de Variables:
IGOa: Impacto de gastos operacionales antes de aplicar el sistema web.
IGOd: Impacto de gastos operacionales después de aplicar el sistema
web.
• H0: El Sistema Web no disminuye el impacto de gastos operacionales
en la facturación electrónica centralizada de la empresa CUETO
S.A.C.
H0: IGOa <= IGOd
El indicador sin el Sistema Web es mejor que el indicador con el Sistema
Web.
• HA: El Sistema Web disminuye el impacto de gastos operacionales en
la facturación electrónica centralizada de la empresa CUETO S.A.C.
HA: IGOa > IGOd
El indicador con el Sistema Web es mejor que el indicador sin el Sistema
Web.
El impacto de gastos operacionales en el Pre-Test es de 8.737% y en el
Post-Test es 1.285%.
Se concluye que existe una disminución del impacto de gastos
operacionales, el cual se aprecia al comparar las medias del Pre-Test y
Post-Test, que disminuye de 8.737% a 1.285%.
En cuanto al resultado del contraste de hipótesis se aplicó la Prueba T-
Student, ya que los datos recopilados (Pre-Test y Post-Test) se
distribuyen normalmente. El valor de T contraste es de 10.829, el cual es
mayor que 2.0150.
42
Tabla 15 Prueba de T-Student para el impacto de gastos operacionales en la
facturación electrónica centralizada antes y después de implementar el Sistema Web
Prueba de T-Student
Media T gl Sig. (bilateral)
IGO_PRETEST 8,814
10,829 5 ,000
IGO_POSTTEST 1,706
Aplicando la fórmula T Student:
Hallando T teórico:
gl = 5
43
α = 0.05
T = 2.0150
44
Figura 11 Prueba T-Student – Impacto de Gastos Operacionales
Debido a ello, se rechaza la hipótesis nula, aceptando la hipótesis

alterna con un 95% de confianza. Además, el valor T obtenido se ubica
45
en la zona de rechazo. Por lo tanto, el Sistema web disminuye el
impacto de gastos operacionales en la facturación electrónica
centralizada de la empresa CUETO S.A.C.
Hipótesis de Investigación 2:
• H2: El Sistema Web disminuye el porcentaje de incidencias en emisión
en la facturación electrónica centralizada de la empresa CUETO
S.A.C.
• Indicador: Porcentaje de incidencias en emisión.
Hipótesis Estadísticas
Definición de Variables:
PIEa: Porcentaje de incidencias en emisión antes de aplicar el sistema
web.
PIEd: Porcentaje de incidencias en emisión después de aplicar el sistema
web.
• H0: El Sistema Web no disminuye el porcentaje de incidencias en
emisión en la facturación electrónica centralizada de la empresa
CUETO S.A.C.
H0: PIEa <= PIEd
El indicador sin el Sistema Web es mejor que el indicador con el Sistema
Web.
• HA: El Sistema Web disminuye el porcentaje de incidencias en
emisión en la facturación electrónica centralizada de la empresa
CUETO S.A.C.
HA: PIEa > PIEd
El indicador con el Sistema Web es mejor que el indicador sin el Sistema
Web.
El porcentaje de incidencias en emisión en el Pre-Test es de 37.611% y
en el Post-Test es 19.027%.
46
Se concluye que existe una disminución del porcentaje de incidencias en
emisión, el cual se aprecia al comparar las medias del Pre-Test y Post-
Test, que disminuye de 37.611% a 19.027%.
En cuanto al resultado del contraste de hipótesis se aplicó la Prueba T-
Student, ya que los datos recopilados (Pre-Test y Post-Test) se
distribuyen normalmente. El valor de T contraste es de 3.872, el cual es
mayor que 2.0150.
Tabla 16 Prueba de T-Student para el porcentaje de incidencias en emisión de la
facturación electrónica centralizada antes y después de implementar el Sistema Web
Prueba de T-Student
Media T gl Sig. (bilateral)
PIE_PRETEST 37,517
3,872 5 ,012
PIE_POSTTEST 19,750
Aplicando la fórmula T Student:
Hallando T teórico:
gl = 5
47
α = 0.05
T = 2.0150
48
Figura 12 Prueba T-Student – Porcentaje de Incidencias en Emisión
Debido a ello, se rechaza la hipótesis nula, aceptando la hipótesis alterna

con un 95% de confianza. Además, el valor T obtenido se ubica en la zona
de rechazo. Por lo tanto, el Sistema web disminuye el porcentaje de
incidencias en emisión en la facturación electrónica centralizada de la
49
IV. DISCUSIÓN
En la presente investigación, el resultado obtenido es que el Sistema Web

disminuyo el impacto de gastos operacionales de un 8.814% a un 1.706%,
lo cual es equivalente a una disminución de 7,108% en promedio. De la
misma manera Navarro en su investigación “Sistema de facturación
electrónica para la gestión de comprobantes de pago basado en
ISO/IEC19845:2015 en Acgenesys S.A.C.”, obtuvo como resultado que el
impacto de gastos operacionales disminuyo de un 0.0278% a un
0.0107%, lo cual equivale a una disminución de 0.0171% en promedio.
Realizando una comparativa de ambas investigaciones, se aprecia que
en la presenta investigación se alcanzó un porcentaje mayor de
disminución del impacto de gastos operacionales con la aplicación del
Sistema Web.
Al mismo tiempo, el Sistema Web disminuyo el porcentaje de incidencias

en emisión de un 37.611% a un 19.027%, lo cual es equivalente a una
disminución de 18.584% en promedio. De la misma manera Navarro en
su investigación “Sistema de facturación electrónica para la gestión de
comprobantes de pago basado en ISO/IEC19845:2015 en Acgenesys
S.A.C.”, obtuvo como resultado que el porcentaje de incidencias en
emisión disminuyo de un 5.96% a un 1.41%, lo cual equivale a una
disminución de 4.55% en promedio. Realizando una comparativa de
ambas investigaciones, se aprecia que en la presenta investigación se
alcanzó un porcentaje mayor de disminución del porcentaje de
incidencias en emisión con la aplicación del Sistema Web.
Estos resultados confirman que el uso de la tecnología dentro de los

procesos, funciones y actividades de una empresa permiten alcanzar una
mejora significativa con cual, la empresa se beneficia. De esta manera,
se comprueba que el Sistema Web para la facturación electrónica
centralizada de la empresa CUETO S.A.C. disminuye el impacto de
50
gastos operacionales en un 1.706% y disminuye el porcentaje de
incidencias en emisión en un 19.027%. Por lo tanto, el Sistema Web
mejora la facturación electrónica centralizada en la empresa CUETO
S.A.C.
51
V. CONCLUSIONES
En conclusión, el Sistema Web mejora la facturación electrónica

centralizada de la empresa CUETO S.A.C., debido a que logro disminuir
el impacto de gastos operacionales y el porcentaje de incidencias en
emisión, permitiendo así obtener cumplir con los objetivos trazados en la
presente investigación.
El Sistema Web disminuye el impacto de gastos operacionales en la

facturación electrónica centralizada de la empresa CUETO S.A.C. Ya
que, logro disminuir el estado del indicador de un 8.814% a un 1.706%.
Entonces, logrando una disminución de 7.108% del indicador mencionado
en promedio; se afirma que el Sistema Web disminuye el impacto de
gastos operacionales en la facturación electrónica centraliza de la
El Sistema Web disminuye el porcentaje de incidencias en emisión en la

facturación electrónica centralizada de la empresa CUETO S.A.C. Ya
que, logro disminuir el estado del indicador de un 37.611% a un 19.027%.
Entonces, logrando una disminución de 18.584% del indicador
mencionado en promedio; se afirma que el Sistema Web disminuye el
porcentaje de incidencias en emisión en la facturación electrónica
centraliza de la empresa CUETO S.A.C.
52
VI. RECOMENDACIONES
Se recomienda llevar a cabo un monitoreo y mantenimiento constante del

sistema web, debido a que este involucra normativas tributarias y estas
normativas en el tiempo tienden a cambiar. De tal manera, que el sistema
en el tiempo perdure, se necesita estar atento a los cambios tributarios
que se puedan dar referente a la creación de la factura y los datos que la
conforman para que sean aplicados.
Adicional a ello, se recomienda llevar a cabo la presente investigación a

empresas de diferentes rubros. Ya que, los indicadores presentados
involucran netamente al proceso de facturación independientemente del
rubro comercial. Y de esta manera, obtener resultados favorables para el
proceso mencionado.
Finalmente, se sugiere tener en cuenta la facturación electrónica para

posteriores investigaciones. Debido a que este es un tema a tener en
cuenta para los siguientes años, ya que SUNAT busca que se logre
estandarizar la facturación electrónica en todos los negocios presentes
en el país.
53
VII. REFERENCIAS
ALCÁNTARA Rodriguez, Jorge Luis. Sistema Easy Bill en la Gestión de Ventas en

la Empresa Security & Trade Company S.A.C., 2017. Tesis (Ingeniero de Sistemas
e Informática). LIMA: Universidad Norbert Wiener, Escuela Academico Profesional
de Ingenierias, 2017. 162 pp.
ANGELI, H.D. and ANTONIO, L.M. Elestronic Invoice for services: An Analysis of
impacts on collection in Brazilian Municipalities. Revista De Contabilidad e
Organizaciones, 2016, vol. 10, no. 26 ProQuest Central. DOI
http://dx.doi.org/10.11606/rco.v10i26.107117.
Arktec.S.A. Software para arquitectura ingeniería y construcción. Arktec S.A.

Disponible en:
http://www.arktec.com/ES/Productos/Constructo/Modulos/FacturacionConstructo.a
spx
AMARO Quispe, Kennidy. Sistema de emisión de comprobantes de pago

electrónicos en el proceso de facturación de Contasis SAC. Tesis (Ingeniero de
Sistemas). Huancayo: Universidad Nacional del Centro del Perú, 2017. 126 pp.
BARREIX, Alberto, ZAMBRANO, Rau. Factura Electrónica en América Latina

Republica de Panamá: Centro Interamericano de Administraciones Tributarias,
2018 [fecha de consulta: 15 de Mayo de 2019].
Disponible en:
https://books.google.com.pe/books?id=DOmaDwAAQBAJ&pg=PR12&dq=facturaci
on+electronica&hl=es&sa=X&ved=0ahUKEwjt-
eP10qvjAhXsHrkGHZP2DWYQ6AEIKDAA#v=onepage&q=facturacion%20electron
ica&f=false
ISBN: 8497256921
54
BENDEZU Figueroa, Freddy. Implementación de sistema de facturación electrónica
con transferencia de comprobantes a la SUNAT en las MYPES AYACUCHO; 2017.
Tesis (Ingeniero de Sistemas). Chimbote: Universidad Católica los Ángeles de
Chimbote, Escuela Profesional de Ingeniería de Sistemas, 2017. 104 pp.
BERENGUEL, José. Desarrollo de aplicaciones web en el entorno servidor. Madrid:

Ediciones Parainfo, S.A., 2016 [fecha de consulta: 15 de abril de 2019].
Disponible en:
https://books.google.com.pe/books?id=gVGACwAAQBAJ&printsec=frontcover&dq
=aplicaciones+web&hl=es&sa=X&ved=0ahUKEwjG2PemlYDiAhWBGLkGHbMWA
0I4ChDoAQhAMAU#v=onepage&q=aplicaciones%20web&f=false
ISBN: 9788428397179
BERZAL, Fernando, CORTIJO, Francisco y CUBERO, Juan. Desarrollo Profesional

de Aplicaciones Web con ASP.NET. 2015
Disponible en:
https://books.google.com.pe/books?id=J1d_9l6zlAIC&pg=PA3&dq=sistema+web&
hl=es&sa=X&ved=0ahUKEwjt8JaP-
93hAhW8IrkGHWI_CFY4ChDoAQhOMAg#v=onepage&q=sistema%20web&f=fals
e
ISBN 8460942457
BISQUERRA Alzina, Rafael. Metodologia de la investigación educativa [en línea].

2da Ed. Madrid: Lavel, Industria Grafica, S.A., 2009. [fecha de consulta: 16 de mayo
de 2019].
Disponible en:
https://books.google.com.pe/books?id=VSb4_cVukkcC&pg=PA143&dq=metodolog
ia+de+la+investigacion+poblacion&hl=es-
419&sa=X&ved=0ahUKEwiPubXgt6PiAhVAHbkGHRjKBxAQ6AEISjAG#v=onepag
e&q=metodologia%20de%20la%20investigacion%20poblacion&f=false
ISBN: 9788471337481
55
CARDADOR, Antonio. Implantación de aplicaciones web en entornos internet,
intranet y extranet [en línea]. Málaga: IC Editorial, 2014. [ fecha de consulta: 15 de
abril de 2019].
Disponible en:
https://books.google.com.pe/books?id=Lj91CQAAQBAJ&printsec=frontcover&dq=
aplicaciones+web&hl=es&sa=X&ved=0ahUKEwjC79aYlYDiAhXIGbkGHUJSDeYQ
6AEILjAB#v=onepage&q=aplicaciones%20web&f=false
ISBN: 9788416433094
CHANG, C., CHIN-JUI, K., HUAI-CHIEN, C., CHEN-YUAN, C., TSUNG-HAO, C.

and PEI-YIN, C. Ergonomic Techniques for a Mobile E-Invoice System:
Operational Requirements of an Information Management System. Human Factors
and Ergonomics in Manufacturing, Nov, 2013, vol. 23, no. 6. pp. 582 ProQuest
Central.
ISSN 10908471
CUYLEN, A., KOSCH, L. and BREITNER, M.H., 2016. Development of a Maturity

Model for Electronic Invoice Processes. Electronic Markets, 05, vol. 26, no. 2, pp.
115-127 ProQuest Central.
ISSN 10196781
DEL RIO Sadornil, Dionisio. Diccionario-Glosario de meotodologia de la

investigación social [en línea]. Madrid: Universidad Nacional de Educacion a
Distancia, 2013 [fecha de consulta: 16 de mayo de 2019].
Disponible en:
https://books.google.com.pe/books?id=XtlEAgAAQBAJ&pg=PT254&dq=metodolog
ia+de+la+investigacion+poblacion&hl=es-
419&sa=X&ved=0ahUKEwiPubXgt6PiAhVAHbkGHRjKBxAQ6AEITzAH#v=onepag
e&q=metodologia%20de%20la%20investigacion%20poblacion&f=false
ISBN: 9788436268034
56
GÓMEZ, Marcelo. Introducción a la metodología de la investigación científica [en
línea]. Córdoba: Editorial Brujas, 2006 [fecha de consulta: 1 de mayo de 2019].
Disponible en:
https://books.google.com.pe/books?id=9UDXPe4U7aMC&printsec=frontcover&dq=
metodologia+de+la+investigacion&hl=es-
419&sa=X&ved=0ahUKEwjBh6P84oriAhWuHbkGHQsVCuwQ6AEIKDAA#v=onep
age&q=metodologia%20de%20la%20investigacion&f=false
ISBN: 9875910260
GONZÁLEZ, José, MORINI, Sandra y DO NASCIMIENTO, Eduardo. Control y

Gestión del área comercial y de producción de la PYME. Una aplicación práctica
con: SP FacturaPlus y SP TPVplus Elite. 1a. ed. España: Netbiblo, 2002. 484 p.
ISBN: 84-9745-022-1
HERNANDEZ, B. and JIMENEZ, J. Performance of e-Invoicing in Spanish Firms.

Information Systems and eBusiness Management, 09, 2013, vol. 11, no. 3. pp. 457-
480 ProQuest Central.
ISSN 16179846.
HERNÁNDEZ, R., FERNÁNDEZ, C. Y BAPTISTA, M. (2010). Metodología de la

Investigación. (5.a ed.). México, D.F: McGraw-Hill.
HERRERA Carranza, Brenda. Diseño e Implementación de la Factura Electrónica

como mecanismo para hacer más eficiente el proceso de facturación en
Certicámara S.A. Tesis (Proyecto de Grado). Bogota: Universidad de la Salle,
Facultad de Ciencias Administrativas y Contables, 2011. 80pp.
ICONIX. Ecured. 18 de abril de 2013.

Disponible en: https://www.ecured.cu/ICONIX
57
LANDEAU, Rebeca. Elaboración de trabajos de investigación. Caracas: Editorial
Alfa, 2007 [fecha de consulta: 1 de mayo de 2019].
Disponible en:
https://books.google.com.pe/books?id=M_N1CzTB2D4C&printsec=frontcover&dq=
landeau+rebeca&hl=es&sa=X&ved=0ahUKEwj-
t4yN44riAhVhK7kGHXVfAPcQ6AEIKDAA#v=onepage&q&f=false
ISBN: 9803542141
LEURO, Mauricio y OVIEDO, Irsa. Facturación y auditoría de cuentas en salud [en

línea]. 5° ed. Bogotá: Ecoe Ediciones. 2016. [fecha de consulta: 15 de abril de 2019].
Disponible en:
https://books.google.com.pe/books?id=61uzDQAAQBAJ&pg=PT91&dq=facturacio
n+centralizada&hl=es&sa=X&ved=0ahUKEwjUtdj_hd7hAhVbIrkGHSkEAmoQ6AEI
KDAA#v=onepage&q=facturacion%20centralizada&f=false
ISBN: 9789587712964
Metodología de la investigación científica por Hernández Arturo [et al.]. Editorial

Área de innovación y desarrollo, S.L., 2018 [fecha de consulta: 1 mayo de 2019].
Disponible en:
https://books.google.com.pe/books?id=y3NKDwAAQBAJ&printsec=frontcover&dq=
metodologia+de+la+investigacion&hl=es-
419&sa=X&ved=0ahUKEwjBh6P84oriAhWuHbkGHQsVCuwQ6AEIWTAJ#v=onep
age&q&f=false
ISBN: 9788494825705
MOLINA, Joaquín. Implantación de aplicaciones informáticas de gestión [en línea].

Madrid: Editorial Visión Net, 2007 [fecha de consulta 15 de abril de 2019].
Disponible en:
https://books.google.com.pe/books?id=9L56g6reVgkC&pg=PA230&dq=APLICACI
ON+WEB&hl=es&sa=X&ved=0ahUKEwjw29C0m4DiAhWaDrkGHSncCF0Q6AEIPj
AE#v=onepage&q=APLICACION%20WEB&f=false
58
ISBN: 9788498218718
MONCADA, José. Estadística para ciencias del movimiento humano [en línea].
Costa Rica: Editorial de la Universidad de Costa Rica, 2005 [fecha de consulta 15
de mayo de 2019].
Disponible en:
https://books.google.com.pe/books?id=cPjFVyPd5PUC&pg=PA14&dq=prueba+t+s
tudent&hl=es&sa=X&ved=0ahUKEwjwjpbCpazjAhWKHbkGHfg5BjYQ6AEIKDAA#v
=onepage&q=prueba%20t%20student&f=false
ISBN: 9977679266
NAVARRO Flores, Theany. Sistema de facturación electrónica para la gestión de

comprobantes de pago basado en ISO/IEC19845:2015 en Acgenesys S.A.C. Tesis
(Ingeniero de Sistemas). Lima: Universidad César Vallejo, Escuela profesional de
Ingeniería de Sistemas, 2017. 147 pp.
NEGRETE Bonilla, Jairo. Desarrollo de un sistema web de facturacion electronica

con comunicación al servicio de rentas internas, aplicado a la empresa expertweb
cia. ltda., en la ciudad de Quito. Tesis (Ingeniero de Sistemas). Quito: Pontificia
Universidad Satólica del Ecuador, Escuela de Ingenieria, 2016. 63 pp.
ORDAYA Lock, Rita. Implementación de un sistema de información para una MYPE

comercial con componentes de libros y facturación electrónica. Tesis (Ingeniera
Informática). Lima: Pontificia Universidad Católica del Perú, Facultad de Ciencias e
Ingeniería, 2015. 68 pp.
Proceso unificado de desarrollo. Ecured. 12 de agosto de 2010.

Disponible en: https://www.ecured.cu/Proceso_unificado_de_desarrollo
RATHS, D., 2014. 7 WAYS TO BREAK UP WITH PAPER. Behavioral Healthcare,

Nov, vol. 34, no. 6, pp. 26-27 ProQuest Central.
59
ISSN 19317093
Sistema Gestor de Base de Datos. Ecured. 24 de marzo de 2011.

Disponible en: https://www.ecured.cu/Sistema_Gestor_de_Base_de_Datos
SCRUM. Ecured. 5 de setiembre de 2014.

Disponible en: https://www.ecured.cu/SCRUM
Servicio de Información contable, gestión económica y financiera. Universitas

Miguel Hernández. 28 setiembre de 2017.
Disponible en:
https://sicgef.umh.es/gestion-financiera/facturacion-2/
VILLADA, Jóse. Instalación y configuración del software de servidor Web. Málaga:

IC Editorial, 2014 [fecha de consulta: 15 de abril de 2019].
Disponible en:
https://books.google.com.pe/books?id=RrfbCgAAQBAJ&pg=PT90&dq=servidor+w
eb&hl=es&sa=X&ved=0ahUKEwjcu-qfvPDhAhUnD7kGHRNfA-
oQ6AEILTAB#v=onepage&q=servidor%20web&f=false
ISBN: 9788416433957
VIVANCO, Manuel. Muestreo Estadístico. Diseño y Aplicaciones. Santiago de Chile:

Editorial Universitaria, S.A., 2005 [fecha de consulta: 15 de mayo de 2019].
Disponible en:
https://books.google.com.pe/books?id=-
_gr5l3LbpIC&pg=PA69&dq=muestreo+aleatorio+simple&hl=es&sa=X&ved=0ahUK
Ewi6rsefjqzjAhVxE7kGHVyvAaEQ6AEIKzAB#v=onepage&q=muestreo%20aleatori
o%20simple&f=false
ISBN: 9561118033
60
ANEXOS
61
ANEXO 01 – MATRIZ DE CONSISTENCIA
62
ANEXO 02 – ENTREVISTA
63
64
ANEXO 03 – CARTA DE ACEPTACIÓN
65
ANEXO 04 – ESPINA DE ISHIKAWA
66
ANEXO 05 – PRE-TEST INDICADOR PORCENTAJE DE INCIDENCIAS EN
EMISIONES
67
ANEXO 06 – PRE-TEST INDICADOR IMPACTO DE GASTOS OPERACIONALES
68
ANEXO 07 – POST-TEST INDICADOR PORCENTAJE DE INCIDENCIAS EN
EMISIONES
69
ANEXO 08 – POST-TEST INDICADOR IMPACTO DE GASTOS
OPERACIONALES
70
ANEXO 09 – VALIDACIÓN DE EXPERTOS DE METODOLOGÍA DE
DESARROLLO DE SOFTWARE
71
72
73
ANEXO 10 – VALIDACIÓN DE EXPERTO DE INDICADORES
74
75
76
77
78
79
ANEXO 11 – Desarrollo de Metodología SCRUM
A continuación de detalle el paso a paso de la ejecución de la metodología de
desarrollo de software utilizada en la presente investigación.
 EQUIPO SCRUM
Es el grupo que estará a cargo del desarrollo de la metodología, llevando a
cabo cada una de sus fases, desarrollando los artefactos y entregables
respectivos, con el fin de obtener el resultado esperado. Las personas que
formaron parte del equipo son:
EQUIPO SCRUM
CARGO
INTEGRANTE
Product Owner Hugo Cueto Cordero

Samuel Montalvan
Equipo de desarrollo Marelyn Carranza

Jhonatan Carhuamanca
Scrum Master Ing. Adderly Santos Cervantes
 PRODUCT BACKLOG
El Product Owner definió el Product Backlog, donde indica todos los
requerimientos necesarios del producto, en este caso el Sistema web.
PRODUCT BACKLOG (LISTA DE PRODUCTO)
N° REQUERIMIENTO DESCRIPCIÓN
1 REGISTRAR EMPRESAS CON Tener la opción de registrar n

SUS CREDENCIALES SOL empresas con sus credenciales
PARA LA EMISIÓN DE SUS SOL, tales como RUC, Usuario
FACTURAS SOL, clave SOL, Certificado Digital,
clave de certificado digital para que
se emitan sus facturas.
2 ASIGNAR USUARIOS A En el registro de las empresas se
EMPRESAS REGISTRADAS cree un usuario para que puedan
acceder al sistema.
80
3 LISTAR PEDIDO VENTA Tener la opción de ver todos los
pedidos venta que registraron los
vendedores desde la aplicación de
pedidos.
4 VALIDAR PEDIDO VENTA Tener la opción de editar los
pedidos venta generados desde la
aplicación de pedidos, en el caso se
tengan que quitar o añadir más
productos a los pedidos, o editar
cantidades de los detalles del
pedido o actualizar información
referente al cliente.
5 LIQUIDAR CUENTA Una vez validados los pedidos
venta, poder liquidar la cuenta del
día de tal manera que pueda ver
todo lo que salió ese día y lo que
debería retornar en el caso haya
sido editado, además los pedidos
venta pasen a ser no editables y ya
no ser pedidos venta sino ventas
asignándose una serie y numero
correlativo de factura con el cual
será posteriormente emitido a
SUNAT.
6 LISTAR VENTA Tener la opción de listar las ventas
generadas en la liquidación,
mostrándose la serie y correlativo
de factura creadas y que aún no se
han emitido a SUNAT.
7 EMITIR FACTURA A SUNAT Seleccionar las facturas por
empresa que se emitirán a SUNAT
y emitirlas.
8 LISTAR FACTURA EMITIDA Luego de emitidas las facturas,
visualizar que todas se hayan
emitido correctamente validando su
CDR.
9 ANULAR FACTURA EMITIDA A Tener la opción de anular facturas,
SUNAT generando documentos de baja
directamente a SUNAT.
10 LISTAR FACTURA ANULADA Luego de anuladas, verificar que se
hayan anulado correctamente
validando su CDR.
11 ENVIAR FACTURA A CLIENTE Tener una opción que me permita
enviar las facturas generadas al
correo registrado por los clientes.
81
12 REGISTRAR GASTOS DE Tener una opción de gastos de
FACTURACIÓN facturación, donde me permita
ingresar montos de dinero
referentes a los gastos que conllevo
una liquidación.
 HISTORIAS DE USUARIO
Se elaboro las historias de usuario, que contienen de forma detallada cada
uno de los requerimientos definidos por el Producto Owner en el Product
Backlog.
Historia de Usuario
Número: 1 Nombre: Registro de
empresas
Usuario: Administrador
Modificación de Historia de Iteración asignada: ---

usuario: -
Prioridad en Negocio (Alta / Puntos estimados: ---
Media / Baja): Alta
Riesgo en desarrollo (Alto / Puntos Reales: ---

Medio / Bajo): Bajo
Descripción:
Tener la opción de registrar n empresas con sus
credenciales SOL, tales como RUC, Usuario SOL, clave
SOL, Certificado Digital, clave de certificado digital para
que se emitan sus facturas.
Observaciones:
82
Historia de Usuario
Número: 2 Nombre: Asignar usuarios
a empresas

usuario: -
Media / Baja): Alta
Medio / Bajo): Bajo
Descripción:
En el registro de las empresas se cree un usuario para que
puedan acceder al sistema.
Observaciones:
Historia de Usuario
Número: 3 Nombre: Listar pedido
venta

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Tener la opción de ver todos los pedidos venta que
registraron mis vendedores desde la aplicación de pedidos.
Observaciones:
83
Historia de Usuario
Número: 4 Nombre: Validar pedido
venta

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Tener la opción de editar los pedidos venta generados desde
la aplicación de pedidos, en el caso se tengan que quitar o
añadir más productos a los pedidos, o editar cantidades de
los detalles del pedido o actualizar información referente al
cliente.
Observaciones:
84
Historia de Usuario
Número: 5 Nombre: Liquidar
cuenta

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Una vez validados los pedidos venta, poder liquidar la
cuenta del día de tal manera que pueda ver todo lo que
salió ese día y lo que debería retornar en el caso haya sido
editado, además los pedidos venta pasen a ser no
editables y ya no ser pedidos venta sino ventas
asignándose una serie y numero correlativo de factura con
el cual será posteriormente emitido a SUNAT.
Observaciones:
Historia de Usuario
Número: 6 Nombre: Listar venta

usuario: -
Media / Baja): Alta
Medio / Bajo): Bajo
Descripción:
Tener la opción de listar las ventas generadas en la
liquidación, mostrándose la serie y correlativo de factura
creadas y que aún no se han emitido a SUNAT.
Observaciones:
85
Historia de Usuario
Número: 7 Nombre: Emitir facturas
a SUNAT

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Seleccionar las facturas por empresa que se emitirán a
SUNAT y emitirlas.
Observaciones:
Historia de Usuario
Número: 8 Nombre: Listar
facturas emitidas

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Luego de emitidas las facturas, visualizar que todas se
hayan emitido correctamente validando su CDR.
Observaciones:
86
Historia de Usuario
Número: 9 Nombre: Anular
facturas emitidas

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Tener la opción de anular facturas, generando
documentos de baja directamente a SUNAT.
Observaciones:
Historia de Usuario
Número: 10 Nombre: Listar
facturas anuladas

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Luego de anuladas, verificar que se hayan anulado
correctamente validando su CDR.
Observaciones:
87
Historia de Usuario
Número: 11 Nombre: Enviar
facturas a clientes

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Tener una opción que me permita enviar las facturas
generadas al correo registrado por los clientes.
Observaciones:
Historia de Usuario
Numero: 12 Nombre: Registrar
gastos de facturación

usuario: -
Media / Baja): Alta

Medio / Bajo): Bajo
Descripción:
Tener una opción de gastos de facturación, donde me
permita ingresar montos de dinero referentes a los gastos
que conllevo una liquidación.
Observaciones:
88
 SPRINT BACKLOG
Se elaboro el sprint backlog que corresponde a la definición de cada uno de
los sprint a realizar agrupados por historias de usuario que serán elaboradas
dentro del tiempo estimado del mismo. De igual manera se detalló cada una
de las actividades que se desarrollaran durante el desarrollo de cada sprint
de tal manera que se demuestra un incremento mas detallado al final de cada
sprint culminado.
SPRINT BACKLOG
N° HISTORIAS DE ESTIMACIÓN
DESCRIPCIÓN
SPRINT USUARIO (# días)
Se realizará la planificación del proyecto,
seguido de los diseños necesarios para el
0 - desarrollo del mismo. Tales como, diagramas de 10
casos de uso, diagramas de base de datos,
prototipos de interfaces de usuario
Se realizará el desarrollo de las interfaces de
1 HU1-HU2 registro de empresas y su asignación de 15
usuarios de acceso al sistema.
Se realizará el desarrollo del mantenimiento del
pedido venta, desde su validación hasta su
HU3-HU4-HU5- registro como venta. Adicional a ello se
2 20
HU6-HU12 desarrollará la interfaz de registro de gastos de
facturación que está asociado a la liquidación de
cuenta.
Se realizará el desarrollo de los envíos y
validaciones de emisión de facturas a SUNAT,
HU7-HU8-HU9- desde la emisión conectándose vía webservice,
3 30
HU10-HU11 la recepción de la respuesta del webservice y el
envió de los documentos emitidos a los clientes.
89
N° ESTIMACIÓN TOTAL
HISTORIA DE USUARIO ACTIVIDADES
SPRINT (#DÍAS) (#DÍAS)
REUNIÓN DE PLANIFICACIÓN 1
DIAGRAMAS DE CASOS DE USO 2
DIAGRAMAS DE BASE DE DATOS 3
DISEÑO DE PROTOTIPO DE
0 - 2 12
INTERFACES
INTERFAZ DE INICIO DE SESIÓN 2
PRESENTACIÓN DE SPRINT 1
REVISIÓN DE SPRINT 1
- REUNIÓN DE PLANIFICACIÓN 1
CREACIÓN DE INTERFAZ DE
2
MANTENIMIENTO DE EMPRESA
VALIDACIÓN DE CAMPOS
2
HU1: Registro de empresas REQUERIDOS
MANTENIMIENTO DE EMPRESA 2
PRUEBA DE MANTENIMIENTO DE
1 2 15
EMPRESA
2
ASIGNACIÓN DE USUARIO A EMPRESA
HU2: Asignar usuarios a
empresas ASIGNACIÓN DE USUARIO A EMPRESA 2
PRUEBA DE ASIGNACIÓN DE USUARIO
1
A EMPRESA
- REVISIÓN DE SPRINT 1
CREACIÓN DE INTERFAZ DE LISTA DE
2 1 23
HU3: Listar pedido venta PEDIDO VENTA
LISTA PEDIDO VENTA 1
90
PRUEBA DE LISTA PEDIDO VENTA 1
1
VALIDACIÓN PEDIDO VENTA
HU4: Validar pedido venta
VALIDACIÓN PEDIDO VENTA 2
PRUEBA VALIDACIÓN PEDIDO VENTA 1
1
LIQUIDACIÓN DE CUENTA
HU5: Liquidar cuenta
LIQUIDACIÓN DE CUENTA 3
PRUEBA DE LIQUIDACIÓN DE CUENTA 1
1
VENTA
HU6: Listar venta
LISTA DE VENTA 1
PRUEBA DE LISTA DE VENTA 1
REGISTRO DE GASTOS DE 1
FACTURACIÓN
REGISTRAR GASTOS DE
HU12: Registrar gastos de 1
FACTURACIÓN
facturación REPORTE DE PORCENTAJE DE
3
GASTOS OPERACIONALES
PRUEBA DE REGISTRO DE GASTOS DE
1
FACTURACIÓN
CREACIÓN DE INTERFAZ DE EMISIÓN
1
DE FACTURAS
3 HU7: Emitir facturas a 28
CREAR CONEXIÓN A WEB SERVICE 3
SUNAT
GENERAR XML 2
FIRMAR XML 2
91
CREAR MÉTODO DE ENVÍO Y
RECEPCIÓN 1
DE XML
EMITIR FACTURA 1
PRUEBA DE EMISIÓN DE FACTURA 1
1
FACTURAS EMITIDAS
HU8: Listar facturas
LISTAR FACTURAS EMITIDAS 1
emitidas
PRUEBA DE LISTA DE FACTURAS
1
EMITIDAS
1
ANULACIÓN DE FACTURAS
HU9: Anular facturas CREAR MÉTODO DE ENVÍO DE
2
emitidas COMUNICACIÓN DE BAJA
ANULAR FACTURAS EMITIDAS 2
PRUEBA DE FACTURAS EMITIDAS 1
1
FACTURAS ANULADAS
HU10: Listar facturas LISTAR FACTURAS ANULADAS 1
anuladas REPORTE DE INCIDENCIAS EN
3
EMISIÓN
PRUEBA DE LISTA DE FACTURAS
1
ANULADAS
92
 SPRINT 0
N° HISTORIA DE ESTIMACIÓN TOTAL

ACTIVIDADES
SPRINT USUARIO (#DÍAS) (#DÍAS)
REUNIÓN DE
1
PLANIFICACIÓN
DIAGRAMAS DE CASOS
2
DE USO
DIAGRAMAS DE BASE
3
DE DATOS
DISEÑO DE
0 - PROTOTIPO DE 2 12
INTERFACES
INTERFAZ DE INICIO DE
2
SESIÓN
PRESENTACIÓN DE
1
SPRINT
o Reunión de planificación
Reunión de planificación del sprint 0, participa todo el equipo Scrum y se lleva
a cabo con el fin de definir las actividades a realizar y las estrategias que se
llevaron a cabo para la realización de las mismas.
 Acta de reunión
o ACTA DE REUNIÓN
Comité o Grupo: Equipo Scrum
Acta No: 1
Citada por: - Fecha: 03-09-2019
Coordinador: Samuel Montalvan Merino
Hora inicio: 9:00 am Fin: 12:00 pm
Secretario: - Lugar: CUETO S.A.C.
PARTICIPANTES
No
Nombre Cargo Teléfono
.
1 Hugo Cueto Cordero Product Owner -
2 Adderly Santo Cervantes Scrum Master -
3 Samuel Montalvan Merino Desarrollador -
93
4 Marelyn Carranza Desarrollador -
5 Jonathan Carhuamanca Desarrollador -
PUNTOS DE DISCUSIÓN
1 Establecer estrategias para el cumplimiento de objetivos.
2 Asignación de tareas para equipo de desarrollo.
3 Estimación de plazos de entrega.
4
5
DESARROLLO DE LA REUNIÓN
1. El señor Hugo Cueto que desempeña el rol de Product Owner detallo los puntos
que a su parecer son más importantes para el desarrollo del proyecto, los cuales son:
*Compromiso de cada integrante del equipo Scrum, indicando que es muy importante
que todos pongan de su parte en la ejecución de cada tarea o actividad asignada, y
en lo posible cada percance o dificultad sea reportada de tal manera que si es factible
se realicen ajustes en las actividades propuestas para un mejor y fácil desarrollo.
*Trabajo en equipo, recalco lo importante que es llevar a cabo esta habilidad ya que
si cada uno avanza por su cuenta limitándose a lo que se le asigna el avance será
pobre y defectuoso. Lo que cambiaría si todos se trabaja conjuntamente, ayudándose
unos con otros, informando y compartiendo el avance de cada uno hacia los demás
integrantes del equipo de desarrollo ya que al fin y al cabo todo está conectado y es
importante que se tenga en cuenta lo que se a hace a fin de que no se tenga que
realizar cambios posteriores que retrasarían el desarrollo del proyecto.
*Proactividad, recalco que lo dicho por él no es algo estricto o final ya que si el equipo
de desarrollo encuentra observaciones no hay problema en comunicarse ya que al
conocer el tema tecnológico pueden indicar sugerencias en cuanto a aspectos
mencionados por él. Siempre buscando realizar las cosas de mejor manera.
2. El Scrum Master Adderly Santos indico las principales actividades que se llevarían
a cabo y los entregables respectivos durante el desarrollo del sprint 0. Involucrando
la parte de planificación del proyecto, desarrollo de diagramas de modelado del
sistema, la base de datos, las interfaces graficas. Luego de ello se detallaron todas
las actividades que involucrarían durante este sprint y al mismo tiempo la asignación
de cada una de ellas.
3. El equipo de desarrollo compartió sus conocimientos referentes a las herramientas

que se utilizarían para el desarrollo de este sprint, ya sea para la parte de
diagramación o diseño, entre las herramientas mencionadas están:
94
*Erwing Data Modeler
*Rational Rose
*Star UML
*Balsamiq
* Mockup builder
Observaciones.
CONCLUSIONES
Período de
No Tarea Responsable Observaciones
cumplimiento
1 Modelado de diagrama Jhonatan
2 días
de casos de uso. Carhuamanca
2 Modelado de base de
Samuel Montalvan 3 días
datos.
3 Diseño de prototipos de
interfaz gráfica de Marelyn Carranza 2 días
sistema.
4 Exposición de tareas
Samuel Montalvan 1 día
concluidas.
5
95
PROJECT CHARTER
NOMBRE DEL PROYECTO SIGLAS DEL PROYECTO

SISTEMA WEB PARA LA
FACTURACIÓN
SW
ELECTRÓNICA
FEC
CENTRALIZADA EN LA
EMPRESA CUETO S.A.C.
DESCRIPCIÓN DEL PROYECTO:
El sistema web para la facturación electrónica centralizada en la empresa CUETO

S.A.C. consiste en el desarrollo de un sistema orientado a la web que permita la
emisión directa de las facturas propias de la empresa como la de sus clientes a
SUNAT. Este sistema debe permitir realizar el envió mencionado y la recepción
de los mismos permitiendo al usuario tener un acceso directo a los mimos.
El desarrollo del proyecto consistirá en:

- Planificación de los sprint.
- Creación de diseño de cada interfaz.
- Desarrollo de lógica a nivel de base de datos.
- Desarrollo de lógica a nivel de software.
- Pruebas de cada módulo desarrollado.
El desarrollo del proyecto estará a cargo de los siguientes:

- Hugo Cueto Product Owner
- Ing. Adderly Santos Cervantes Scrum Master.
- Samuel Montalvan  Desarrollador en equipo de desarrollo.
- Marelyn Carranza Desarrollador en equipo de desarrollo.
- Jhonatan Carhuamanca Desarrollador en equipo de desarrollo.
El proyecto será realizado desde el 01 de setiembre hasta 30 de noviembre,

llevándose a cabo cada entregable según lo pactado en el cronograma. La gestión
del proyecto se realizará en las instalaciones de CUETO S.A.C. por el equipo
SCRUM.
DEFINICIÓN DE REQUISITOS DEL PROYECTO:

El Cliente tiene los siguientes requisitos:
- Registrar empresas con sus credenciales sol para la emisión de sus facturas
- Asignar usuarios a empresas registradas
- Listar pedido venta
- Validar pedido venta
- Liquidar cuenta
- Listar venta
- Emitir factura a SUNAT
96
- Listar factura emitida
- Anular factura emitida a SUNAT
- Listar factura anulada
- Enviar factura a cliente
- Registrar gastos de facturación
OBJETIVOS DEL PROYECTO:

CONCEPTO OBJETIVOS CRITERIO DE ÉXITO
Cumplir con la elaboración de los
siguientes entregables: Gestión del Aprobación de todos
1. ALCANCE Proyecto, Contratos, Curso de Gestión los entregables por
de Proyectos, Curso de GP usando MS parte del cliente.
Project e Informes.
Concluir el proyecto en
Concluir el proyecto en el plazo 12 semanas, del 01 de
2. TIEMPO
solicitado por el cliente. Setiembre y hasta el 30
de Noviembre.
Cumplir con el presupuesto estimado No exceder el
3. COSTO del proyecto de presupuesto del
S/. 9641,78. proyecto.
FINALIDAD DEL PROYECTO:
Generar ingresos para la empresa.
JUSTIFICACIÓN DEL PROYECTO:

JUSTIFICACIÓN JUSTIFICACIÓN
CUALITATIVA CUANTITATIVA
Generar ingresos para la empresa. Flujo de
Ingresos.
Ampliación de clientes de la empresa. Flujo de
Egresos.
Disminuir egresos de la empresa. Flujo de
Egresos.
DESIGNACIÓN DEL PROJECT MANAGER DEL PROYECTO

NOMBRE Adderly Santos NIVELES DE AUTORIDAD
REPORTA A Hugo Cueto
Exigir el cumplimiento de los entregables del
SUPERVISA A Equipo de proyecto.
desarrollo
97
ORGANIZACIONES O GRUPOS ORGANIZACIONALES QUE INTERVIENEN
EN EL PROYECTO
ORGANIZACIÓN O GRUPO ROL QUE DESEMPEÑA
ORGANIZACIONAL
CUETO S.A.C. Empresa encargada del financiamiento
del proyecto. Además, es la empresa
para la cual se está desarrollando el
proyecto en cuestión.
PRINCIPALES AMENAZAS DEL PROYECTO (RIESGOS NEGATIVOS)

- Los entregables planificados no son entregados en según el cronograma
propuesto.
- Equipo de desarrollo no encuentra información para conectarse al
webservice de SUNAT.
- Dificultades para crear la estructura XML de la factura.
- Estaciones de trabajo en las que se laboran deficientes.
- Dificultades para usar los métodos de envió y respuesta del webservice de
SUNAT hacia el sistema web.
- Equipo de desarrollo no puede leer respuesta de CDR de SUNAT.
PRINCIPALES OPORTUNIDADES DEL PROYECTO (RIESGOS POSITIVOS)
- El desarrollo del sistema web para la facturación electrónica centralizada en
la empresa CUETO S.A.C. permitirá una reducción en las incidencias en
emisiones dentro de la empresa.
- El desarrollo del sistema web para la facturación electrónica centralizada en
la empresa CUETO S.A.C. permitirá una reducción en los gastos
operacionales dentro de la empresa.
PRESUPUESTO PRELIMINAR DEL PROYECTO:

CONCEPTO MONTO (S/.)
1. Recursos Equipo de Proyecto 5400
Humanos
2. MATERIALES Material 3941,78
3. Bienes de Local 300
inversión
TOTAL LÍNEA BASE 9641,78
TOTAL PRESUPUESTO 9641,78
98
SPONSOR QUE AUTORIZA EL PROYECTO
NOMBRE EMPRESA CARGO FECHA
Hugo CUETO S.A.C. Gerente 05-09-2019
Cueto General
99
o Diagramas de base de datos
 Diagrama de base de datos lógico
100
 Diagrama de base de datos físico
101
o Prototipos de interfaces
 Inicio de Sesión
 Mantenimiento de Empresas
102
 Asignación de usuarios de empresa
103
 Lista de pedido venta
 Validación de pedido venta
104
 Liquidación de cuenta
 Lista de venta
105
 Emisión de facturas
 Lista de facturas
106
 Anulación de facturas
 Lista de facturas anuladas
107
108
o Revisión del Sprint 0
Se verifico que se haya culminado cada una de las actividades
definidas en el sprint, y se indicando observaciones o pendientes si lo
hubiera.
DURACIÓN
ACTIVIDADES A DURACIÓN
N° ESTADO OBSERVACIÓN FINAL
REALIZAR (#días)
(#días)
REUNION DE TERMINADO
1 1 - 1
PLANIFICACIÓN TOTAL
Scrum Master indicó
DIAGRAMAS DE CASOS que no era necesario
2 2 ANULADO 2
DE USO realizar esa
documentación
DIAGRAMAS DE BASE TERMINADO
3 3 - 0
DE DATOS TOTAL
DISEÑO DE PROTOTIPO TERMINADO
4 2 - 2
DE INTERFACES TOTAL
PRESENTACIÓN DE TERMINADO
5 1 - 1
SPRINT TOTAL
TERMINADO
6 REVISIÓN DE SPRINT 1 - 1
TOTAL
109
o Desarrollo del Sprint 0
Gráfica que detalla curva de desarrollo del sprint, en base a las actividades planteadas.
ESTADÍSTICA DE DESARROLLO DE SPRINT 0

3.5
2.5
1.5
0.5
0
REUNION DE DIAGRAMAS DE DIAGRAMAS DE DISEÑO DE INTERFAZ DE PRESENTACION REVISION DE REUNION DE
PLANIFICACION CASOS DE USO BASE DE DATOS PROTOTIPO DE INICIO DE SESION DE SPRINT SPRINT PLANIFICACION
INTERFACES
110
 SPRINT 1
2
MANTENIMIENTO DE EMPRESA
HU1: Registro de empresas VALIDACIÓN DE CAMPOS REQUERIDOS 2

PRUEBA DE MANTENIMIENTO DE
1 2 15
EMPRESA
2
ASIGNACIÓN DE USUARIO A EMPRESA
PRUEBA DE ASIGNACIÓN DE USUARIO
1
A EMPRESA
111
Reunión de planificación del sprint 1, participa todo el equipo Scrum y
se lleva a cabo con el fin de definir las actividades a realizar y las
estrategias que se llevaron a cabo para la realización de las mismas.
 Acta de reunión
 ACTA DE REUNIÓN
Acta No: 2
PARTICIPANTES
No
.
6
7
1 Segmentar modulo a desarrollar.
2 Desarrollo de parte gráfica.
3 Desarrollo de capa de base de datos.
4 Desarrollo de lógica de sistema.
5 Pruebas de modulo desarrollado.
6 Seguimiento de patrón de arquitectura a utilizar.
7 Control de plazos estimados.
8 Presentación de modulo desarrollado.
112
1. El scrum master indicado y segmento cada una de las actividades que se

realizarían para el desarrollo del sprint 1. En este sprint ya se encuentra involucrado
lo referente al desarrollo del sistema y la codificación del mismo. Debido a ello se le
explico detalladamente al producto owner como se llevaría a cabo esto y las
presentaciones que aquí se involucrarían.
2. El equipo de desarrollo indico en que sería mejor que cada uno se haga cargo,
debido a las habilidades con las que cada uno cuento.
*Jhonatan Carhuamanca: Desarrollo de interfaz gráfica de cada uno de los módulos
involucrados.
*Samuel Montalvan: Encargado de llevar a cabo la lógica de la base de datos y la
del sistema.
*Marelyn Carranza: Encargada de las pruebas de cada módulo realizado, verificara
la validación de cada uno de los campos y el registro correcto.
3. El producto owner solo recalco que se cumplan los plazos indicados para el
desarrollo del módulo mencionado juntamente con cada una de sus funciones.
Observaciones.
CONCLUSIONES
Período de
cumplimiento
1 Crear interfaz de
Jhonatan
mantenimiento de 2 días
Carhuamanca
empresa.
2 Crear capa de base de
datos para el
mantenimiento de
empresas.
3 Pruebas de
mantenimiento de Marelyn Carranza 1 día
empresa.
4 Crea interfaz de
Jhonatan
asignación de usuario a 2 días
Carhuamanca
empresa.
113
datos para la
asignación de usuario a
empresa.
6 Pruebas de asignación
Marelyn Carranza 1 día
de usuario a empresa.
7 Exposición de módulos
terminados.
o Creación de interfaz de mantenimiento de empresa
114
o Validación de campos requeridos
115
o Mantenimiento de empresa
116
117
 Vista
118
119
 Modelo
120
121
122
123
 Controlador
124
125
o Creación de interfaz de asignación de usuarios
126
o Asignación de usuario a empresa
127
 Modelo
128
129
130
 Controlador
o Revisión de Sprint 1
ACTIVIDADES A DURACIÓN
N° DURACIÓN ESTADO OBSERVACIÓN
REALIZAR FINAL
REUNIÓN DE TERMINADO
1 2 - 2
CREACIÓN DE
INTERFAZ DE TERMINADO
2 2 - 2
MANTENIMIENTO TOTAL
DE EMPRESA
VALIDACIÓN DE
TERMINADO
3 CAMPOS 2 - 2
TOTAL
REQUERIDOS
MANTENIMIENTO TERMINADO
4 2 - 2
DE EMPRESA TOTAL
PRUEBA DE
TERMINADO
5 MANTENIMIENTO 2 - 2
TOTAL
DE EMPRESA
CREACIÓN DE
INTERFAZ DE
TERMINADO
6 ASIGNACIÓN DE 2 - 2
TOTAL
USUARIO A
EMPRESA
ASIGNACIÓN DE
TERMINADO
7 USUARIO A 1 - 1
TOTAL
EMPRESA
PRUEBA DE
ASIGNACIÓN DE TERMINADO
8 1 - 1
USUARIO A TOTAL
EMPRESA
REVISIÓN DE TERMINADO
9 1 - 1
SPRINT TOTAL
131
ESTADISTICA DE DESARROLLO DE SPRINT 1

2.5
1.5
0.5
0
REUNION DE CREACION DE VALIDACION DE MANTENIMIENTO PRUEBA DE CREACION DE ASIGNACION DE PRUEBA DE REVISION DE
PLANIFICACION INTERFAZ DE CAMPOS DE EMPRESA MANTENIMIENTO INTERFAZ DE USUARIO A ASIGNACION DE SPRINT
MANTENIMIENTO REQUERIDOS DE EMPRESA ASIGNACION DE EMPRESA USUARIO A
DE EMPRESA USUARIO A EMPRESA
EMPRESA
132
 Sprint 2
REUNIÓN DE PLANIFICACIÓN 1
DIAGRAMAS DE CASOS DE USO 2
DIAGRAMAS DE BASE DE DATOS 3
0 - DISEÑO DE PROTOTIPO DE INTERFACES 2 12
INTERFAZ DE INICIO DE SESIÓN 2
PRESENTACIÓN DE SPRINT 1
CREACIÓN DE INTERFAZ DE MANTENIMIENTO
2
DE EMPRESA
HU1: Registro de empresas VALIDACIÓN DE CAMPOS REQUERIDOS 2
1 PRUEBA DE MANTENIMIENTO DE EMPRESA 2 15
CREACIÓN DE INTERFAZ DE ASIGNACIÓN DE
2
USUARIO A EMPRESA
PRUEBA DE ASIGNACIÓN DE USUARIO A
1
EMPRESA
CREACIÓN DE INTERFAZ DE LISTA DE PEDIDO
1
2 VENTA 23
HU3: Listar pedido venta
LISTA PEDIDO VENTA 1
PRUEBA DE LISTA PEDIDO VENTA 1
133
Reunión de planificación del sprint 2, participa todo el equipo Scrum y
se lleva a cabo con el fin de definir las actividades a realizar y las
estrategias que se llevaron a cabo para la realización de las mismas.
ACTA DE REUNIÓN
Acta No: 3
PARTICIPANTES
No
.
6
7
1 Análisis de base de datos de sistema de pedidos de la empresa CUETO S.A.C..
Asignación de responsable de crear consultas y procedimientos almacenados
2
en la base de datos.
3 Desarrollo de interfaces graficas requeridas.
4 Desarrollo de lógica de sistema.
5 Pruebas de modulo desarrollado.
8 Presentación de modulo desarrollado.
134
1. El scrum master indicó que lo primero que se haría sería el análisis de la base de
datos que se consumirá, que es la que utiliza la empresa para el registro de
pedidos mediante su aplicación móvil. Esta parte es muy importante porque nos
permitirá llegar a la venta y factura final que será enviada mediante el sistema web
a SUNAT.
2. El equipo de desarrollo indico en que seria mejor que cada uno se haga cargo,
debido a las habilidades con las que cada uno cuento.
*Jhonatan Carhuamanca: Desarrollo de interfaz grafica de cada uno de los modulos
involucrados.
*Samuel Montalvan: Encargado de llevar a cabo la lógica de la base de datos y la
del sistema.
*Marelyn Carranza: Encargada de las pruebas de cada modulo realizado, verificara
la validación de cada uno de los campos y el registro correcto.
3. El producto owner indico que el brindaría las facilidades para tener acceso al
sistema móvil de pedidos, de tal manera que se obtenga la información necesaria.
Observaciones.
CONCLUSIONES
Período de
cumplimiento
1 Crear interfaz de Jhonatan
1 día
búsqueda de pedidos. Carhuamanca
datos para la búsqueda Samuel Montalvan 1 día
de pedidos.
3 Pruebas de búsqueda
de pedidos.
4 Crea interfaz de
Jhonatan
validación de pedido 1 día
Carhuamanca
venta.
datos para la validación Samuel Montalvan 2 días
de pedido venta.
6 Pruebas de validación
de pedido venta.
135
1 día
liquidación de cuenta. Carhuamanca
datos para la Samuel Montalvan 3 días
liquidación de cuenta.
9 Pruebas de liquidación
de cuenta.
1 día
búsqueda de ventas. Carhuamanca
datos para la búsqueda Samuel Montalvan 1 día
de ventas.
12 Pruebas de búsqueda
de ventas.
13 Crear interfaz de
Jhonatan
registro de gastos de 1 día
Carhuamanca
facturación.
datos para el registro
de gastos de
facturación.
15 Pruebas de registro de
gastos de facturación.
16 Exposición de módulos
terminados.
o CREACIÓN DE INTERFAZ DE LISTA DE PEDIDO VENTA
136
137
o LISTA PEDIDO VENTA
138
o PRUEBA DE LISTA PEDIDO VENTA
139
 Modelo
 Controlador
140
o CREACIÓN DE INTERFAZ DE VALIDACIÓN PEDIDO VENTA
141
o VALIDACIÓN PEDIDO VENTA
o PRUEBA VALIDACIÓN PEDIDO VENTA
142
143
144
145
 Modelo
146
147
148
 Controlador
149
150
o CREACIÓN DE INTERFAZ DE LIQUIDACIÓN DE CUENTA
151
152
o LIQUIDACIÓN DE CUENTA
153
o PRUEBA DE LIQUIDACIÓN DE CUENTA
154
155
 Modelo
156
 Controlador
o Creación de interfaz de Lista de Venta
157
158
o Lista de Venta
159
 Modelo
 Controlador
160
o Creación de interfaz de gastos de facturación
161
o Registro de gastos de facturación
162
163
 Modelo
164
 Controlador
ACTIVIDADES DURACIÓN
N° DURACIÓN ESTADO OBSERVACIÓN
A REALIZAR FINAL
REUNIÓN DE TERMINADO
1 1 - 1
CREACIÓN DE
2 1 - 1
LISTA DE TOTAL
PEDIDO VENTA
LISTA PEDIDO TERMINADO
3 1 - 1
VENTA TOTAL
165
PRUEBA DE
TERMINADO
4 LISTA PEDIDO 1 - 1
TOTAL
VENTA
CREACIÓN DE
5 1 - 1
VALIDACIÓN TOTAL
PEDIDO VENTA
VALIDACIÓN TERMINADO
6 2 - 2
PEDIDO VENTA TOTAL
PRUEBA
TERMINADO
7 VALIDACIÓN 1 - 1
TOTAL
PEDIDO VENTA
CREACIÓN DE
8 1 - 1
LIQUIDACIÓN TOTAL
DE CUENTA
LIQUIDACIÓN TERMINADO
9 3 - 3
DE CUENTA TOTAL
PRUEBA DE
TERMINADO
10 LIQUIDACIÓN 1 - 1
TOTAL
DE CUENTA
CREACIÓN DE
11 1 - 1
LISTA DE TOTAL
VENTA
LISTA DE TERMINADO
12 1 - 1
VENTA TOTAL
PRUEBA DE
TERMINADO
13 LISTA DE 1 - 1
TOTAL
VENTA
CREACIÓN DE
INTERFAZ DE
TERMINADO
14 REGISTRO DE 1 - 1
TOTAL
GASTOS DE
FACTURACIÓN
REGISTRAR
TERMINADO
15 GASTOS DE 1 - 1
TOTAL
FACTURACIÓN
PRUEBA DE
REGISTRO DE TERMINADO
16 1 - 1
GASTOS DE TOTAL
FACTURACIÓN
REVISIÓN DE TERMINADO
17 1 - 1
SPRINT TOTAL
166

3.5
2.5
1.5
0.5
167
 Sprint 3
CREACIÓN DE INTERFAZ DE EMISIÓN DE FACTURAS 1
CREAR CONEXIÓN A WEB SERVICE 3
GENERAR XML 2
HU7: Emitir facturas a SUNAT FIRMAR XML 2
CREAR MÉTODO DE ENVIÓ Y RECEPCIÓN DE XML 1
EMITIR FACTURA 1
PRUEBA DE EMISIÓN DE FACTURA 1
CREACIÓN DE INTERFAZ DE FACTURAS EMITIDAS 1
HU8: Listar facturas emitidas LISTAR FACTURAS EMITIDAS 1
PRUEBA DE LISTA DE FACTURAS EMITIDAS 1
3 CREACIÓN DE INTERFAZ DE ANULACIÓN DE 28
1
FACTURAS
CREAR MÉTODO DE ENVIÓ DE COMUNICACIÓN DE
HU9: Anular facturas emitidas 2
BAJA
ANULAR FACTURAS EMITIDAS 2
PRUEBA DE FACTURAS EMITIDAS 1
CREACIÓN DE INTERFAZ DE LISTA DE FACTURAS
1
ANULADAS
HU10: Listar facturas anuladas LISTAR FACTURAS ANULADAS 1
REPORTE DE INCIDENCIAS EN EMISIÓN 3
PRUEBA DE LISTA DE FACTURAS ANULADAS 1
168
o Reunión de Planificación
Reunión de planificación del sprint 3, participa todo el equipo Scrum y se lleva
a cabo con el fin de definir las actividades a realizar y las estrategias que se
llevaron a cabo para la realización de las mismas.
ACTA DE REUNIÓN
Acta No: 4
PARTICIPANTES
No
.
6
7
1 Desarrollo de módulo de series de Facturas
2 Conexión a WebService de SUNAT.
3 Desarrollo de módulo de envió de facturas.
4 Desarrollo de módulo de anulación de facturas.
5 Pruebas de módulos desarrollado.
8 Presentación de modulos desarrollado.
169
1. El scrum master indico que en este sprint es donde más compromiso se necesita
con la finalidad de poder terminar el proyecto en el menor tiempo posible. Además,
se hacer mucho mas participe al dueño del producto en esta parte del desarrollo ya
que como se abarcaría el tema netamente del envío de facturas le debemos tener
al tanto de los resultados que se esta obteniendo.
2. El equipo de Desarrollo, menciono lo siguiente:

 Jhonatan Carhuamanca: Como encargado de las interfaces solicito una
reunión personal con el dueño del producto, debido a que estas interfaces
serán las mas usadas para llevar a cabo la optimización del proceso de la
empresa y para el usuario el diseño debe ser intuitivo y fácil de entender.
 Marelyn Carranza: Seré parte del desarrollo de la conexión al WebService de
SUNAT y a la creación de los métodos de envío y recepción.
 Samuel Montalvan: Ya he estado realizando unas pruebas conectándome al
WebService de SUNAT, por ello hay que enfocarnos en la estructura del XML
como crearlo y guárdalo en el sistema. Teniendo ello en el menor tiempo
posible nos facilitara el desarrollo y la implementación de los métodos de envío
y recepción.
3. El product owner indico que cualquier duda o consulta de puedan comunicar con
él a su número de celular 983432341. Exigió un compromiso un poco mayor, ya
que el tema tributario puede generarle problemas y gastos excesivos de llevarse a
cabo mal. Por ello, dijo que en cada avance sea comunicado a él o se le envié un
Excel con el avance que se esta teniendo.
Observaciones.
CONCLUSIONES
Período de
cumplimiento
1 día
mantenimiento de series. Carhuamanca
2 Crear capa de base de datos
Samuel
para el mantenimiento de 1 día
Montalvan
series.
3 Prueba de mantenimiento de Marelyn
1 día
series. Carranza
4 Crea interfaz de emisión de Jhonatan
1 día
facturas. Carhuamanca
170
5 Crear capa de base de datos Samuel
1 días
para la emisión de facturas. Montalvan
6 Creación de conexión a Samuel
3 días
Webservice de SUNAT. Montalvan
7 Creación de método de Samuel
2 días
creación de XML. Montalvan
8 Creación de método de firma Samuel
3 días
de XML. Montalvan
9 Creación de método de
Samuel
envío y recepción de emisión 5 días
Montalvan
de facturas.
10 Creación de método de
Samuel
envío y recepción de 5 días
Montalvan
anulación de facturas.
11 Prueba de emisión de Marelyn
3 días
facturas. Carranza
12 Prueba de anulación de Marelyn
3 días
facturas. Carranza
13 Listado de facturas emitidas. Samuel
1 día
Montalvan
14 Listado de facturas Samuel
1 día
anuladas. Montalvan
15 Creación de reporte de Samuel
1 día
facturas emitidas. Montalvan
16 Creación de reporte de Samuel
1 día
facturas anuladas. Montalvan
17 Exposición de módulos Samuel
1 día
terminados. Montalvan
171
o Interfaz de emisión de Facturas
172
o Conexión a WebService SUNAT
o Generar Xml
173
o Firmar Xml
174
o Métodos de envío y Recepción de Xml
o Emisión de Factura
175
176
 Modelo
177
 Controlador
178
o Interfaz de Facturas emitidas
179
o Lista de Facturas Emitidas
180
 Modelo
181
 Controlador
o Interfaz de anulación de Facturas
182
183
o Método de envío de Comunicación de Baja
o Anulación de Facturas
184
185
 Modelo
186
 Controlador
o Interfaz de facturas anuladas
187
o Lista de facturas anuladas
188
189
190
 Modelo
 Controlador
191
DURACIÓN
N° ACTIVIDADES A REALIZAR DURACIÓN ESTADO OBSERVACIÓN
FINAL
TERMINADO
1 REUNIÓN DE PLANIFICACIÓN 1 - 1
TOTAL
CREACIÓN DE INTERFAZ DE TERMINADO
2 1 - 1
EMISIÓN DE FACTURAS TOTAL
CREAR CONEXIÓN A WEB TERMINADO
3 3 - 3
SERVICE TOTAL
TERMINADO
4 GENERAR XML 2 - 2
TOTAL
TERMINADO
5 FIRMAR XML 2 - 2
TOTAL
CREAR MÉTODO DE ENVIÓ Y TERMINADO
6 1 - 1
RECEPCIÓN DE XML TOTAL
TERMINADO
7 EMITIR FACTURA 1 - 1
TOTAL
PRUEBA DE EMISIÓN DE TERMINADO
8 1 - 1
FACTURA TOTAL
9 1 - 1
FACTURAS EMITIDAS TOTAL
TERMINADO
10 LISTAR FACTURAS EMITIDAS 1 - 1
TOTAL
PRUEBA DE LISTA DE TERMINADO
11 1 - 1
FACTURAS EMITIDAS TOTAL
12 1 - 1
ANULACIÓN DE FACTURAS TOTAL
192
CREAR MÉTODO DE ENVIÓ TERMINADO
13 2 - 2
DE COMUNICACIÓN DE BAJA TOTAL
ANULAR FACTURAS TERMINADO
14 2 - 2
EMITIDAS TOTAL
PRUEBA DE FACTURAS TERMINADO
15 1 - 1
EMITIDAS TOTAL
TERMINADO
16 LISTA DE FACTURAS 1 - 1
TOTAL
ANULADAS
LISTAR FACTURAS TERMINADO
17 1 - 1
ANULADAS TOTAL
PRUEBA DE LISTA DE TERMINADO
18 1 - 1
FACTURAS ANULADAS TOTAL
TERMINADO
19 ENVIÓ DE FACTURAS A 1 - 1
TOTAL
CLIENTES
CREAR MÉTODO DE ENVIÓ A TERMINADO
20 1 - 1
CORREO DE CLIENTES TOTAL
ENVIAR FACTURAS A TERMINADO
21 2 - 2
CLIENTES TOTAL
PRUEBA DE ENVIÓ DE TERMINADO
22 1 - 1
FACTURAS A CLIENTES TOTAL
TERMINADO
23 REVISIÓN DE SPRINT 1 - 1
TOTAL
193
o Desarrollo de Sprint 3

6
194

Montalvan MSA-SDinterbacional

Cargado por

Copyright:

Formatos disponibles

Montalvan MSA-SDinterbacional

Cargado por

Información del documento

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

Montalvan MSA-SDinterbacional

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA

ESCUELA ACADÉMICO PROFESIONAL DE INGENIERÍA DE

Sistema web para la facturación electrónica centralizada en la empresa

TESIS PARA OBTENER EL TÍTULO PROFESIONAL DE

El siguiente trabajo está dedicado a mi

Dando cumplimiento a las normas establecidas en el Reglamento de Grados y

La investigación, tiene como propósito fundamental: determinar cómo influye un

La presente investigación está dividida en siete capítulos:

Tabla 01 Cuadro comparativo de sistemas gestores de base de datos ........... 9

Figura 1 Fórmula Indicador Impacto de Gastos Operacionales...................... 16

La presente tesis detalla el desarrollo de un Sistema Web para la facturación

El tipo de investigación es aplicada, el diseño de la investigación es preexperimental

Palabras clave: sistema web, facturación electrónica centralizada, SCRUM

Keywords: web system, centralized electronic billing, SCRUM

1.1. Realidad Problemática

En el Perú, la SUNAT ha tomado a las TIC como parte de su estrategia para

1.2. Trabajos previos

Negrete Bonilla Jairo Camilo en el año 2016, Desarrollo de un sistema web

Bendezu Figueroa Freddy en el año 2017, Implementación de sistema de

Amaro Quispe Kennidy en el año 2017, Sistema de emisión de comprobantes

Alcántara Rodríguez Jorge en el año 2017, Sistema Easy Bill en la Gestión

Ordaya Lock Rita en el año 2015, Implementación de un sistema de

1.3. Teorías relacionadas al tema

• Berzal, Cortijo, Cubero (2014) comenta lo siguiente:

• Molina (2014) define lo siguiente, el sistema web es un sistema

1.3.2. Lenguaje de Programación

1.3.5. Servidor IIS

1.3.6. Base de Datos

Fuente: Instituto Tecnológico Superior de Lerdo (2014)

Fuente elaboración Propia (Ver Anexo 8)

En base a la evaluación de expertos de la metodología de desarrollo

1.3.8. Facturación Electrónica Centralizada

• Independientemente de la factura permite seleccionar diferentes tipos y

• Es un procedimiento más eficiente que se lleva a cabo siguiendo una serie

Figura 1 Fórmula Indicador Impacto de Gastos Operacionales

Fuente: Martínez, Humberto (2015)

Adicional a ello, Chang, et al. (2016) añade lo siguiente, el desarrollo

Teniendo en cuenta ello, existe un gasto en la recaudación de los

Barreix, Zambrano (2018) indican que, la implementación de un

 Indicador para la dimensión Emisión de Factura

Fuente: Cuylen, Kosch y Breitner (2016)

La implementación de un sistema de facturación electrónica brinda un

A su vez Raths (2014), mencionó que si se adapta un sistema

Barreix, Zambrano (2018) añaden que, el sistema de Facturación

1.4. Formulación del problema

1.5. Justificación del estudio

1.5.2. Justificación Económica

1.5.3. Justificación Institucional

2.1. Diseño de investigación

2.1.2. Diseño de Estudio

En el diseño Preexperimental con preprueba y posprueba se cuenta con

El diseño de la investigación realizada es Preexperimental con preprueba

Figura 3 Fórmula Diseño Pre Experimental

Fuente: Introducción a la metodología de la investigación científica, 2016

2.1.3. Método de Investigación

2.2. Variables y operacionalización

• Variable Dependiente: Facturación Electrónica Centralizada

Tabla 03 Matriz Operacional de la variable

Fuente: Elaboración propia