En este artículo, presentamos los fundamentos de la construcción del «Módulo de Servicio» que se incorporó al Sistema de Facturación Electrónica de ZEVEN S.A. en 2020.
Cuando se inició el desarrollo de este módulo, se publicaron en el blog de aquel entonces varios white papers con el objetivo de proporcionar a los futuros usuarios una perspectiva técnica y detallada desde el punto de vista del programador sobre la solución que se estaba construyendo.
Un white paper es un informe o guía autorizada que aborda problemas complejos y presenta la filosofía del emisor sobre el asunto. Está destinado a ayudar a los lectores a entender un tema, resolver un problema o tomar una decisión.
En el contexto del desarrollo de software, los white papers detallan aspectos técnicos, desafíos y soluciones adoptadas durante el proceso de creación del software.
A continuación, se presentan los white papers del desarrollo del Módulo de Servicio.
INDICE
MÓDULO SERVICIO - White Paper del 19 de febrero 2020
Hoy comenzamos los trabajos de programación del nuevo Módulo de Servicio, que se incorporará a nuestro producto de facturación electrónica.
Iniciamos mapeando el recorrido lógico que tendrá todo el proceso, desde el inicio del servicio hasta su finalización.
Las fases del proceso son las siguientes:
- Inicio del servicio: Definición de la naturaleza del servicio.
- Ingreso del servicio: Registro del servicio dentro de la actividad económica.
- Proceso o trabajo: Elaboración del servicio.
- Finalización del servicio.
ANÁLISIS DE LA FASE 1 (Inicio del Servicio)
En esta fase, se define específicamente el servicio que se ofrecerá a los clientes.
El programa debe incluir una sección en la configuración donde se puedan especificar uno o más tipos de servicio.
Esto permitirá a cada actividad económica crear y gestionar diferentes tipos de servicios según sus necesidades.
Ejemplo Práctico #1
Imaginemos una empresa dedicada a la venta de repuestos de automóviles que también ofrece varios servicios a sus clientes, como:
- Cambio de aceite
- Cambio de batería (después de la venta)
- Lavado de vehículos
El programa debe permitir al usuario ingresar cada tipo de servicio para que se puedan, ademas de elaborar el servicio, generar reportes específicos por tipología de servicio.
Ejemplo Práctico #2
En el caso de una empresa que realiza reparaciones de equipos, los servicios podrían incluir:
- Reparación de teléfonos celulares
- Reparación de computadoras
- Formateo de PCs
- Limpieza de teléfonos
Flexibilidad en la Configuración
Una pregunta común es ¿cómo definir los datos que se ingresarán al crear el servicio si cada actividad puede definir los tipos de servicio de manera autónoma?.
Para esto, utilizaremos el mismo principio que se usa en la ficha de clientes-proveedores-artículos para la definición de campos adicionales.
Esto permitirá configurar, al momento de la creación del tipo de servicio, los campos que se deberán ingresar durante la recepción o inicio del servicio, proporcionando al programa una flexibilidad enorme.
Resumen de la Fase 1
Cada cliente podrá crear una cantidad ilimitada de servicios que pueden ofrecer.
Cada servicio podrá configurarse de manera independiente y flexible, utilizando el principio de campos adicionales.
Una vez definida toda la Fase 1, podemos iniciar el trabajo de programación de toda la lógica correspondiente a esta fase.
En nuestro próximo White Paper, analizaremos la Fase 2: Ingreso del servicio dentro de la actividad económica.
MÓDULO SERVICIO - White Paper del 24 de febrero 2020
En este White Paper, abordaremos el recorrido lógico de la recepción del servicio.
Hasta ahora, hemos definido los campos de servicio para cada una de las tres fases.
Para evitar confusiones en aquellos que siguen nuestra lógica lineal, aclaramos que ciertos campos serán definidos de manera fija y formarán parte de la estructura básica del servicio.
A partir de ahora, haremos una distinción técnica: continuaremos llamando «servicio» a lo que hemos desarrollado hasta el momento, y utilizaremos «asistencia» para referirnos a la recepción de cualquier servicio que hayamos configurado.
Es decir, una asistencia no es más que un servicio que brindamos a un cliente.
Detalles y Registro de la Asistencia
Al iniciar una asistencia, habrá un campo fijo denominado «detalle» o «nota de recepción«.
Además, incluiremos un campo fijo para el código del cliente que recibe nuestra asistencia/servicio y un campo para registrar un adelanto/abono solicitado para realizar la asistencia.
Es importante tener en cuenta que, dado que debemos registrar un adelanto en dinero, esta actividad debe ser informada en el reporte de cobros como un ingreso.
Por lo tanto, el proceso de registro de cobros debe incluir un eventual cobro de una asistencia al inicio (abono).
Proceso de Cobro
Nos enfrentamos a dos escenarios posibles:
- La persona que registra el servicio es la misma que recibe el dinero.
- Un cajero realiza la actividad de cobro.
Para cubrir ambas situaciones, al registrar el inicio de la asistencia, incluiremos una casilla de verificación (checkbox) que indique si la persona que registra la asistencia también recibe el adelanto/abono.
Además, debemos modificar la sección de cobros para permitir el registro de cobros parciales o totales de asistencias.
Al generar la factura, se deberá hacer el correspondiente encaje entre el abono y el saldo de la factura.
Integración y Sincronización de Datos
La ficha de clientes también debe incluir una pestaña que concentre todas las asistencias realizadas al cliente. Esta pestaña solo estará habilitada para las instalaciones que tengan el módulo de servicio incluido.
En resumen, con la introducción de la aceptación de las asistencias, debemos:
- Aceptar abonos y sincronizarlos con la sección de cobros y la ficha de clientes.
- Prever la interacción de las asistencias con la futura factura generada.
Todos estos nuevos datos deben sincronizarse con los diferentes reportes que ya genera el programa. ¡Un gran desafío!
