Entre las Open Apps publicadas hasta el dia de hoy, hay una que destaca entre las demas, quizá por ello ha sido merecedora del 1er premio en el concurso de aplicaciones organizado por Velneo y cuyo fallo se emitió en el 1er trimestre del 2010.

¡SI!, se trata de la aplicación enviada por InnovaDB, en la cual se integra de forma brillante toda la gestión de documentos de la empresa, y no hablo de una gestión documental, sino de los documentos que se emiten diariamente tanto para compras como para ventas, como presupuestos, pedidos, albaranes, facturas y por supuesto, con sus respectivas lineas de movimientos.

Puede gustar mas o menos, pero hay que reconocer que se ha llevado la abstracción, casi al limite, unificando todos los documentos en tan solo 2 tablas, una de documentos y otra de movimientos de almacén.

Tal es asi, que en la tabla de Documentos, se registran Facturas recibidas, Facturas emitidas, Albaranes de compra, Albaranes de venta, Pedidos a proveedor, Pedidos de clientes, Presupuestos, eso si diferenciados para poder usar aquel que sea necesario en cada momento.

Del mismo modo, la tabla de Movimientos, se usa para registrar cualquier movimiento de almacén que se produzca en cada uno de los documentos anteriormente citados (esta tabla es histórica de Documentos).

Y todo ello resuelto magistralmente, mediante la parametrización de cada uno de los documentos, en una tabla de Tipos de documento.

Si miramos el esquema de como quedaría una gestión de las primeras que todos hemos usado en algún momento, años atrás, el esquema quedaría tal como este:

Si miramos el esquema, tal y como queda despues de llevar la abstración a los limites, el resultado es este:

¿Podriamos abstraer más aún?, pues si pero, ¿mereceria la pena?

¿Cual es mi opinión a esta estructura?, la verdad es que mi opinión poco importa aqui, lo importante es que seais capaces de valorar vosotros mismos si os gusta, si es operativa, si es … lo que necesitais, y si la respuesta es positiva, adelante.

Enhorabuena por vuestro premio, y por vuestra nueva web.

Un abrazo de mi para vosotros, y a ver cuando tenermos la oportunidad de volver a tomarnos unas cervecitas

Como ya indicamos en un articulo anterior “El esqueleto de nuestras aplicaciones“, la presentación de V7 en sociedad fue determinante a la hora de establecer una estrategia de futuro que permitiera una evolución del E.R.P. que habiamos estado instalando a nuestros clientes, manteniendo su esencia, y potenciando las nuevas caracteristicas que V7 aportaría.

Asi comenzó un periodo de analisis y pruebas para renovar todo lo que habiamos creado hasta el momento, y empezamos a preguntarnos todo aquello que hasta ahora nos habian pedido los clientes para incluirlo en el nucleo, como funcionalidades “de serie”, y dejar que la parte personalizable a cada cliente, se pudiera reducir al minimo.

Asi empezamos a realizarnos preguntas, y por supuesto, a dar solución a cada una de ellas:

El resultado, a todas estas funcionalidades es:

1. Un E.R.P. multi-empresa, multi-división, multi-almacén, y multi-ejercicio. Asi es, aunque en V7 permite instanciar varias aplicaciones con una misma solución, hemos quedido potenciar aún mas esta funcionalidad, y podemos trabajar con varias empresas dentro de la misma instancia, varias delegaciones para cada empresa, múltiples almacenes de mercancia y varios ejercicios de forma simultanea, sin necesidad de reinstanciar nada, y sobre todo, pudiendo combinar todo esto como os apetezca.
2. Posibilidad de buscar, crear o modificar cualquier registro desde cualquier lugar en donde sea necesario. Esto nos permite, p.e., al introducir un albaran de venta, crear el cliente en ese mismo instante, o modificar alguno de sus datos, sin abandonar el documento para nada.
3. Control de articulos y familias con todos los datos necesarios para la compra-venta de los mismos.
4. Control de stock para multiples almacenes, control de envases y tambien stock de lotes.
5. Gestion de entidades valida para clientes, proveedores, acreedores, agentes, empleados, con multiples direcciones de envío, multiples domiciliaciones bancarias, etc.
6. Gestión de movimientos de almacen, compras y ventas, integrado en una misma tabla (abstracción máxima) o separando los distintos tipos de documentos en tablas diferentes, al igual que su hermano menor, del cual se hablaba en el articulo Analisis de una aplicación completa. De esta forma, manteniendo las dos estructuras, es el cliente final el que decide como quiere que funcione su aplicación.
7. Integración con las webs de los proveedores y clientes.
8. Generación de hojas de carga especializadas, diferentes segun el sector al que se destina la actividad empresarial.
9. Control de zonas de venta y rutas de reparto.
10. Informes de expediciones.
11. Control de tarifas ilimitado, permitiendo desde una tarifa única, tarifas comunes para varios clientes, incluso tarifas para cada uno de los clientes.
12. Control de precios de oferta, descuentos, ofertas en especie, promociones, etc.
13. Estadistica de compras y ventas, por agente, por zona de venta, por ruta de reparto, por cliente, por proveedor, por articulos, por familias, por ejercicio completos, por meses, etc.
14. Calculo de comisiones por diversos conceptos, reparto de mercancia, cobros de albaranes y facturas, comisiones en porcentaje o en euros, configurable por familias, por articulos, por agentes, por repartidores, etc.
15. Calculo de costes, con escandallo fijo o variable, etc.
16. TPV para venta con codigos de barras, impresion de tickets, control de turnos, informes de ventas, traspaso de tickets a la gestión.
17. Modulo opcional de gestión de vehiculo de flota, control de operaciones a vehiculos, mensajes de  aviso de operaciones pendientes, informes.
18. Contabilidad integrada en el mismo pack
19. Contabilización automatica del 80% de los documentos necesarios para controlar la contabilidad.
20. Descargas a contabilidad totalmente configurables por el usuario.
21. Contabilización con plantillas predefinidas para los documentos mas habituales
22. Generación de informes contables oficiales como Balances de sumas y saldos, Cuentas de resultados, impresión de Libros oficiales, y otros balances propios.
23. Emisión de extractos por pantalla e impresora, punteo de apuntes contables, verificación de descuadres.
24. Automatización de procesos, como cierre y apertura, etc.
25. Gestión de libros de I.V.A. repercutido, I.V.A. soportado, libro de I.R.P.F.
26. Generación de los impuestos mas habituales, como: modelo 303 de I.V.A. mensual/trimestral, 390 de I.V.A. anual, 347 de operaciones con terceros, 340 de presentación telematica, 115, 110, 190.
27. Control de vencimientos a cobrar y a pagar, generación de remesas automaticas.
28. Gestión de tesoreria, previsión de cobros y pagos, etc.
29. Generación de cuadernos 19, 32 y 58 del C.S.B.
30. Log de operaciones de usuario completo, a todos los niveles, que permite conocer todos los pasos que realiza cada usuario.
31. Permisos de acceso a las diferentes opciones de la aplicación para cada uno de los usuarios y acceso completo al administrador.
32. Exportación de datos en los formatos mas conocidos, como: ASCII, XML, LML, CSV.
33. Exportación de datos a EXCEL.
34. Emisión de informes por pantalla, impresora (con vista previa), generación de informes en HTML y PDF, etc.
35. Importación de datos contables y de gestión, que permiten iniciar la actividad rapidamente con datos de otras aplicaciones.
36. Instalación automatizada y datos básicos preinstalados que permite empezar a trabajar directamente desde la primera ejecución, con un minimo de esfuerzo.
37. y mucho más…
38. Y si a todo esto, le incluimos multiplataforma (Windows, Linux, Mac, Meego)
39. Multi-idioma (idiomas predeterminados: Español-Ingles) y posibilidad de traducir a cualquier otro idioma.
40. Interface grafica muy intuitiva y agradable
41. Capacidad para deshacer los procesos y operaciones mas importantes, volviendo a dejar los documentos y registros en su estado anterior.
42. Posibilidad de trabajar en la nube, en una red local o en una intranet sin ninguna herramienta adicional
43. Acceso completo al administrador para consultar los datos de cualquier tabla completa o por alguno de sus indices.
44. Acceso web a toda la aplicación desde los navegadores mas usados.
45. y alguna que otra novedad que esta por llegar …
46. Graficos estadísticos en formatos de lineas, barras, circulares, 3D, en breve
47. Una tienda virtual para los usuarios registrados, en breve
48. Una tienda virtual para clientes habituales, en breve
49. Un CMS para su negocio, que le permitirá publicar contenido sin conocimientos web, en breve
50. Despues de ofrecerte todo esto … ¿que necesitas?
51. ¿necesitas mas? … pues nos lo pides y te lo hacemos
52. ¿necesitas menos? … pues como la aplicación es completamente modular, solo se instalará aquello que necesites realmente
53. ¿necesitas financiación? … pues solo tienes que solicitarlo y lo estudiaremos
54. ¿necesitas el codigo fuente? … todo es posible, llegaremos a un acuerdo
55. ¿necesitas aprender a bailar? … pues va a ser que ¡NO!, hay si que no te podemos ayudar. Pero quizá podamos recomendarte a alguien que te ayude.

Y con todas estas funcionalidades y aun no te hemos dicho a que tipo de negocio se adapta nuestro E.R.P., pues contesta a unas preguntas:

• ¿Te dedicas a vender, tienes clientes?
• ¿Te dedicas a comprar, tienes proveedores?
• ¿Tienes que facturar tus ingresos?
• ¿Necesitas una contabilidad integrada?
• ¿Tienes una gestoria/asesoria que te realiza las labores contables y fiscales?
• ¿Necesitas controlar las existencias del almacén?
• ¿Necesitas poder comprar y vender sin controlar el stock?
• ¿Necesitas funcionalidades que no te ofrecen los E.R.P. estandard?
• ¿Necesitas todo el control sobre la información de tu aplicación?
• ¿Pasas de controlar nada, solo te interesa facturar y punto?
• ¿Eres mayorista y distribuyes articulos de terceros?
• ¿Fabricas tus propios productos y los vendes?
• ¿Tienes agentes y/o repartidores que trabajan a comisión?
• ¿Pasas de dar comisiones y realizas venta directa?
• ¿Necesitas gestionar los cobros telematicamente?
• ¿Tus clientes te pagan cuando les parece bien a ellos?
• ¿Te gusta trabajar comodamente y evitar errores?
• ¿Y de que productos hablamos? alimentación, mobiliario, bebidas y licores, cristalería, etc…

Ahora revisa las respuestas y si hay algunas de ellas que tienen respuesta afirmativa (casi seguro que has contestado afirmativamente al menos a la mitad de las preguntas ), pues entonces, ¡este E.R.P. se adapta a ese tipo de negocio!

Porque hay palabras que no entran en nuestro vocabulario, IMPOSIBLE solo puede haber una cosa, ir al SOL y volver de una pieza, pero … ¿y si vamos de noche?

… y si no, ya encontraremos otra solución, pero si hay que ir, se va.

Todos los que llevamos tiempo desarrollando con ésta herramienta, lejos queda ya 1997 y la versión 2.0 de Velazquez Visual, tanto tiempo dedicado a crear una serie de aplicaciones, donde las plantillas no existian, y nuestros programas crecian en la misma medida en que los clientes nos realizaban sus peticiones para cubrir cada vez mas necesidades.

Al principio con poca experiencia en la herramienta, y apenas sin conocer el negocio de nuestro cliente, lo mejor que nos podia ocurrir es encontrar a alguien con las ideas claras de lo que queria conseguir.

No obstante, las aplicaciones se instalaban y funcionaban correctamente y a base de continuas actualizaciones, muy comodas, eso si, sobre todo para los que veniamos de trabajar con SQL (y algunos sabran lo que era realizar cambios en las bases de datos en la decada de los 90).

Tanto cambio, tantas prisas, tanta potencia requiere un buen conocimiento y unos buenos frenos, porque a veces habia que frenar y pensar hacia donde nos llevaba ese camino.

Y ya con las aplicaciones terminadas y en correcto funcionamiento, con miles de registros, con varios usuarios concurrentes y sin la posibilidad de volver atás, el cliente nos pide “algo”, una chorrada, algo tan tonto como para no poder decir que no, y tan sumamente importante como para tener que tirar gran parte del desarrollo, simplemente porque esa “chorrada” (que afectaba a la estructura de tablas) no estaba prevista inicialmente.

Varias veces con distintas aplicaciones, he decidido que lo mejor era empezar de nuevo, tener en cuenta todo el trabajo realizado anteriormente, incorporar las nuevas peticiones y plantear un nuevo analisis de la aplicación, y ya puestos, migrar los datos de una aplicacion a otra.

Puede parecer una locura, pero lo hice, por una razón, porque lo pedia el cliente, porque queria que se sintiera comodo con la aplicación y porque ese cliente me facilitaba el acceso a nuevos clientes cada vez que hablaba de mi, y de lo bien que funcionaba su aplicación.

De tal forma, las aplicaciones llegaron a ser robustas y fiables y estaban preparadas para cualquier nueva ampliación que al cliente se le pudiera ocurrir. De esto, me he cuidado mucho durante los ultimos años, no solo de ampliar las peticiones del cliente, sino de analizar como afectan dichas peticiones al resto de la estructura y preveer el futuro para evitar problemas.

Cuando nuestras aplicaciones ya rozaban la perfección (que dientes tengo), aparece V7, y se abren nuevas posibilidades, unas necesarias y otras muy atractivas, y surge un nuevo problema: ¿migrar mi aplicación? o ¿empezar de cero?

Puedes ver otras opiniones al respecto en estos articulos que ya se publicaron en su dia:

Herramienta de migración

Conviene migrar las aplicaciones de V6 a V7

Serán migradas las plantillas de V6 a V7

Como ya he indicado anteriormente, a partir de la presentación de V7 en sociedad, se tomo una decisión, habia que dar un cambio y preparar las aplicaciones para ese futuro inminente que se aproximaba, pero a cada decisión surgian nuevos problemas,

¡SI!, vamos a desarrollar una aplicación de cero, y a solucionar los problemas actuales y a mejorar lo que ya funciona, pero como, si V7 aún no está operativa!, aún no ha sido liberada la versión v7.0, ¿esperamos?  o ¿empezamos ya?

Habia 2 opciones, esperar a la primera versión de V7 que no se sabia cuando estaria disponible, o empezar ya y migrar la aplicación cuando apareciese la versión oficial y el migrador del que tanto se hablaba.

Decidi que no se podia esperar, y no me equivoque, se desarrollo una nueva aplicación, con el editor de toda la vida, probe cambios para asegurar el mejor resultado en todos los modulos de la aplicación, y se puso en marcha el proyecto.

V7 se retrasó tanto en el tiempo, que la aplicación se terminó y ya puestos, que mejor forma de averiguar que todo funcionaba como se habia previsto que instalar la aplicación a los clientes, y el primero, con un poco de miedo, por las prisas y por los posibles bugs que pudieran surgir, se instalo y a funcionar, un mes después, todos los bugs estaban corregidos, pero lo mas importante, no afecto a la actividad en ningun momento. Prueba superada, ya tenemos una estructura que nos servirá para afrontar el desarrollo con V7 de forma fiable. Y lo mejor de todo, como V7 no era oficial, en tan solo un año se hicieron 16 instalaciones, todas con exito y funcionando en 2/3 dias de media.

Aparece V7 y la herramienta de migración y tras leer la información anterior publicada por parte de Velneo, tenemos que volver a preguntarnos que hacer,

- existe una herramienta de migración, pero se nos recomienda no usarla ¿?

- la herramienta no migra la aplicación completa, solo tablas, variables, procesos, y poco mas,

- si seguimos los consejos de velneo, empezar de cero, puede significar mucho tiempo perdido

la solución, despues de tener una aplicación tan joven, preparada para el futuro y con una experiencia tan buena, habia que aprovechar ese trabajo y decidimos migrar solo lo importante, la parte izquierda del editor (tablas, tablas estaticas, variables), pero no vamos a migrar los procesos,

Seguiremos los consejos de Velneo y desarrollaremos de nuevo todo el interfaz, y ya veremos el resultado …

Han pasado algunos meses de esto, y ahora que vemos el resultado, nos gusta, y lo mas importante, a los clientes tambien les gusta, solo faltan pequeños detalles para que la aplicación este lista y pueda ser comercializada.

Ha sido un camino largo, pero ya casi hemos llegado al final …

… o quizá me equivoque y es ahora cuando hemos llegado al principio, despues del verano lo sabremos.

Para el esquema de nuestra gestión, de la cual exponiamos el esquema en el articulo anterior: Analisis de una aplicación completa, hemos visto que era necesario disponer de una funcion muy interesante, pero que de la cual no disponemos en la versión actual v7.4.

Asi pues, me planteo si debo desarrollar mi propia función para este proposito o debo buscar algun recurso que realice dicha tarea, y a pesar de que la segunda opción es muy atractiva ya que me libera de un tiempo del que a veces no se dispone, he decidido que crear una función propia y ademas hacerlo en Velneo v7, puede ser un ejercicio práctico que merezca la pena.

Convertir un importe a texto

Aunque seguramente no es la mejor decisión, ya que disponemos de otras formas de resolver el problema, me he puesto manos a la obra y aqui esta el resultado del ejercicio.

El código adjunto corresponde a la función definida para convertir cualquier numero a su valor en texto, y nos será muy útil para imprimir el valor numerico del importe de un cheque, por ejemplo.

Espero que os sea de utilidad.

En esta ocasión y para variar voy a mostrar el esquema de una pequeña y sencilla, pero completa aplicación de gestión.

Y vamos a ver algunos conceptos importantes que debemos tener en cuenta al diseñar nuestra base de datos.

Para este ejemplo he decidido que necesitamos una gestión que nos permita controlar varias empresas al tiempo, que sea multi-ejercicio y multi-almacén.

Nuestra gestión, tambien debe ser capaz de tramitar albaranes de compra, albaranes de venta, movimientos de almacen y por supuesto, la posibilidad de facturar los albaranes y contabilizar las facturas generadas.

Como ya se explicó anteriormente en el articulo sobre la abstracción, debemos analizar cada punto del esquema y decidir si nos conviene abstraer el esquema o mantener la sencillez en el desarrollo.

El esquema final que ha resultado de todo este planteamiento es el siguiente:

No es quizá el esquema mas abstracto, ya que podriamos haber utilizado una misma tabla para todos los movimientos de almacén, pero he decidido que para según que tipo de negocio, no es necesaria dicha abstracción y he preferido prescindir de ella en favor de un mantenimiento mas sencillo por parte del desarrollador que se inicia.

No obstante, si he usado una única tabla de entidades, que seria utilizada para clientes y proveedores, con el fin de evitar duplicidad en los datos introducidos por el usuario.

Analicemos los puntos mas importantes de la aplicación y veamos cuales son sus ventajas y sus inconvenientes:

¿Utilizar una OpenApp o desarrollar una nueva?

Esta pregunta, debemos responderla antes de comenzar, ya que de no ser asi, podria ser necesario repetir parte de la tarea de analisis y la perdida de tiempo que conlleva. Usar una OpenApp está muy bien, ahorra trabajo, y podria estar preparada en poco tiempo con algunas modificaciones y correcciones, pero ¿se ajusta el esquema a lo que necesito?, o lo que es mas importante, ¿que me va a llevar mas tiempo, realizar mi propio esquema o entender el esquema de la OpenApp?

¿Todo en un proyecto o usamos varios proyectos?

Lo primero que deberiamos decidir, ya que al menos de momento, no es posible separar las tablas de un proyecto en 2 proyectos diferentes, es si vamos a mantener todas las tablas dentro del mismo proyecto o no. Si queremos aprovechar la potencia de la herencia para reutilizar el esquema para otras posibles aplicaciones que pudieramos tener pendientes, deberiamos separar las tablas en varios esquemas, pero ¿cuantos?, ¿que tablas en cada proyecto?, ¿que proyectos heredan y cuales son heredados?. También podemos optar por mantener unido todo el conjunto y hacer mas sencillo el desarrollo, pero en este caso, el futuro de la aplicación estará muy limitado por esta decisión.

¿Que tipos de tablas y que relaciones debe haber entre las tablas?

Ya decidida la parte anterior, ahora nos toca profundizar un poco mas y saber de que tipo va a ser cada una de las tablas usadas en el proyecto, maestra, submaestra, historica, y analizar una a una con sus ventajas e inconvenientes.

¿Entidades multi-empresa o no?

En este punto deberiamos decidir si la tabla de entidades deberia ser historica de empresas o no, si tenemos en cuenta que al ser Multiempresa, un cliente/proveedor deberia ser creado tantas veces como empresas tengamos y dicha entidad realice operaciones con la empresa. Si la tabla Entidades no es multiempresa, al crear un cliente/proveedor estara disponible para todas las empresas desde ese instante.

Compras, ventas y almacén, ¿juntas o separadas en tablas diferentes?

Como he indicado anteriormente, si utilizamos las mismas tablas para movimientos de almacén, el usuario final no deberia notar absolutamente nada, pero para el desarrollador puede ser mas complicado mantener esa aplicación, y puede ocasionar errores en futuras actualizaciones de la aplicación si no se tiene mucho cuidado al realizar los cambios.

Facturas de compra y venta, ¿ que relación deben tener con contabilidad?

Las facturas deben ser maestras o historicas de los asientos y/o apuntes contables, o quizá no deberian tener ninguna relación. Si relacionamos las facturas con los asientos, esto nos permitiria mantener la integridad entre gestión y contabilidad, pero si deseamos que nuestra contabilidad pueda ser usada por multiples aplicaciones de gestión con estructuras diferentes, deberiamos pensar en separar la contabilidad, y desarrollarla completamente por separado.

Los vencimientos, ¿en contabilidad o en gestión?

Si esta pregunta se la hacemos a un contable, su respuesta sería clara y rotunda, ¡en contabilidad!, pero si tenemos una gestión de ventas y procesos de facturación, no tiene mucho sentido que tengamos que introducir los vencimientos manualmente, ¿o quizá si?

¿Hasta donde queremos llegar?

Otra pregunta muy importante que debemos tener muy clara, es ¿hasta donde queremos llegar en este proyecto?, ¿que necesidades tenemos?, ¿el esquema planteado aqui es suficiente o necesitas más?, y si es asi, ¿cuanto más?

Plantear una aplicación, necesita muchas preguntas, y sobre todo, tener claras las respuestas a esas preguntas, y solo asi conseguiremos que en el futuro no tengamos sorpresas desagradables por problemas no previstos.

Y no voy a ser yo quién os diga lo que debeis hacer en cada momento, este articulo, pretende crear un debate y que cada uno pregunte o responda a lo que pueda ser su diseño más apropiado.

Para nuestra solución, ya hemos tomado todas las decisiones importantes y estamos avanzando en el desarrollo, pero cada aplicación es muy personal, y debeis encontrar las respuestas a vuestras necesidades.

Al hilo de los ultimos comentarios realizados por nuestro amigo del foro, Luis Palomo “Overall” y basandome en mi corta experiencia con V7, he decidido volver a la carga con una nueva critica, y alla cada cual con las conclusiones que quiera sacar de ella, pero creo que la unica conclusión valida a lo que voy a exponer es: “mejorar lo que tenemos para evitar los problemas que aqui se plantean”.

El hilo al que me refiero en concreto es este:

Copiar una solucion de Overall

Y como yo mismo comente en este hilo, hay existe un problema al copiar proyectos de una solucion a otra, y que se detalla en este articulo que escribi hace varios meses, Las malas costumbres del 7 de abril de 2010, apenas un mes y 1/2 despues de publicarse la version 7.3

Para ir concretando, el problema no surge en el instanciamiento de datos, el problema no lo tiene el cliente final que desarrolla una aplicacion personalizada para su PYME, el problema real, lo tenemos los desarrolladores que nos dedicamos exclusivamente a la programación y vamos a tener multiples aplicaciones, todas muy similares pero personalizadas para cada uno de los clientes, y ante tal planteamiento se me ocurren varias formas de afrontarlos para obtener el mejor resultado posible.

Y cual es ese resultado:

1. Que el cliente este satisfecho con su aplicación, y el resultado tenga una relación calidad/precio optima.
2. Que los desarrolladores trabajemos en una aplicación común y solo tengamos que realizar las personalizaciones para cada uno de ellos, abaratando asi los costes para ser competitivos.

Un ejemplo practico “y real” de todo esto, hemos desarrollado un pequeño E.R.P. basico pero lo suficientemente completo como para servir de plantilla para futuros desarrollos y este es es esquema de la solución:

Fijaos en el circulo rojo, que hemos marcado claramente el proyecto de contabilidad que es el único que nos interesa para este ejemplo, mas adelante veremos porque.

Paralelamente, en otro departamento, estamos desarrollando otra aplicación para corredurias de seguros,

Y aunque no será el último, para este ejemplo lo vamos a dejar aqui, tambien hemos desarrollado una gestión para cristalerías, y algunos modulos adicionales como Flota, etc.

Con todo esto, ya tenemos los ingredientes para nuestro guiso, y hasta ahora lo que eran 3 soluciones independientes, se convierte en un problema que debemos solucionar, ¿cual?

Nuesto cliente, “corredor de seguros” quiere tener instalada la contabilidad, y por supuesto nuestro cliente “cristalero” tambien, ya que una vez desarrollada, el coste no es elevado y deciden que es una buena opción.

Hasta ahora, no se ha planteado nada raro, creo yo, es mas, es nuestro caso real y es nuestro problema actual.

Segun lo que se plantea en el foro, y el articulo escrito por mi mismo anteriormente al que se hacia referencia tenemos varias soluciones posibles:

1. Si seguimos el articulo Las malas costumbres al pie de la letra, bastaria con copiar los poyectos de Contabilidad y sus heredados a la nueva solución, y tendriamos la contabilidad en los 3 proyectos, repetida, pero seguirian siendo pequeños proyectos, con un problema añadido, si realizamos modificaciones en Contabilidad, hay que copiar nuevamente los proyectos y por tanto surgen posibilidad de errores, o realizar las modificaciones 3 veces. ¡Hemos decidido que esta no es la solucion al problema que se plantea!
2. Si seguimos el consejo de FGutierrez en el hilo de Overall, en el que nos aconseja no copiar los proyectos para no tener ducplicados, solo nos queda una solución, heredar la conta desde los proyectos de Corredurias de seguros, y desde Cristalerias. ¡Esta es una buena solución! y este seria el resultado:

Y aqui vemos como el resultado de heredar la contabilidad por las nuevas aplicaciones, convierte nuestros 3 pequeños proyectos en un macro proyecto que seguira creciendo a medida que vayamos incorporando mas funcionalidad.

Como he dicho anteriormente, no me preocupa el resultado de la instalacion en el cliente, no es el tema que nos ocupa en este momento, ya que el instalador se encargara de usar los proyectos que sean necesarios para la instalación.

La intencion de este articulo, vuelvo a repetir, es plantear los problemas que tendremos los desarrolladores ante esta situación, y es que, aunque la solucion de FGutierrez es totalmente validad y la mas correcta, ahora nos surge otro problema añadido, del que tambien he publicado otro articulo hacetan solo un par de semanas, el 6 de junio de 2010, llamado Mejoras en el rendimiento, que nos plantea el problema de redimiento de vDevelop y los refrescos cuando la solución empieza a crecer con multiples proyectos.

Este ejemplo es muy relativo, si tenemos en cuenta que solo he utilizado 3 de los desarrollos que actualmente estamos preparando para nuestros clientes, pero no quiero olvidar y espero que asi se repita, con Velazquez Visual, realizamos más de 80 instalaciones personalizadas en tan solo 4 años, y si con 3 aplicaciones ya tenemos un pequeño problema de rendimiento, como será cuando lleguemos a 15 o 20 aplicaciones…

y ahora, ¿Cual es la solución?

Esta semana ha sido intensa en emociones, buenas y malas, y os lo voy a contar, para que podais preveer los problemas que me han surgido y que me han dado tantos quebraderos de cabeza en tan poco tiempo.

Todo viene, a cuento de que hay que cambiar los tipos de IVA, de lo que se deduce que al final, el culpable es el gobierno, como de casi todo lo que pasa es este pais.

Pero no nos desviemos del tema, habia que cambiar los tipos de IVA y he realizado los cambios necesarios en el mapa (en V6.x) para preveer todos los posibles problemas que puedan surgir ese dia, ya que debe estar funcionando paralelamente con los 2 tipos de IVA, y permitir realizar ventas en julio al 18% y facturar albaranes de junio al 16% entre otras cosas, modificaciones que no estaban previstas en el mapa.

Total, que se hicieron las modificaciones, y vamos a realizar las pruebas oportunas para comprobar que el dia 1 de julio todo sera correcto, asi pues:

1. detenemos en el servidor de V6 una de las empresas,
2. hacemos una copia de seguridad de la carpeta completa para poder usarla como empresa de pruebas,
3. se publica la nueva empresa en el servidor,
4. se asignan los permisos a los usuarios,
5. se instala la nueva versión del mapa modificado para la ocasión,
6. se reinicia la aplicacioón y ya esta todo listo para probar.

Todo en marcha de nuevo, comienzan las pruebas, se hacen albaranes, pedidos, presupuestos, se prueban todos los procesos implicados en documentos que usan los diferentes tipos de IVA y se procesan los albaranes para ser facturados y contabilizados, y ¡voila!, que alegria , porque salvo por un pequeño despiste en presupuestos, todos los demas documentos y procesos funcionaban estupendamente.

Que alegria, despues de unos meses complicados por cambios estructurales imprescindibles, de regeneracion de una parte esencial de la aplicacion que habia desaparecido, y de migraciones en datos que debian ser realizadas “SI o SI”, las cosas parece que empiezan a funcionar y todos estamos alegres y felices.

Lo malo que tienen estas cosas, es que la sensación de euforia suele durar poco, porque a partir de ahi empiezan a surgir otros problemas que nada tenian que ver con los cambios realizados en el mapa,

* desde la ficha del cliente, ¡no puedo entrar en la ficha contable del cliente!
* desde el menu principal, ¡los ficheros de TLR se importan mal, no aparecen los datos del cliente!
* y otros problemas que nada tienen que ver con el IVA, y ademas, en la empresa original, ni siquiera en la copia, teniendo en cuenta que el mapa de la empresa original no habia sido modificado.

Tras varias horas interminables de ayer, y un par de horas mas hoy que solo podia pensar en “Tierra !tragame!”, como una luz me vino a visitar, y parece que el proplema ya esta solucionado.

La causa del problema, precisamente la copia de seguridad, y es que el mapa usado en la empresa hace uso de un fichero VRT, que contiene datos comunes a varias empresas y que por tanto, tambien estaba siendo usado por la nueva empresa de pruebas.

Este problema no hubiera existido de no haber sido por estas pruebas, o quiza hubiera sido mucho peor mas adelante, por otras causas.

El problema en si, “Que habian dos mapas en ejecución, en diferentes empresas, con cambios en la estructura de tablas, abriendo algunos ficheros comunes”

La solución, sencilla, se ha parado el servidor, se ha copiado la carpeta comunes, se ha redireccionado el fichero VRT a la copia de la nueva carpeta y se han separado fisicamente los datos de la empresa original y la de pruebas, y ahora si, ahora todo funciona correctamente y ha vuelto la normalidad.

Y menos mal que teniamos copia el mapa anterior a las modificaciones, porque recuerdo que no es posible restaurar la copia de seguridad si no se dispone de una copia del mismo mapa que hay instalado en la propia copia, en el fichero “VCS”

Pero ¡que susto!, ahora un cafetito y me voy de vacaciones, que me las he ganado, al menos, eso creo.

Y ha salido el sol, al final va a ser un buen dia

aunque, siempre habra alquien que intente joderlo … ¿o no?

Estos ultimos dias, con la salida de V7.4 he empezado a probar un poco mas a fondo la nueva versión, a pese a que los articulos creo que son de lo mas correctos, en algunos casos puede que hayan sido mal interpretados, en cualquier caso no tratan de ser otra cosa que lo que son, criticas constructivas para que aquellos que se quieran dar por aludidos, pues hagan lo que consideren oportuno.

No me dedico a dar ordenes, me dedico a hacer sugerencias, que permitan mejorar, que es a fin de cuentas lo que todos queremos, y para calmar un poco esos animos, que parecen caldearse cuando en realidad no es para tanto, os voy a dejar un cuento:

Estaba un lindo pajarito en su nido, en lo alto de un arbol, temblando de frio, pues sus padres habian salido (a la compra de la semana y a esas cosas), cuando en un descuido y la curiosodad de los peques, se acerco demasiado al borde del nido y se calló al suelo y aunque el golpe no fue demasiado fuerte, unido al tremendo frio que hacia, el parajito perdio el conocimiento.

Ya casi a punto de morir, una vaca se acerco y vacio sus escrementos sobre el pajarito (que desconsiderada la vaca), pero el calor de los escrementos permitio al pajarito reponerse, y a pesar del mal olor que le impregnaba, logro sobrevivir.

Loco de contento, (gracias a la vaca) empezo a piar, aunque apenas podia moverse ya que los escrementos le cubrian casi por completo, y en esto un lindo gatito se le acerco, y haciendo un favor al pajarito le ayudo a salir del estiercol, le ayudo a limpiarse un poco de tanta suciedad y luego ¡se lo comio!

…. ah, que no te gusta el final del cuento, … pues puede que tengas razón, pero es un cuento con moraleja.

¿Que cual es la moraleja?

Pues sencilla:

Que aquel que se caga en ti, no es siempre tu enemigo,

y aquel que te saca de la mierda, no siempre es tu amigo.

Y ahora, ¡a pensar!

Todo el mundo dice que las comparaciones son odiosas, pero gracias a esas comparaciones todas las cosas que conocemos han ido mejorando dia a dia,

Comparar es innato al ser humano.

Porque los coches tienen 6 airbags, pues porque un dia alguien comparo su marca con la marca de la competencia y decicio que si la competencia tenia 2 airbags, podria vender mas vehiculos si le instalaba 6.

Cuando vais a pedir un credito a un banco, ¿que haceis?, pues preguntar costes financieros en varias entidades y comparar, y despues contratar el que mas os conviene.

¿Porque BOLT batio el record de velocidad?, pues sencillamente porque se han comparado los tiempos empleados en realizar las pruebas con los del anterior record mundial /olimpico.

Ya lo dijó Colón, “busca, compara y si encuentras algo mejor ¡compralo!”, poque estaba seguro que dejaba las camisas mas blancas que nadie.

Cuando eres joven y buscas para pillar chicha, ves a dos amigas, y lo primero que haces ¿que es?, ¿comparar? pues te equivocas, no es comparar, lo primero es imaginarte con las dos al tiempo, pero como decides que eso no va a ser posible, comparas y decides cual te gusta mas, por su sonrisa, por sus ojos, por su trasero, o por lo que mas te guste, pero las comparas y luego te decides, y casi siempre… casi siempre… te equivocas, porque luego resulta que tu le gustas a la otra, (como tengo los dientes de blancos).

Básicamente, ¿por que comparamos?,  porque lo necesitamos para saber si lo que tenemos es mejor que lo que tiene nuestro vecino, y asi poder pincharle y darle envidia.

Yo que se por que comparamos, porque si…

Asi que, aunque no os guste he comparado V6 y V7 por que son hermanastras (del mismo padre), y porque no tenia otra cosa mejor que hacer.

Velneo nuestro que estas en el norte, hagase tu volutad …

¡Joder! se me ha olvidao el padre nuestro.