Sistema de punto de venta con soporte al procesamiento de

pagos en criptomonedas y su integración en los procesos

administrativos de la empresa Pinttosoft C.A.

TRABAJO INSTRUMENTAL DE GRADO

presentado ante la
UNIVERSIDAD CATÓLICA ANDRÉS BELLO
como parte de los requisitos para optar al título de
INGENIERO EN INFORMÁTICA

REALIZADO POR LUIS EDUARDO LARA DIAZ

TUTOR EMPRESARIAL DANIELYS ALDANA

TUTOR ACADÉMICO FRANKLIN BELLO
FECHA ABRIL, 2020
 i

DEDICATORIA

A Dios por darme la oportunidad de llegar hasta este momento y haberme dado salud
para lograr todos mis objetivos a lo largo de mi carrera.

A mis padres por ser el pilar fundamental en todo lo que soy, en toda mi educación,
tanto académica, como de la vida, por su incondicional apoyo perfectamente mantenido
a través del tiempo.

Todo este trabajo ha sido posible gracias a ellos.

A mis abuelas Amelia y Solima por siempre estar pendiente de mi carrera universitaria,
por quererme y apoyarme siempre.

A Todos aquellos que participaron de manera directa e indirecta en la elaboración de

esta tesis, familiares, amigos, profesores y compañeros.
 ii

AGRADECIMIENTO

Agradezco primeramente a Dios por ser mi guía, brindándome paciencia y sabiduría

para culminar con éxito mi meta propuesta.

A mis padres, quienes son mi mayor fuente de inspiración, que a través de su amor,
paciencia y buenos valores ayudan a trazar mi camino.

A mi hermana, mi primera amistad gracias por estar ahí a lo largo de mi vida.

A la luna de mi vida, le agradezco por todo su apoyo, eres mi motivación e inspiración.

A mi familia, le quiero agradecer todo el apoyo que me brindaron durante toda mi vida.

A mis amigos y compañeros, les agradezco el haberme apoyado en este camino.

A mis profesores, tutores y demás personas, quienes me asesoraron en esta tesis les
agradezco de todo corazón todo su esfuerzo.

A mi tutor de tesis el profesor Franklin Bello, por sus enseñanzas, paciencia y

orientación a lo largo de la carrera y la realización de esta tesis.

A todos muchas gracias.

 iii

ÍNDICE DE CONTENIDO

pp.
DEDICATORIA ........................................................................................................................ i
AGRADECIMIENTO .............................................................................................................. ii
ÍNDICE DE CONTENIDO ..................................................................................................... iii
ÍNDICE DE FIGURAS............................................................................................................ vi
ÍNDICE DE TABLAS ........................................................................................................... viii
RESUMEN .............................................................................................................................. ix
INTRODUCCIÓN .................................................................................................................... 1
CAPÍTULO I ............................................................................................................................ 4
El Problema............................................................................................................................... 4
Planteamiento del Problema ...................................................................................... 4
Solución Propuesta .................................................................................................. 7
Objetivos ................................................................................................................ 8
Objetivo general. .................................................................................................. 8
Objetivos específicos. ........................................................................................... 8
Aportes .................................................................................................................. 9
Aporte funcional. ................................................................................................. 9
Aporte tecnológico. .............................................................................................. 9
Justificación ............................................................................................................ 9
Alcance ................................................................................................................ 11
Limitaciones ......................................................................................................... 11
CAPÍTULO II ......................................................................................................................... 12
Marco Teórico......................................................................................................................... 12
Antecedentes de la Investigación ............................................................................. 12
Bases Teóricas ...................................................................................................... 13
Sistemas de información. .................................................................................... 13
Modelo de desarrollo de software. ........................................................................ 14
Modelo en cascada. ............................................................................................ 14
Modelo entidad-relación. .................................................................................... 16
Sistema gestor de bases de datos (SGBD). ............................................................. 16
 iv

Arquitectura de software MVC (Modelo Vista Controlador). ................................... 17

Mapeo objeto-relacional (ORM). ......................................................................... 18
Marco de trabajo (Framework). ............................................................................ 18
Criptografía. ...................................................................................................... 19
Cadena de bloques (Blockchain). ......................................................................... 19
Criptomoneda. ................................................................................................... 21
Punto de venta (PDV). ........................................................................................ 21
Bases Legales .......................................................................................................................... 22
Decreto Nº 3.719 publicado en la Gaceta Oficial Nº 6420 de la República Bolivariana de
Venezuela. ........................................................................................................ 22
Campos de factura legal en la República Bolivariana de Venezuela. ......................... 24
CAPÍTULO III ........................................................................................................................ 26
Marco Metodológico ............................................................................................................... 26
Tipo de Investigación ............................................................................................. 26
Técnicas e Instrumentos de Recolección de Datos...................................................... 26
Observación libre o no estructurada. ..................................................................... 26
Revisión documental. ......................................................................................... 27
Metodología de Desarrollo...................................................................................... 28
Procedimiento Metodológico .................................................................................. 28
CAPÍTULO IV........................................................................................................................ 31
Resultados ............................................................................................................................... 31
Análisis de los Procesos Administrativos que Lleva a Cabo un Sistema de Punto de Venta
............................................................................................................................ 31
Definición de los Requerimientos del Sistema ........................................................... 35
Requerimientos funcionales ................................................................................. 36
Requerimientos no funcionales ............................................................................ 38
Requerimientos de almacenamiento...................................................................... 38
Diseño del Sistema de Punto de Venta en Base a los Requerimientos Definidos ............ 40
Diseño de la base de datos. .................................................................................. 40
Diseño de la aplicación. ...................................................................................... 44
Diseño de pruebas. ............................................................................................. 82
Diseño arquitectónico. ........................................................................................ 85
 v

Construcción del Sistema Punto de Venta de Acuerdo al Diseño Planteado ................... 88

Herramientas de desarrollo. ................................................................................. 88
Estructura de carpetas del sistema. ....................................................................... 89
Construcción de los componentes del sistema. ....................................................... 90
Pruebas del sistema. ........................................................................................... 93
Documentación del Sistema de Punto de Venta Desarrollado ...................................... 93
CAPÍTULO V ......................................................................................................................... 94
Conclusiones y Recomendaciones .......................................................................................... 94
Conclusiones......................................................................................................... 94
Recomendaciones .................................................................................................. 95
REFERENCIAS BIBLIOGRÁFICAS .................................................................................... 97
APÉNDICES........................................................................................................................... 99
Apéndice A: Gaceta Oficial Numero 6420 de la República Bolivariana de Venezuela -
Decreto Nº 3.719 ................................................................................................. 100
Apéndice B: Formato de Factura del Sistema .......................................................... 101
Apéndice C: Formato de Archivo Excel para Importar Órdenes de Compra ................ 102
Apéndice D: Interfaces Graficas del Sistema Punto de Venta .................................... 103
Apéndice E: Ejemplos de Casos de Prueba del Sistema ............................................ 110
Apéndice F: Manual de Usuario del Sistema ........................................................... 119
Apéndice G: Manual Técnico del Sistema............................................................... 126
 vi

ÍNDICE DE FIGURAS
pp.
Figura 1. Diagrama del Sistema Propuesto ..................................................................... 8
Figura 2. Modelo de desarrollo en cascada ................................................................... 15
Figura 3. Modelo Vista Controlador ............................................................................ 17
Figura 4. Estructura e información contenida en un bloque de la cadena de bloques
(blockchain). ............................................................................................................ 20
Figura 5. Diagrama de flujo de la primera parte del proceso de cobro y facturación. .......... 32
Figura 6. Diagrama de flujo de la segunda parte del proceso de cobro y facturación. ......... 33
Figura 7. Modelo entidad-relación del sistema propuesto. .............................................. 41
Figura 8. Modelo relacional del sistema propuesto......................................................... 43
Figura 9. Estructura modular del sistema propuesto. ...................................................... 44
Figura 10. Diagrama de caso de uso para la configuración del sistema. ............................ 45
Figura 11. Caso de uso para la configuración de la empresa. ........................................... 46
Figura 12. Diagrama de actividades para la configuración de la empresa. ......................... 47
Figura 13. Prototipo de interfaz gráfica para la configuración de la empresa ..................... 48
Figura 14. Caso de uso para la configuración de los métodos de pago. ............................. 49
Figura 15. Diagrama de actividades para la configuración de los métodos de pago. ........... 50
Figura 16. Prototipo de interfaz gráfica para la configuración de los métodos de pago. ...... 51
Figura 17. Caso de uso para la configuración de las unidades de medición. ...................... 52
Figura 18. Diagrama de actividades para la configuración de las unidades. ....................... 53
Figura 19. Prototipo de interfaz gráfica para la configuración de las unidades. .................. 54
Figura 20. Caso de uso para la configuración de los impuestos. ....................................... 55
Figura 21. Diagrama de actividades para la configuración de los impuestos. ..................... 56
Figura 22. Prototipo de interfaz gráfica para la configuración de los impuestos. ................ 57
Figura 23. Caso de uso para el catálogo de productos. .................................................... 58
Figura 24. Diagrama de actividades para el catálogo de productos. .................................. 59
Figura 25. Prototipos y flujos de interfaz gráfica para el catálogo de productos. ................ 60
Figura 26. Caso de uso para el catálogo de clientes. ....................................................... 61
Figura 27. Diagrama de actividades para el catálogo de clientes. ..................................... 62
Figura 28. Prototipo de interfaz gráfica para el catálogo de clientes. ................................ 63
Figura 29. Caso de uso para el catálogo de proveedores. ................................................ 64
Figura 30. Diagrama de actividades para el catálogo de proveedores................................ 65
Figura 31. Prototipo de interfaz gráfica para el catálogo de proveedores. .......................... 66
Figura 32. Caso de uso para la gestión de almacenes. ..................................................... 67
Figura 33. Diagrama de actividades para la gestión de almacenes. ................................... 68
Figura 34. Prototipos y flujo de interfaces para la gestión de almacenes. .......................... 69
Figura 35. Caso de uso para la gestión de órdenes de compra. ......................................... 70
Figura 36. Diagrama de actividades para la gestión de órdenes de compra. ....................... 71
Figura 37. Prototipos y flujo de interfaces gráficas para la gestión de órdenes de compra. .. 72
Figura 38. Caso de uso para la gestión de inventario. ..................................................... 73
 vii

Figura 39. Diagrama de actividades para la gestión de inventario. ................................... 74

Figura 40. Prototipos y flujo de interfaces gráficas para la gestión de inventario. ............... 75
Figura 41. Caso de uso para la gestión de ventas. .......................................................... 76
Figura 42. Diagrama de actividades para la gestión de ventas ......................................... 78
Figura 43. Diagrama de actividades para pagos en criptomonedas mediante el sistema
Kapturela. ................................................................................................................ 79
Figura 44. Prototipo de interfaz gráfica para el submódulo clientes dentro de la gestión de
ventas. ..................................................................................................................... 80
Figura 45. Prototipos y flujo de interfaces gráficas para el submódulo inventarios dentro de la
gestión de ventas. ...................................................................................................... 80
Figura 46. Prototipos y flujo de interfaces gráficas para el submódulo productos
seleccionados dentro de la gestión de ventas. ................................................................ 81
Figura 47. Flujo de desarrollo con Spring Framework. ................................................... 85
Figura 48. Estructura de proyecto Spring-Maven. .......................................................... 86
Figura 49. Arquitectura del sistema propuesto. .............................................................. 87
Figura 50. Estructura de carpetas del sistema propuesto. ................................................ 89
Figura 51. Ejemplo de componente repositorio. ............................................................ 91
Figura 52. Ejemplo de componente servicio.................................................................. 92
 viii

ÍNDICE DE TABLAS

Tabla 1. Campos mínimos de la factura legal ............................................................... 25

Tabla 2. Módulos de un sistema de punto de venta ....................................................... 33
Tabla 3. Requerimientos funcionales ........................................................................... 36
Tabla 4. Requerimientos no funcionales ....................................................................... 38
Tabla 5. Requerimientos de almacenamiento ................................................................ 39
Tabla 6. Especificación del caso de uso para la configuración de la empresa..................... 46
Tabla 7. Esoecificación del caso de uso para la configuración de los métodos de pago ....... 49
Tabla 8. Especificación del caso de uso para la configuración de las unidades de medición 52
Tabla 9. Especificación del caso de uso para la configuración de los impuestos ................ 55
Tabla 10. Especificación del caso de uso para el catálogo de productos ............................ 58
Tabla 11. Especificación del caso de uso para el catálogo de clientes .............................. 61
Tabla 12. Especificación del caso de uso para el catálogo de proveedores ........................ 64
Tabla 13. Especificación del caso de uso para la gestión de almacenes ............................. 67
Tabla 14. Especificación del caso de uso para la gestión de órdenes de compra ................. 70
Tabla 15. Especificación del caso de usopara la gestión de inventario ............................. 73
Tabla 16. Especificación del caso de uso para la gestión de ventas ................................. 77
Tabla 17. Plan de ejecución de casos de prueba ............................................................ 82
 ix

SISTEMA DE PUNTO DE VENTA CON SOPORTE AL PROCESAMIENTO DE

PAGOS EN CRIPTOMONEDAS Y SU INTEGRACIÓN EN LOS PROCESOS
ADMINISTRATIVOS DE LA EMPRESA PINTTOSOFT C.A.

Autor: Br. Luis Eduardo Lara Diaz

Tutor Académico: Ing. Franklin Bello
Tutor Empresarial: Ing. Danielys Aldana
Fecha: Abril, 2020

RESUMEN

A continuación, el desarrollo de un sistema de punto de venta con soporte al

procesamiento de pagos en criptomonedas, mediante tecnología blockchain y su
integración en los procesos administrativos de la empresa Pinttosoft C.A, empresa cuya
principal función es el desarrollo de software y destacada por ser fundadora de la
criptomoneda venezolana Onixcoin. Los criptoactivos están cada vez más presentes en
manos de las personas que buscan ganancias, o alternativas financieras a la devaluación
de su moneda de curso legal, en vista de esto, las empresas siendo conscientes de este
mercado, adoptan progresivamente esta tecnología para la realización de transacciones
financieras seguras y eficientes, pero no existe una forma explícita que describa el
registro administrativo y contable de un pago en criptomonedas, en consecuencia, la
empresa Pinttosoft C.A propuso crear un sistema que realice esta inclusión en los
métodos de pago tradicionales y formalice de manera clara y descriptiva estas
transacciones ante el fisco y la empresa. La solución desarrollada permite registrar el
proceso de facturación y cobro, al igual que genera la información para la gestión
administrativa-contable de Pinttosoft, teniendo presente las interfaces necesarias para
exportar e importar esta información a sus sistemas administrativos. Se utilizó el
modelo de desarrollo en cascada, donde se realizó un análisis de la situación actual, la
definición de requerimientos, el diseño de la solución, la construcción y documentación
del sistema. El proyecto fue desarrollado en el lenguaje de programación Java,
haciendo uso del IDE IntelliJ IDEA y el SGBD PostgreSQL.

Palabras clave: Punto de venta, criptomonedas, blockchain, facturación,

información administrativa-contable.
 1

INTRODUCCIÓN

Las criptomonedas son activos digitales intangibles, creados para funcionar

como medio de intercambio, estas tienen como principal característica ser un sistema
que no necesita una autoridad central, es decir que está fuera del control de los
gobiernos e instituciones financieras. En Venezuela y en el mundo, cada vez más
comercios utilizan criptomonedas como métodos de pago adicional a los métodos
tradicionales, también, esta tendencia tecnológica se encuentra en manos de cada vez
más personas, que buscan invertir para generar ganancias, enviar transferencias
internacionales con baja comisión y gran rapidez o utilizar una moneda que sufra
menos devaluación que sus monedas locales, además, la cantidad de aplicaciones que
hacen uso de ellas no es despreciable, y este número crece cada día al igual que el
interés que se le presta.

En el 2018 en Colombia, fueron instalados 25 cajeros en donde se puede retirar

o comprar criptoactivos, al igual que en Colombia, pero en mayor medida, podemos
encontrar a Reino Unido donde las criptomonedas son interpretadas como activos
personales, y estos según su regulación, sufren impuestos, o Japón el cual se posiciona
como el país con las leyes más avanzadas en materia financiera respecto a las
criptomonedas.

La devaluación del bolívar soberano en Venezuela, crea un auge de gente que

busca entrar al mundo de las criptomonedas, buscando un refugio económico, un
medio de pago o un sistema de envío de remesas, por esto y más, los comercios
venezolanos empiezan a optar por este método de pago, pero, Venezuela es uno de los
tantos países que no posee regulaciones explícitas sobre las transacciones en
criptomonedas, en materia tributaria, por lo tanto, actualmente la mayoría de estas
transacciones que se hacen con criptomonedas, involucran intercambios directos entre
la billetera personal del comercio y la billetera personal del usuario, sin pasar por un
sistema que gestione la transferencia y genere información sobre esta, esto implica para
el estado una cantidad de operaciones que escapan de la obligación tributaria, también
 2

es una pérdida estratégica para las empresas, ya que este método, si no se gestiona de
la manera correcta no existe una constancia clara de los ingresos, información que de
poseer, logra cierto dominio en la compra y venta de productos en el restablecimiento
del inventario sin caer en pérdidas por la variabilidad del mercado.

Como solución a esta problemática, la empresa Pinttosoft C.A., dedicada al

desarrollo de software y localizada en la República Bolivariana de Venezuela en el
estado Bolívar, Ciudad Guayana, plantea este proyecto, el cual consiste en el desarrollo
de un sistema de punto de venta con soporte al procesamiento de pagos en
criptomonedas y su integración en los procesos administrativos de la empresa, que sea
capaz de llevar un registro administrativo-contable de estos pagos en criptodivisas sin
alejar al usuario de su proceso de facturación y venta al que está acostumbrado, sistema
orientado a las transacciones financieras dentro del territorio nacional.

El desarrollo del proyecto, es guiado por el modelo de desarrollo denominado

en cascada, el cual propone un desarrollo lineal y secuencial, iniciando desde el análisis
de la situación actual donde se presenta la necesidad, de este análisis, se definen los
requerimientos de la solución, se diseña el sistema en base a los requerimientos, se
construye el sistema propuesto, el cual es verificado y validado con el fin de comprobar
el cumplimiento de las necesidades y requerimientos del usuario, y además es
documentado, en virtud de los entregables resultados de cada una de sus fases.

El presente informe está estructurado en cinco capítulos. En el capítulo I se

plantea el problema, en el que se describe la necesidad de la empresa, se establecen los
objetivos del desarrollo, los cuales son puntos para la medición en el avance del
proyecto, se define el alcance, las limitaciones y la justificación del proyecto. En el
capítulo II se presenta el marco teórico de la investigación, el cual contiene los
antecedentes de la investigación además de las bases teóricas y legales sobre el tema
de estudio. En el capítulo III, se detalla el tipo de investigación, las técnicas para la
recolección de datos utilizadas en la investigación y se describe la metodología
utilizada. En el capítulo IV, se expone el desarrollo de la investigación, así como el
 3

análisis previo para la obtención de los resultados. En el capítulo V, se listan las

conclusiones y recomendaciones, de los resultados alcanzados, Finalmente se muestran
las referencias bibliográficas utilizadas para la realización de este trabajo además de
los aprendices referenciados en el trabajo.
 4

CAPÍTULO I

El Problema

Planteamiento del Problema

Las criptomonedas desde su creación han evolucionado en número y volumen

de USD en sus mercados, incrementándose cada día (la plataforma de intercambio
BITMEX maneja más de 8.000 millones de dólares en 24 horas). Poseen características
de seguridad y privacidad que las hacen atractivas para todo el mundo. Una de las
particularidades de las criptomonedas es que son descentralizadas, es decir, no existe
un ente rector para su funcionamiento e intercambio. Sin embargo, los gobiernos a nivel
mundial regulan las transacciones comerciales en sus países, aplicando los impuestos
necesarios para el funcionamiento del estado.

Las transacciones hechas en dinero fiat, no involucran ningún problema, debido

a que esta es la moneda que un gobierno ha declarado legal, está bajo sus regulaciones,
además es el sistema monetario que se utiliza para llevar a cabo intercambios
comerciales, cada intercambio genera una factura y un impuesto que a su vez es
cancelado al estado en la misma moneda. Ahora bien, si se plantea realizar
transacciones en criptomonedas, las cuales son definidas como activos digitales
intangibles y los entes del estado aún no han adecuado su plataforma tecnológica para
recibir estos como forma de pago, surgen las siguientes interrogantes con respecto al
intercambio comercial.

¿Cómo pagar los impuestos generados en una transacción o facturación con

criptomonedas?, ¿Cómo se refleja su ingreso a la caja de la empresa o comercio?, ¿Cuál
es el valor de estos activos al momento de facturar y al hacer el cierre diario o mensual
para el pago de impuestos?, ¿Cómo y dónde se reflejan contablemente las pérdidas o
superávit que la fluctuación en el valor de mercado de estos activos generen?, ¿Como
reflejo el nivel de inventario de mis productos cuando los vendo en criptomonedas?,
 5

entre otros interrogantes que hoy en día se plantean las organizaciones que desean
implementar este tipo de monedas digitales para el cobro de sus productos o servicios.

Actualmente se transita por un entorno empresarial impactado por una

constante innovación tecnológica. El dinero y los medios de pagos no escapan de esta
evolución. El pago electrónico directo y entre iguales representado por criptomonedas
(monedas digitales) ha revolucionado modelos de negocios y esquemas gerenciales. En
Venezuela hoy en día, las empresas y comercios han ido adoptando este método de
pago en criptomonedas por medio de transacciones interpersonales P2P (peer-to-peer).

En este contexto, la empresa Pinttosoft C.A., empresa visionaria y con un

enfoque tecnológico integral en torno al desarrollo de software, aplicaciones y
productos vanguardistas, que en busca de un aporte tecnológico para el país con
tecnología blockchain creó la criptomoneda Onixcoin en el año 2017, para darle
variedad de uso dentro y fuera del país, por lo que ahora está desarrollando una
plataforma integral denominada Business Center, la cual contará con siete (07)
módulos o unidades de negocio que van desde la compra-venta de la criptomoneda con
bolívares soberanos (BsS) o con otras criptomonedas, acceso a créditos personales o
comerciales, adquisición online de productos de consumo masivo, servicios de
formación académica, actividades de entretenimiento, entre otros. Sin embargo, la
empresa presenta como problemática, la ausencia de registros contables generados por
las transacciones realizadas en criptomonedas, siendo su criptomoneda Onixcoin el
principal producto ofertado en sus plataformas y un activo del cual se requiere un
manejo contable expedito y más especializado, que brinde una mejor capacidad de
decisión a la empresa.

Actualmente, no existe una referencia expresa y precisa para determinar el

reconocimiento de las criptomonedas a nivel empresarial, en virtud de que existe un
vacío jurídico-administrativo sobre la categoría apropiada para clasificar este tipo de
activo. Hoy en día, el reconocimiento, medición y revelación de las criptomonedas no
se plantea explícitamente en las normativas nacionales ni internacionales, sin embargo,
 6

en la normativa nacional venezolana, el día 28 de diciembre del año 2018 fue publicado
en la gaceta oficial, el decreto número tres mil setecientos diecinueve (3.719), el cual
puede considerarse como premisa en la problemática y la solución, ya que este hace
mención a las operaciones en el territorio nacional en moneda extranjera o criptodivisas
autorizadas por la ley.

Sobre la base de las consideraciones anteriores, la ausencia de información

explicita de los procesos necesarios para la emisión de la moneda digital o
criptomonedas como crédito de pago de parte de los organismos delegados trae como
consecuencia que las empresas opten por no realizar un registro contable con la
información referente a las transacciones en criptomonedas, esto ocasiona a la vez
pérdida de información administrativa-contable y fiscal, así como desconocimiento de
las capacidades financieras. De seguir la situación, la falta de información traerá gran
dificultad en la elaboración de estrategias y planes financieros para la posterior toma
de decisiones gerenciales, al igual que puede llevar a incurrir en el no cumplimiento de
exigencias legales que pudieran acarrear sanciones.

Para lograr reflejar adecuadamente las transacciones que se generen por el uso
de las criptomonedas, se debe plantear una solución integral en la gestión
administrativa de todos los procesos contables de cada unidad de negocio, alineada a
las normas internacionales de contabilidad (NIC) y específicamente a la normativa
venezolana vigente.

En virtud de lo anteriormente expuesto, la alta gerencia de Pinttosoft C.A., se

propuso crear un sistema que registre el proceso de facturación y cobro, tanto de
manera tradicional como en criptomonedas, además de generar información para la
gestión administrativa-contable de la organización, brindando a futuro una solución
para aquellos comercios que adopten este método de cobro en sus transacciones
cotidianas.
 7

Solución Propuesta

El desarrollo de un sistema de punto de venta (PDV) como aplicación de

escritorio bajo la arquitectura de software modelo-vista-controlador (MVC), así como
el paradigma de programación orientado a objetos (POO) en conjunto con el lenguaje
de programación Java, haciendo uso del framework Spring Boot integrado con la
familia de productos JavaFX para el desarrollo de aplicaciones de escritorio
multiplataforma.

El sistema busca integrar, el proceso de facturación y cobro de un producto,

tanto en moneda fiat (dinero de curso legal), como en criptomonedas, a través del
consumo de microservicios con tecnología blockchain, generando información que
permita realizar los respectivos asientos contables de forma adecuada, es decir, si el
cobro se realiza en moneda fiat, el sistema genera la información como
tradicionalmente lo hace una caja, integrado al sistema de contabilidad de la empresa
o comercio; sin embargo, cuando se generen transacciones en criptomonedas, el
sistema genera información adicional sobre otras variables involucradas en la
operación, como por ejemplo, los valores de mercado de la criptomoneda respecto al
bolívar soberano, bitcoin y dólar estadounidense.

Se plantea utilizar como manejador de base de datos, el sistema de gestión de

bases de datos relacionales PostgresSQL.

En la Figura 1, se presenta el diagrama del sistema propuesto, en donde se

identifican las interacciones y flujos de datos del sistema punto de venta con el sistema
administrativo de la empresa y el sistema que cumple la función de pasarela de pago
para las transacciones en criptomonedas.
 8

Figura 1. Diagrama del Sistema Propuesto

Objetivos

Objetivo general.

Desarrollar un sistema de punto de venta con soporte al procesamiento de pagos

en criptomonedas y su integración en los procesos administrativos de la empresa
Pinttosoft C.A.

Objetivos específicos.

1. Analizar los procesos administrativos que lleva a cabo un sistema de punto

de venta.

2. Definir los requerimientos del sistema de punto de venta con soporte al

procesamiento de pagos en criptomonedas y su integración en los procesos
administrativos de la empresa Pinttosoft C.A.

3. Diseñar el sistema de punto de venta en base a los requerimientos definidos.

4. Construir el sistema de punto de venta de acuerdo al diseño planteado.

5. Documentar el sistema de punto de venta desarrollado.

 9

Aportes

Aporte funcional.

● Innovar con un sistema de punto de venta que permita la inclusión de

criptomonedas como medio de cobro, eliminando cálculos manuales y
transacciones interpersonales comúnmente llevadas a cabo por los operadores
del sistema cuando se involucra un pago en criptomonedas.

● Generar la nueva información contable y fiscal necesaria para la realización

de los asientos contables de las transacciones en criptomonedas según los
requerimientos del ente regulador (SENIAT).

● Integrar los procesos contables conforme a los distintos tipos de monedas (fiat
y criptomonedas).

Aporte tecnológico.

● Promover el uso de la tecnología blockchain a nivel empresarial, a fin de que

las empresas aprovechen sus beneficios financieros (transacciones
inmutables, transparentes, seguras y confiables entre las partes sin necesidad
de intermediarios).

● Incorporar las criptomonedas como un método de pago en los sistemas de

facturación y venta tradicionales.

● Automatizar las consultas de los valores de mercado de la criptomoneda, a fin

de lograr las equivalencias de las transacciones específicas.

Justificación

En la continua búsqueda por parte de la empresa Pinttosoft C.A., de

aplicaciones que sigan las tendencias tecnológicas en el ámbito financiero y
económico, que produzcan un incremento en el uso de las criptomonedas y que a su
vez ofrezcan a la organización en su posición de fundadora de la criptomoneda
 10

venezolana Onixcoin, una mejora en los procesos de compra, venta y uso de su

producto (Onixcoin), por lo tanto, plantea el desarrollo de un sistema de punto de venta
que permita realizar pagos en criptomonedas y genere la información pertinente de
facturación y cobro necesaria en los procesos administrativos de la empresa. La
culminación de este proyecto establece los siguientes beneficios:

• Para el Estado, como figura jurídica, se añaden a los recaudos que recibe los
impuestos de las transacciones realizadas mediante criptomonedas en la compra
y venta de un producto o prestación de un servicio, como consecuencia directa
de la formalización del registro contable y administrativo presente dentro de las
responsabilidades fiscales.

• Para las empresas y comercios la incorporación del uso de este sistema en sus
operaciones básicas, como un bien estratégico que permita llevar un control
administrativo y contable de las operaciones financieras que involucren
transacciones en criptomonedas, así como la reducción del esfuerzo y tiempo
actual necesarios para implementar este método de pago en el proceso de
cobro.

• Para la empresa Pinttosoft C.A., proveerá un aumento en la capacidad de

facturar y gestionar las transacciones diarias de compra y venta de su producto
(criptomoneda Onixcoin) y servicios asociados proporcionados a través de sus
plataformas de juegos y negocios.

• Para los usuarios de criptomonedas, la posibilidad de hacer uso de ellas como

método de pago de una manera formal y cotidiana con la misma facilidad que
cualquier otro método de pago (efectivo, crédito, débito, entre otros) y con el
respaldo de la generación de una factura asociada a la operación.
 11

Alcance

● Este sistema permite la reposición de inventario importando las órdenes de

compra existentes en el sistema administrativo de la empresa, gestiona los
procesos de cobro y facturación en la venta de productos realizada a un
cliente, establece un protocolo de comunicación con la plataforma Kapturela
para aceptar criptomonedas como método de pago, así como los reportes
derivados de estas operaciones, además permite la configuración del sistema
para trabajar con la información de la empresa y proporciona seguridad
mediante procesos de control de acceso.

● El sistema permite generar las facturas solo en BsS., bajo las normas
establecidas por el ente regulador venezolano (SENIAT).

● Fueron considerados como métodos de pago, los procedimientos utilizados

actualmente en Venezuela, es decir, mediante puntos de venta electrónicos en
sus dos modalidades (débito y crédito), efectivo y adicionalmente en
criptomonedas.

● Es necesario señalar que la investigación fue realizada para la empresa

Pinttosoft C.A. con localidad en la zona industrial los pinos, manzana/Calle
28, Parcela N° 08 - Galpón N° 02, Ciudad Guayana - Estado Bolívar.

Limitaciones

● El método de pago en criptomonedas se realizó mediante la pasarela de pago

Kapturela, la cual, durante la realización del trabajo, aún estaba siendo
desarrollada por la empresa Pinttosoft C.A.

● La realización de pagos de prueba con criptomonedas, requirió conexión a

internet para la comunicación con el sistema externo Kapturela.

● Las soluciones para la integración de las criptomonedas en el sistema de punto

de venta y parte del desarrollo de la plataforma Kapturela, se vieron
reformuladas por parte de la empresa, debido a la publicación del Decreto Nº
3.719 en la Gaceta Oficial número 6420 de la República Bolivariana de
Venezuela publicada el 28 de diciembre del año 2018.
 12

CAPÍTULO II

Marco Teórico

Antecedentes de la Investigación

Se pone en evidencia una amplia gama de investigaciones realizadas que

respaldan la inclusión de las criptomonedas como solución financiera en los países
que están en algún tipo de crisis o resulte más conveniente el uso de una moneda más
estable, así como de las problemáticas financieras respecto a la legalidad de las
transacciones y de su control.

Vergara (2017) quien en su trabajo “Retos para las autoridades reguladoras y

de control frente a la utilización del bitcoin como medio de pago electrónico”, realizó
un análisis crítico de las criptomonedas desde una perspectiva jurídica y regulatoria,
tomando como modelo el Bitcoin. En este trabajo, analizó las soluciones adoptadas
por los países consultados para la investigación, planteando como objetivo general la
definición de los lineamientos para una propuesta de regulación razonable de las
monedas virtuales y estableciendo sus objetivos específicos como la obtención de las
respuestas a las siguientes interrogantes: ¿qué son las monedas virtuales?, ¿para qué
sirven?, ¿son legales?, ¿deberían ser reguladas?, ¿cuál sería el objetivo de la
regulación?

Finalmente concluyó que la estrategia para regular estas transacciones en las

que se utiliza la criptodivisa, es la de aplicar soluciones que cuiden los intereses de
los usuarios tanto como de las autoridades, debido a que por su carácter
descentralizado, cualquier cambio externo a su estructura, será en vano y no podrá
ser impuesto, se establece que, se debe informar sobre las limitaciones en las
regulaciones y los riesgos que estas conllevan tomando como ejemplo que no existe
mecanismo legal que pueda obligar al destinatario de fondos a devolverlos.

Además, Vergara (2017) agrega que se debería exigir que las operaciones
 13

realizadas con criptomonedas sean convertidas a la moneda de curso legal con motivo
de establecer las obligaciones tributarias en base a el cálculo del precio a la fecha de
la criptomoneda involucrada, también la obligación a la empresa de llevar un registro
de todas las transacciones que se realizan con criptomonedas y de identificar a los
involucrados en estas operaciones, como un paso en contra del lavado de dinero.

En base a las consideraciones anteriores, se toman como referencia las

propuestas desde el punto de vista del ente regulador, y se formalizan como
requerimientos en la solución del problema, así como un punto de vista que explica
la problemática presente en la situación actual y los vacíos legales existentes en la
investigación.

Bases Teóricas

En esta sección se presentan las bases teóricas que sustentan la investigación y

permiten conocer los conceptos básicos necesarios para el entendimiento del desarrollo
de este proyecto.

Sistemas de información.

Un sistema de información se basa en un conjunto de procesos que interactúan

entre sí, estos operan una colección de datos estructurada, a su vez, capturan,
almacenan, elaboran y distribuyen selectivamente la información necesaria para la
operación de una empresa, y para las actividades de dirección y control
correspondientes, información la cual apoya a los procesos de toma de decisiones
necesarios para desempeñar correctamente las funciones de negocio de la empresa de
acuerdo con su estrategia. (Andreu, Ricart y Valor, 1991).

Un sistema de información es desarrollado a través de una serie de pasos

definidos dentro de un modelo de desarrollo.
 14

Modelo de desarrollo de software.

Un modelo de desarrollo de software o un proceso de desarrollo de software es

definido por Pressman (2010) como “Una estructura para las actividades, acciones y
tareas que se requieren a fin de construir software de alta calidad” (p.26). Divide el
proceso de desarrollo de un sistema de información en etapas bien diferenciadas y en
lo general se busca que una etapa haya concluido antes de dar comienzo a otra,
buscando que cada etapa cumpla con los objetivos planteados y proporcione las bases
para la siguiente etapa.

De esta manera se busca plantear un desarrollo guiado, donde cada etapa

presenta una porción del problema de menor complejidad y unos resultados
fundamentados en la culminación exitosa de las etapas previas, existiendo diversos
modelos de desarrollos, entre los que destacan el modelo en cascada, el modelo
incremental y el modelo ágil.

Modelo en cascada.

Este modelo de desarrollo es un proceso secuencial, que propone una serie de

fases las cuales se ejecutan una detrás de otra, denominado en cascada debido a la
secuencia que sigue el desarrollo, donde las fases parecen caer hacia las siguientes,
siguiendo un flujo de ejecución de arriba a abajo. Este modelo requiere la finalización
de la etapa anterior antes de dar inicio a la siguiente y de unos requerimientos fijos,
bien definidos o con una estabilidad razonable.

Tal como se ilustra en la Figura 2, sugiere un enfoque sistemático y secuencial para

el desarrollo del software, que comienza con la especificación de los requerimientos
por parte del cliente y avanza a través de planeación, modelado, construcción y
despliegue, para concluir con el apoyo del software terminado. (Pressman, 2010,
p.34).
 15

Figura 2. Modelo de desarrollo en cascada

Sistema de bases de datos.

Un sistema de información hace uso de un sistema de bases de datos, para

almacenar de una manera estructurada los datos necesarios para su funcionamiento,
estos dos sistemas son elaborados en conjunto, por esta razón, se incluyen actividades
para el desarrollo de un sistema de base de datos dentro de las fases del modelo de
desarrollo, culminando en un producto final capaz de generar y almacenar
información de una entrada de datos.

Un sistema de base de datos es una combinación de recursos que permiten el

manejo de la información, este sistema engloba la colección de datos almacenados
bajo una estructura definida y de un mismo contexto denominada base de datos, los
programas que se encargan de la gestión de la base de datos y las personas que harán
uso de él.

Los sistemas de bases de datos se diseñan para gestionar grandes cantidades de

información. Esas grandes cantidades de información no existen aisladas. Forman
parte del funcionamiento de alguna empresa, cuyo producto final puede que sea la
información obtenida de la base de datos o algún dispositivo o servicio para el que
la base de datos sólo desempeña un papel secundario. El diseño de bases de datos
implica principalmente el diseño del esquema de las bases de datos. (Silberschatz,
Korth y Sudarshan, 2006, p.11).

El diseño de base de datos de maneras generales se descompone en tres fases:

 16

Diseño conceptual: corresponde a una descripción de la realidad, en un

lenguaje de alto nivel y de fácil entendimiento, se identifican las entidades, sus
atributos y las relaciones entre ellas.

Diseño lógico: Se traducen y se transforman los esquemas obtenidos en el

diseño conceptual en un conjunto de estructuras propias del modelo de datos elegido,
independientemente del sistema manejador de datos a utilizar.

Diseño físico: Se realiza una implementación de los resultados del diseño

lógico dependiente del sistema manejador de base de datos en donde se transforman
las entidades en tablas, las instancias en filas y los atributos en columnas, también se
establecen las reglas de negocio en forma de restricciones de acceso y
almacenamiento.

Modelo entidad-relación.

El modelo de datos entidad-relación (E-R) no es más que una percepción de

la realidad. Según Silberschatz, Korth y Sudarshan (2006) “Consiste en un conjunto
de objetos básicos, denominados entidades, y de las relaciones entre esos objetos”
(p.13). Este análisis de la realidad es un fuerte punto de inicio que plantea una de las
primeras etapas para el diseño de la base de datos cuando se requiere que la
información esté almacenada en estructuras relacionadas, para ello se utilizan los
Sistemas Gestores de Bases de Datos.

Sistema gestor de bases de datos (SGBD).

El SGBD es un programa que permite a los usuarios realizar acciones sobre una
base de datos. Ramos, Ramos y Montero (2006) lo definen como “Un conjunto de
programas que acceden y gestionan esos datos” (p.7). Uno de los SGBD más utilizado
actualmente es PostgreSQL.

El PostgreSQL es un potente sistema de base de datos relacional de objetos de

código abierto que usa y amplía el lenguaje SQL combinado con muchas características
 17

que almacenan y escalan de manera segura las cargas de trabajo de datos más
complicadas.

La arquitectura de PostgreSQL proporciona confiabilidad, integridad de datos,

un conjunto de características robustas, extensibilidad y al ser código abierto, cuenta
con el apoyo de la comunidad, en innovaciones y continuidad del desarrollo.

Arquitectura de software MVC (Modelo Vista Controlador).

La arquitectura de software dicta la forma en que la aplicación será

estructurada, construida y como las partes de esta funcionan y se comunican. Según
Bahit (2014) “El MVC es un patrón de arquitectura de software encargado de separar
la lógica de negocio de la interfaz del usuario. MVC divide las aplicaciones en tres
niveles de abstracción”, tal como se ilustra la Figura 3.

Modelo. Representa la lógica de negocios. Es el encargado de acceder de

forma directa a los datos actuando como “intermediario” con la base de datos.

Vista. Es la encargada de mostrar la información al usuario de forma gráfica.

Controlador. Es el intermediario entre la vista y el modelo. Es quien controla

las interacciones del usuario solicitando los datos al modelo y entregándose a la vista
para que ésta, lo presente al usuario.

Figura 3. Modelo Vista Controlador

Recuperado de: https://sites.google.com/site/programacionapuntes/home/mvc

 18

Mapeo objeto-relacional (ORM).

Existen problemas de incompatibilidad conceptual y técnicas entre bases de

datos relacionales y la programación bajo el paradigma orientado a objetos. Por
ejemplo: el modelo relacional no puede modelar la herencia del modelo orientado a
objetos o las diferencias entre los tipos de datos, así como muchos otros.

Una de las técnicas para sobreponerse a estos problemas es haciendo uso de un

mapeo objeto relacional o ORM (object-relational mapping), la cual es una técnica de
programación para convertir datos del sistema de tipos utilizado en un lenguaje de
programación orientado a objetos al utilizado en una base de datos relacional. (Becerra,
Hidalgo y Pérez, s.f).

Según Becerra, Hidalgo y Perez (s.f) debido a que las bases de datos
relacionales solo pueden almacenar tipos de datos primitivos (enteros, cadenas de texto,
etc.), los objetos de la aplicación deben pasar por un proceso de conversión, en el que
son convertidos en registros capaces de ser almacenados en las tablas, un ORM, abstrae
esta conversión, permitiendo ir de objetos a registros y viceversa si se requiere
recuperar la información, gracias a este proceso, se posibilita el uso de las
características propias de la orientación a objetos (es esencialmente la herencia y el
polimorfismo).

Marco de trabajo (Framework).

Galindo y Camps (2008) definen un Framework como un “Conjunto de clases

cooperativas que construyen un diseño reutilizable para un tipo específico de software”
(p.38). Galindo y Camps (ob.cit) también añaden que un Framework “Proporciona la
arquitectura partiendo el diseño en clases abstractas, definiendo sus responsabilidades
y colaboraciones” (p.38).

Ventajas: Minimiza tiempos de desarrollo, reduce los riesgos del desarrollo,

proporciona una arquitectura consistente entre aplicaciones.
 19

Desventajas: Limitación de la flexibilidad, dificultad de aprendizaje, reducción

de la creatividad.

Criptografía.

La criptografía es la creación de técnicas para el cifrado de datos. Teniendo

como objetivo conseguir la confidencialidad de los mensajes. Si la criptografía es la
creación de mecanismos para cifrar datos, el criptoanálisis son los métodos para
“romper” estos mecanismos y obtener la información. Una vez que nuestros datos
han pasado un proceso criptográfico se dice que la información se encuentra cifrada.
(Stamp, 2011).

Distintas tecnologías utilizan estas técnicas para crear información digital

infalsificable, como es el caso de la tecnología blockchain donde se usan funciones
matemáticas que verifican la relación entre una clave publica y una privada, logrando
de esta manera verificar y aceptar transacciones sin revelar la clave privada, una de
las técnicas más utilizadas es el hashing criptográfico para obtener direcciones
digitales a partir de una clave publica, durante el proceso de minado, verificar bloques
nuevos y para la generación de árboles Merkle (estructura de datos utilizada en el
proyecto Bitcoin).

Cadena de bloques (Blockchain).

La cadena de bloques es definida por EquiSoft (2017) como “Un libro contable
público descentralizado diseñado para registrar transacciones en un entorno protegido.
En otras palabras, es un tipo de base de datos usado para registrar las transacciones,
que es copiado en todas las computadoras que conforman la red específica” (p.4).

Es una base de datos distribuida compartida por una gran cantidad de usuarios
de forma peer-to-peer, esto quiere decir que todos los nodos cumplen la función de
servidor y cliente, no hay ningún tipo de jerarquía que los diferencie, por lo tanto, cada
computadora está en un plano de igualdad con las demás. La información añadida a la
blockchain es publica y puede ser consultada en todo momento por los usuarios de la
 20

red. La información solo puede ser añadida a la cadena de bloques si existe un acuerdo
entre la mayoría de las partes y transcurrido un tiempo, la información agregada en un
bloque ya no podrá ser modificada. (Retamal, Roig y Muñoz, 2017, p.34).

Cuando un nuevo bloque se crea, los nodos denominados mineros se encargan

de validar la escritura de los datos en la blockchain, este proceso genera una
compensación económica para los mineros y esta validez se logra a través de la revisión
y mutuo acuerdo de la mayoría de los participantes. En la Figura 4, se ilustra cómo es
un bloque de la cadena usado en el bitcoin.

Figura 4. Estructura e información contenida en un bloque de la cadena de bloques (blockchain).

Recuperado de: https://bitcoin.org/bitcoin.pdf.

Uno de los principales usos que se le da a esta tecnología, nace en el 2008

cuando Satoshi Nakamoto publica un mecanismo para implementar la criptomoneda
Bitcoin haciendo uso de cadenas de bloques para registrar transacciones en una red
peer-to-peer.
 21

Criptomoneda.

En inglés el término cryptocurrency se define por el diccionario de Cambridge

como “a digital currency produced by a public network, rather than any government,
that uses cryptography to make sure payments are sent and received safely”. [Una
moneda digital producida por una red pública, en lugar de un gobierno, que utiliza la
criptografía para garantizar que los pagos se envíen y se reciban de forma segura].

Solo existe en la cadena de bloques o blockchain que la soporta y debido a un

proceso de confirmación de transacciones en la red, no puede gastarse dos veces.

Punto de venta (PDV).

Sorensen (2019) Se refiere a un punto de venta como un “Sistema configurado

para procesar los pagos presenciales de los clientes”. Sorensen (ob.cit) también
argumenta:

PDV no es una máquina o proceso independiente – es una constelación de

elementos que juntos te permiten procesar las transacciones que se realizan
de cara al público de forma eficiente y agilizar procesos comerciales
conectados con tus ventas. El conjunto variará en apariencia y funcionalidad
dependiendo de la tecnología elegida, los métodos de pago aceptados, si
quieres imprimir recibos en papel, cómo quieres registrar las ventas y
organizar la contabilidad diaria y los sistemas de inventario que tengas
instalados para tus productos. (párr.2).

.
 22

Bases Legales

En esta sección se presentan las leyes y normativas que sustentan la

investigación, información la cual regula la solución y establece parte de los
requerimientos del sistema.

Decreto Nº 3.719 publicado en la Gaceta Oficial Nº 6420 de la República

Bolivariana de Venezuela.

En la Gaceta Oficial número 6420 de la República Bolivariana de Venezuela

publicada el 28 de diciembre del año 2018, se encuentra el Decreto Nº 3.719 el cual se
refiere a “Los sujetos pasivos que realicen operaciones en el territorio nacional en
moneda extranjera o criptodivisas, autorizadas por la ley, deben determinar y pagar las
obligaciones en moneda extranjera o criptodivisas” (p.29).

Este Decreto se compone por 8 artículos, los cuales se resumen a continuación:

El artículo 1 se desglosa en las siguientes consideraciones:

• El sujeto pasivo que lleve a cabo operaciones en moneda extranjera o

criptodivisas, deben determinar y pagar las obligaciones en moneda
extranjera o criptodivisas, no en moneda fiat.
• Se habla de sujeto pasivo, el cual es un término usado en la contabilidad
dentro del ámbito de las obligaciones fiscales que se refiere a la persona
natural o jurídica que esta obliga a cumplir con sus obligaciones
tributarias, esto quiere decir que el decreto toma en cuenta a ambos tipos
de personas.
• Hace referencia exclusivamente a las operaciones dentro del territorio
nacional, por lo tanto, se habla de tributos nacionales.
• Se limita a aquellas operaciones las cuales constituyan hechos
imponibles generadores de tributos nacionales.
 23

• Solo aplica para las operaciones autorizadas por la ley a través de los
Convenios Cambiarios suscritos entre el Ejecutivo Nacional y el Banco
Central de Venezuela o mediante Decreto Presidencial.

El artículo 2 excluye de la aplicación de la normativa a las operaciones de los

títulos valores negociados en la Bolsa de Valores y a la exportación de bienes y
servicios, realizados por órganos o entes públicos.

El artículo 3 indica que la determinación y pago de las obligaciones tributarias

en moneda extranjera o criptodivisas previsto en este decreto, será aplicable a los
tributos, sus accesorios y sanciones derivadas del incumplimiento de las obligaciones.

El artículo 4 delega al Servicio Nacional Integrado de Administración

Aduanera y Tributaria (SENIAT) la función de dictar la normativa que establezca las
formalidades para declarar y pagar en moneda extranjera o en criptodivisas las
obligaciones señaladas en el decreto.

El artículo 5 delega a la Superintendencia de las Instituciones del Sector

Bancario (SUDEBAN) la función de dictar la normativa para regular las adecuaciones
que deban realizarse a las instituciones que conforman el sector bancario para la
ejecución de este decreto.

El artículo 6 define que la repetición de pago, recuperación o devolución de los

tributos nacionales por los supuestos establecidos en el decreto, se realizara en moneda
nacional al tipo de cambio oficial vigente en la fecha del pago del tributo o de registro
de la declaración de aduana.

El artículo 7 deja al Ministerio del Poder Popular de Economía y Finanzas como

encargado de la ejecución del decreto.
 24

El artículo 8 dice que el decreto entrara en vigencia a partir de su publicación

en Gaceta Oficial de la República Bolivariana de Venezuela.

En conclusión, tal como lo indica el artículo 8, este Decreto entró en vigencia

en el momento de su publicación en Gaceta Oficial el día 28 de diciembre del año 2018,
sin embargo, estando a finales del año 2019, aún no se ha establecido por parte del
SENIAT ni del SUDEBAN el reglamento, ni los procesos necesarios para cumplir con
las obligaciones tributarias en este tipo de operaciones, evidenciando así el vacío legal
presente respecto a el correcto manejo de las criptomonedas como método de pago.

Por otro lado, el Decreto hace mención de cierta responsabilidad que tiene el
sujeto pasivo de determinar en sus operaciones el tributo el cual debe pagar, en
consecuencia, surge la necesidad de tener la capacidad de registrar los valores de
mercado y tipo cambiario en el momento de la transacción de pago dado que se requiere
esta información para el posterior cálculo tributario. En el Apéndice A, se muestra el
Decreto completo.

Campos de factura legal en la República Bolivariana de Venezuela.

El SENIAT establece los siguientes campos mínimos los cuales deben estar
presentes en el documento legal denominado factura, el cual es emitido sobre la venta
de productos o la prestación de servicios. En la Tabla 1 se listan estos campos mininos
de la factura legal.
 25

Tabla 1
Campos mínimos de la factura legal

Ítem Campo

1 R.I.F. del emisor.

2 Nombres y apellidos o razón social del emisor

3 Domicilio fiscal y teléfono del emisor.

4 RIF o cedula de identidad, del adquirente del bien o receptor del servicio.

5 Nombre y apellido o razón social, del adquirente del bien o receptor del servicio.

6 Dirección fiscal y teléfono, del adquirente del bien o receptor del servicio.

7 Debe tener la denominación “FACTURA”.

8 Número de factura y Número de control.

9 Fecha y hora de emisión.

Descripción de la venta del bien o de la prestación del servicio, indicando la cantidad

10
y monto.

Todo tipo de ajuste, descuento o anulaciones en el precio, debe contar con su debida
11
descripción y valor ajustado.

12 Especificar la base imponible, IVA (indicando la alícuota) y monto total a cancelar.

 26

CAPÍTULO III

Marco Metodológico

Tipo de Investigación

La investigación de campo se define como aquella “que se efectúa en el lugar

y tiempo en que ocurren los fenómenos objeto de estudio” (Zorrilla, 1993). En
consecuencia este trabajo se trata de una investigación de campo, ya que se estudia
la realidad social actual en que se encuentra Venezuela, con respecto a la búsqueda
de nuevas alternativas financieras que contribuyen a la seguridad, transparencia y
escalabilidad en el sistema global financiero, a la vez existen decretos, resoluciones
y providencias establecidas por el Servicio Nacional Integrado de Administración
Aduanera y Tributaria (SENIAT) y otros entes reguladores que norman los procesos
administrativos y financieros en el cual se enmarca el estudio.

Técnicas e Instrumentos de Recolección de Datos

Según Arias (2012) “Un instrumento de recolección de datos es cualquier

recurso, dispositivo o formato (en papel o digital), que se utiliza para obtener,
registrar o almacenar información”. (p.68). Los procesos, técnicas y métodos de
recolección de datos seguidos con respecto al tipo de investigación que permitieron
la obtención eficiente de la información a lo largo del desarrollo del proyecto fueron:

Observación libre o no estructurada.

Cuando se habla de un fenómeno social del cual no se tiene referencia u

orientación como lo es la inclusión de las criptomonedas en el ámbito financiero, se
planteó hacer un estudio general de la situación sin estructuración previa, con la
intención de observar los aspectos legales, de concepto, de operación, administrativos
y financieros que puedan acontecer ante la problemática y la solución, a su vez se
observa el funcionamiento y estructuración general de un sistema punto de venta.
 27

Revisión documental.

Corresponde a la utilización en el estudio de fuentes primarias y secundarias

como textos, trabajos de grados pertinentes al estudio, manuales, folletos revistas,
Internet entre otros recursos. (Castro, 2010, p.94).

Dentro de las fuentes consultadas durante del desarrollo del proyecto, se

encuentran los whitepaper de las criptomonedas, en los cuales se describen aspectos
tecnológicos, comerciales y financieros del proyecto, así como la explicación de la
problemática que la criptomoneda busca solucionar.

También, se realizó el análisis de estudios que establecen argumentos sobre

el trato de las criptomonedas, sus aplicaciones, ventajas y desventajas de estas en el
ámbito financiero y las soluciones que se plantean en los países que han adoptado
esta tecnología, estableciendo reglamentos y fomentando su uso, como es el caso de
Venezuela con su criptomoneda “El Petro” y España con sus regulaciones sobre las
criptomonedas, entre muchos otros que adoptan esta tecnología o buscan regular de
alguna manera su uso y aporte al fisco.

Como se establece el desarrollo bajo las leyes venezolanas, se realizó el

estudio de las leyes y regulaciones impuestas por sus organismos reguladores, en
específico el SENIAT, sobre los procesos de facturación en la compra y venta de un
producto o prestación de un servicio, y las responsabilidades impuestas a los
comercios y empresas, además de las leyes internacionales de contabilidad buscando
un argumento descriptivo de la información y procesos, que se preste como solución
ante la problemática de las criptomonedas como método de pago y su inclusión en un
sistema de punto de venta.
 28

Metodología de Desarrollo

El modelo de desarrollo empleado se denomina Cascada, también llamado

secuencial o ciclo de vida clásico, este se caracteriza por un conjunto de fases
ordenadas, donde cada una debe de ser terminada antes de dar inicio a la siguiente,
siendo poco recomendable el volver atrás, pero se tiene cierta tolerancia a esto.

Esta metodología se amoldó al desarrollo del proyecto, debido a que al

tratarse del desarrollo de un sistema punto de venta, que es ampliamente utilizado, se
tenía una base sólida y bien definida de los requerimientos de este tipo de sistemas,
así como de su estructura general, adicional a esto, este modelo propone usar una
gran cantidad de tiempo en las primeras fases de análisis y diseño, logrando definir
así requerimientos cuyas probabilidades de cambios bruscos se ven altamente
minimizadas y se establece en cada fase del desarrollo un resultado verificable y
documentado.

Procedimiento Metodológico

1. Análisis de los procesos administrativos que lleva a cabo un sistema de

punto de venta.

• Se hizo un estudio de la situación actual de los sistemas de punto de venta,

identificando los procesos que son llevados a cabo por estos, así como su
distribución en módulos, funcionalidad e información generada y manejada por
estos sistemas.
• Adicionalmente es necesario identificar los reglamentos existentes buscando
determinar la posible integración del método de pago en criptomonedas a un
sistema de punto de venta, así como la información que este requiere de las
transacciones comerciales.
• Finalmente, del estudio en conjunto con la empresa Pinttosoft se identifican los
reportes los cuales el sistema punto de venta debe generar y se especifica la
información que estos detallan.
 29

2. Definición de los requerimientos del sistema de punto de venta con

soporte al procesamiento de pagos en criptomonedas.

Dentro del marco de las observaciones anteriores y sus resultados, se procedió

al desarrollo de la ingeniería de requerimientos, buscando así, otorgar precisión y
claridad de los requisitos, validaciones y capacidades del sistema propuesto, en sus
ramificaciones funcionales, no funcionales y de almacenamiento, teniendo como
resultado un listado de requerimientos del sistema a cumplir; sirviendo este, para el
seguimiento, verificación y validación del sistema.

3. Diseño del sistema de punto de venta en base a los requerimientos

definidos.

Para el logro de este objetivo, se procedió a la elaboración de cuatro fases de

diseño, comenzando por el diseño de la base de datos buscando primeramente
conceptualizar la información requerida por el cliente (diseño conceptual)
seguidamente elaborando el diseño lógico de esta, como segunda fase se procede a
diseñar la aplicación, especificando la estructura modular del sistema en general y la
elaboración de las interfaces gráficas mediante diagramas de casos de uso y de
actividades que explican los comportamientos del sistema, además se diseñaron los
prototipos y flujos de interfaz necesarios para describir cada una de las pantallas del
sistema, la tercera fase corresponde al diseño de las pruebas, donde se diseña un plan
de pruebas de la aplicación que permita en su ejecución verificar los algoritmos y
validar los requerimientos del sistema, por último, en la cuarta fase de diseño, se
realizó el diseño arquitectónico de la solución, donde se describe el marco de trabajo
y los patrones de software utilizados en la solución.
 30

4. Construcción del sistema de punto de venta de acuerdo al diseño

planteado.

La construcción del sistema fue guiada por la lista de requerimientos y diseños

elaborados en las fases anteriormente planteadas, buscando la elaboración de los
requerimientos bajo los estándares establecidos por la empresa Pinttosoft C.A., los
patrones y características de la arquitectura de software MVC (modelo-vista-
controlador).

La construcción de la base de datos fue llevada a cabo en el sistema gestor de

bases de datos PostgreSQL, el cual es estándar de la empresa en los modelados de
información relacionales, para la codificación se empleó el lenguaje de programación
Java, haciendo uso del framework Spring Boot integrado con la familia de productos
JavaFX por las ventajas visuales y de core en la construcción de aplicaciones de
escritorio multiplataforma que otorga bajo el paradigma orientado a objetos (POO),
obteniendo como resultado el sistema de punto de venta con soporte al procesamiento
de pagos en criptomonedas y su integración en los procesos administrativos de la
empresa Pinttosoft C.A., sobre el cual se realizaron las distintas pruebas diseñadas a
fin de detectar los posibles errores y de esta manera validar el cumplimiento de los
requerimientos del sistema.

5. Documentación del sistema de punto de venta desarrollado.

En simultaneidad y posteriormente al desarrollo del sistema, se procedió a la

compilación de los distintos entregables resultantes de las etapas anteriores,
obteniendo así, el manual técnico del sistema donde se detalla los aspectos de la
solución resultado de las fases de diseño y de construcción del sistema, y se elaboró
el manual de usuario como material detallado del uso y funcionalidad del sistema.
 31

CAPÍTULO IV

Resultados

En el siguiente capítulo se presentan los resultados alcanzados con respecto

a los objetivos planteados.

Análisis de los Procesos Administrativos que Lleva a Cabo un Sistema de Punto

de Venta

El módulo de ventas engloba los procesos principales llevados a cabo por un

sistema de punto de venta, dentro de este módulo encontramos los procesos de cobro
y facturación, los cuales suplen la mayor parte de la necesidad de un sistema de este
tipo.

En la Figura 5, se observa la primera parte del proceso de cobro y facturación,

la cual corresponde a la selección del cliente al que se le realiza la venta (el cliente
necesita estar registrado en el sistema, ya que sus datos son necesarios en el documento
factura), continua con la selección de los productos que el cliente busca comprar y
finaliza con la generación de una cotización la cual se presenta y se busca cobrar.

El proceso de cobro y facturación continua en la Figura 6 en donde se

seleccionan los métodos de pago por los cuales el cliente pagara su compra, se establece
el monto a pagar en cada selección, además, si la selección del cliente corresponde a
un pago mediante criptomonedas, la solución de este proyecto adiciona actividades
para el pago a través de una pasarela de pago, en donde primeramente se identifica de
una lista de criptomonedas aceptadas dentro de la plataforma la criptomoneda con que
el cliente pagara, luego se genera un código QR el cual contiene la información de la
transacción y al ser escaneado por el cliente, se genera un estado de transacción que
dicta si el pago del cliente fue aceptado o rechazado; si se cancela la totalidad del
monto, se genera el documento denominado factura poniendo fin a el proceso de cobro
y facturación.
 32

Figura 5. Diagrama de flujo de la primera parte del proceso de cobro y facturación.

 33

Figura 6. Diagrama de flujo de la segunda parte del proceso de cobro y facturación.

 34

El sistema contiene procesos de configuración, de control de inventario, de

compra y venta, y genera reportes con la información resultado de sus operaciones.
En la Tabla 2 se presentan los módulos que comparten los sistemas de punto de venta.

Tabla 2
Módulos de un sistema de punto de venta

Módulo Descripción

Catálogo Gestionar los productos para que posteriormente puedan ser agregados
de Productos al inventario mediante una compra de existencias a un proveedor.
Catálogo Gestionar a los clientes de la empresa que buscan adquirir productos y
de Clientes servicios de esta.
Gestionar los proveedores, registrando la información de estos
Catálogo
vendedores a los cuales la empresa realiza compras de productos para
de Proveedores
incrementar su inventario.
Gestionar la información de los espacios físicos en los cuales los bienes
Almacenes
en inventario se encuentran almacenados.
Gestionar las órdenes de compras que se le hacen a los proveedores para
Compras lograr el incremento de existencias de un producto del catálogo, y de
esta manera adicionarlo en inventario para su posterior venta.
Categorías Gestionar las categorías en las cuales los productos pueden agruparse.
Inventario Gestionar la información de venta y existencias de los productos.
Permite realizar la venta de productos a un cliente, así como llevar a
Venta cabo los procesos de cobro, facturación y descuento de inventarios
asociados a esta operación.
Permite generar con motivo administrativo, los reportes e información
Reportes
necesaria para la empresa.
Gestiona el acceso del sistema, administrando usuarios, grupos y
Control de acceso
permisos.
Permite gestionar la información de la empresa, impuestos, moneda
Configuración
utilizada, zona horaria, entre muchas otras configuraciones.

Una vez identificados los módulos del sistema, se alinea la integración de las
criptomonedas al sistema punto de venta en conjunto con lo argumentado dentro de las
bases legales de la investigación. En primer lugar, se establece la necesidad de que el
sistema permita registrar los valores de mercado y tipo de cambio en el momento de la
transacción de pago en criptodivisas. Después como parte del proceso de facturación
dentro del módulo ventas, es necesario emitir la factura al cliente, para este documento
 35

se utilizan los campos mínimos en la normativa impuesta por el SENIAT listados en la

Tabla 1 y se elabora el formato de la factura generada por el sistema ilustrado en el
Apéndice B.

Prosiguiendo con el análisis del sistema punto de venta, dentro del módulo
reportes, se deben elaborar cuatro reportes los cuales fueron especificados por la
directiva de la empresa Pinttosoft, dichos reportes son:

• Reporte diario en el cual por producto se detalla la cantidad vendida, el

precio del producto, impuesto total y el monto total.
• Reporte mensual en el cual por producto se detalla la cantidad vendida,
el impuesto total y el monto total.
• Histórico de inventario: se muestra la cantidad total de productos
registrados, en existencia, vendidos y comprados, también la fecha en
que se registró la última compra y el último ingreso además del precio
actual del producto.
• Resumen de ventas: Mensualmente se divide lo cobrado en los
diferentes métodos de pago (efectivo, criptomonedas, débito y crédito)
y en los diferentes impuestos manejados por el sistema (Ejemplo: IVA),
además se calcula el monto total cobrado en base a lo anterior planteado.

Definición de los Requerimientos del Sistema

De la investigación y de los resultados obtenidos en la fase anterior, se

procedió al desarrollo de la ingeniería de requerimientos de manera de lograr las
correctas especificaciones que describan el comportamiento del sistema punto de
venta de manera clara y sin ambigüedades.
 36

Requerimientos funcionales

En la Tabla 3, se definen los comportamientos que debe cumplir el sistema.

Tabla 3
Requerimientos funcionales

ID Req. Descripción del requerimiento Proceso

Configurar la información general de la empresa y viejos datos de control

RF-001
de la facturación previa.

RF-002 Consultar, agregar, editar y eliminar métodos de pagos.

Configuración
Consultar, agregar, editar y eliminar unidades de medidas en las que se de sistema
RF-003
expresan los productos.

Consultar, agregar, editar y eliminar los impuestos de venta que pueden

RF-004
aplicar sobre los productos.

Catálogo de
RF-005 Consultar, agregar, editar y eliminar la definición de los productos.
productos

Catálogo de
RF-006 Consultar, agregar, editar y eliminar los clientes de la empresa.
clientes

Catálogo de
RF-007 Consultar, agregar, editar y eliminar los proveedores de la empresa.
proveedores

Importar las órdenes de compra existentes en el sistema administrativo

RF-008
de la empresa.

RF-009 Consultar y editar la información de venta de los productos en inventario.

RF-010 Consultar, agregar, editar y eliminar los almacenes de la empresa.

Gestión de
Generar la recepción de mercancía de la empresa a través de la inventario
RF-011 distribución de las órdenes de compra en los almacenes y gestionar así,
las existencias en inventario de la nueva mercancía.

RF-012 Una orden de compra puede ser anulada de ser requerido.

RF-013 Consultar los detalles de una orden de compra.

 37

Continuación Tabla 3
Requerimientos funcionales

ID Req. Descripción del requerimiento Proceso

El proceso de venta debe abarcar el proceso de facturación, la cobranza y la emisión de

RF-014
la factura.

En el proceso de facturación se debe poder establecer el cliente (nuevo o existente) al

RF-015
cual se le adjudica la factura.

En el proceso de facturación se debe poder seleccionar los productos en inventario, así

RF-016
como la cantidad deseada de cada uno de estos.

Cuando el sistema factura un producto, se debe descontar de existencia la cantidad

RF-017
solicitada. Gestión
de
El proceso de cobranza debe permitir elegir entre los métodos de pago para el pago de la ventas
RF-018
factura.

Debe existir un método de pago que permita hacer uso de criptomonedas, a través de la
RF-019 plataforma Kapturela que cumple el papel de pasarela de pago con criptomonedas
desarrollado por la empresa Jaspesoft C.A., en asociación con la empresa Pinttosoft C.A.

Integrar en el sistema, la notificación de estado de transacción en un pago en

RF-020
criptomonedas.

RF-021 Consultar las facturas generadas por el sistema y permitir anularlas de ser requerido.

Generar
RF-022 Generar los reportes: de ventas (resumen, diarias, mensuales) y el histórico de inventario.
reportes

Control de
RF-023 Consultar, agregar, editar y eliminar las cuentas de acceso al sistema.
acceso
 38

Requerimientos no funcionales

En la Tabla 4, se listan las características generales y restricciones del sistema,

así como los criterios para que su uso sea adecuado.

Tabla 4
Requerimientos no funcionales

ID Req. Descripción del requerimiento

RNF-001 El sistema debe poseer interfaces gráficas bien formadas.

El sistema y sus productos deben cumplir con las leyes de la República Bolivariana
RNF-002
de Venezuela vigentes para la fecha que tengan cabida en el ámbito del proyecto.

El sistema se debe de poder ejecutar en diferentes sistemas operativos

RNF-004
(multiplataforma), siempre que la ejecución de aplicaciones JAVA sea posible.

RNF-005 El sistema manejador de base de datos debe ser PostgreSQL.

RNF-006 El sistema debe resguardar los datos de acceso no autorizado.

Requerimientos de almacenamiento

Se procede a través de premisas, la formación de textos descriptivos, los cuales

describen los datos, descomponen los comportamientos y la información presente en
el sistema. En la Tabla 5 se observan los distintos requerimientos de los cuales se inicia
la formación de estructuras de almacenamiento, así como a la identificación de las
entidades, atributos y relaciones.
 39

Tabla 5
Requerimientos de almacenamiento

ID Req. Descripción del requerimiento

Una empresa que busca hacer uso de un sistema de punto de venta debe especificar su
RA-001 información jurídica como lo es su nombre, rif y dirección, información la cual, dentro
del marco legal, debe formar parte de las facturas emitidas por el sistema.

Las empresas, pueden contar o no con una previa facturación manual o en algún otro
sistema, por lo tanto, el sistema debe conocer los números de control y de factura previos
RA-002
manejados por la empresa, para dar continuidad a estos, cumpliendo con su obligación
legal.

El sistema debe almacenar la información del producto, como lo establece un sistema de

RA-003 inventario, la fecha de ingreso al sistema, el código del producto, su nombre y la
descripción que se le da.

RA-004 Un producto debe ser expresado en una unidad de medición.

Un impuesto puede ser aplicado a un producto, y un producto puede tener o no un

RA-005
impuesto aplicado.

La empresa aumenta las existencias de un producto en inventario, mediante la recepción

de productos en sus almacenes, realizando órdenes para la compra de una variedad de
RA-006 productos, de las cuales se requiere conocer el monto total de la compra, la información
jurídica del proveedor al cual se le atribuye la orden, el precio de compra por unidad, la
cantidad de producto comprado y en qué unidad se expresa esa cantidad.

Un producto está presente en inventario cuando se le atribuye una existencia en un

RA-007 almacén, consecuencia de una recepción, el cual una vez en inventario, se debe
especificar su precio de venta.

Para las empresas es importante llevar un control de sus clientes, por lo tanto, se
identifican los atributos de un cliente, como una persona natural, poseedora de un código
RA-008
correspondiente a su documento de identidad, nombre, apellido, dirección y teléfono de
contacto.

Un cliente puede realizar en distintos momentos diferentes compras, donde una compra
de productos a la empresa se hace directamente en el proceso de facturación, donde se
RA-009 ingresan los productos con existencia en inventario que el cliente está comprando y la
cantidad deseada de cada uno de estos, continúa con el cobro de la factura y finaliza con
la emisión de la factura al cliente.

Una factura debe especificar su estado, la fecha de emisión de la misma, el número de

factura, el número de control, el subtotal, el total exento, el total de sus impuestos , el
total a pagar, el cliente al cual se le facturo y a su vez debe detallar por producto la
RA-010
cantidad comprada, el precio de venta de la unidad, el porcentaje de impuesto y el monto
cobrado por este (si este aplica), el total a pagar sin impuestos (total bruto), además del
registro en inventario que está sufriendo el descuento de existencias.
 40

Continuación Tabla 5
Requerimientos de almacenamiento

ID Req. Descripción del requerimiento

El cliente puede realizar el pago del monto de su factura a través de diferentes métodos
RA-011
de pago identificados por su nombre y descripción.

Cada pago realizado por el cliente debe ser registrado, se debe almacenar la fecha y el
RA-012 tiempo en que se está ejecutando el pago, el monto que se está cancelando, el método de
pago que se está usando, la factura a la cual pertenece el pago y una descripción de este.

Si el cliente decide realizar un pago mediante criptomonedas, se debe llevar un control

de la información adicional correspondiente a la criptomoneda usada, como su nombre
y símbolo, además de los precios de mercado en el momento de la transacción, los cuales
RA-013
utiliza para hacer la equivalencia entre el monto que se desea cancelar, y la cantidad de
criptomonedas necesarias, estos precios son, precio en bitcoin de la criptomoneda, precio
del bitcoin en la moneda local Venezolana, precio del bitcoin en dólares Americanos.

Un usuario debe tener un estatus, un nombre de usuario, una clave, y este debe ser de un
RA-014
tipo entre administrador y vendedor.

Diseño del Sistema de Punto de Venta en Base a los Requerimientos Definidos

Una vez definidos los requerimientos del sistema, se procedió a la elaboración

de los distintos diseños de estructura, comportamiento y datos manejados por el
sistema, así como el diseño de las interfaces graficas de la aplicación y el plan de
prueba a ejecutar una vez finalizada la construcción del sistema.

Diseño de la base de datos.

Siguiendo los requerimientos de almacenamiento de la solución, se desarrolló

el diseño de la base de datos, el cual abarcó el diseño conceptual y el diseño lógico.

Diseño conceptual.

Para comenzar con el diseño de la base de datos, se realizó una descripción

de la realidad mediante un modelo, el cual describe el problema y relaciona sus
conceptos en un lenguaje de alto nivel y de fácil entendimiento. En la Figura 7 se
muestra el modelo entidad-relación del sistema propuesto, en el que se identifican las
entidades, sus atributos y las relaciones entre estas.
 41

Figura 7. Modelo entidad-relación del sistema propuesto.

 42

Diseño lógico.

Como segundo punto del diseño de la base de datos, se procedió a traducir y

transformar el modelo entidad-relación al modelo relacional, siguiendo los pasos de
transformación estandarizados en el diseño de una base de datos relacional.
Obteniéndose el modelo relacional de la base de datos del sistema propuesto tal como
se ilustra en la Figura 8.

.
 43

Figura 8. Modelo relacional del sistema propuesto.

 44

Diseño de la aplicación.

Estructura modular.

Con el objetivo de describir la funcionalidad desde una perspectiva modular,

se diseñó la estructura del sistema punto de venta tal como se ilustra en la Figura 9,
para lograr observar los procesos y actividades encapsuladas en los distintos módulos
del sistema, así como las clases que toman parte en estos, de esta estructura, se
fundamenta el diseño de interfaces gráficas y la construcción del sistema.

Figura 9. Estructura modular del sistema propuesto.

 45

Diseño de la interfaz gráfica.

Una vez que la estructura modular es diseñada, se procedió a el diseño de las

interfaces de usuario por módulo, mediante la utilización de casos de uso para describir
el comportamiento del sistema punto de venta, desde la perspectiva de su interacción
con el usuario, también se usan diagramas de actividades para modelar los casos de
uso, buscando complementar la descripción del comportamiento y sus actores,
adicionalmente se presenta el prototipado y el flujo de las interfaces necesario para
cumplir con las actividades definidas.

Diagrama de caso de uso general para la configuración del sistema.

El diagrama de caso de uso ilustrado en la Figura 10 para el módulo de

configuración del sistema, se divide en cuatro casos de usos que describen los
submódulos a configurar.

Figura 10. Diagrama de caso de uso para la configuración del sistema.

 46

Caso de uso para la configuración de la empresa.

El caso de uso para el submódulo de la configuración de la empresa es

ilustrado en la Figura 11, los detalles de este caso se especifican en la Tabla
6 y se modela el proceso en el diagrama de actividades de la Figura 12.

Figura 11. Caso de uso para la configuración de la empresa.

Tabla 6
Especificación del caso de uso para la configuración de la empresa

Caso de Uso Configuración de la empresa

Actor Administrador del sistema

Objetivo Gestionar la información de la empresa del sistema

Requerimientos RF-001

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder a la

Pre-condiciones
configuración del sistema

El actor podrá consultar la información de la empresa además de modificar su

Descripción
información de operación y fiscal

Post-condiciones Modificación de la información de la empresa

 47

Figura 12. Diagrama de actividades para la configuración de la empresa.

 48

En la Figura 13, se ilustra el prototipo de interfaz diseñado para la configuración

de la empresa, el cual usa como base el caso de uso en la Figura 11 y las actividades
descritas en la Figura 12.

Figura 13. Prototipo de interfaz gráfica para la configuración de la empresa

 49

Caso de uso para la configuración de los métodos de pago.

El caso de uso para el submódulo de la configuración de los métodos

de pago es ilustrado en la Figura 14, los detalles de este caso se especifican
en la Tabla 7 y se modela el proceso en el diagrama de actividades de la Figura
15.

Figura 14. Caso de uso para la configuración de los métodos de pago.

Tabla 7
Especificación del caso de uso para la configuración de los métodos de pago

Caso de Uso Configuración de los métodos de pago

Actor Administrador del sistema

Objetivo Gestionar los métodos de pago del sistema

Requerimientos RF-002

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder a la

Pre-condiciones
configuración del sistema

El actor podrá consultar los métodos de pago existentes, ver la información de

Descripción cada uno de ellos, buscar entre estos por un dato en específico, ingresar nuevos
métodos, además de modificar y eliminar los ya existentes

Post-condiciones Modificación de los métodos de pago

 50

Figura 15. Diagrama de actividades para la configuración de los métodos de pago.

 51

En la Figura 16, se ilustra el prototipo de interfaz diseñado para la configuración

de los métodos de pago, el cual usa como base el caso de uso en la Figura 14 y las
actividades descritas en la Figura 15.

Figura 16. Prototipo de interfaz gráfica para la configuración de los métodos de pago.
 52

Caso de uso para la configuración de las unidades de medición.

El caso de uso para el submódulo de la configuración de las unidades

de medición es ilustrado en la Figura 17, los detalles de este caso se
especifican en la Tabla 8 y se modela el proceso en el diagrama de actividades
de la Figura 18.

Figura 17. Caso de uso para la configuración de las unidades de medición.

Tabla 8
Especificación del caso de uso para la configuración de las unidades de medición

Caso de Uso Configuración de las unidades de medición

Actor Administrador del sistema

Objetivo Gestionar las unidades de medición del sistema

Requerimientos RF-003

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder a la

Pre-condiciones
configuración del sistema

El actor podrá consultar las unidades de medición existentes, ver la información

Descripción de cada una de ellas, buscar entre estas por un dato en específico, ingresar
nuevas unidades de medición, además de modificar y eliminar las ya existentes

Post-condiciones Modificación de las unidades de medición

 53

Figura 18. Diagrama de actividades para la configuración de las unidades.

 54

En la Figura 19, se ilustra el prototipo de interfaz diseñado para la configuración

de las unidades, el cual usa como base el caso de uso en la Figura 17 y las actividades
descritas en la Figura 18.

Figura 19. Prototipo de interfaz gráfica para la configuración de las unidades .

 55

Caso de uso para la configuración de los impuestos.

El caso de uso para el submódulo de la configuración de los impuestos

es ilustrado en la Figura 20, los detalles de este caso se especifican en la Tabla
9 y se modela el proceso en el diagrama de actividades de la Figura 21.

Figura 20. Caso de uso para la configuración de los impuestos.

Tabla 9
Especificación del caso de uso para la configuración de los impuestos

Caso de Uso Configuración de los impuestos

Actor Administrador del sistema

Objetivo Gestionar los impuestos del sistema

Requerimientos RF-004

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder a la

Pre-condiciones
configuración del sistema

El actor podrá consultar los impuestos existentes, ver la información de cada

Descripción uno de ellos, buscar entre estos por un dato en específico, ingresar nuevos
impuestos, además de modificar y eliminar los ya existentes

Post-condiciones Modificación de los impuestos

 56

Figura 21. Diagrama de actividades para la configuración de los impuestos.

 57

En la Figura 22, se ilustra el prototipo de interfaz diseñado para la configuración

de los impuestos, el cual usa como base el caso de uso en la Figura 20 y las actividades
descritas en la Figura 21.

Figura 22. Prototipo de interfaz gráfica para la configuración de los impuestos.

 58

Caso de uso para el catálogo de productos.

El caso de uso para el módulo del catálogo de productos es ilustrado

en la Figura 23, los detalles de este caso se especifican en la Tabla 10 y se
modela el proceso en el diagrama de actividades de la Figura 24.

Figura 23. Caso de uso para el catálogo de productos.

Tabla 10
Especificación del caso de uso para el catálogo de productos.

Caso de Uso Catálogo de productos

Actor Administrador del sistema

Objetivo Gestionar las definiciones de los productos

Requerimientos RF-005

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder al

Pre-condiciones
catálogo de productos

El actor podrá consultar los productos existentes, ver la información de cada

Descripción uno de ellos, buscar entre estos por un dato en específico, ingresar nuevos
productos además de modificar y eliminar los ya existentes.

Post-condiciones Modificación de los productos en el catálogo

 59

Figura 24. Diagrama de actividades para el catálogo de productos.

 60

En la Figura 25, se ilustran los prototipos y flujos de interfaz diseñados para el

catálogo de productos, los cuales usan como base el caso de uso en la Figura 23 y las
actividades descritas en la Figura 24.

Figura 25. Prototipos y flujos de interfaz gráfica para el catálogo de productos.

 61

Caso de uso para el catálogo de clientes.

El caso de uso para el módulo del catálogo de clientes es ilustrado en la Figura

26, se especifican los detalles de este caso en la Tabla 11 y se modela el proceso en
el diagrama de actividades de la Figura 27.

Figura 26. Caso de uso para el catálogo de clientes.

Tabla 11
Especificación del caso de uso para el catálogo de clientes

Caso de Uso Catálogo de clientes

Actor Administrador del sistema

Objetivo Gestionar los clientes de la empresa

Requerimientos RF-006

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder al

Pre-condiciones
catálogo de clientes

El actor podrá consultar los clientes existentes, ver la información de cada uno
Descripción de ellos, buscar entre estos por un dato en específico, ingresar nuevos clientes
además de modificar y eliminar los ya existentes.

Post-condiciones Modificación de los clientes en el catálogo

 62

Figura 27. Diagrama de actividades para el catálogo de clientes.

 63

En la Figura 28, se ilustra el prototipo de interfaz diseñado para el catálogo de

clientes, el cual usa como base el caso de uso en la Figura 26 y las actividades descritas
en la Figura 27.

Figura 28. Prototipo de interfaz gráfica para el catálogo de clientes.

 64

Caso de uso para el catálogo de proveedores.

El caso de uso para el módulo del catálogo de proveedores es ilustrado en la

Figura 29, se especifican los detalles de este caso en la Tabla 12 y se modela el
proceso en el diagrama de actividades de la Figura 30.

Figura 29. Caso de uso para el catálogo de proveedores.

Tabla 12
Especificación del caso de uso para el catálogo de proveedores

Caso de Uso Catálogo de proveedores

Actor Administrador del sistema

Objetivo Gestionar los proveedores de la empresa

Requerimientos RF-007

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder al

Pre-condiciones
catálogo de proveedores

El actor podrá consultar los proveedores existentes, ver la información de cada

Descripción uno de ellos, buscar entre estos por un dato en específico, ingresar nuevos
proveedores además de modificar y eliminar los ya existentes.

Post-condiciones Modificación de los proveedores en el catálogo

 65

Figura 30. Diagrama de actividades para el catálogo de proveedores.

 66

En la Figura 31, se ilustra el prototipo de interfaz diseñado para el catálogo de

proveedores, el cual usa como base el caso de uso en la Figura 29 y las actividades
descritas en la Figura 30.

Figura 31. Prototipo de interfaz gráfica para el catálogo de proveedores.

 67

Caso de uso para la gestión de almacenes.

El caso de uso para el módulo almacenes es ilustrado en la Figura 32, se

especifican los detalles de este caso en la Tabla 13 y se modela el proceso en el
diagrama de actividades de la Figura 33.

Figura 32. Caso de uso para la gestión de almacenes.

Tabla 13
Especificación del caso de uso para la gestión de almacenes

Caso de Uso Gestión de almacenes

Actor Administrador del sistema

Objetivo Gestionar los almacenes de la empresa

Requerimientos RF-010, RF-011

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder a

Pre-condiciones
almacenes

El actor podrá consultar los almacenes existentes, ver la información de cada

uno de ellos, buscar entre estos por un dato en específico, ingresar nuevos
Descripción
almacenes además de modificar y eliminar los ya existentes. Se pueden recibir
órdenes de compra en un almacén, y consultar las órdenes recibidas.

Post-condiciones Modificación de los almacenes de la empresa

 68

Figura 33. Diagrama de actividades para la gestión de almacenes.

 69

En la Figura 34, se ilustran los prototipos y flujos de interfaz diseñados para la

gestión de almacenes, los cuales usan como base el caso de uso en la Figura 32 y las
actividades descritas en la Figura 33.

Figura 34. Prototipos y flujo de interfaces para la gestión de almacenes.

 70

Caso de uso para la gestión de órdenes de compra.

El caso de uso para el módulo órdenes de compra es ilustrado en la Figura 35,

se especifican los detalles de este caso en la Tabla 14 y se modela el proceso en el
diagrama de actividades de la Figura 36.

Figura 35. Caso de uso para la gestión de órdenes de compra.

Tabla 14
Especificación del caso de uso para la gestión de órdenes de compra

Caso de Uso Gestión de órdenes de compra

Actor Administrador del sistema

Objetivo Gestionar las órdenes de compra de la empresa en el sistema

Requerimientos RF-008, RF-012, RF-013

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder a

Pre-condiciones
órdenes de compra

El actor podrá consultar las órdenes de compra existentes, ver la información de

cada una de ellas, buscar entre estas por un dato en específico, importar nuevas
Descripción
órdenes desde un archivo además de anular o ver los detalles de las ya
existentes.

Post-condiciones Modificación de las órdenes de compra de la empresa en el sistema

 71

Figura 36. Diagrama de actividades para la gestión de órdenes de compra.

La acción importar órdenes espera que el usuario proporcione un archivo Excel

de extensión “.xls” con los datos de las órdenes de compra registradas en el sistema
administrativo de la empresa, estos datos deben de estar en el formato visible en el
Apéndice C.
 72

En la Figura 37, se ilustran los prototipos y flujos de interfaz diseñados para la

gestión de órdenes de compra, los cuales usan como base el caso de uso en la Figura
35 y las actividades descritas en la Figura 36.

Figura 37. Prototipos y flujo de interfaces gráficas para la gestión de órdenes de compra.
 73

Caso de uso para la gestión de inventario.

El caso de uso para el módulo inventario es ilustrado en la Figura 38, se

especifican los detalles de este caso en la Tabla 15 y se modela el proceso en el
diagrama de actividades de la Figura 39.

Figura 38. Caso de uso para la gestión de inventario.

Tabla 15
Especificación del caso de uso para la gestión de inventario

Caso de Uso Gestión de inventario

Actor Administrador del sistema

Objetivo Gestionar el inventario de la empresa en el sistema

Requerimientos RF-009

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder a

Pre-condiciones
inventario

El actor podrá consultar los registros de inventario existentes, ver la información

Descripción de cada uno de estos, buscar entre estos por un dato en específico y modificar
la información de venta de un producto en un inventario.

Post-condiciones Modificación del inventario de la empresa en el sistema

 74

Figura 39. Diagrama de actividades para la gestión de inventario.

 75

En la Figura 40, se ilustran los prototipos y flujos de interfaz diseñados para la

gestión de inventario, los cuales usan como base el caso de uso en la Figura 38 y las
actividades descritas en la Figura 39.

Figura 40. Prototipos y flujo de interfaces gráficas para la gestión de inventario.

 76

Caso de uso para la gestión de ventas.

El caso de uso para el módulo ventas es ilustrado en la Figura 41, se

especifican los detalles de este caso en la Tabla 16 y se modela el proceso en el
diagrama de actividades de la Figura 42.

Figura 41. Caso de uso para la gestión de ventas.

 77

Tabla 16
Especificación del caso de uso para la gestión de ventas

Caso de Uso Gestión de ventas

Actor Administrador del sistema o usuario vendedor

Objetivo Gestionar las ventas del sistema

Requerimientos RF-014, RF-015, RF-016, RF-017, RF-018, RF-019, RF-020

Iniciar sesión en el sistema y ser un usuario de tipo administrador, acceder a

Pre-condiciones
inventario

Permite gestionar el proceso de venta, donde el actor, selecciona un cliente al

cual se le generará una factura, selecciona los productos en inventario y las

Descripción cantidades de estos que se van a vender, calcula los montos de la operación,
gestionar los pagos realizados por el cliente a través de los diferentes métodos
de pago y marcar la finalización del proceso emitiendo la factura al cliente

Post-condiciones Crea una factura y demás elementos con los datos de la venta
 78

Figura 42. Diagrama de actividades para la gestión de ventas

 79

Para realizar un pago mediante criptomonedas, se diseñan las actividades de

la Figura 43, las cuales describen el proceso de pago con este método y las
interacciones que se dan entre el usuario, el sistema punto de venta y el sistema
externo Kapturela.

Figura 43. Diagrama de actividades para pagos en criptomonedas mediante el sistema Kapturela.

En las siguientes figuras, se ilustran los prototipos y flujos de interfaz diseñados

para la gestión de ventas, los cuales usan como base el caso de uso en la Figura 41 y
las actividades descritas en la Figura 42 y 43.
 80

Figura 44. Prototipo de interfaz gráfica para el submódulo clientes dentro de la gestión de ventas.

Figura 45. Prototipos y flujo de interfaces gráficas para el submódulo inventarios dentro de la gestión
de ventas.
 81

Figura 46. Prototipos y flujo de interfaces gráficas para el submódulo productos seleccionados dentro
de la gestión de ventas.
 82

Diseño de pruebas.

En la Tabla 17 se detalla el plan de pruebas diseñado que dé cabida a las pruebas

unitarias y de integración a las que el sistema será sometido luego de su construcción,
con la finalidad de verificar las funcionalidades de los módulos y validar el
cumplimiento de los requerimientos definidos.

Tabla 17
Plan de ejecución de casos de prueba

Ítem Módulo y Actividades

1 Configuración de la empresa

1.1 Consultar la información de la empresa

1.2 Modificar la información de la empresa

2 Configuración de los métodos de pago

2.1 – 2.4 C.R.U.D de métodos de pago

2.5 Buscar método

3 Configuración de las unidades de medición

3.1 – 3.4 C.R.U.D de unidades de medición

3.5 Buscar unidad

4 Configuración de los impuestos

4.1 – 4.4 C.R.U.D de impuestos

4.5 Buscar impuesto

5 Catálogo de Productos

5.1 – 5.4 C.R.U.D de productos

5.5 Buscar producto

6 Catálogo de Clientes

6.1 – 6.4 C.R.U.D de clientes

6.5 Buscar cliente

7 Catálogo de Proveedores

7.1 – 7.4 C.R.U.D de proveedores

 83

Continuación Tabla 17
Plan de ejecución de casos de prueba

Ítem Módulo y Actividades

7.5 Buscar proveedor

8 Almacenes

8.1 – 8.4 C.R.U.D de almacenes

8.5 Buscar almacén

8.6 Recibir órdenes de compra en almacén

8.7 Ver órdenes de compra recibidas

9 Órdenes de compra

9.1 Consultar órdenes de compra

9.2 Importar órdenes de compra

9.3 Ver detalles de orden de compra

9.4 Anular orden de compra

9.5 Buscar orden de compra

10 Inventario

10.1 Consultar inventarios

10.2 Modificar inventario

10.3 Buscar inventario

11 Ventas

11.1 Clientes

11.1.1 Consultar Clientes

11.1.2 Buscar cliente

11.1.3 Crear cliente

11.1.4 Seleccionar cliente

11.2 Inventarios

11.2.1 Consultar inventarios

11.2.2 Seleccionar inventario

 84

Continuación Tabla 17
Plan de ejecución de casos de prueba

Ítem Módulo y Actividades

11.3 Productos Seleccionados

11.3.1 Consultar productos

11.3.2 Editar cantidad

11.3.3 Eliminar producto

11.3.4 Calcular y mostrar total, artículos e impuestos

11.4 Pagar

11.4.1 Consultar métodos de pago

11.4.2 Ingresar pago normal

11.4.3 Ingresar pago en criptomonedas

11.4.3.1 Consultar criptomonedas aceptadas por Kapturela

11.4.3.2 Seleccionar criptomoneda y generar código QR por Kapturela

11.4.4 Eliminar pago ingresado

11.4.5 Calcular faltante por pagar

11.4.6 Emitir Factura

12 Reportes

12.1 Generar el reporte de ventas diarias

12.2 Generar el reporte de ventas mensuales

12.3 Generar el histórico de inventario

13 Control de acceso

13.1-13.4 C.R.U.D de usuarios

13.5 Buscar usuario

.1

1313.
 85

Diseño arquitectónico.

La arquitectura de la aplicación viene dada por el marco de trabajo

Spring, el cual brinda estructura, patrones y estándares que hacen que el
desarrollo sea rápido, modular y de fácil mantenimiento, cualidades buscadas
en este proyecto, debido a que el sistema abarca requerimientos generales de un
punto de venta y pueden surgir cambios posteriores en los procesos y datos
dependiendo del tipo de producto o servicio en venta, además el surgimiento de
nuevos reglamentos puede involucrar cambios adicionales.

Marco de trabajo Spring - módulo Spring Boot.

Spring es un marco de trabajo de código abierto para el desarrollo de

aplicaciones Java o sobre las máquinas virtuales de Java. Tiene una estructura
modular, el cual contiene diferentes módulos donde cada uno brinda solución
a diferentes problemas, web, de escritorio, microservicios, entre otros y una
serie de patrones y herramientas las cuales pueden ser aplicadas en las
distintas capas de la aplicación, su flujo de desarrollo consiste en tres fases tal
como se ilustra en la Figura 47.

Figura 47. Flujo de desarrollo con Spring Framework.

Spring Boot es un módulo del marco de trabajo Spring, tiene el mismo

flujo de desarrollo que el Framework Spring, y busca simplificar las fases 1 y
3, de esta manera los usuarios se centran en la segunda fase de desarrollo de
la aplicación, esto se hace mediante un asistente, el cual genera un proyecto
partiendo del tipo de aplicación que deseas, el asistente identifica las
 86

dependencias necesarias, configura el framework y genera una estructura de

archivos como se puede apreciar en la Figura 48.

Figura 48. Estructura de proyecto Spring-Maven.

ORM Hibernate.

Hibernate es una herramienta que facilita el mapeo de objeto-relacional para la

plataforma Java. Se utiliza para manipular la base de datos mediante objetos, lo cual
disminuye la complejita y abstrae la capa de persistencia de datos.

Patrones de arquitectura.

MVC.

Se establece el patrón MVC el cual es guiado por la interacción con el usuario;

haciendo uso de 3 componentes (Modelos, Vistas y Controladores), este patrón busca
separar la lógica del negocio de su representación y los datos.
 87

Servicio.

Un servicio se usa para definir operaciones a nivel de negocio, esto abstrae al

controlador del acceso a datos y otorga menos acoplamiento entre las capas.

Patrones de diseño.

Repositorio.

Un repositorio es una abstracción, este separa la lógica de acceso a datos y la

asigna a las entidades en la lógica de negocios, esta capa de repositorios desvincula a
la capa superior de la implementación del modelo, lo cual hace posible el cambió en la
forma de acceder a los datos.

Arquitectura resultada.

Se elabora la arquitectura del sistema ilustrada en la Figura 49, la cual es

resultado de la aplicación de los distintos patrones y buenas prácticas del marco de
trabajo Spring integrado con Hibernate. Debido a que predominan los tres componentes
del patrón MVC, la arquitectura de software del sistema propuesto se considera MVC.

Figura 49. Arquitectura del sistema propuesto.

 88

Construcción del Sistema Punto de Venta de Acuerdo al Diseño Planteado

Completada la fase de definición de requerimientos y la fase de diseño,

comienza la fase de construcción donde se procedió en primer lugar a definir las
herramientas de desarrollo utilizadas, luego a realizar la estructuración de las carpetas
del sistema propuesto y en último lugar con la construcción de los componentes del
sistema mediante procesos de codificación siguiendo la arquitectura de la solución, y
los estándares establecidos por la empresa Pinttosoft.

Herramientas de desarrollo.

Se utiliza el lenguaje de programación orientado a objetos Java para la

codificación del sistema en conjunto con el framework Spring Boot integrado con la
familia de productos JavaFX, debido a sus ventajas visuales y de core en la
construcción de aplicaciones de escritorio multiplataforma, también por su integración
natural con el ORM Hibernate permitiendo modelados de bases de datos relacionales,
además de la facilidad de acceso a documentos de Microsoft en específico Microsoft
Excel mediante la Liberia Apache POI.

Como entorno de desarrollo se utilizó el entorno de desarrollo integrado IntelliJ

IDEA en su versión del 2018.3.6 el cual tiene ventajas de productividad en proyectos
Java con el framework Spring, Hibernate y el gestor de dependencias Maven, este
genera mediante el creador de Spring Boot este tipo de proyectos, descarga las
dependencias, también se encarga de compilar y ejecuta este tipo de proyectos, además
permite la integración de la herramienta Scene Builder de la empresa Gluon para el
manejo de interfaces visuales con JavaFX mediante interacciones de arrastrar y soltar
(drag and drop).

El desarrollo de la base de datos fue llevado a cabo en el sistema gestor de bases

de datos PostgresSQL, el cual es estándar de la empresa en los modelados de
información relacionales.
 89

Estructura de carpetas del sistema.

Se identifican las carpetas del sistema utilizando la estructura de proyecto

Spring-Maven ilustrada en la Figura 48, y la arquitectura del sistema. En la Figura 50
se muestran los directorios en donde se organizan las clases que integran al sistema.

Figura 50. Estructura de carpetas del sistema propuesto.

 90

Construcción de los componentes del sistema.

Se codifican los componentes del sistema siguiendo la estructura modular

ilustrada en la Figura 9 y la arquitectura del sistema planteada en la Figura 49.

Cada módulo generalmente involucra una instancia en cada uno de los

componentes, por ejemplo: si se desea elaborar el módulo catálogo de clientes, será
necesario entonces codificar, el módulo, el repositorio, el controlador, el servicio y
la vista asociada a las funcionalidades y datos de un cliente. Cabe recalcar, que los
componentes son identificados por diversas anotaciones necesarias para que el
framework Spring identifique los componentes correctamente.

Ahora cada uno de los componentes fue codificado de la siguiente manera:

Modelo: Se crea una clase identificada por la anotación @Entity, lo cual dice
que es una entidad de Hibernate que será mapeada, esta clase corresponde a cada
relación en el modelo lógico de la base de datos, en otras palabras, una tabla,
identificando, sus atributos y métodos, generalmente solo son necesarios los getter y
setter. Sobre esta clase se utilizan anotaciones del ORM Hibernate que mapean el
objeto a una base de datos, cada anotación identifica un elemento, por ejemplo:
@Column para identificar a un atributo como una columna en la tabla de base de
datos, entre otros que sirven para identificar características o relaciones entre
entidades (tablas).

Repositorio: Se crea una clase repositorio por modelo identificada por la

anotación @Repository, esta clase es una interfaz que contiene los métodos que son
traducidos a operaciones sobre la base de datos. El framework Spring permite el uso
de este patrón de diseño, y proporciona facilidades como la clase CrudRepository la
cual, si es extendida, proporciona los métodos básicos de crear, consultar, editar y
eliminar una entidad, además es posible describir el resultado de la operación en base
de datos, solo nombrando los métodos en lenguaje de alto nivel, por ejemplo:
findBy(atributo), findAllBy(atributo), entre muchas más combinaciones. En la
 91

Figura 51 se ilustra como ejemplo el repositorio de las órdenes de compra del sistema.

Figura 51. Ejemplo de componente repositorio.

Servicio: Se crea una clase servicio identificada por la anotación @Service,

la cual corresponde a funcionalidades de negocio en respuesta a los eventos del
usuario gestionados por el controlador, se comunica con la capa de datos mediante
uno o más repositorios y da respuesta al controlador sobre su petición, es una buena
práctica manejar las validaciones de las entidades en esta clase, así como las
transacciones, Spring gestiona las transacciones de un método con la anotación
@Transactional. En la Figura 52 se ilustra como ejemplo el servicio de los almacenes
del sistema.
 92

Figura 52. Ejemplo de componente servicio.

Controlador: Se crea una clase controlador identificada por la anotación

@Component, la cual corresponde a la compilación de métodos que generan la vista,
rellenan la información de esta, además manejan los eventos que el usuario detona a
través de sus acciones en la vista y envía a esta información a sus solicitudes. Un
controlador, utiliza los diferentes servicios creados para dar respuesta a las
funcionalidades solicitadas por el usuario abstrayéndose de la capa de datos.

Vistas: Las interfaces graficas se codifican en un lenguaje de etiquetas

parecido a XML, se escriben en archivos FXML los cuales utilizan componentes
predefinidos en la Liberia JavaFX, por ejemplo <Button></Button>, cada uno de
estos componentes puede ser identificado por un atributo fx:id y mediante la
anotación @FXML pueden ser instanciados por sus identificadores dentro del
controlador, por lo tanto, ser capaz de modificar su aspecto visual, información o
 93

gestionar las acciones sobre este. Las diferentes interfaces graficas construidas
durante este apartado, se encuentran en el Apéndice D.

Pruebas del sistema.

Por cada módulo completamente construido se realizan las pruebas de sus

funcionalidades, ejecutando el plan de pruebas diseñado, para lo cual se hace uso de
casos de prueba que permitan comprobar el correcto funcionamiento de una
funcionalidad específica, o evidenciar la ocurrencia de un error y pasar a la corrección
del mismo, ejemplos de estos casos de prueba se pueden observar en el Apéndice E,
en donde en una tabla, se establece el control del flujo y las condiciones por las que
la funcionalidad fue evaluada. Finalizar la ejecución del plan de pruebas, valida que
los requerimientos sean cumplidos por el sistema punto de venta desarrollado.

Documentación del Sistema de Punto de Venta Desarrollado

Una vez finalizada la construcción del sistema, se compilaron los resultados

obtenidos en las fases previas, información con la cual se procedió a la confección
del manual de usuario anexado en el Apéndice F, donde se especifica en lenguaje
simple, una guía que puede ser entendida por cualquier usuario, brindando
información sobre las funciones que el sistema cumple, las instrucciones sobre su uso
y solución a posibles problemas durante el uso del sistema, además, se confeccionó
el manual técnico del sistema en un lenguaje que implica cierto grado de
conocimientos en el área, donde se explican aspectos del sistema, para el posterior
mantenimiento por parte de otros desarrolladores TI de la empresa Pinttosoft C.A.,
entre los elementos presentes en este manual se encuentran los resultados de la fase
de diseño en concreto el diseño base de datos, su descripción y diagramas, la
explicación detallada de las soluciones desarrolladas, así como detalles de
implementación, de software y hardware, este manual técnico puede ser observado
en el Apéndice G.
 94

CAPÍTULO V

Conclusiones y Recomendaciones

Conclusiones

El presente proyecto tuvo como objetivo el desarrollo de un sistema de punto

de venta con soporte al procesamiento de pagos en criptomonedas y la integración en
los procesos administrativos de la empresa Pinttosoft C.A.

● Del estudio de un sistema de punto de venta, se identificaron los módulos y

las funcionalidades generales, lo cual permite una visión general y modular
de los sistemas de este tipo, además, se identifican en el ámbito legal, los
conflictos que existen actualmente en la República Bolivariana de Venezuela
en la implementación de las criptomonedas como método de cobro y se
plantea cómo causa principal de estos conflictos, la inexistente descripción de
los procesos de cálculo y cobro tributario de las operaciones de este tipo.

● Se realizó la ingeniería de requerimientos sobre el estudio de un sistema de

punto de venta, logrando así definir y descomponer las necesidades del
sistema tomando en cuenta la integración de criptomonedas como método de
cobro, clasificando los resultados en requerimientos funcionales, no
funcionales y de almacenamiento, estos requerimientos guiaran el desarrollo
en las etapas posteriores, buscando siempre el cumplimiento de estos por
parte del sistema resultado.

● El diseño del sistema describe las funcionalidades a través de una serie de

diagramas que detallen simple y puntualmente los aspectos del sistema a
desarrollar, donde se pueden evidenciar los actores y su participación en los
procesos así como el flujo que se sigue para cumplir con una funcionalidad,
también se presentan los modelos y estructuras del mismo, que permiten
mediante un lenguaje simple a usuarios y desarrolladores, entender
modularmente el sistema, segmentando funcionalidades, información y pasos
 95

para que se cumpla con los requerimientos definidos.

● La construcción del sistema punto de venta es guiado por los diseños

anteriores, en donde se plantea un desarrollo modular con componentes,
fáciles de mantener y poco acoplados, además de ser una aplicación
multiplataforma que puede ejecutarse en cualquier sistema operativo, esto
puede ser así debido a que es desarrollada en el lenguaje de programación
Java, haciendo uso de frameworks, patrones de programación y diseño que
brinden abstracciones entre capas y componentes. El sistema es elaborado de
esta manera, debido a que la solución es general y el punto de venta no está
orientado a un sector en específico y la reglamentación de sistemas de este
tipo que integren criptomonedas en sus métodos de cobro, no está definida,
por esto y demás, el sistema debe está diseñado para tener una alta tolerancia
a cambios que puedan darse en un futuro.

● Dentro de la construcción del sistema, se ejecuta el plan de pruebas diseñado

para validar modularmente el cumplimiento de los requerimientos,
verificando que las funcionalidades den los resultados deseados y sus
módulos se integren entre ellos.

Recomendaciones

Para futuros trabajos de investigación y mejoras en el modelo propuesto es

recomendable:

• Desarrollar y migrar en completitud el módulo reposición de inventario, de

manera de automatizar dentro del sistema la capacidad de emitir órdenes de
compra sobre productos faltantes a los proveedores.

• Implementar al sistema, procesos completos de control de acceso a través

de grupos y permisos que engloben la funcionalidad disponible mediante el
correcto manejo de permisología dentro del sistema.
 96

• Para las empresas que quieran implementar criptomonedas como método

de pago, determinar una metodología a seguir o un proceso automatizado
que garantice que la información es almacenada correctamente, es de
calidad y no supone una carga adicional para el proceso donde se está
implementando.

• Para la empresa Pinttosoft C.A, poner en marcha una estrategia de

implementación, que permita crear un ambiente de prueba para el sistema
dentro de sus comercios aliados, de manera que los usuarios empiecen a
formar parte de la nueva era financiera, además de continuar sus esfuerzos
en el desarrollo de la plataforma Kapturela, en función de seguir integrando
de la mejor manera un estándar en el adecuado uso y registro de
criptomonedas en las operaciones cotidianas de las empresas y comercios.
 97

REFERENCIAS BIBLIOGRÁFICAS

Andreu, R., Ricart J. E. y Valor, J. (1991): Estrategia y Sistemas de Información.

España: Mc Graw-Hill.

Arias, F. (2012). El proyecto de investigación. Introducción a la metodología

científica. Caracas: Episteme.

Bahit, E. (2014). POO y MVC en PHP: El paradigma de programación orientada a

objetos en PHP y el patrón de arquitectura de software MVC. Recuperado de:
https://www1.herrera.unt.edu.ar/biblcet/wp-
content/uploads/2014/12/eugeniabahitpooymvcenphp.pdf

Barrera M., (1995). Líneas de investigación en metodología de la investigación

holística. Venezuela: Magisterio.

Becerra, F., Hidalgo, E., Pérez, J. (s.f.). Object Relational Mapping. Recuperado de:
https://www.academia.edu/11977539/Object_Relational_Mapping

Castro, L (2010). Metodología de la Investigación. Venezuela: Universidad Central de

Venezuela.

EquiSoft (2017). La cadena de bloques: Una tecnología disruptiva con el poder de

revolucionar el sector financiero. Recuperado de: https://www.equisoft.com/wp-
content/uploads/2017/09/White-paper-Blockchain-ESP-1.pdf

Galindo J., Camps, J. (2008). Diseño e implementación de un marco de trabajo

(framework) de presentación para aplicaciones JEE. Recuperado de:
http://openaccess.uoc.edu/webapps/o2/bitstream/10609/876/1/00765tfc.pdf

PostgreSQL (1996). About PostgreSQL. Recuperado de

https://www.postgresql.org/about/
 98

Pressman, R. (2010). Ingeniería del Software: Un Enfoque Práctico. México: Mc

Graw-Hill.

Ramos, M., Ramos, A. y Montero, F. (2006). Sistemas gestores de bases de datos.

España: Mc Graw-Hill

Retamal, C., Roig, J. y Muñoz, J. (2017). La blockchain: Fundamentos, aplicaciones y

relación con otras tecnologías disruptivas. Universidad Politécnica de Catalunya.
Recuperado de:
https://www.mincotur.gob.es/Publicaciones/Publicacionesperiodicas/EconomiaIndust
rial/RevistaEconomiaIndustrial/405/DOLADER,%20BEL%20Y%20MU%C3%91O
Z.pdf

Silberschatz, A., Korth, H. y Sudarshan, S. (2006). Fundamentos de bases de datos.

España: Mc Graw-Hill.

Sorensen, E. (2019). Como funciona un sistema PDV moderno: los fundamentos.

Mobile Transaction. Recuperado de: https://es.mobiletransaction.org/punto-de-
venta-fundamentos/

Stamp, M. (2011). Information Security Principles and Practice. USA: Wiley.

Vergara, M. (2017). Retos para las autoridades reguladoras y de control frente a

la utilización del bitcoin como medio de pago electrónico. Recuperado de:
https://www.repositorio.uasb.edu.ec/bitstream/10644/5513/6/T2197-MDFBS-
Vergara-Retos.pdf

Zorilla, S. (1993). Introducción a la metodología de la investigación. México:

Aguilar Leon y Cal, Editores.
 99

APÉNDICES
 100

Apéndice A: Gaceta Oficial Numero 6420 de la República Bolivariana de Venezuela -

Decreto Nº 3.719

Figura A. 1. Gaceta Oficial Numero 6420 de la República Bolivariana de Venezuela

Decreto Nº 3.719
 101

Apéndice B: Formato de Factura del Sistema

Figura B. 1. Formato de Factura generada por el sistema

 102

Apéndice C: Formato de Archivo Excel para Importar Órdenes de Compra

Figura C. 1. Archivo Excel en proceso de importe de órdenes de compra

 103

Apéndice D: Interfaces Graficas del Sistema Punto de Venta

Figura D. 1. Pantalla Inicio de sesión

Figura D. 2. Pantalla ventas – selección cliente

 104

Figura D. 3. Pantalla ventas – inventarios disponibles

Figura D. 4. Pantalla ventas – productos seleccionados

 105

Figura D. 5. Pantalla inventario

Figura D. 6. Pantalla productos

 106

Figura D. 7. Pantalla crear-editar producto

Figura D. 8. Pantalla órdenes de compra

 107

Figura D. 9. Pantalla ver detalles de órdenes de compra

Figura D. 10. Pantalla recepciones de órdenes de compra

 108

Figura D. 11. Pantalla almacenes

Figura D. 12. Pantalla clientes

 109

Figura D. 13. Pantalla proveedores

Figura D. 14. Pantalla configuración de empresa

 110

Apéndice E: Ejemplos de Casos de Prueba del Sistema

111
112
113
114
115
116
117
118
 119

Apéndice F: Manual de Usuario del Sistema

SISTEMA DE PUNTO DE VENTA

CON SOPORTE AL PROCESAMIENTO DE PAGOS
EN CRIPTOMONEDAS

MANUAL DE USUARIO
1. Objetivos de la Aplicación

Permitir la reposición de inventario importando las órdenes de compra existentes en el

sistema administrativo de la empresa, gestionar los procesos de cobro y facturación en la
venta de productos realizada a un cliente, establecer un protocolo de comunicación con la
plataforma Kapturela para aceptar criptomonedas como método de pago, así como los
reportes derivados de estas operaciones, además permitir la configuración del sistema para
trabajar con la información de la empresa y proporcionar seguridad mediante procesos de
control de acceso.

Módulo Descripción

Catálogo Gestionar los productos para que posteriormente puedan ser agregados
de Productos al inventario mediante una compra de existencias a un proveedor.

Catálogo Gestionar a los clientes de la empresa que buscan adquirir productos y

de Clientes servicios de esta.

Catálogo Gestionar los proveedores, registrando la información de estos

vendedores a los cuales la empresa realiza compras de productos para
de Proveedores incrementar su inventario.

Gestionar la información de los espacios físicos en los cuales los bienes

Almacenes
en inventario se encuentran almacenados.

Gestionar las órdenes de compras que se le hacen a los proveedores para

Compras lograr el incremento de existencias de un producto del catálogo, y de
esta manera adicionarlo en inventario para su posterior venta.

Inventario Gestionar la información de venta y existencias de los productos.

Permite realizar la venta de productos a un cliente, así como llevar a

Venta
cabo los procesos de cobro, facturación.

Permite generar con motivo administrativo, los reportes e información

Reportes
necesaria para la empresa.

Control de acceso Gestiona el acceso del sistema, administrando los usuarios.

Permite gestionar la información de la empresa, configurar los

Configuración
impuestos, métodos de pago y unidades a utilizar en el sistema.
 121

2. Requerimientos del Sistema

Requerimiento Descripción

Sistema Manejador de Bases de Datos PostgreSQL 10

Entorno de Ejecución Java 11 (Oracle JRE 11 o OpenJDK 11)

Espacio en Disco 400 MB

RAM 512GB

3. Ingreso a la Aplicación

Seleccione el programa y ejecute el archivo .JAR correspondiente a la aplicación de punto

de venta.

Una vez activada la aplicación, se vera la siguiente pantalla de inicio de sesión, ingrese
el usuario y la contraseña proporcionados por el administrador del sistema y presione el botón
Iniciar Sesión.
 122

El usuario es autenticado e ingresa al sistema, mostrando la siguiente pantalla de Punto

de Venta, donde se evidencia al lado izquierdo, un menú de navegación el cual posee solo
dos opciones disponibles, las cuales son: Punto de Venta (POS o PDV) y Cerrar Sesión, esto
es debido a que el usuario Vendedor solo puede utilizar el sistema para realizar ventas del
inventario ya cargado.

4. Punto de Venta (POS o PDV)

Pestaña Cliente

La pestaña cliente permite seleccionar un cliente asociado a la operación o registrar un

nuevo cliente si el involucrado en la venta no lo está.

Seleccionar cliente

1. Dirigirse a la tabla con los clientes existentes

2. Hacer clic en el cliente asociado a la operación
3. Presionar el botón “Seleccionar”

Registrar nuevo cliente

1. Dirigirse al formulario al lado derecho de la pantalla

2. Ingresar los datos del cliente a registrar
3. Presionar el botón “Guardar”
 123

Pestaña Inventario

La pestaña inventario permite seleccionar el producto y las cantidades que el cliente

desea comprar.

Seleccionar producto

1. Dirigirse a la tabla con los productos existentes

2. Hacer clic en el producto deseado por el cliente
3. Presionar el botón “Seleccionar”
4. Ingresar la cantidad deseada del producto
5. Presionar el botón “Aceptar”
 124

Pestaña Productos Seleccionados

La pestaña productos seleccionados permite ver los productos asociados a la compra

del cliente, los lista, calcula el total a pagar y detalla el monto en impuestos y la cantidad de
artículos asociados a la operación.

Editar cantidad

1. Dirigirse a la tabla con los productos seleccionados

2. Hacer clic en el producto al cual se desea modificar la
cantidad
3. Presionar el botón “Editar Cantidad”
4. Ingresar la nueva cantidad deseada
5. Presionar el botón “Aceptar”

Eliminar producto

1. Dirigirse a la tabla con los productos seleccionados

2. Hacer clic en el producto el cual se desea eliminar
3. Presionar el botón “Eliminar”
4. Presionar el botón “Aceptar”

Si el cliente está de acuerdo con la cotización mostrada, se continua con el

proceso de cobro y emisión de la factura.
 125

Proceso de Cobro y Emisión de la Factura.

Luego de validar la cotización con el cliente, presione el botón “PAGAR”. Se

encontrará en una pantalla para ingresar los distintos pagos realizados por cliente para
cancelar el monto cotizado en su totalidad.

Presione el botón según el método de pago por el cual el cliente pagara, si este método
de pago es diferente a criptomonedas, se seguirá el siguiente procedimiento:

Cobro y Emisión (Métodos de pagos comunes)

1. Ingresar monto a pagar por este método

2. Ingresar descripción asociada a la operación
3. Presionar el botón “Aceptar”
4. Si el monto fue cancelado en su totalidad, puede emitir
la factura
5. Presionar el botón “Emitir Factura”

Si presiono el botón asociado a el pago en criptomonedas, deberá seguir el

siguiente procedimiento:

Cobro y Emisión (Criptomonedas)

1. Ingresar monto a pagar por este método

2. Ingresar descripción asociada a la operación
3. Presionar el botón “Aceptar”
4. Seleccionar de la lista, la criptomoneda por la cual el
usuario paga
5. Presionar el botón “Ok”
6. El usuario escanea el código QR generado
7. Si la transacción fue exitosa, se puede continuar.
8. Si falla, se intenta de nuevo por el mismo método o
con uno diferente.
9. Si el monto fue cancelado en su totalidad, puede emitir
la factura
10. Presionar el botón “Emitir Factura”
 126

Apéndice G: Manual Técnico del Sistema

SISTEMA DE PUNTO DE VENTA

CON SOPORTE AL PROCESAMIENTO DE PAGOS
EN CRIPTOMONEDAS

MANUAL TECNICO
 127

5. Objetivos de la Aplicación

Permitir la reposición de inventario importando las órdenes de compra existentes

en el sistema administrativo de la empresa, gestionar los procesos de cobro y
facturación en la venta de productos realizada a un cliente, establecer un protocolo de
comunicación con la plataforma Kapturela para aceptar criptomonedas como método
de pago, así como los reportes derivados de estas operaciones, además permitir la
configuración del sistema con la información de la empresa y proporcionar seguridad
mediante procesos de control de acceso.

Módulo Descripción

Catálogo Gestionar los productos para que posteriormente puedan ser agregados al
de Productos inventario mediante una compra de existencias a un proveedor.
Catálogo Gestionar a los clientes de la empresa que buscan adquirir productos y
de Clientes servicios de esta.
Gestionar los proveedores, registrando la información de estos vendedores a
Catálogo
los cuales la empresa realiza compras de productos para incrementar su
de Proveedores
inventario.
Gestionar la información de los espacios físicos en los cuales los bienes en
Almacenes
inventario se encuentran almacenados.
Gestionar las órdenes de compras que se le hacen a los proveedores para lograr
Compras el incremento de existencias de un producto del catálogo, y de esta manera
adicionarlo en inventario para su posterior venta.
Inventario Gestionar la información de venta y existencias de los productos.
Permite realizar la venta de productos a un cliente, así como llevar a cabo los
Venta
procesos de cobro, facturación.
Permite generar con motivo administrativo, los reportes e información
Reportes
necesaria para la empresa.
Control de acceso Gestiona el acceso del sistema, administrando los usuarios.
Permite gestionar la información de la empresa, configurar los impuestos,
Configuración
métodos de pago y unidades a utilizar en el sistema.
 128

6. Requerimientos del Sistema

Requerimiento Descripción

Sistema Manejador de Bases de

PostgreSQL 10
Datos

Entorno de Ejecución Java 11 (Oracle JDK 11 o OpenJDK 11)

Espacio en Disco 400 MB

RAM 513GB

7. Herramientas Utilizadas en el Desarrollo

Herramienta Descripción

PgAdmin 3 Herramienta de administración y desarrollo para PostgreSQL

Entorno de desarrollo y ejecución para la construcción de

Java 11
aplicaciones usando el lenguaje de programación Java.
(Oracle JDK 11
Incluye herramientas para desarrollar, depurar y monitorear
o OpenJDK 11)
aplicaciones en Java, como el compilador y las APIs de Java
Es un marco de trabajo que permite desarrollar aplicaciones
Spring
para Java

Spring Boot Permite la rápida configuración del marco de trabajo Spring

Es un conjunto de paquetes gráficos que permite desarrollar

Java FX
interfaces de aplicaciones multiplataforma

Proporciona una serie de herramientas para diseñar interfaces

Scene Builder
graficas con Java FX
 129

Entorno de desarrollo integrado para el desarrollo de

IntelliJ IDEA
aplicaciones Java

8. Configuración de la Base de Datos

Usando la herramienta pgAdmin 3, se debe crear un usuario con permisos para

manejar bases de datos y una base de datos. En la Figura 1 se observa cómo es la
interfaz de pgAdmin 3 y explicaremos como crear una base de datos.

Figura G.53. pgAdmin 3

Conexión al Servidor de Base de Datos

Se comienza conectándose al servidor local o algún otro de poseerlo, haciendo

clic en Servers, una vez dentro, se conecta a un servidor registrado con clic izquierdo
o se registra uno nuevo con clic derecho.

Creación de Base de Datos

Una vez conectado a un servidor, se sigue el siguiente procedimiento para crear

una base de datos.

Crear base de datos

4. Clic derecho en Databases y seleccionar la opción de nueva

base de datos
 130

5. Rellenar la información básica del formulario (Nombre de

la base de datos y el usuario dueño de esta)
6. Aceptar la creación

En el ejemplo de la Figura 1, se observa que se creó una base de datos posdb

en el servidor local para trabajar con el sistema, y el dueño de esta base de datos es el
usuario postgresql. Haciendo uso de esta información es necesario configurar la
aplicación, para que haga uso de nuestra base de datos.

5. Configuración de la Aplicación

Figura G.54. Aplicación - Archivo de Configuración.

El marco de trabajo Spring en su modulo Spring Boot, propone el uso del

archivo application.properties, para definir las distintas propiedades necesarias
para que nuestra aplicación use cierta funcionalidad, en concreto para el sistema
punto de venta es necesario definir:
 131

Propiedad Descripción

Define el sistema manejador de base de datos que se este usando,

DIALECT el dialecto depende de la versión del SGBD y las capacidades que
se requieran en el sistema
Define si iniciar el sistema debe actualizar las tablas si tiene
DDL-AUTO cambios, o volver a crearlas eliminando toda la información, entre
otras opciones
El servidor de base de datos genera un URL para entablar
URL
conexión con él, este debe ir aquí
El nombre de usuario con permisos en nuestra base de datos, se
USERNAME
usa para la conexión con la base de datos

PASSWORD La contraseña del usuario para la conexión con la base de datos

 132

9. Ingreso a la Aplicación

Seleccione el programa y ejecute el archivo .JAR correspondiente a la aplicación

de punto de venta.

Una vez activada la aplicación, se vera la siguiente pantalla de inicio de sesión,

ingrese el usuario y la contraseña proporcionados por el administrador del sistema y
presione el botón Iniciar Sesión.

El usuario es autenticado e ingresa al sistema, mostrando la siguiente pantalla de

Punto de Venta, donde se evidencia al lado izquierdo, un menú de navegación con las
distintas funcionalidades del sistema.
 133

10. Punto de Venta (POS o PDV)

Pestaña Cliente

La pestaña cliente permite seleccionar un cliente asociado a la operación o registrar

un nuevo cliente si el involucrado en la venta no lo está.

Seleccionar cliente

1. Dirigirse a la tabla con los clientes existentes

2. Hacer clic en el cliente asociado a la operación
3. Presionar el botón “Seleccionar”

Registrar nuevo cliente

4. Dirigirse al formulario al lado derecho de la pantalla

5. Ingresar los datos del cliente a registrar
6. Presionar el botón “Guardar”
 134

Pestaña Inventario

La pestaña inventario permite seleccionar el producto y las cantidades que el

cliente desea comprar.

Seleccionar producto

6. Dirigirse a la tabla con los productos existentes

7. Hacer clic en el producto deseado por el cliente
8. Presionar el botón “Seleccionar”
9. Ingresar la cantidad deseada del producto
10. Presionar el botón “Aceptar”
 135

Pestaña Productos Seleccionados

La pestaña productos seleccionados permite ver los productos asociados a la

compra del cliente, los lista, calcula el total a pagar y detalla el monto en impuestos y
la cantidad de artículos asociados a la operación.

Editar cantidad

6. Dirigirse a la tabla con los productos seleccionados

7. Hacer clic en el producto al cual se desea modificar la
cantidad
8. Presionar el botón “Editar Cantidad”
9. Ingresar la nueva cantidad deseada
10. Presionar el botón “Aceptar”

Eliminar producto

5. Dirigirse a la tabla con los productos seleccionados

6. Hacer clic en el producto el cual se desea eliminar
7. Presionar el botón “Eliminar”
8. Presionar el botón “Aceptar”

Si el cliente está de acuerdo con la cotización mostrada, se continua con el

proceso de cobro y emisión de la factura.
 136

Proceso de Cobro y Emisión de la Factura.

Luego de validar la cotización con el cliente, presione el botón “PAGAR”. Se

encontrará en una pantalla para ingresar los distintos pagos realizados por cliente para
cancelar el monto cotizado en su totalidad.

Presione el botón según el método de pago por el cual el cliente pagara, si este
método de pago es diferente a criptomonedas, se seguirá el siguiente procedimiento:

Cobro y Emisión (Métodos de pagos comunes)

6. Ingresar monto a pagar por este método

7. Ingresar descripción asociada a la operación
8. Presionar el botón “Aceptar”
9. Si el monto fue cancelado en su totalidad, puede emitir
la factura
10. Presionar el botón “Emitir Factura”

Si presiono el botón asociado a el pago en criptomonedas, deberá seguir el

siguiente procedimiento:

Cobro y Emisión (Criptomonedas)

11. Ingresar monto a pagar por este método

12. Ingresar descripción asociada a la operación
13. Presionar el botón “Aceptar”
14. Seleccionar de la lista, la criptomoneda por la cual el
usuario paga
15. Presionar el botón “Ok”
16. El usuario escanea el código QR generado
17. Si la transacción fue exitosa, se puede continuar.
18. Si falla, se intenta de nuevo por el mismo método o
con uno diferente.
19. Si el monto fue cancelado en su totalidad, puede emitir
la factura
20. Presionar el botón “Emitir Factura”
 137

21. Inventario
Este módulo permite observar los inventarios generados automáticamente por
el sistema por una recepción de órdenes de compra en un almacén (Un ingreso de
existencias).

La única opción posible en los inventarios son las de editar su información, si

se necesita desactivar un producto para pausar su venta o editar su precio de venta, se
sigue el siguiente procedimiento.

Editar Inventario

1. Seleccionar Inventario a editar

2. Presionar el botón “Editar”
3. Ingresar en el formulario los nuevos datos del
inventario
4. Presionar el botón “Guardar”
 138

22. Productos
Este módulo permite observar los productos registrados dentro del sistema, así
como crear uno nuevo, modificar la información de alguno existente y eliminar alguno.
Debe tener en consideración:
• No puede editar o eliminar un producto asociado a una operación
de venta, debido a que el documento Factura ya fue registrado con
los datos de este y hay limitaciones legales como de integridad de la
base de datos.
• Un producto debe de estar registrado al momento de cargar las
órdenes de compra que se asocien a este o generara un error.

Se siguen los siguientes procedimientos para llevar a cabo las acciones posibles
dentro de este módulo.

Eliminar Producto

1. Seleccionar Producto a eliminar

2. Presionar el botón “Eliminar”
3. Presionar el botón “Aceptar”
 139

Crear y editar un producto, se lleva a cabo a través de esta interfaz, en donde se

identifica que acción está realizando, y se presenta el formulario de campos del
producto, cabe destacar que las unidades e impuestos, depende de los elementos
previamente configurados en el sistema.

Crear Producto

1. Presionar el botón “Crear”

2. Rellenar los datos del producto en el formulario
3. Presionar el botón “Guardar”

Editar Producto

1. Seleccionar Producto a editar

2. Presionar el botón “Editar”
3. Ingresar en el formulario los nuevos datos del producto
4. Presionar el botón “Guardar”
 140

23. Órdenes de Compra

Este módulo permite ver las órdenes de compra ingresadas al sistema, ver sus
detalles o anularlas, además permite importar nuevas desde el sistema de
administración de la empresa.
Debe considerar.
• Al momento de recibir órdenes de compra en un almacén, que el
archivo seleccionado contenga la información desde el sistema
administrativo de la empresa y esta sea correcta y escrita en el
formato indicado, esto es debido a que las validaciones son
limitadas.
• Recuerde registrar los productos asociados a un nuevo importe.
 141

El proceso de importar es uno de los más importantes de este sistema, debido

a que es la única forma de incrementar las existencias de un producto en inventario
para la venta de este, estas órdenes son importadas a través de un archivo Excel de
extensión “.xls” el cual debe cumplir con el siguiente formato.

Se debe seguir los siguientes procedimientos para realizar las acciones

disponibles en este módulo.

Importar Órdenes

1. Presionar el botón “Importar”.

2. Seleccionar archivo Excel con la información de las nuevas
órdenes de compra con el formato esperado.
3. Visualizar nuevas órdenes de compra registradas en el
sistema.

Anular una orden de compra, actualiza el estatus de la orden a Anulada, por lo

tanto, no podrá ser recibida en ningún almacén y figurará en el listado hasta ser
eliminada desde la base de datos.

Anular Orden

1. Seleccionar una orden de compra que no esté anulada o

recibida en un almacén.
2. Presionar botón “Anular”.
 142

Ver Detalles de Orden

1. Seleccionar una orden de compra.

2. Presionar botón “Ver detalles”.
3. Visualizar detalles de orden de compra seleccionada.

Los detalles de una orden de compra invocan la siguiente pantalla

 143

24. Recepciones
Permite observar las órdenes de compra recibidas y en que almacén lo fueron,
es una característica administrativa que no genera acciones en el sistema más allá
de listar.

25. Almacenes

Este módulo permite observar, registrar, editar y eliminar los almacenes de la

empresa, así como recibir mercancía en alguno de ellos.
 144

Se siguen los siguientes procedimientos:

Crear Almacén

1. Rellenar los datos del almacén en el formulario

2. Presionar el botón “Guardar”

Editar Almacén

1. Seleccionar almacén a editar

2. Presionar el botón “Editar”
3. Ingresar en el formulario los nuevos datos del almacén
4. Presionar el botón “Guardar”

Eliminar Almacén

1. Seleccionar un almacén
2. Presionar el botón “Eliminar”.
3. Presionar “Aceptar”

Recibir en Almacén

1. Seleccionar almacén a realizar una recepción de órdenes de

compra.
2. Presionar botón “Recibir en almacén”.
3. Seleccionar orden de compra a recibir.
4. Presionar botón “Recibir orden”.

26. Clientes

Este módulo permite observar, registrar, editar y eliminar los clientes de la

empresa.
Debe considerar.
• Un cliente no puede ser editado o eliminado si esta previamente
asociado a una Factura.
 145

Se siguen los siguientes procedimientos:

Registrar Cliente

3. Rellenar los datos del cliente en el formulario

4. Presionar el botón “Guardar”

Editar Cliente

5. Seleccionar cliente a editar

6. Presionar el botón “Editar”
7. Ingresar en el formulario los nuevos datos del cliente
8. Presionar el botón “Guardar”

Eliminar Cliente

2. Seleccionar un cliente
3. Presionar el botón “Eliminar”.
4. Presionar “Aceptar”
 146

27. Proveedores

Este módulo permite observar, registrar, editar y eliminar los proveedores de la

empresa.
Debe considerar.
• Los proveedores están asociados con un importe de órdenes de
compra, puede que el registro de uno nuevo no sea necesario, ya que
esto es realizado automáticamente por el sistema.

Se siguen los siguientes procedimientos:

Registrar Proveedor

5. Rellenar los datos del proveedor en el formulario

6. Presionar el botón “Guardar”

Editar Proveedor

9. Seleccionar proveedor a editar

10. Presionar el botón “Editar”
11. Ingresar en el formulario los nuevos datos del
proveedor
12. Presionar el botón “Guardar”
 147

Eliminar Proveedor

3. Seleccionar un proveedor
4. Presionar el botón “Eliminar”.
5. Presionar “Aceptar”

28. Configuraciones

Este módulo permite modificar la información de la empresa, gestionar los

métodos de pago, las unidades para los productos utilizadas en el sistema y gestionar
los impuestos que puede que sufra la venta de un producto.
Debe considerar.
• El número de Control y de Factura dejara de ser editable dentro del
sistema una vez la carga inicial es llevada a cabo, si es necesario, el
administrador puede hacer la edición por base de datos.
• Un método de pago, una unidad o un impuesto no pueden ser
modificados si son utilizados en una operación de venta
previamente o están asignados a un registro asociado.
 148

Para ingresar o modificar la información de la empresa, rellene el formulario en

la pestaña empresa y presione el botón guardar.
Las pestañas de métodos de pago, unidades e impuestos siguen los mismos
procedimientos.

Registrar un Elemento

7. Rellenar los datos del elemento en el formulario

8. Presionar el botón “Guardar”

Editar Elemento

13. Seleccionar elemento a editar

14. Presionar el botón “Editar”
15. Ingresar en el formulario los nuevos datos del elemento
16. Presionar el botón “Guardar”

Eliminar Elemento

4. Seleccionar un elemento
5. Presionar el botón “Eliminar”.
6. Presionar “Aceptar”