Respuestas de foro creadas
-
Entradas
-
A que ventana se refieren? Al panel de busqueda que esta en el tpv o la ventana (InfoProduct) que se abre cuando no se encuentra de manera directa? Porque si es la ultima hay un tema de accesos a datos fuera del thread GUI que puede llegar a causar problemas: la búsqueda de los productos se hace de un thread aparte, ese thread actualiza datos que utiliza el thread GUI; esto genera ocasionalmente problemas, pero son aletorios y difíciles de reproducir (es un problema de sincronización); seguramente en una maquina de múltiples núcleos se da de manera más frecuente.
Pero no debería buscar las librerias el path del servidor (deberia usar solo sus propias librerias y runtime de java), al menos el cliente pesado… Podes postear el contenido de Libetya.sh?
Yo alguna vez vi algo raro en la construcción del cliente pesado, que me hizo pensar que iba a tener un problema de librerías si el cliente se corría en una máquina en la que no estaba instalado el servidor (al final no lo testie, pero me quedo la duda); pero era otra librería, no log4j.jar, porque esta se incluye sin problemas en el OXPXLib.jar que viene dentro en el zip).
Cliente 9.07??
Bueno, la clase que no encuentra si esta incluida en cliente pesado generado por la version 10.09 (y casi seguro en la 10.03); el archivo OXPXLib.jar termina contendiendo el que esta en tool/lib/log4j.jar; este jar es que el que contiene la clase que no encuentra tu version (org.apache.Log4j.Level).
Mira el libertya.sh, al invocar a java tiene que pasarle como referencia el lib/OXPXLib.jar en algun momento (y tambien el lib/OXP.jar y el lib/JasperReports.jar);El libertya.sh de donde lo sacaste? Porque al menos en mi sistema no va a parar al cliente pesado (ok, mi sistema es XP, y genera un .exe que basicamente debería hacer lo mismo que el Libertya.sh; no se si bajo sistemas no windows lo genera…. lo deberia generar para ambos, esto es, el Liberya.exe y el Libertya.sh, pero bueno )
Matias, vos decis que la pestaña “de cuotas” (vencimientos de pagos creo que es) es editable? (una pavada pero no lo pude chequiar ya que en la base actual que tengo no tengo ninguna factura con esquemas de pagos…); pense que no, por eso todo el tema de “automatico” vs “manual”. Si es editable (lo cual tiene todo el sentido ahora que lo pienso; esto es, siempre son manuales, al menos respecto a los montos y la fechas) entonces tiene cierto sentido que afterSave de MInvoicePaySchedule (de aca en mas IPS) revalide la factura y la guarde (pero solo bajo ciertas ciertas circunstancias que adelante explico).
Mire un poco el codigo de Adempiere, y es casi identico, en particular:
-MInvoice.IsPayScheduleValid es Y si y solo si la sumataria delos IPS.DueAmt es exctamente igual a MInvoice.GrandTotal.
-IPS.afterSave revalida la factura si se modifico DueAmt (is_ValueChanged(“DueAmt”), lo cual creo que es true incluso en instancias recien creadas); lo caul creo que tambien es un error aca, ya que se hace siempre.
-la utilización de los porcentajes y descuentos es igual (IPS.DueAmt = GranTotal * Porcentaje; IPS.DiscountAmt = IPS.DueAmt * Porcentaje de descuento )
-MPaymentTerm.applySchedule : tambien le agrega al ultimo IPS lo que resta si las totales no son exactamente igual (esto es, si uno tiene una 3 cuotas, de 30%, la ultima va ser tratada en la practica como de 40%), y tambien llama sobre el final a MInvoice.validatePaySchedule()
-Tambien se rendondean incorrectametne los montos de las cuotas (se uiliza la escala de la moneda para realizar la division necesaria para el porcentaje, pero no para redondear el resultado de la mutiplicación; por lo tanto el monto de la cuota va a tener mas decimales que lo que dice la precisión de la moneda….. el tema es que ellos almacenan los montos como numeric, esto es, con cualquier cantidad de decimales; libertya almacena todo con 2 decimales…. esto en libertya se va a producir un redondeo o trucado a nivel de base de datos sobre estos montos, se haga o no el redondeo desde java…)… en cualquier caso, la correccion posterior que hace MPaymentTerm creo que lo soluciona en ambos sistemas (el tema es que ellos pueden llegar a tener el monto de una cuota por ej con valor 33.1234 incluso cuando la precisión de la moneda sea 2; Libetya va a tener necesariamente 33.12, pero esto por que lo hace la base de datos…. )Las diferencias:
-MInvoice cuando vueve a salvar los ips llama a un metodo saveEx, lo cual simplemente es un save() pero que dipsara una excepcion en caso de el save retorne false (esta buena la idea, ya que simplifica mucho el tipico codiogo “if o.save()! return “error o dispara una execpion”. Esto es, el prepareIt falla si falla el guadadado de los IPS (lo cual tieen sentido, si no puede darse el caso de que los IPS queden en estado inconsistente con respecto a MInvoice.IsPayScheduleValid)
-no se intenta saltear feriados del EC y cosas por el estilo; la fecha del pago es siempre la fecha de facturación mas la cantidad de dias netos datos en C_PaySchedule, lo mismo para la fecha “de descuento” (la cual no se entiende bien si es para un sobrecargo o descuento….)En cualquier caso, lo que mas raro veo es el afterSave de los IPS; ya que no tienen en cuenta dos cosas: que la factura ya este paga (en ese caso seria un error, al menos conceptual, creo modificar el plan de pagos), en tal caso deberia disparar un error y si se esta invocando desde MPaymentTerm o MInvoice en estos dos casos es incorrecto la revalidación de la factura y su guardado (esto se va a hacer a posteriormente).
Dicho esto, pienso que el codigo de MInvoicePaySchedule deberia tener un flag para saltear la revalidación, y que este flag se seteado tanto de MPaymentTerm como Minvoce; algo asiCode://MInvoicePaySchedule
public booelan afterSave(newRedord, sucess)
{
if (!sucess) return false;if (m_skipInvoiceValidatePaySchedule)
return true;if( is_ValueChanged( “DueAmt” )) {
log.fine( “afterSave” );
getParent();
m_parent.validatePaySchedule();
m_parent.save(); //IGUAL ESTO ES DUDOSO, tal vez deberia usarse un
//update directo sobre la factura para setear IsPayScheduleValid
//con el resultado de validatePaySchedule, asi se saltea toda la logica
//de after y beforeSave de MInvoice
}
return true;
}public beforeSave(newRecord)
{
//opcional, agregar esto:
getParent();
if (m_parent.isPaid())
{
“error la factura ya esta paga”;
return false;}
//lo que sigue igual
}//finalmente el flag false por defecto; saltea la revalidación y guardado de la factura
boolean m_skipInvoiceValidatePaySchedule = false;
public booelan getSkipInvoiceValidatePaySchedule() { return m_skipInvoiceValidatePaySchedule;}
public void setSkipInvoiceValidatePaySchedule(booelan skip)
{ m_skipInvoiceValidatePaySchedule = skip}Finalmente MPayementTerm.applySchedule y MInvoice.validatePaySchedule setean este flag a true en cada instancia de MInvoicePaySchedule a la que acceden (en ambos casos, el que determina si cada IPS y la factura es valida como un todo va a ser MInvoice; no es necesario que cada IPS invoque la revalidación)
En cuanto a que el AfterSave de Minvoice genere el esquema de pagos (y asi dejar de usar el callout) tiene sentido, pero me parece que trae otros problemas ya que este afterSave se puede llamar muchas veces… Todas estas cosas son necesidades visuales, ya que se van a pisar en el prepareIt…. Tal vez habria que agregar un boton para que el usuario puede regenrar el esquema de pagos cuando lo desee (esto tiene la contra de que se tiene que agregar una columnas mas en la base de datos… tampoco me gusta mucho… habria que encontrar una solucion generar para agregar este tipo de “acciones” a tablas pero sin modificarlas; en vez de esto agregar otras “tablas” de extensión, que generen menus de accciones en la ventanas, especificas para la tabla… hace rato que quiero hacer algo al respecto como una solución general a esta y otras cosas, algun dia tendré tiempo… igual, esto es otro tema)
Que tal Dario. A que llamas instalar pl/java bajo postgres 9.0 o 8.4? Te pregunto porque el instalador de libertya no usa un instalador de postgres común (en realidad, creo que si, pero agrega otro .exe que instala la extensión necesario para que postgres soporte pl/java; el instalador de postgres detecta esta extensión y la instala también).
Si miras el archivo data/postgresql.conf (en el postgres que te instala Libertya) vas a ver que sobre el final hay una seccion:Code:#——————————————————————————
# CUSTOMIZED OPTIONS
#——————————————————————————#custom_variable_classes = ” # list of custom variable class names
custom_variable_classes = ‘pljava’ # list of custom variable class names
pljava.classpath=’E:\PostgreSQL\8.3\share\pljava\pljava.jar’En donde E:\PostgreSQL\8.3\ depende de donde lo hayas instalado. En particular, en ese pljava.jar bajo el directorio sharepljava existe la clase org/postgresql/pljava/internal/Backend.class (abrilo con cualquier programa que maneje zips)
El install_jar no solo requiere que se alla creado el esquema sqlj, y que pl/java este “instalado” en la base de datos (el tema es que pl/java se instala en posgtre como un todo, pero después se habita por base de datos).
No se si replicando esta configuración y directorio en 8.4 o 9.0 se estaría instalando de manera manual a PL/java; habría que probar.
Más allá de todo esto, desde hace tiempo que pienso que habría que librarse de PL/java completamente…. algo estuve haciendo en estos días (pase todas las bomPriceXXX y bomQtyXXX por sus equivalentes salvo un pequeño cambio de semántica relativa a los precios en instancias de productos, que no se si se usara mucho), y mis tests es que usando un equivalente Pl/PgSql hay incluso mejoras de performance. Me trabe un poco en otras funciones (invoiceOpen por ej) porque se empiezan a relacionar con otras cuestiones más generales en las que tengo mis dudas de si actualmente se esta haciendo lo correcto (por ej, la vista C_Invoice_V que es usada por estas funciones, tiene cosas medio raras… si se modifica esta vista, también se afecta otras partes del sistema que hacen uso directo de la misma; por ej, el calculo del crédito usado por una EC….)
De nada.
Matias, que se llame a esta lógica desde MInvoice.prepareIt, no se si esta tan mal, que se lo llame desde el callout, supongo que es para que se regeneren automaticamente cada vez que se cambian y el usuario pueda verlo desde la pestaña “Programa de pagos” o “vencimientos de pagos”, no recuerdo (esto mucho no me gusta, porque indirectamente se modifica a la factura bajo ciertas condiciones; yo preferiría un proceso aparte…).Otra cosa que tal vez vi, con la que tengo mi dudas:
MInvoicePaySchedule en afterSave llaman a MInvoice.ValidatePaySchedule y luego a MInvoice.save()…. eso dentro de la logica anterior no tiene sentido; al menos si los vencimientos de pago se van a generar de manera automática: MPaymentTerm genera los MInvoicePaySchedule (y los salva, lo cual va a llevar al afterSave) , luego llama a MInvoice.validatePaySchedule(); en donde se relee los MInvoicePaySchedule y se verifica que la suma de los mismos es igual al GranTotal; si es asi se los setea como validos y se los vuelve a salvar (ademas de setear MInvoice.isPayScheduleValid…).
La invocación MInvoice.validatePaySchedule() desde MInvoicePaySchedule no tiene mucho sentido; (ya que MInvoice parece ser el que tiene la facultad de determinar cuando es o no valido un vencimiento) y me da la sensación que solo obedece a una cuestion visual para que en la pestaña pricipipal se actualice el tilde isPayScheduleValid cada vez que se crea un vencimiento en la 4ta solapa…. pero esto ultimo, nuevamente tiene sentido si los vencimientos se van a generar de manera manual; lo cual tiene sentido, por ej, para facturas de Proveedores.Pensando en esto, no debería haber un tilde en C_PaymentTerm que diferencie estos dos casos? Digamos: isManual (cuando el termino de pago es manual, el usuario ingresa por si mismo los C_InvoicePaySchedule, poniendo el monto y la fecha de vencimiento de cada pago; toda la logica de generación automatica se saltea si el termino de pago es manual).
Bajo esta situación MInvoicePaySchedule no llamaria a isPayScheduleValid salvo que pertenezca a un termino de pago manual (aun asi tal vez sea necesario…. no me gusta mucho la idea MInvoice.save() sea llamada desde muchos lados….).La idea se completaría así:
MInvoice.prepareIt:
-si el termino de pago es automatico, igual que antes (esto sobre el final va terminar seteando isPayScheduleValid)
-si el termino es manual , se llama validatePaySchedule(); si esta ok (habria que considerar que cuando hay 0 vencimientos, también esta ok; el paySchedule no es valido, pero el usuario no erro los montos de los pagos, simplemente no agrego ninguno), seguimos, si no , hay dos opciones: o setea isPayScheduleValid a falso y se sigue como si nada; o se dispara un error “los montos de los vencimientos no igualan al de la factura”En cualquier caso, lo que se hace en el afterSave de MInvoicePaySchedule no seria necesario (el before save pienso que tampoco…)
Otras temas relacionados:
– los lookups de termino de pago y de forma de pago deberian modificables cuando la factura esta marcada como pagada (IsPaid; dicho sea de paso este campo no parece ser muy usado, por ej, no se lo tiene en cuenta como filtro para calcular el credito usado una EC, pero parece estar siendo actualizado correctamente)– la suma de los montos de los vencimientos, debería ser exactamente igual a la de la factura? Supongo que esto simplifica mucho las cosas, pero no se entiende como se aplicacrian los descuentos en los vencimientos de pago (por ej, de nuevo el calculo del credito usado parece mirar en C_InvoicePaySchedule cuando se valido, es vez de mirar el C_Invoice.GrandTotal; el tema es tal como esta ahora, se va a llegar a los mismo resultados, ya que C_Invoice.GrandTotal = la sumatoria de C_InvoicePaySchedule.DueAmt, si no sería valido el esquema).
-miraron algún sistema relacionado a ver como están manejando actualmente estas cosas? Despues chusmeo un poco.
Esta buena la idea, yo me había topado en el pasado con una necesidad similiar (tuve que tocar el código…). Lo que si tal vez habria que tener en cuenta la impresora fiscal especifica que se use; no creo que sea muy usual, pero en mi caso se iban a usar 2 contralodores fiscals distintos; una tiqueadora y una paginadora… El tema es que la tiqueadora tiene tipicamente la mitad ancho de linea que las paginadoras para la descripción de los items; en las paginadoras podias poner hasta la descripción, era muy dificil que te pasaras; el la tiqueadora ya no (40 caracteres es lo tipico).
No se como lo habran modelado, pero a mi se me habia ocurrido un simple campo de texto en la configuración de la impresora fiscal (el tema es que el codigo primero generaba las descripción y despeus iba a mirar que driver usar…..) con una semantica preestablecida; algo como por ej, pora imprimir el UPC (con padding minimo 14) y despues el nombre algo como:“@UPC@14 @Name@”
incluso se podria extender un poco para permitir cosas como “si no tiene upc, imprimir el codigo; despues el nombre”“@UPC,Value@14 @Name@”
y si uno queria otra formato para la paginadora (pero dejando a la tiqueadora tranquila)por ej, que pongo al final la descripción (o lo que entre), algo como:
“@UPC,Value@14 @Name@ @Description@”Requería solo un campo de texto en la definicion del la contralodora fiscal, esto es, en donde uno especifica el driver a usar (con cierta semántica predefinida para ciertos campos especiales) y obtener la configuración de la impresora fiscal antes que generar las descripciones.
Bueno, pinta medio mal, pero tal vez este haciendo cosas “raras” (raras para el tpv…).
Veo que estas usando un Tarifa de Costo…. ahi tenes algo mal configurado. Te diría que
1) Crees una lista de venta (con impuestos o no incluidos) y una versión dentro de esta
2) Ponele precios a los productos con los que vas a probar dentro de esta lista (teoricamente el TPV no te debería permitir agregar un producto que no tiene precio en la lista que esta usando el TPV, pero ahí creo que hay un bug)
3) Modifiques la configuración del TPV para que use esta nueva lista de preciosOtra cosa; si podes evita usar la funcionalidad de cambiar lista de precios; más aún cambiar de una lista de precios con impuestos incluidos a otra sin impuestos (ahí había un bug en 10.03, que creo que sigue estando) o viceversa. Te digo porque a “ojo” me da la sensación de que desde el TPV se considera que los precios tienen IVA pero al momento de crear la factura no (o al revés); si no, es muy raro que haya tal diferencia.
No, la categoría de IVA se configura a nivel de compañía y es compartida por todas las organizaciones que la componen (pensá Organización como sucursal); así está diseñado.
Tu categoría de IVA la especificas en Perfil Conf. de Coampañia; Conf.de Compañia->Compañia; Solapa Información de Compañia; supongo que en tu caso Responsable Monotributista (si no me equivoco no deberías tocar nada mas; necesariamente de debería obligar facturas C, creo….)Tenes que tocar código en cualquiera de los dos casos. En cuanto a la descripción se setea en FiscalDocumentPrint.loadDocumentLines; ahí lo que hace actualmente es agregar “clave del producto” concatenado a “nombre del producto”.
En cuanto a la cantidad de decimales, es un poco más complicado porque esta a cargo del driver especifico que estés usando; actualmente, si no me equivoco siempre se “escala” las cantidades a 2 o 4 decimales dependiendo del driver (hay algunas tiqueadoras que soportan cierto numero de decimales); este seteo de escala hace que una cantidad por ej 2, sea enviada al la tiqueadora como “2.0000”; la p441 al parecer imprime los decimales que le envíes, aún cuando represente un numero entero (esto es, no elimina los “ceros a derecha”)En cuanto a lo de C_InvoiceLine esta bien; la tenes que sacar de ahi (o de alguna vista Postgre, pero necesariamente esta vista va basarase en la misma tabla).
En cuanto a m_product_costing, no estoy muy seguro…. esa tabla no se se esta actualizando correctamente en la actualidad (si mal no recuerdo esta mas relacionada con el procesador contable y con algún algoritmo de “estimación” de costos).
Lo que tal vez tengas que mirar es como se relacionan los productos con respecto a un lista de precios de costo; la tablas son
M_PriceList, M_PriceList_Version , M_ProductPrice (relaciona un producto sin conjunto de atributos con una verson de lista), y tal vez M_ProductPriceInstance (relaciona un producto con conjunto de atributos a una versión de lista).Si… es otra limitación de Libertya con la que me encontré en el pasado (lo que si, no recuerdo si encontré una solución; había pensado en alguna modificaciones, una era un pequeño hack, otra era mas de núcleo…. no recuerdo si implemente alguna de las dos, despues busco un poco….). El tema es que Libertya, aun cuando el TPV te permite “pagar” de más, no registra los vueltos (los pagos SIEMPRE igualan el monto a pagar total); al momento de la impresión fiscal se buscan estos pagos asociados a la factura, que nunca generan vuelto (salvo pequeños errores de redondeo, siempre te va generar “CAMBIO 0” en el tique).
Si mal no recuerdo, si miras la linea de caja que te genera un pago en efectivo con vuelto desde el TPV vas a ver que te registra el monto que requerirías para saldar la factura sin vuelto (esto es, no te registra el monto real que te pagan, si no el necesario para saldar la factura).
Realmente no entiendo porque el TPV no genera ese pago en efectivo por el monto real; tal vez sea una limitación general : los pagos sumados de una factura no pueden superar el monto de la misma.
No tengo muy en claro como interactúa las tiqueadoras con los cajones de dinero, pero seguro que Libertya no emite este comando tal como esta en la actualidad (asumo que el comando no siempre debería emitirse ya que este cajón parece opcional…).
Mirando la documentación de hasar el comando se OpenDrawer; mire si se podía configurar la tiqueadora para que lo abra automáticamente siempre finalice la impresión de un documento fiscal (de esa manera no se requiere modificar a Libertya) pero no encontré nada (capaz que existe algo, ya que tiene sentido que lo haga automaticamente; habría que preguntar en Hasar….).Pero bajo que escenario? El Boton Cobrar (en la segunda solapa) solo se habilita cuando los pagos registrados superan el monto a pagar (menos descuentos); quiero decir, esta bien que este deshabilitado mientras no alcances el monto a pagar.