[Javier Ader]

Pero ese no parece ser un CUIT válido; posiblemente pase algoritmo de chequeo del dígito verificador, pero los dos primeros dígitos no son 20,27,23 ni 30.

[Javier Ader]

que raro… 10.09 no?
El perfil que tenes que usar es Administración, no Administración de Compañia (o al revés! jajaj, estoy casi seguro que es el primero, lo había probado y todo, pero tal vez puse el otro) y tal vez tengas que tildar en preferencias “mostrar pestañas contables” (o algo similar); después reiniciar el cliente.
Lo que es seguro es que la ventana Esquema Contable te tiene que aparecer en algún perfil.

[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

[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]

La configuración por defecto viene con el control de periodo automatico (si no lo tenes, tildalo), lo que tendrías que cambiar es los “Días de Historia”;
Estas dos cosas las accedes desde Perfil Administración; Contabilidad->Esquema Contable. Posiblemente después de hacer esto tengas que abrir y cerrar el cliente que desde el cual estas queriendo realizar la factura (pero me parece que no es necesario).

Saludos

[Javier Ader]

Buenas. Si tenes control de periodo automático, no es necesario (ni tiene utilidad) abrir los periodos manualmente; en este caso tenes que poner que permitís ingresar documentos con fechas, digamos, 30 días antes al periodo actual.

[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]

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]

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

[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?

[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

[Javier Ader]

La tasa es a la que esta asociada el producto y tiene que estar activa para que el TPV la vea.

[Javier Ader]

Buenas Franco. Estuve mirando el código en 10.09, y si, parece requerir un pedido por remito, pero:

1) No hace la validación de este requerimiento (eso hace en MInOut.prepareIt se obtenga un pedido a partir del id C_Order_ID = 0), y te permite completarlo sin problemas…el tema es que hace cosas muy raras con el stock: al acceder al “pedido” con id 0, actualiza el stock utilizando attributos de instancias creados al vuelo (esto creo que antes no pasaba….). Esto es, si es requerida tal asociación de cabecera de remito a cabecera de pedido, que no permita completar un remito al cual nunca se le especifico el pedido.

y
2) No veo la razón de esta necesidad; por un lado porque en muchos casos es muy “restrictiva” (uno tiene que si o si , usar un pedido… en muchos casos, veo como algo mucho más frecuente que no se usen pedidos; lo veo innecesariamente burocrático), y por otro “poco flexible” (no solo desde el TPV, si no, en general): uno puede asociar un solo pedido a un remito… Lo extraño, es que las tablas parecen indicar “claramente” (al menos para mi), que la asociación entre remitos y pedidos en realidad se da a nivel de lineas (pero tampoco debería ser un necesidad); esto es, un linea de remito puede “satisfacer” a una linea de pedido, otra de otro, etc. La relación pedido-remito, es muchos a muchos y se da en realidad a nivel de lineas. El C_Order_ID en la cabecera del remito para mi no tiene mucho sentido, salvo a lo sumo para marcar que un remito fue generado a partir de un pedido, pero solo como un campo informativo sin mayor semántica. Lo mismo con la facturas-pedidos; ademas acá también se da la relación factura-remito a nivel de lineas.

[Javier Ader]

Franco, lo que pusiste esta perfecto; el tpv sí intenta tener en cuenta esta configuración; pero el bug esta en que getPoSCOnfig().isPrintWarehouseDeliverDocument() nunca es seteado a partir de lo que diga la configuración en la base de datos; es seteado siempre a true (en realidad, hay un linea comentada en 10.09 que evita que sea tenido en cuenta esta configuración; probablemente para testear la comentaron, y despues se olvidaron de descomentarla). Esto pasa en constructor de la clase PosConfig; sobre el final se ve:

Code:

setDeliverOrderInWarehouse(pos.isDeliverOrderInWarehouse());
//setPrintWarehouseDeliverDocument(pos.isPrintWarehouseDeliverDocument());
setPrintWarehouseDeliverDocument(true);

Debería ser simplemente :

Code:

setDeliverOrderInWarehouse(pos.isDeliverOrderInWarehouse());
setPrintWarehouseDeliverDocument(pos.isPrintWarehouseDeliverDocument());

Ok, esto mirando los fuentes de 10.09, que tal vez no sean exactamente los mismo que con los que se genero el release binario (quiero decir, tal vez el bug no este en la versión binaria; la verdad que no lo probé)

[Javier Ader]

Que tal Franco. Si, seguro que se tiene que internamente imputar 60; yo habia pensado que tal vez se podría modelar el vuelto haciendo una entrada de caja por 100 y una de salida por 40; que también conceptualmente correcto, pero bueno, quedaría registrado como un pago “negativo” que por otras cosas que vengo mirando me parece que generaria más problemas…
El campo de la factura que decis tiene sentido, pero me preguntaba si el campo WriteOffAmt de las lineas de alocación no tienen la idea de “vuelto”; siguiendo tu ejemplo si se generaría una linea de alocación con
Ammount : 100
WriteOffAmt: -40
Asociada a una linea de caja por 60, creo que se “solucionaria” (obviamente la logica de impresión fiscal debería tener en cuenta esto).
La otra sería usar algún campo de la linea de caja, me da la sensación que debería tener alguna forma de especificar el “monto real” o el “vuelto” (ahí también hay un campo “WriteOffAmt”, pero ademas otro, que no se que idea tendrá: “WhiteoffAmt”; después miro si en algún lado se hace uso de este campo)

[Autor]

Entradas