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:

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

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:

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

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?

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

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)

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.