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)
