Un patrón de diseño heteredoxo puede sarlvarte el pellejo.

[[AzidRain]]

Lo que a continuación relato es un puro ejemplo de como trabajamos muchos que desarrollamos software a medida ( por favor no confundir ni pensar siquiera que se parece al software comercial).

Hace cerca de año y medio un cliente me buscó porque tenía un grave problema en su empresa relacionado con las cuentas por cobrar, no sabía quien le debía, cuanto y desde cuando, quien merecía crédito y quien no y ya se imaginarán el caos que había por ahí. Obsérvese que no me preguntó por un sistema concreto que hiciera algo, simplemente quería resolver ese problema porque le representaba pérdidas económicas a su empresa amén de no darle una certidumbre financiera adecuada.

Obviamente la opción era sistematizarle el proceso de manera que todo fuera automático y se fuera dando seguimiento a cada una de esas cuentas y clientes, conocer a detalle el monto de los atrasos y asignar créditos de manera sistemática. Hasta aquí vamos muy bien, pero el problema radica que como ya sabemos, en el proceso administrativo las cuentas por cobrar (o accounts payables en gringo) siempre surgen a posteriori de que se ha facturado a un cliente determinado, o lo que es lo mismo, tenemos que tener primero una facturación mas o menos bien para de ahi partir a cuentas por cobrar.

Sistema de facturación existía y estaba en uso desde 1994 con un impresionante record de 0 caídas y 0 errores en operación. Se trataba de un sistema en Clipper (también desarrollado por su servilleta) utilizando tablas lisas y llanas DBF. Este sistema fue suficiente para esta empresa durante mas de 10 años y resistió sin problemas los embates de Windows y los lenguajes visuales, pero sin embargo es obvio que como que ya no cuadraba para poder hacer lo de CxC. Ahora otra complicación, al ser un programa de escritorio estaba instalado en cada sucursal que facturaba a clientes (3) por lo que obviamente la información de cada una de las sucursales es distinta y no tiene relación con la de las demás. Amén de que no puede ser ni consultada ni actualizada de forma remota, salvo con el uso de algún VNC.

Que bonito problema no? En el modelo del sistema nuevo de CxC este tenia que tener forma de proporcionar la misma información a quienes manejaban esta situación en las 3 sucursales de manera que forzosamente se requería acceso via internet a una base de datos de cualquier clase.

Solución propuesta: Se desarrolló un sistema el Delphi que mantenía y controlaba estas cuentas x cobrar, las cuales estaban modeladas en una base de datos MySQL con acceso vía internet. Como la información fuente, las facturas, se encuentran fuera del motor MySQL se tuvo que hacer un pequeño software "agente" instalado en cada sucursal que se encargaba de convertir los datos DBF a registros en las tablas de MySQL CxC. La complicación seguía porque un mismo cliente podía tener diferentes claves de identificación de acuerdo con la sucursal que lo hubiera dado de alta dado que eran autónomas. Además de que existían muchos registros con la misma información correspondientes a un mismo cliente, así como cambios de domicilios y demás. Para solucionar esto se creó una opción en el sistema de CxC que enlazaba un cliente de CxC con varios números de identificación de acuerdo a la sucursal, de manera que se unificaran en un solo cliente.

Diariamente en las sucursales, se corría un proceso que actualizaba la base de datos MySQL a partir de los datos DBF local.

Pensarán, ¿Por qué no se hizo de una vez la facturación? El cliente no quiso porque obviamente costaría bastante más y su apuración en ese momento era precisamente el dinero así que ni hablar había que buscarle como solucionarlo.

Casi 1 año después se le propuso hacer la facturación mostrándole las ventajas de que ya se hiciera basado en un servidor común y hacerlo vía internet. Finalmente accedió aunque solo a un sistema muy reducido. Aquí ya se tendieron los puentes necesarios para ligar la facturación con las cxc cosa que se logró facilmente a nivel de base de datos, sin embargo nos enfretamos a algunos problemas:

* CxC se desarrolló en Delphi6 haciendo uso extensivo de QuickReport y en 1 solo reporte de TeeChart (por solicitud del cliente)
* Facturación se hizo en D7, el cual ya no traía el QuickReport ni Teechart, bueno el que traía no funcionaba con lo que ya teníamos.

Adquirimos la licencia de QReport Pro 7.0 para Delphi 7 y así continuamos desarrollando esta facturación. Hasta aquí digamos que vamos mas o menos bien.

Hace unos días en una reunión con un asesor administrativo del cliente, se le mostraron ambos programas y quedo encantado con los mismos, pero sugirió fusionarlos en una sola aplicación. Gulp! pensé.Pero se encargó de darle muchos argumentos a mi cliente de por qué lo necesita de esa manera cosa que obviamente a nosotros nos conviene como desarrolladores.

Actualmente estoy empezando a estudiar la forma de hacer esta fusión y aunque aún no llego a la parte medular ni al código si estoy analizando algunas cosas que aunque no son buenas prácticas de desarrollo, al final me van a beneficiar al hacer esta fusión y por lo mismo quiero compartirlas aquí. Obviamente tomando en cuenta que el primer desarrollo se hizo a marchas forzadas y con mucha presión por parte del cliente, no se hizo un análisis a fondo y se tuvo que empezar a operar con una versión alpha con muchos errores y bugs aún sin corregir pero la urgencia era ya mucha de parte del cliente. Además no se se sabía si en algún momento se haría o no la facturación en algún momento o no.


El antipatrón Forma Miniaplicación.

Casi la totalidad de las formas utilizadas en el sistema de CxC se desarrollaron de manera independiente unas de otras. Como prácticamente los usuarios estaban esperando que se terminara cada una para empezar a utilizarla la forma debía incluir todo lo necesario para funcionar sin tener que esperar a que estuviera lista alguna otra. De esta manera, mucha lógica de negocio quedó encapsulada en cada una de las formas. Cosa que va contra toda lógica valga la redundancia. Sin embargo, a la larga era la única forma de no tener que regresar sobre nuestros pasos cada 2 o 3 meses. Cada forma se desarrolló como si fuera una sola aplicación, tratando de que no afectara a otras partes de la aplicación completa. Finalmente luego de varios meses se terminó el último módulo y la última forma.

El programa de facturación se hizo de forma muy similar y prácticamente por las mismas razones.

Ahora, en el momento de empezar a fusionar ambas cosas, me doy cuenta que en muchos casos solo bastará con agregar las formas a uno u otro para que funcionen sin mucho problema, dejándonos tiempo para analizar y modelar la solución completa como mandan los cánones.

La visión es crear una sola aplicación a la cual posteriormente vamos a ir agregando módulos hasta finalmente terminar con Contabilidad.

Algo así:

* Facturación
* Cuentas por cobrar
* Cuentas por pagar
* Bancos
* Liquidaciones de Viaje
* Contabilidad

La empresa se dedica al autotransporte de carga general y paquetería.

Aquí seguiré comentando los avances que vayamos haciendo esperando sirvan para quienes se enfrentena a casos similares.