He desarrollado una nueva funcionalidad que permite agilizar los pagos parciales de una factura en Openbravo ERP. Primero explicaré la problemática que tiene la forma de trabajar de Openbravo y porqué se ha pensado en esta solución.
Cuando en Openbravo creamos una factura a esta se le asocian una serie de efectos que inicialmente estarán en estado «–» (pendiente), el condicionante es que una vez procesada una factura (completada en terminología de Openbravo) el total de los efectos debe ser igual al total de la factura. Como consecuencia de este requisito lo que hace Openbravo es que al completar una factura automáticamente te crea los efectos en base a las condiciones para ese cliente según su ficha en datos maestros. El problema que tiene esta solución es que estamos vaticinando como y cuando vamos a cobrar según la forma y condiciones de pago del cliente pero eso a veces no corresponde con lo que finalmente va a suceder.
Vamos a poner un ejemplo muy sencillo en el que la forma de pago es «giro bancario» y nos van a pagar a 60 días. Resulta que el cliente nos hace un pago parcial a los 20 días en efectivo, ¿cómo reflejamos esto en Openbravo?. De entrada tenemos un problema porque si hemos completado la factura se nos debe haber creado un efecto por el total de la factura con vencimiento a 60 días y este será el que actualmente tendremos en cartera de efectos.
Para este tipo de conflictos Openbravo nos provee de una herramienta que se llama «Liquidación» y que nos permite transformar unos efectos en otros. Esta herramienta tiene como entrada de 1 a n efectos ya existentes que son los que se van a cancelar y como salida de 1 a n efectos nuevos que son los que se van a generar, cómo es lógico la condición es que la suma de los efectos cancelados coincida con la suma de los efectos generados.
Por tanto la forma de solucionar el problema que tenemos es:
- crear una liquidación en la que cancelamos el efecto de la factua a 60 días y genermos dos nuevos, uno con las mismas condiciones del original pero por cantidad del total de la factura – el efectivo adelantado y el otro con condiciones de pago en efectivo por valor de la cantidad adelantada.
- Este último efecto es el que cobraremos por banco, caja o lo que corresponda dejando pendiente el segundo efecto generado.
En este caso particular en el que sólo se va a hacer un pago parcial existe otra solución que consiste en:
- Reactivar la factura (desprocesarla) con lo que los efectos que se generaron al completarla desaparecerán.
- Ahora en la pestaña de efectos de la factura añadimos un nuevo efecto que correponde al pago parcial en efectivo.
- Volvemos a completar la factura, esto provoca que Openbravo vuelva a generar los efectos según las condiciones del cliente, pero esta vez por la cantidad pendiente ya que tiene en cuenta el efecto que acabamos de introducir.
- Cobramos el efecto por banco, caja o lo que corresponda lo que implica que la factura queda definitivamente bloqueada y no se podrá reactivar.
En resumen, la segunda solución es la más ágil y cómoda pero tiene el inconveniente que sólo se puede hacer un pago parcial. La primera solución es el estandar en Openbravo, cuando queremos manipular efectos debemos hacerlo mediante una liquidación, pero tiene el inconveniente de que el hecho de tener que pasar por el proceso de crear y procesar una liquidación es lento (es el usuario el que debe introducir los datos de los efectos a generar, sus condiciones, cantidades… además de tener que hacer el cálculo para que el total de efectos generados y cancelados cuadren).
Al final hablando con un cliente se encontró una solución, primero veamos su especificación funcional:
- Creamos y completamos una factura, esto como ya hemos comentado nos genera sus efectos.
- Cuando el cliente nos hace un pago parcial que cobraremos por banco o caja vamos a «Extracto bancario» o a «Diario de caja» y creamos un nuevo registro.
- Añadimos el efecto de la factura como linea con lo que en el caso de caja el campo «Importe» de la linea se rellena con el total del efecto y en el caso de banco sucede lo propio con el campo «Imp.declarado».
- Si nos fijamos estos campos son editables así que una vez aplicado el parche podremos modificar dicha cantidad y en su lugar poner un valor entre 0 y el total del efecto.
- Procesamos el «Extracto bancario» o el «Diario de caja»
Nota 1: En cualquiera de los dos casos, banco o caja, al guardar la linea con el nuevo importe el efecto de dicha linea automáticamente será substituido por uno nuevo que refleje esa cantidad, por lo tanto si volvemos a modificar la cantidad y ponemos un valor entre 0 y el nuevo importe se volverá a repetir el procedimiento.
Nota 2: En este punto la única forma de volver atrás es desprocesando la entrada de caja o banco, eliminando la linea y por último desprocesar y eliminar la liquidación que se ha generado de forma automática por debajo.
Como se decía al principio el propósito de este desarrollo es agilizar los pagos parciales evitando tener que hacer una liquidación de forma manual. El atajo consiste simplemente en que en el momento de cobrar indicas una nueva cantidad y es el sistema el que hace la liquidación de forma automática por debajo dejando todo listo para que sólo tengas que procesar el banco o caja.
Ahora veamos como aplicar el cambio. Lo primero que debemos hacer es descargarnos el parche:
partialpayments.tar.bz2
partialpayments.tar.bz2.md5
Después de copiar estos dos archivos al raiz del código fuente de nuestra instalación de Openbravo ERP debemos comprobar que se han bajado correctamente:
md5sum -c partialpayments.tar.bz2.md5
Si todo esta bien ya podemos descomprimir y desempaquetar el parche:
tar xvfj partialpayments.tar.bz2
Y por último debemos actualizar nuestra base de datos:
ant update.database
Ya sólo queda decir que este parche está bajo licencia gpl versión 3.
Nota: Se ha elminado el archivo ya que sólo es compatible con versiones antiguas de la 2.40.
Cheli
Supongo que esto será para Openbravo 2.40 no?
No te animas a hacer un módulo para 2.50?
En principio y mientras no cambie mucho la definición de las dos tablas implicadas, cosa que dudo que haya sucedido en 2.50 pero no puedo asegurar porque no lo he comprobado, este parche debería funcionar en cualquier versión 2.x.
No, no me animo a hacer un módulo, de hecho todavía no he tocado apenas la 2.50 como aquel que dice pero si que he leido toda la documentación técnica y funcional y he visto algunas cosas. En términos de desarrollo los módulos aportan muy poco ya que la diferencia de desarrollar con módulos o no es que ahora todos los problemas clásicos con dbsourcesmanager, conflictos de código, etc se han transladado del core a los módulos pero esos problemas no han desaparecido, siguen siendo los mismos de siempre. Si a esto le sumamos el trabajo de tener que crear y mantener el módulo pues…
La única y nada desdeñable ventaja de los módulos y las plantillas está en los entregables. Ahora puedes meter tu código y/o datos en un módulo y permitir a un usuario instalarlo en un click, lo que pasa es que en el caso de este parche considero que aplicarlo es muy muy sencillo con lo que no le veo ninguna ventaja al hecho de modulizarlo o no. Además como ya sabes si lo entregara como módulo solo serviría para la versión 2.50 y no como ahora que sirve para cualquier 2.x.
Estos son los motivos por los que no va a existir ningún módulo para este parche.
Un saludo.
Cheli,
Así como otras veces he criticado algún post tuyo, esta vez tengo que felicitarte. Este tipo de artículos además de enseñar funcionalidad del sistema, aportan un gran valor por el desarrollo en sí.
Este parche va a ser de gran utilidad para versiones anteriores a la 2.50.
De todas maneras, mostrar a la persona del primer comentario que la versión 2.50 trae esta funcionalidad incluida en el core del sistema.
http://wiki.openbravo.com/wiki/ERP/2.50/ReleaseNotes#Revised_Functionality (5693)
En un extracto bancario, cuando estás seleccionando efectos para darlos como pagados/cobrados a través del botón de «crear lineas de», cada efecto tiene un campo de «importe propuesto» editable.
Imaginemos que tenemos un efecto de 100€ que proviene de una factura de pago. Cuando vamos al extracto bancario a darlo como pagado, si en el campo «importe propuesto» ponemos 60, la aplicación por detrás creará una liquidación partiendo el efecto de 100€ en uno de 40 y otro de 60, y a su vez dará el de 60 como pagado.
Todo esto será transparente para el usuario, que verá como en el sistema queda un efecto de 40 pendiente.
Esta funcionalidad es muy similar a la que ha desarrollado Cheli, y que está disponible en la versión 2.50 sin módulos adicionales.
Por último, Cheli, me sorprende lo que dices que los mismos problemas de conflictos se mantienen al desarrollar un módulo para la versión 2.50. Tengo entendido que la 2.50 introduce el concepto de UUID, por el cual los ID de las tablas pasan a ser palabras de 32 carácteres creados aleatoriamente por un generador. Es de suponer que esto evite por completo la generación de conflictos al desarrollar un módulo y al instalarlo en un entorno independiente. A qué te refieres?
Un saludo,
Julius.
Gracias a los dos por vuestras explicaciones. En principio no necisto la funcionalidad, pero está bien saber que esto ya está en 2.50. Lo suyo sería que lo metieran como «backport» en 2.40, también.
A cheli, yo he estado trasteando con módulos y tengo unos comentarios que hacer al respecto:
– Como dice Julius, el uuid es una mejora tremenda. Si quieres hacer un proceso que haga inserts, te puedes olvidar del get_sequence_next y ese coñazo. No hemos desarrollado en paralelo todavía, pero sí que supongo que en código a mezclar, se van a obviar muchísimos problemas.
– Creo que la única ventaja no está en los entregables, también en la diferenciación clara de qué es Openbravo core y qué es un módulo, además de que en un proyecto puedes separar mucho más facilmente un módulo, de sus traducciones, de otro módulo que corrige/modifica/implementa otra funcionalidad, etc.
– Por lo que yo he visto, meter triggers, nuevas tablas, nuevos campos, procesos, y tal, es muy fácil. Los procesos de empaquetación y exportación/importación han funcionado sin problemas.
– Mis desarrollos los he hecho en oracle pero luego no los he podido portar a postgre. Creo además que los módulos no son completamente independientes de base de datos.
– actualizar de la 2.50 a 2.50MP1 funcionó perfectamente. Estos procesos sin embargo consumen mucha memoria. No funcionan bien en las máquinas virtuales.
Un Saludo
Por cierto, respecto a tu parche, me he fijado en una cosa.
– Si el usuario ejecuta el update.database antes de haber hecho un export.database, perderá todos los cambios que haya hecho, ¿no?
Veo que el clásico marketing de Openbravo y sus medias mentiras sigue funcionando, en eso los catalanes de Openbravo son unos expertos y por eso la mayoría de mis comentarios se centran en tener que matizar las cosas que dicen.
Empecemos por UUID, UUID no es un gran avance ya que los problemas que pretende solucionar ya estaban solucionados en versiones anteriores ¿cómo crees sinó que desarrollaban las decenas de programadores de OB sin colisionar entre ellos?. Para versiones anteriores a la 2.50 se utilizaba una cosa que se llama identificador de desarrollador y siempre que para cada proyecto se le asignara un identificador único a cada desarrollador y este fuera escrupuloso en utilizar el identificador que tenía asignado para cada proyecto en el que estaba no había ningún problema. Este mecanismo consistia en que para cada identificador de desarrollador se te asignaba un rango de registros para las claves primarias de cada tabla de diccionario pero esto no sucedía para datos maestros (master data) ya que en principio no tiene sentido. Ahora bien, lo que han querido hacer con UUID es que puedas coger una serie de datos maestros y empaquetarlos sin colisionar, eso antes también era posible pero siempre que lo hicieras por ejemplo con un script sql a base de inserts de forma que se te vayan asignando los identificadores para esa instalación, y siempre y cuando no tengas conflictos de integridad referencial entre tablas. Si lo intentabas hacer desde dbsourcemanager colisionaba por lo ya comentado, no se tenía en cuenta el identificador de desarrollador para datos maestros.
En cuanto a rendimiento UUID es un paso atrás bastante importante, típicamente se utilizan enteros para claves primarias en bases de datos ya que indexan mucho mejor lo que implica mayor rendimiento y porque en consultas sql como por ejemplo los join también son considerablemente más eficientes. Ahora hemos pasado de tener como claves primarias un NUMBER(10), o lo que es lo mismo un entero razonablemente pequeño a un varchar(32) que es una cadena realmente grande pero bueno, este inconveniente los que tomaron la decisión de adoptar UUID ya lo sabían.
A conflictos me refería principalmente a conflictos de código pero para explicar que en cuanto a desarrollo mi opinión es que los módulos no aportan nada y que no solucionan absolutamente ningún problema de los que ya existian tendría que escribir un nuevo apunte. Si algún día me da por escribir ese artículo vosotros mismos podréis ver lo fácil que me va a resultar desmontar todo ese marketing que os han colado.
Esto no quita que como ya dije los módulos y plantillas son una gran ventaja para generar entregables, pero en cuanto a desarrollo no lo son.
Cheli
Hola Cheli,
Para empezar déjame decirte que puede que hable desde el desconocimiento ya que me doy cuenta que tú tienes más experiencia con Openbravo. Pero aún así me gustaría profundizar, pues tendré que trabajar con esta herramienta y no sé todavía que me voy a encontrar.
Teóricamente, si las actualizaciones de Openbravo sólo van a afectar al core, y además se hacen sobreescribiendo (fíjate en el .obx de la MP1, es casi igual que el propio .tar que está en sourceforge), no implica esto que no va a haber conflictos de código?
Por otra parte mantengo mi opinión de que los módulos sí que aportan a nivel de desarrollo, sobre todo en cuanto a organización y claridad. No me has dado ningún argumento para desmontar esta afirmación, que claramente debe de haber sido una gran mentira que me han colado desde cataluña.
Con esto quiero decirte que me gustaría hacer debate y mostrar opinión, pero no que entremos en descalificaciones.
Hola Pepe, como veo que estás impaciente no me va a quedar más remedio que dedicar parte de la tarde a escribir ese apunte al que hacía referencia.
Creo que ha habido un malentendido, no pasa nada suele suceder cuando se «conversa por escrito» en foros, correos-e y demás. La alusión a los catalanes es porque la parte de marketing, consultoría y demás cosas suele corresponder a los que dirigen la empresa y estos en su mayoría son catalanes que están en la oficina de Barcelona. El problema de estos es que son comerciales excesivamente agresivos empezando por su director general y suelen llevar sus argumentos comerciales tan al límite de la mentira pero siempre sin llegar a esta para que con rigor nadie pueda decir que mienten. Eso si, los que sabemos un poco del producto se nos queda una cara de ¡este se piensa que yo soy imbécil!. Tranquilo, que no es una cosa de Openbravo, es sabido que esto lo hacen el 95% de las empresas pero eso no quita que sea una mala práctica y que por tanto tenga el derecho a decirlo, a ver si por casualidad ese 95% algún día desciende.
En contraposición la gente de Pamplona, quitando alguno de los directivos que circulan por ahí de los que también me han llegado algunas perlas, no suele haber problemas ya que la mayoría son ingenieros o profesionales en su rama y se dedican a temas técnicos. Mi experiencia personal con los desarrolladores de openbravo en general ha sido fantástica ya que he tenido la suerte de tener la colaboración en algún proyecto de alguno de los profesionales que tienen en ingeniería, el soporte es otro cantar, ahí he tenido de todo. Es más en temas comerciales yo paso, no es mi ámbito pero en temas técnicos cuando he tenido la oportunidad de hablar con algunos ingenieros de Openbravo suelen estar bastante de acuerdo conmigo, ellos saben perfectamente que decisiones se toman y porqué y que ventajas y debilidades tiene cada nueva funcionalidad. Si ellos fueran los comerciales seguro que no tendríamos que escuchar algunas de las pseudomentiras que tenemos que aguantar.
Si te esperas un rato podrás leer el artículo, aunque me da la impresión que después de leerlo seguirás sin estar de acuerdo.
Un saludo.
Hola Cheli,
Visto que tampoco yo estoy trabajando mucho esta tarde, te voy a contestar 🙂
Voy a esperar a leer el artículo y así podremos intercambiar opiniones. No puedes asegurar desde ahora que no voy a estar de acuerdo. Es posible que discrepe en todo, en algo o en nada.
El problema, por lo que he leído de tus posts, es el lenguaje y el tono con el que escribes aquí. Ya sé que es tu casa y que puedes hacer lo que quieras, pero mi consejo es que te moderes. Es decir, mete toda la caña a quien quieras, a mí me mandan implantar Openbravo o Navision, o lo que toque.
Te pongo ejemplos de este tono, cosas que a mí personalmente me han molestado:
-«me da la impresión que seguirás sin estar de acuerdo»
-«como veo que estas impaciente no me das mas remedio»
-«ese marketing que te han colado»
-el tema de los catalanes (esto ya has explicado que es un malentendido)
Enfin, desde el mayor respeto, y con ganas de mantener un tono amistoso, te digo estas cosas.
Un Saludo.
Hola Pepe, lo cierto es que yo no es que no esté trabajando es que estoy de vacaciones y ya ves, aquí dando la lata 😀
El hecho que diga que seguirás sin estar de acuerdo es porque me da la impresión que ya tienes hecho tu juicio sobre Openbravo y eso es muy difícil de cambiar, pero bueno es tu opinión y como se suele decir es como los culos cada uno tiene el suyo. Lo de que estás impaciente es porque te había indicado que cuando tuviera un momento y ganas escribiría un apunte sobre el tema, pero al contestarme así me dejas en evidencia al decir que no te he dado ningún argumento y por tanto me veo con la obligación moral de hacerlo lo antes posible. Como dices, no puedo estar rajando y luego no dar explicaciones de porque rajo. En cuanto al marketing es una fras más dirigida a mi mismo que a ti, me da rabia que le tomen a la gente el pelo y si lo has tomado en plan «mira a este pardillo que se las cuelan todas» no es así.
Total que aún así a veces si que es cierto que pretendo crear cierta polémica, no creo que sea malo siempre que se genere debate y todo el mundo sea educado.
Cuando leas el apunte ya me comentas.
Saludos.