[Javier Ader]

Buenas. Como comente en este otro thread https://www.libertya.org/comunidad/foro-libertya/8-desarrolladores/3227-semantica-de-invoiceopen-cinvoicev- estoy intentando migrar las funciones PL/Java a PL/PGSql; esto brevemente tiene las siguientes ventajas:
-mejor performance
-mejor mantenimiento
-mejor legibilidad
-simplicidad de implementación e instalación
-futura migración a PostGreSQL 9.0
-dejar de depender del proyecto PL/Java que esta muy poco mantenido.

En lo personal ando medio complicado de tiempo en estos dias, pero mi mayor escollo actual es no esta muy clara la semántica actual de muchas de estas funciones bajo Libertya actual (en realidad, creo que hay varios bugs…); implementar las funciones en PL/PGSql es en realidad la parte más simple si se parte del comportamiento esperado. En este sentido creo que, si esto avanza, habria que de consensuar entre todos varias definiciones, y posiblemente modificar codigo actual (esto principalmente porque mirando varias partes no parece para nada claro ciertas cosas; por ej, la migración de “montos positivos a negativos” creo quedo por la mitad en varios lados).

Para empezar planteo algunas cosas (algunas ya puse en el otro thread):
1) Lo montos totales de las facturas/notas de debitos/notas de credito (sin importar si son de proveedor o a acliente) deben tener montos positivos?
Por simplicidad (y creo que actualmente es asi; pero lo ideal seria que le mismo codigo lo requierea) deberia ser asi.

2) Los montos de alocación (pagos a facturas) son siempre no negativos? De nuevo, esto creo que debería (y es) asi actualmente.

3) Los montos de alocación podrian superar el monto de la factura? El codgio actual parece negar esto.

4) Como se considera que una factura o n.d esta pagada? Mi idea es que, la respuesta incial es que C_Invoice.IsPaid = ‘Y’ (esto tiene gran importancia para calcualar cuanto nos deben o debemos a una determinada EC); la respuesta “completa” que implica cuando el flag anterior debe setearse a Y es que la invocación a la funion invoiceOpen((idFactura,0) = 0 (exactamente igual a cero; posiblemente negativo si se puede “sobre pagar” una factura). De aca la importancia de la semantica esperada de esta función y de los puntos anteriores, esta que la idea es que esta función retorne “cuanto falta para saldar completamente una factura”; pero para esto hay que definir si los montos son positivos o posiblmente negativos de muchas otros objetos relacionados.

5) Notas de credito: cuando se debe considerar “pagada” una NC? (y de paso, que significar pagada en este contexto…), y como se debería calcular el monto pendiente de la misma para ser usada total o parcialmente como parte de pago?
Mi enfoque actual, es que simplemente sigan las mismas reglas generales de las facturas; en particular el actual inoviceOpen (tanto en PL/Java como en PG/SQl que posteo más adelante) simplemente calcula “la suma de las alocaciones directas y los montos que ya se usaron como medio de pago); el calculo actual respeta el ejemplo que pongo en la thread que referi. Basicmente: invoiceOpen sobre una nota de credito retorna el monto (no negativo) de la misma que aún puede usare como medio pago; retorna 0, cuando ya se uso totalmente o se “pago” de manera convencional (hay que ver este ultimo punto con más detenimiento; actualmente , no parece que se puede pagar un N.C como si fuese una factura normal, pero a mi entender tiene sentido)

6) Finalmente los montos de los pagos (C_Payments) y los de las lineas de caja (C_CashLine)…. aca si parece no respetarse “lo montos son positivos”; realmente no le veo sentido (al menos por parte de C_Payment) permitir montos negativos, conceptualmente, un pago siempre es un valor positivo, el sentido del mismos (si es un cobro a cliente, o un pago a proveedor) se debería determinar de otra manera (en realidad, se determinar de otra manera actualmente, usando IsReceipt). Algo similar para las lineas de caja (aca ya lo veo más dificil, pero de nuevo, seria mucho más claro conceptualmente que el monto sea positivo; el sentido que se determine mediante otro campo). También (y esto relacionado con “cuanto nos debe o debemos a una EC”) es como manejar pagos por adelantado.

En cualquier caso, habría que ver cada una de las tablas y campos relacionados a estos temas y definir claramente que valores puede tomar y su significado; no son tantas, pero el tema es que desde código son usadas desde muchos lados (en particular C_Payment).

Ok, más allá de esto, les paso lo que tengo hecho actualmente:

http://www.mediafire.com/?h70x1acdqdpop

[estan todas las bomXXX, con algún detalles de cambio semántico; todas las currenyXXX, ivoiceOpen y paymentAvailable; esta ultima no funcionando correctamente para pagos a proveedor, ya estos toman montos negativos, pero las alocaciones a los mismos no; el fix que requiere es simple, pero hay que ver si esta función debería retornar valores negativos]

Pienso que tal vez habría que levantar un repositorio en algún lado e ir actualizándolo; yo no tengo problemas de hacer uno en sourceforge y darle permisos de admin a quien desee colaborar de los partners. Debería poder terminarse bastante rápido si nos ponemos de acuerdo en la semántica de las mismas; como dije, llevarlas a cabo, es bastante simple.

Saludos
Javier

[Cognitiva Consultores]

Javi, me parece estratégicamente importante liberarnos de pl/java… En lo que podamos colaborar ahí estaremos. Sería genial que la gente del proyecto también acompañe, porque realmente creo que simplificaría mucho el mantenimiento y la optimización.

[Federico Cristina]

Javier,

Gracias por el aporte. Este es un tema que estamos barajando desde hace tiempo, con la intención de quitar PL/Java definitivamente, justamente por las ventajas que comentás.

Procuraremos delinear las especificaciones necesarias a fin de converger a una solución lo más consistente posible.

Saludos,
Federico

[Javier Ader]

Buenas. Estuve avanzando un poco; me faltan unas pocas nada mas.
Subí el proyecto a SF; acá pueden ver el changelog de la ultima versión a la actual
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/log/b99d2acbc46d

Copipasteo el shortLog:

Code:

66 minutes ago Javier Ader PaymenTerm – paymentTermDiscount agregado default tip changeset | files
7 hours ago Javier Ader PaymentTerm – paymentTermDueDate agregado – un Bug PL/java corregido changeset | files
12 hours ago Javier Ader PaymentTerm – paymentTermDueDays agregado – un BUG PL/java solucionado changeset | files
37 hours ago Javier Ader PaymentTerm – funciones auxiliares lastDayOfMonth y calculateDateDue changeset | files
47 hours ago Javier Ader agregado firstOf changeset | files
2 days ago Javier Ader Nuevas funcion nextBusinessDay (simple) changeset | files
2 days ago Javier Ader Funcion addDays agregada (en OpenXpertya) changeset | files
3 days ago Javier Ader Funcioes de fechas: trunc y daysbetween (en OpenXpertya) changeset | files
3 days ago Javier Ader se agrego PaymentAllocated.sql changeset | files
3 days ago Javier Ader commit inicial changeset | files
(0) tip

Algunos comentarios:

-en la version PL/Java actual hay varios pequeños bugs que se dan solo ocasionalmente (por ej PaymentTermDueDays a veces le erra por un dia; PaymentTermDueDate hace lo mismo). Esto me ocurrió corriendo varios de los tests que estan en test-paymentTerm.sql. Realmente no se porque ocurren; mirando el codigo java de las funciones da la sensación de que no deberían pasar (lo extraño es que para casos muy similares en uno le erra y en otro no…..)

-Los test-paymentTerm.sql (y los otros archivos tests que hay) los corro sobre una base con PL/Java y en otra idéntica salvo que tiene PL/PGSql; los resultados son los mismos, salvo cuando la versión en PL/Java comete un error (esto es, los resultados me difieren cuando la versión PGSql corrige el bug)

-no testie completamente a paymentTermDiscount porque para en mis bases tengo todos C_PaymentTerm que no aplican descuentos (aplican descuento 0%). Si alguien tiene una base de datos con terminos de pago que aplican descuentos (y facturas asociadas) y me los testea, se agradece (simplemente habría que correr los scripts en test-paymentTerm.sql para esta función y ver si dan los resultados esperados)

-Dicho sea de paso; estos descuentos (y las fechas de vencimiento de los términos de pago) y la semántica de varios de los campos que afectan a los algoritmos y la idea de estos últimos, creo que habría que detallarla (hay datos que no se usan, otros que no tiene mucho sentido….). Supongo que habría que hacer otro thread aparte, ya que hay bastante variantes.

-los scripts, si se aplican en orden “correcto” (en realidad, creo no es totalmente necesario respetar el orden, ya que postgres no parece chequear dependencias desde dentro de código pgSql )deberían poder aplicarse sobre cualquier base actual y no deberían ocurrir problemas. En cualquier caso, en cuanto me haga un tiempo hago su solo script que aplique todos los cambios a la vez (y agregue un par de nuevas funciones que antes no estaban), así no se tiene que andar aplicando función por función.

Finalmente, le dejo un snapshot de la actual versión: nuevasFunciones-30-06-11-a6820d9d931e.zip, por si la quieren bajar de acá (desde sorceforge se puede browsear los archivos desde acá http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/summary siguiendo el link files, o bajarlos usando cualquier cliente mercurial)

http://www.mediafire.com/?t03g33dvzjaancl

Cualquier comentario, duda, sugerencia, etc…

Saludos

[Cognitiva Consultores]

Javi, para probarlo habría que correr los scritps y también cambiar las llamadas en las clases o manteniendo los mismos nombres de procedures no habría conflicto?

[Javier Ader]

Que tal Fede. En teoria deberias correr los scripts y nada mas; lo que hacen simplemente es redefinir (usando un CREATE O REPLACE FUNCTION ) las funciones hechas en PL/Java para que ahora usen la definición en PGSql, pero manteniendo el mismo nombre y los mismo parametros y tipos.
Pongo como ejemplo solo para las funciones BOMPrice:

NOTA: ahi mire y el parece me falto poner en el repostitorio bomPriceStd (estaba bomPriceStd.txt pero era incorrecta); ahi subi el nuevo bomPriceStd-2int , lo puede bajar dese aca http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/cc64eff3e474/BOM/BOMPriceStd-2int.sql ; simplemente copiar y pegar)

1) Ejecutar ROUND.sql : crea una nueva funcion requerida por las demas funciones PGSQL
(todos los siguientes estan bajo dir BOM)
2) PriceLimit:
2.1) Correr BOMPriceLimit-2int-conCorreccionNull.sql y BOMPriceLimit-3int.sql (esto redefine la actuales funciones PL/java libertya.bompricelimit(m_product_id integer, m_pricelist_version_id integer) y libertya.bompricelimit(m_product_id integer, m_pricelist_version_id integer, m_attributesetinstance_id integer). La cnatidad de funiones en este este punto es identica a la anterior.
3) PriceList: idem anterior pero corriendo BOMPriceList-2int.sql y BOMPriceList-3int.sql
4) PriceStd: correr http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/cc64eff3e474/BOM/BOMPriceStd-2int.sql (ya que no esta en el zip que postie antes) y BOMPriceStd-3int.sql

En este punto podes correr este test:

Code:

set search_path to libertya;

select
P.M_Product_ID,p.Name,PP.M_PriceList_Version_ID,
bomPriceStd(P.M_product_ID,PP.M_PriceList_Version_ID),
bomPriceLimit(P.M_product_ID,PP.M_PriceList_Version_ID),
bomPriceList(P.M_product_ID,PP.M_PriceList_Version_ID),
P.AD_Client_ID
from
M_Product P inner join M_ProductPrice PP on (p.M_Product_ID = PP.M_Product_ID);

o (los precios de todos los productos en todas las versiones de lista activas)

Code:

select
P.M_Product_ID,p.Name,PLV.M_PriceList_Version_ID,
bomPriceStd(P.M_product_ID,PLV.M_PriceList_Version_ID),
bomPriceLimit(P.M_product_ID,PLV.M_PriceList_Version_ID),
bomPriceList(P.M_product_ID,PLV.M_PriceList_Version_ID),
P.AD_Client_ID
from M_Product P inner join M_PriceList_Version PLV
on ( P.AD_Client_ID = PLV.AD_Client_ID)
where P.AD_CLient_ID = 1010016
AND PLV.IsActive = ‘Y’

En este punto, logueandote en libertya y abriendo la ventana de información de productos, estarías testeano de otra manera las mismas funciones. Esta ventana también usa las BOMQty, que tambien estan hechas actualmente en PL/Java, asi si queres, que para migrarla totalmente deberias correr los siguientes scripts:

5) BOMQty
-BOMQtyReserved-3-int.sql, BOMQtyOrdered-3-int.sql,BOMQtyOnHand-3-int.sql, BOMQtyAvailable-3-int.sql

Después de esto, todas la funciones PL/Java relativas a precios y stock estarían migradas.

---

Aprovecho y planteo una cosa sobre los productos BOM, que actualmente hace que las funciones BOMPrice sean muy costosas (tambien en PGSql) cuando no encuentran el precio de manera directa: M_Product.IsBOM actualmente no se esta teniendo en cuenta en algoritmo (tampoco en PL/Java), por lo tanto a veces se cae en una llamada recursiva innecesaria. Dicho esto, pregunto, si un product es BOM, tiene que tener este flag en ‘Y’ no?

[Matías Nerón Cap]

Javi (perdón el atrevimiento) pasé las currencyxxx a la versión LY 11.05 que está por salir. Te quería comentar que me saltó un errorcito cuando lo estuve testeando (cargando facturas, completando, etc.)
En la función currencyround() que es nueva, en las dos sentencias RETURN ROUND() con las precisiones de costo y std de c_currency, hay que castear explícitamente a integer las precisiones. Las dos sentencias quedarían:

Code:

RETURN ROUND (p_Amount, v_CostPrecision::integer);

Code:

RETURN ROUND (p_Amount, v_StdPrecision::integer);

Cualquier cosa avisa…
Saludos
Matías Cap

[Javier Ader]

Muchas gracias por testear Matias! No es ningún atrevimiento, es un aporte. En cuanto al ROUND, es como decis, el tema es que deberias haber corrido el ROUND.sql que esta en la raiz; esta funcion justmante hace que todos esos castings sean innecesarios (y en realidad, ese round se usa desde muchas otro lados; al parecer hay muchos campos a nivel de base de datos que tienen “numeric” cuando deberian tener integer; de ahi el problema on el ROUND… postgres tiene un ROUND(numeric,integer), pero no un ROUNT(numeric,numeric); este ultimo round es el que justamente agrega ROUND.sql).

Más allá de eso, ya que estas testeando las conversiones de moneda (algo que yo testie pero sin mucho mirar “casos reales”, ni jugar mucho con las fechas de validez), es que las versión de PGSql al igual que en PL/Java soporta la idea de si no encuentra una conversión directa, usar la inversa; pero a diferencia de PL/Java no usa nunca el “divisor”, si no que lo calcula “al vuelo”, a partir del multiplicador (1/multiplicador) de la conversion inversa; creo que esta forma es mas clara (por lo menos más simple…). El campo divisor pasaria ser una especie de campo informativo, ya que realmente no se usan para los cálculos.

Ok, últimas novedades:
BOM:
-agregue un scripcito (simplemente la concatenación de otros) que aplica en un paso todas la funciones BOMxxx y el ROUND.sql
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/64a4dfc78e8a/BOM/ALL_BOM.sql
simplemente copiar y pegar en PGAdmin, correr y sale andando.
-unos tests para las bom (los mismos que postie acá, asi ya quedan)
Invoice:
-agregue dos InvoiceDiscount, una que emula lo que hace actualmente PL/Java (nvoiceDiscount-actual.sql), y otra que es la que sugiero, ya que para mi es incorrecto como fucnciona actualmente; ver invoiceDiscount-sugerida.sql y invoice-notas.txt para una explicación de porque pienso que hay algo mal. De cualquier manera, probablemente todo este tema de los descuentos, como plantie antes, merezca una discución un poco más profunda; ya haré un thread al respecto.
-test para invoiceOpen e invoiceDiscount

http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/b99a62d8339f/Invoice/Notas-invoice.txt
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/b99a62d8339f/Invoice/invoiceDiscount-actual.sql
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/b99a62d8339f/Invoice/invoiceDiscount-sugerida.sql
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/b99a62d8339f/Invoice/tests-invoice.sql

Si no me equivoco, faltan trasladar 2 o 3 funciones PLJava.

Saludos
Javier

[Cognitiva Consultores]

Javi, ya tenemos en laboratorio la 1105 beta sin pl/java. Directamente corrimos tu script y ya estamos probando. En ese orden quería consultarte lo siguiente:

El impacto funcional de pl/java, se circunscribe a la infoProduct, BOM y alguna otra cosa mas? redondeos? Como para saber que puntos funcionales ir a testear además de los procesos normales de venta.

Gracias por el aporte y esperamos acompañar un poco con el testing.

Gracias!!!

[Javier Ader]

Que tal Fede. De modo resumido:
bomXXX: utilizada desde infoProduct y desde casi cualquier proceso que tenga que ver con precios de lista o cantidades de stock. Lo unico raro aca es cuando uno define un producto bom pero no le asocias un precio: la idea de la funcion es calcular el precio a partir de sus componentes (no se si tiene mucho sentido, pero es como funciona); lo mismo para la cantidad en stock, si no encuentra stok directamente (aca si tiene un poco de mas sentido, pero para ciertos tipos de BOM); aca el algoritmo es un poco más complicado.

currencyXXX: utilizada por cualquier documento o vista (informes) en los que se utilicen mas de una moneda o una moneda distinta a la asociada a la compañía (por ej, el crédito usado de la EC esta implícitamente en la moneda asociada a la compañía y se calcula a partir de Invoices que por ej, pueden estar en otras monedas). Estas funciones son usadas por muchas otras (en realidad por casi todas las que tengan que ver con montos)

paymentXXX: utilizada (o deberían serlo )por cualquier proceso que asocie pagos (C_Payments) a facturas de manera diferida (todo menos efectivo); en general para pagos adelantados; en general están para saber si un determinado pago esta totalmente “usado” (en teoría un mismo pago puede saldar parcialmente muchas facturas; incluso permanecer parcialmente usado). Igual esta medio rara esta parte; al menos los pagos adelantados de Orden de Pago/Cobro, según este algoritmo quedan “usados”.

invoicePaid/invoiceOpen: sirven para saber cuando se pago de una factura o cuanto falta pagar (implícitamente usando la moneda de la factura). InvoiceOpen en particular se usa para calcular (al menos en 10.09) el credito usado; ademas, en el caso de que se le pase un segundo parámetro distinto de null o cero, y en el caso de que la factura tenga asociada un esquema de vencimiento/cuotas, sirve para saber cuanto resta pagar determinada cuota; por ej
F1 de 100 , a 30 y 60 dias, con 40% y 60% en cada cuota: cuota 1 a 30 dias = 40$, cuota 2 a 60=60$; si paga 50$, la cuota 1 debería retornar 0 (siempre se salda las cuotas en orden creciente de vencimiento, como es de esperar), y la cuota 2 = 50$ (el pago anterior saldo 10$ de los 60$)

paymentTermXXX: todas estas están asociadas términos de pago PERO SIN vencimientos de pago /cuotas (por ej, un termino de pago a 30 dias, pero que sin entradas en la segunda pestaña); estos términos de pago son siempre por el total (o si queres “una sola cuota”); el tema aca es que por un lado estan las que calculan cuando un termino de pago se vence dada un determinada fecha de documento (típicamente una factura) y las otras, el descuento que debería tener el pago…. acá parece haber un mezcla de semánticas de lo que pasa cuando se usa vencimientos de pago/cuotas… Tal vez habría que eliminar esta parte y obligar a usar siempre un esquema de pago (si queres inmediato 1 sola cuota a 0 días….). Estas igual, no parecen estar en uso; tal vez la usen un par de vistas (y por lo tanto informes).

invoiceDiscount: para saber que descuento se se podría aplicar a una factura si se paga en determinada fecha; depende a veces de las de paymentTermXXX y a veces de los que dice los esquemas de pago… de ahí que haya funcionamiento medio distintos; la historia parece haber sido asi: primero solo se soportaba medios de pago a una sola fecha de vencimiento (pero con son posibles fechas para aplicar descuentos), después se agregaron “cuotas”, pero acá, la fechas finales se podían modificar manualmente (esto creo que es mucho mas flexible), así como también los descuentos… salvo que ahora hay un solo descuento posible (paymentTerm de manera directa soporta 2), e invoiceDiscount tiene un bug a mi entender (de ahi que subi invoiceDiscount-sugerida.sql)… en el camino quedo como una mezcla de enfoques distintos. Igual , creo que actualmente, no se usa desde código.

varias asociadas a fechas: en particular nextBusinessDay: esta tiene relación con el tilde próximo dia hábil del termino de pago; (la idea es que si el termino de pago es a 10 días, pero, esa fecha es domingo, bueno, que se pase para el lunes). Esto es usado en términos de pago “sin cuotas”, pero no cuando tiene cuotas (esta es otra diferencia semántica); en ninguno de los casos, se utiliza actualmente los días no hábiles no “standard” (digamos, navidad), que se especifican en la tabla C_NonBussinesDay.

Ok, esto de todas maneras es “en donde deberían estar siendo usadas” de manera conceptual; realmente en donde se usan exactamente desde código (salvo las currencyXXX y las bomXXX, ya que estas se usan en facturas, remitos, pedidos, contabilidad; y varias vistas, que te muestra pgAdmin como “dependientes”) no lo se… habría que hacer un búsqueda de string sobre todas las fuentes y empezar a documentar su uso. Por esto, yo para testearlas (aunque no sirve para hacer un testeo exhaustivo en general) corro sentencias sql directamente (por lo menos me sirve para ver si difieren de lo que me responde pl/java).

—-
Ok, hice dos commits mas: invoicePaid, getAllocatedAmt (función “privada”; tal como esta en pl/java actual) y modifica invoiceOpen así es consistente con invoicePaid (las dos usan getAllocatedAmt; si algún momento se cambian el algoritmo de alocacion, solo hay que modificar esta función) y AcctBalance (ni idea desde donde se usa esta función….):

http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/ea66dcb8f57a/Account/acctBalance.sql
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/83c0632ae53a/Invoice/getAllocatedAmt.sql
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/83c0632ae53a/Invoice/invoiceOpen-nueva.sql
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/83c0632ae53a/Invoice/invoicePaid.sql

InvoiceOpen-nueva.sql ademas tenia un bugcito (la variable SQLERR creo que en postgres no existe)

[Javier Ader]

Bueno, ahí hice otros commits:
agregue:
bpartnerRemitLocation
productAttribute: con una pequeña modificación; la lista de atributos se muestran en forma nombre:valor, y no como actualmente “valor:nombre”
charAt: acá solucione un bug en PL/Java; todo un tema esta función, porque se usa desde muchas vistas para inferir los “multiplicadores”; en particular rv_c_invoice y rv_c_inovicetax pasaran a negar algunos valores para ciertos tipos de “facturas” (por ej, notas de crédito). Habría que investigar un poco en donde se ven estas y todas sus vistas relacionadas; pero seguro que tienen que ver con varios informes.
nextId: esta función no estaba funcionando en PL/Java; puse una implementación que anda, si que la quieren agregar

En teoría, desde mi punto de vista, solo falta cashLineAvailable, todas las demás no tiene mucho sentido y pienso que habría que eliminarlas por completo (y también a muchas de las versiones “numeric” que no se entienden muy bien para que están….).

Saludos

[Javier Ader]

Buenas. Ahí subí CashLineAvailable y un test sobre la misma
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/4dd49f57f754/CashLine/cashLineAvailable.sql
http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/raw-file/4dd49f57f754/CashLine/tests-cashline.sql

Supuestamente están todas (ok, faltan algunas, pero no tienen mucho sentido y me parece que no se usan o directamente no funcionan; por ej, la función para obtener la MAC del servidor, la versión de openxpertya!?). Después subo un script que instala todas las funciones a la vez (en las que di dos opciones, pongo la que supongo que es la correcta, sin importar si es identica a la version de PL/Java; en ese caso de querer usar la otra, se puede correr el script global y despues el de la funcion particular).
De cualquier manera, si se plantea un migración total, pienso que antes habria que seguir los siguientes puntos, alugnos de los cuales no tienen que ver directamete con PL/Java, pero los afecta:
1) O arreglar las vistas rv_c_invoice y rv_c_inovicetax para que retornen lo mismo que antes de la corrección de la función charAt o dejarlas como están (posiblemente, el nuevo funcionamiento sea el correcto…). No investigue mucho el uso de estas vistas y sus dependientes, pero me da la sensacion que solo afectarian a algunos reportes (simplemente algunos montos ahora van a ser negativos, por ej, para notas de credito)
2) Definir como se calculan los descuentos sobre facturas: la lógica en PL/Java actual no tiene sentido para descuentos en caso de que la factura tenga asociado un esquema de vencimiento valido; y, en caso de que no tenga un esquema de vencimiento valido (el calculo del descuento se da a partir del termino de pago asociado), la fecha en que se aplica el descuento esta mal calculada (no se calcula con respecto a la fecha de vencimiento de la factura, si la fecha en que fue facturada). En este caso puse dos versiones PGSql de de InvoiceDiscount que la que es afectada.
3) Notar que bomPriceXXX actual deshabilita la funcionalidad de poder poner precios para determinado (producto,conjunto de atributos). Esto no se si se esta usando, pero no creo que sea un gran limitación: un producto bajo distintos conjuntos de atributos típicamente tiene que tener el mismo precio.
4) InvoiceOpen ya no toma el monto total de la factura via C_Invoice_V, siempre lo toma desde GrandTotal directamente; esto porque se asume que la suma de vencimientos de pagos necesariamente es igual a GranToal (el codigo MInvoice hace que esto se cumpla; si no se cumple, entonce el esquema de vencimientos no es tenido en cuenta tampoco en C_Invoice_V); tambien, tampoco hay “mltiplicadores”; todos los montos relacionados se asumen no negativos, sin importar “el tipo” de factura (en particular C_Invoice.GrandTotal, y C_AllocationLine.Ammount y la suma C_AllocatinLine.Amount +C_AllocatinLine.Discountamt+C_AllocatinLine.Writeoffamt )
5) En caso de los pagos (C_Payment), creo que los montos también son actualmente no negativos: el “sentido” del pago, se podria determinar por IsReceipt; creo también que la ventanas actuales Order de Pago y Orden de Cobro generan montos positivos para los C_Payments. Aca ya tengo mis dudas (me he econtrado algunos “Contra Movimientos”!? con monto negativo… ) ; hay codigo que claramente puede setear estos montos a valores negativos , pero creo que es codigo viejo o hay algo que no estoy teniendo en cuenta. En cualquier caso, si se permiten montos negativos , entonces habria que determinar que deberia retornar funciones como PaymentAvailable y PaymentAllocated.
6) Redefinir todas las vistas que referencian a las versiones “numeric” de las fucnioes, para que pasen a usar las versiones “integer” (estas vistas parecen ser viejas, ya que considera que los ids de las tablas son de tipo numeric). No son tantas:
-rv_warehouseprice : (por ej, las tres bomPriceXXX(numeric,numeric) por sus correspondientes bomPriceXXX(integer,integer)
-rv_mpc_order_bomline
-rv_mpc_order_storage
-c_payselection_chek_v
-c_payselection_chek_vt
-rv_cash_detail
-rv_projectcycle
-rv_payment
-TOdas las que referencian a ProductAttribue(numeric) (ok, aca hay como 10, despues completo)

7) Eliminar todas las versiones “numeric” (en este punto no deberia haber problemas, ya que por el punto anterior, no tendrían ninguna dependencia)

Eliminar las restantes funciones PL/Java; al menos yo no le veo sentido o no funcioan
-libertya.charat(source “char”, pos integer) RETURNS “char”
-libertya.charat(p_string character varying, p_pos numeric) – ESTA NO ESTA en PL/Java, pero tira un error; se tiene que usar la nueva charAt
-libertya.documentno(p_mpc_mrp_id integer) : esto tiene que ver MPC_MRP, todo lo caul dudosamente este funcionando… Si es necesaria esta funcion, creo la version PGSql, es ejecutar solo un select.
-libertya.get_classpath(character varying)
-libertya.getmacaddresses()
-libertya.install_jar(character varying, character varying, boolean)
-libertya.openxpertyaproperties()
-libertya.openxpertyaproperty(p_key character varying)
-libertya.openxpertyaversion()
-libertya.openxpproperties()
-libertya.openxpproperty(p_key character varying)
-libertya.openxpversion()
-libertya.remove_jar(character varying, boolean)
-libertya.replace_jar(character varying, character varying, boolean)
-libertya.set_classpath(character varying, character varying)

(los siguiente por ahora nunca los probe; la otra forma de lograrlo es hacer un dump solo del esquema libertya y después restauralo en otra base de datos que no tenga PL/Java instalado, como ocurre en general cuando se crea una nueva base; a eso posiblemente habria que seguirlo con comandos VACCUM , ANALIZE, REINDEX por cuestiones de performance)
9)Eliminar el esquema sqjl
10) Desinstalar el lenguaje PL/Java a nivel de la base de datos (esto creo que es conveniente porque de esta manera los procesos del servidor sirviendo a esta base de datos no cargan en memoria el runtime de java, el cual va a ocupar memoria por cada conexión de manera innecesaria)

En este punto, se habría eliminado y migrado todo lo referente a PL/Java.

[Javier Ader]

RELEASE 1.0

Ok, ahí terminé el script sql que instala todo en uno; creo que toma en cuenta todas las funciones realmente necesarias por el sistema (las demás, como plantie en el post anterior, pienso que deberian eliminarse).

Uso:
—
Bajar http://sourceforge.net/projects/pgsqllib/files/v1.0/PGSqlParaLibertya-v1.0.zip/download
Descomprimir y correr (por ej, desde pgAdmin, previamente seleccionado la base de datos) el archivo AllInOne/AllInOne.sql
Para ver que scripts individuales lo componen mirar (NO correr) crateAllIOne.cmd o los comentarios previos a cada CREATE OR ALTER FUNCTION en AllInOne.sql

Opcionalmente se puede ir migrando de a pasos, pero para eso hay que saber bien que hace cada función y de que otras depende.

Saludos

[Federico Cristina]

Javier,

Genial el aporte. Para el próximo release procuraremos incorporar este tema, a fin de migrar hacia plpgsql y poder así empezar a olvidarnos de pl/java.

Muchas gracias!

Saludos,
Federico

[Jorge Dreher]

Hola a todos, si les sirve, puedo pasarte el script que tengo con la migracion de las funciones a pgsql hechas en Adempiere (que es la herramienta con la que trabajo) las tengo en produccion, quizas sirvan al menos como para tomar de referencia.

Te dejo mi email.

jorge.dreher@gmail.com

[Autor]

Entradas