Respuestas de foro creadas
-
Entradas
-
Buenas, y saludos a la gente del foro que hace rato que no ando por acá.
Carlos, estuve mirando por arriba el codigo del reporteador interno, y lo que determina en donde se imprime un item es la columna AD_PrintFormatItem.PrintFormatType (campo traducido como “Area”); ahi se puede especificar si va en la cabecera, en el cuerpo del documento , o en el pie.
En teoria esto lo podrías especificar en la ventana Formato de Impresion, pesataña Elemento de Formato, opcion Area. El tema es que este ultimo campo no aparece. Mire un poco en el diccionario de datos para ver porque no lo estaba mostrando y tiene una logica de despliegue:
@IsForm@=Y & @IsStandardHeaderFooter@=N
Esto es, tal como esta el diccionario de datos por defecto, la única forma de que puedas poner algo en el pie (o en la cabecera) es yendo a la primer pestaña (Formato de Impresión), tildando el campo “Es Formulario” y destilando “Encabezadomiento/Pie Standard”, guardando y volviendo al campo que quieras poner como texto directo en el pie o cabecera. Que implicancias tiene esto o si es correcto o no, ni idea (en realidad, casi seguro que te va a dejar de generar el pie y el encabezado standard…)…. pero por ej, el formato Transferencia Bancaria hace uso de esto; en particular de el item llamado “Line” va a parar en el encabezado (que hace este item de tipo “Linea” no lo se; casi seguro que simplemente dibuja una linea horizontal….).
Fijate que estos items de texto fijo casi seguro que tienen que tener un Tipo De Formato distinto a Campo; Campo te va a pedir de columna sacar el valor, lo cual no tiene mucho sentido.La otra es cambiar en el diccionario de dato la lógica de despliegue para que al opción Area la muestre siempre, pero no se si sería correcto.
PD : en el caso de un campo fijo de texto lo que va a imprimir es lo que pongas en Texto a Imprimir, aunque en realidad, antes va a ir a mirar a las traducciones en “Traducción del Objeto” (la ultima pestaña en la ventana). Aún mas, el texto que se imprimir puede tener variables, por ej si en Texto a Imprimir pones:
@Page@ @*Page@ @of@ @*PageCount@
te debería aparecer en cada pie de pagina algo como
Pagina 2 de 24
“Pagina” y “de” son la traducción (por diccionario de datos) de las variables @Page@ y @of@ (esto es si uno podría por ej @Product@ deberia trasladarse a Producto); 2 y 24 son los valores de variables especiales @*Page@ (pagina actual) y @*PageCount@ (cantidad de paginas en total). Eso en realidad es lo que hace justamente en el “pie por defecto”. Otras variables especiales son :
@*ReportName@
@*CurrentDateTime@
@*MultiPageInfo@
@*CopyInfo@
@*Header@
@*CurrentDate@No, no que yo sepa. La única manera de que un documento de contabilice inmediatamente después de completado, es forzar la contabilización del mismo manualmente.
Buenas. La verdad que no se como funciona ese proceso de eliminación global, pero debería eliminarte los asientos contables asociados (lo cual es relativamente fácil), si no, es un bug.
Buenas. Si tenes el servidor de aplicaciones corriendo, el subsistema contable periódicamente corre y procesa contablemente todos los documentos que no hayan sido contabilizados; no es necesario contabilizarlos manualmente.
Buenas. El codigo de compleción de Pedidos esta en la clase MOrder, metodo completeIt; pero la forma correcta de completar un Pedido pre-creado en estado Draft (Borrador; C_Oder.DocStatus = ‘DR’), es obteniendo una instancia de MOrder para ese pedido en particular y llamar al metodo de MOrder, processIt (“CO”) o algo muy similar (mira la clase PoSOnline, metodo completeOrder que en un punto hace esto; la diferencia ahi es que ademas se hacen muchas otras cosas, porque ademas crea el pedido desde cero; no te compliques por ese lado, mira solo como lo completa).
En general, si lo tenes pre-creaados (asumo que si por lo que decís), ya guardados y en estado Draft, lo que tenes que hacer es una función similar a
Code:function String completeOrder(int C_Order_ID)
{//lo lee desde la base de datos; se asume que existe uno con tal C_Order_ID
//y con el stado Draft
MOrder o = new MOrder(getCtx(),C_Order_ID,get_TrxName());if (o.processIt(“CO)) //lo copleto
{
if (o.save()) //y lo salvo
return “”; //OK
}
//si se llega acá hubo un error
return “Error completando Pedido “+ C_Order_ID + ” ,Num.Doc =” + o.DocumentNo();
}Solo tenes que hacer eso para completarlos (o algo similar) por cada pedido, obteniendo previamente el id del pedido (como hcer esto ya es otro tema(; no hay que leer las lineas ni nada.
Por cualquiera, lo importante es que no exista al momento de iniciar el cliente. En ese archivo se guardan datos de configuración del cliente y si no existe, lo va a volver a crear. SI te referis a que cambiar pro
, por el tu nombre de usario en la maquina; si queres entra a
C:Documents and Settings y ahi busca una carpeta con tu nombre de usuario; dentro de esa carpeta vas a encontrar el Libertya.properties; ese Libertya.properties renombra, no la carpeta.El editor de pgAdmin lo abris con el 6to boton partiendo desde la izquierda en la barra de herramientas del pgAdmin, el que tiene un lapicito; se habilia cuando seleccionas una base de datos.
Es es el boton para abrir el editor. EL otro boton al que me referia es el “Siguiente” en la ventana de Recibos de Cliente; me da la sensación que estas dandole muchas veces click, y que por cada una se esta creando una transacción… digo, porque no entiendo como podes tener mas de 20 transacciones a la vez.Ah, si si…. por alguna razón medio magica a mi entender, la lineas chquean que haya bastante stock cada vez que son guardadas….
El tema es asi; en es punto el pedido ya esta completo, y se reservo stock por una unidad (vos tenes en este punto 1 unidad real y 1 reservada, por lo tanto no te quedan ninguna disponible). La logica de completar la factura, modifica la lineas del pedido asociado, y las guarda; la lineas al ser guardada nuevamente chequean stock, pero en este punto te quedan 0 disponibles (la misma complecíón del mismo pedido incremento las cantidades reservadas..) y falla.
Esto se da en MOrderLine.beforeSave(), en la sección:Code:/*
* Añade una comprobacion en el metodo beforSave
* de las lineas de pedido y albaran, para que en
* las transacciones de venta, no se pueda guardar
* seleccionar un conjunto de atributos cuyo
* stockage sea menor que el indicado en la linea.
*/
if (o.isSOTrx() && getM_AttributeSetInstance_ID() != 0) {
// BigDecimal avQty = (BigDecimal)DB.getSQLObject(get_TrxName(), “SELECT COALESCE(SUM(QtyOnHand-QtyReserved), 0.0) FROM M_Storage INNER JOIN M_Locator ON (M_Locator.M_Warehouse_ID=M_Storage.M_Locator_ID) WHERE ? IN (M_AttributeSetInstance_ID,0) AND M_Product_ID = ? AND M_Locator.M_Warehouse_ID = ? “, new Object[]{getM_AttributeSetInstance_ID(), getM_Product_ID(), getM_Warehouse_ID()});
// BigDecimal avQty = MStorage.get(getCtx(), getM_Locator_ID(), getM_Product_ID(), getM_AttributeSetInstance_ID(), get_TrxName());
BigDecimal avQty = MStorage.getQtyAvailable(getM_Warehouse_ID(), getM_Product_ID(), getM_AttributeSetInstance_ID(), get_TrxName());
if (avQty.compareTo(getQtyEntered()) < 0) { log.saveError("NotEnoughStocked", ""); return false; } }Lo extraño es que ese chequeo lo hace solo si la linea tiene seteado un valor en getM_AttributeSetInstance_ID(), lo cual no es el caso en general. Estas usando productos con conjuntos de atributos? Porque si no, hay un doble bug; primero, la linea de pedido que comienza con un M_AttributeSetInstance_ID con 0 o null , termina con un valor distinto de 0; y despues el chequeo de stock se hace dos veces (en realidad, a mi entender, no se debería hacer nunca; a lo sumo se hace en la compleción del pedido, pero no cada vez que se guarda una linea….).
Por lo pronto te diría que comentes todo ese chequeo; después si podes, busca el id del pedido generado, y ejecuta la siguiente sentencia desde pgAdmin
Code:select M_OrderLine_ID, M_Product_ID,M_AttributeSetInstance_ID, * form M_OrderLine
where M_Order_ID =Y postealo.
La tercer columna, M_AttributeSetInstance_ID, debería en teoria estar en cero si es que no usas productos con conjuntos de instancia.Me refería a abriar varias instancias del cliente de Libertya (el cliente es lo que usas todo el tiempo) accediendo a la misma base de datos (esto es, el servidor de base de datos). Algo similar puede llegar a pasar si corres instancias del servidor de Libertya contra la misma base de datos (mas difícil, pero es posible si haces cosas raras)
En cuanto a lo de posgres9; intenta (o renombrando para probar) el archivo Libertya.properties que esta en C:Documents and Settings
y volve a abrir el cliente pesado, configura la conexión y entra.
También, abri el configurar.exe, y mira si en algun lugar aparece “postgres9” (en algunos de los nombres de usuario que usa libertya); si es asi cambialo por postgres (antes apaga el servidor si esta corriendo), corre el chequeo y si esta todo bien, dale Guardar.
Si te estaba pasando esto, el servidor de aplicaciones era el que estaba generando los errores de rol no conocido.Por otro lado (o antes si queres, porque lo anterior no se si tiene mucho que ver), volve a hacer lo que hiciste antes (no apretes muchas veces el boton si no anda; con un par de veces debería alcanzar), pero esta vez, en vez de mirar en Server Status ejecuta la siguiente query (previamente seleccionando la base de datos y abriendo un editor)
Code:select d.datname,
c.relname, c.relkind,
CASE
when c.relkind = ‘r’ THEN ‘table’
when c.relkind = ‘i’ THEN ‘index’
when c.relkind = ‘S’ THEN ‘sequence’
when c.relkind = ‘v’ THEN ‘view’
ELSE ‘other’
END as nameRelKind,l.mode,l.granted,l.pid,
* from pg_locks l
left join pg_database d on (d.oid = l.database)
left join pg_class c on (c.oid = l.relation)y postea el resultado de las primeras columnas.
Ok, pero igual debe ser algún problemita con la ventana de recibos que hace algo raro con las transacciones; supongo que Matias lo debe tener en vista.
Lo del role postgre9, no se que tendrá que ver; pero casi seguro que es porque configuraste algo con PosgtreSql 9, o te quedo la configuración (la que vez en Configurar.exe, pero que tambien queda en el archivo libertya.properties en el directorio %USERPROFILE% en windows y HOME, creo, en Linux) incorrecta, ya que al parecer en algun momento estas queriendo acceder con “usuario” postgres9, cuando en la configuración normal el unico usuario a nivel de base de datos que existe ademas de libertya es postgres (NO postgres9).
Más allá de eso, el problema me parece que viene por otro lado… obviamente hay un bloqueo, ya que la pantalla muestra como 20 conexiones corriendo bajo una transacción (eso no es un escenario para nada común, salvo que estés corriendo muchos clientes contra el mismo servidor, y estos se bloquearon en algún punto entre si… si todo los demás que abras potencialmente se van a bloquear también….).
Me parece que sí, hay algo raro (a mi me ha pasado crear un remito de entrada que no parece incrementar el stock…).
No lo testie pero estoy casi seguro que el problema esta aca:
MInOut.checkMaterialPolicy()Busca la siguiente sección de código:
Code:if( ii == 0 ) {
if( storage.getQtyOnHand().compareTo( qtyToDeliver ) >= 0 ) {
line.setM_AttributeSetInstance_ID( storage.getM_AttributeSetInstance_ID());
needSave = true;
log.config( “Direct – ” + line );
qtyToDeliver = Env.ZERO;
} else {Eso lo que hace es modificar el M_AttributeSetInstance_ID de la linea de remito a algo que en general es distinto de cero. Posteriormente en el completeIt , al tener un linea M_AttributeSetInstance_ID distinto de cero se hace una hace, creo, una chequeo de cantidad de stock actual incorrecto.
No lo testie, pero cambiando la primer sección que puse por esta:
Code:if( ii == 0 ) {
if( storage.getQtyOnHand().compareTo( qtyToDeliver ) >= 0 ) {
//line.setM_AttributeSetInstance_ID( storage.getM_AttributeSetInstance_ID());
//needSave = true;
//log.config( “Direct – ” + line );
//qtyToDeliver = Env.ZERO;MInOutLineMA ma = new
MInOutLineMA( line,
storage.getM_AttributeSetInstance_ID(),
qtyToDeliver);if( !ma.save()) {
;
}
qtyToDeliver = Env.ZERO;} else
Tal vez ande, ya que de esta manera nunca se modifica el M_AttributeSet_ID de la linea (pero requiere crear un MInOutLineMA como en todos los demás casos), y el completeIt en teoría haría el chequeo de stock correcto.
No se si anda, pero casi seguro que por ahí viene la cosa (en realidad, todo eso código es medio raro…).
En cualquier caso , si podes desde pgAdmin ejecuta la siguientes sentencias (seleccionando previamente la base de datos en cuestion y abriendo un editor de sentencias)Code:set search_path to libertya;
select * from M_Storage
where M_Product_ID =y postea lo que te muestra; tenes que reemplazar
con el id real del producto que te esta trayendo problemas, esto es, el valor de la columna M_Proudct.M_Product_ID ; este valor lo podes ver en la ventana normal de productos (en la que podes modificarlos, no en la que posteaste en el screen) haciendo doble click en la parte inferior derecha que muestra algo como [1/233], una vez seleccionado el producto) Lo raro es que al parecer PL/Java esta bien isntalado (lo reconoce como lenguaje el servidor y esta habilitado para la base de datos en cuestión) , si no le tiraria otro error. Lo que no esta econtrando es o el jar, o la clase (lo cual puede debeser al clashpath usado internamente).
Ejecutaste
select sqlj.install_jar(‘file:/home/ServidorOXP/lib/sqlj.jar’, ‘libertya’, true)
y
select sqlj.set_classpath(‘libertya’, ‘libertya’);Contra la base de datos correcta?
el sql.jar tiene adentro el product.class?
Que tal jdreher; justamente tome como referencia tanto los scripts de Adempiere 3.6 como 3.4 (esta ultima porque utilizaba el mismo manejo de BOM que LIbertya; en una versión posterior cambiaron), incluso reporte un par de bugs (aunque lo hice en un thread de red1.org, no en sourceforge…), más que nada porque varias funciones bajo PostGreSql no va a funcionar como en Oracle (por ej, Pg/Sql no dispara una excepción si un “select” no genera exactametne una fila algo que los scripts de adempiere actuales dan por sentado… esas excepciones solo se disparan si usa el modificador STRIC); después creo que tienen un “bug” funcional en invoiceDiscount (esta es la idea que supongo correcta: http://pgsqllib.hg.sourceforge.net/hgweb/pgsqllib/pgsqllib/file/2a70f9c5b0d2/Invoice/invoiceDiscount-sugerida.sql ; los puntos 1 y 2 son en los que modifique la semántica; invirtiendo una comparación de fecha, ya que de lo contrario no tiene sentido (1) y usando la fecha inferida a partir del termino de pago , en lugar de DateInvoiced, para calcular el descuento (2))
Saludos
Buenas. Sigo sin saber porque ocurre esto realmente, pero mirando los log de PostgreSQL la tabla
AD_Sequence es accedida usando un select de la forma (y solo a esta tabla)Code:SELECT ….. FROM AD_Sequence
FOR UPDATEEse FOR UPDATE me parece que es la clave; en realidad creo recordar haber visto sistemas basados en compiere evitaban este modificador (por alguna razón…) cuando el servidor era PostGreSQL; como si este FOR UPDATE funcionase como era esperado bajo Oracle, no así sobre PostGreSql. Después investigo un poco más.
PD: el lock sobre C_Bpartner nuevo debe venir por otro lado…. no creo que se lo acceda esta tabla con un FOR UPDATE en algún punto del sistema, pero uno nunca sabe….
Que tal. Me parece que lo de Maxion era sobre 10.09. Igual, la ventana te alcanza mostrar que se envía algún comando? En el log de preferencias te muestra algún error (creo que lo podrías ver, pero via la ventana principal)? Finalmente, esto creo que es algo que cambio en 11.05 (la impresión fiscal, al menos desde el tpv se hace “medio” en diferido por decirlo de alguna manera, en su propia transaccion de acceso a base de datos), en la misma instancia (o en otro pero sin cerrarla) habías generado alguna impresión fiscal de algún tipo (en general desde el TPV, pero desde la ventana normal me parece que es lo mismo)?
Digo, porque que se tilde totalmente me da mas una sensación de bloqueo en base de datos (o a nivel de TCP, pero es ya lo veo mas raro) que otra cosa.
