[Javier Ader]

Respondo de “memoria” ya que no tengo libertya a mano. Los únicos ingresos que se permiten agregar de manera manual son los que están dentro de una categoría especificada como “Manual”; todos los ivas, salvo que hayas cambiado algo, vienen configurados como impuestos automáticos.
Creo que para hacer lo que requerís tenes que ir a impuestos; crear un categoría manual (digamos Percepciones IVA), un impuestos dentro de esta (el mismo nombre…), y después desde Fact. Proveedores, en Otros Impuestos (o como se llame la solapa que te permite ingresar impuestos de manera manual), creas una nueva entrada, seleccionas el impuesto manual y pones el monto.

[Javier Ader]

Buenas. Creo que el problema que tenia JL, según hablamos, era ocurrió un cambio de año! Esto genera problemas aún cuando el procesador contable este en modo automático (bajo este modo, se selecciona automáticamente dentro de los periodos actuales; pero si no hay periodos precreados para el 2011, no anda; esto es, este modo selecciona y ‘abre’ matemáticamente periodos, pero no los crea).
En este caso, la solución que en contramos fue
– crear un nuevo año con nombre 2011 en bajo el calendario actual (NO crear un nuevo calendario; el tema es que libertya solo usa un calendario, el referencia desde la información de empresa…)
– posicionado sobre ese año se dispara el proceso crear periodos.

Y listo. La proxima vez que se contabilice algo en el 2011, la configuración del procesador contable se actualiza automaticamente para que quede apuntando al periodo actual bajo el 2011.

La otra alternativa es crear otro Calendario nuevo, pero hay que cambiar la configuración del cliente para que apunte al nuevo calendario; me parece que esto ultimo no es lo correcto (y va a traer problemas cuando alguien quiera contabilizar algo en el 2010, porque el nuevo calendario no va a tener este año salvo que se cree… o sea, se termina teniendo lo mismo: un calendario con más de un año).

[Javier Ader]

Alguno de los productos o mas de uno tiene asociado una configuración de impuestos asociadas que trae problemas. En particular asegúrate que ninguno tenga la categoría “default” (o como se llame), y que al menos uno de los impuestos dentro de la categoría de impuestos (los productos se asocian a una categoría de impuestos; dentro de cada categoría puede haber mas de un impuesto; en particular las categorias de IVA predefinidas viene con un solo impuesto) asociada tenga el tildado “Predefinido”.
La razón es que el TPV (pienso que por un pequeño bug) busca aquel impuesto dentro de la categoria asociada al producto que tengan el tilde “predefinido”; si no encuentra ninguno, en vez de usar cualquier otro “no predefinido” no pone nada; despues al crear el pedido falla (porque la lisneas de pedido requieren que tengas asociado un impuesto).
Me estoy refiriendo al tilde “predefinido” dentro de la subpestaña impuesto, no Categoría de impuestos (este último tilde no se usa desde el tpv).

[Javier Ader]

Bueno, no se nada del componente, pero ese error que mostras surge porque no esta econtrando un clase. Para que no encuentre una clase, una de dos, o la clase nunca existió (seria medio raro…) o estas corrindo un cliente cuyas librerias no se actualizaron después del upgrade (no se si esta en los pasos de la instalación del componente, pero en algun momento seguro que alguien o algo tiene que disparar el Configurar.exe; ejecútalo por las dudas).
Otras cosas:
-Proba el cliente pesado (tiene que estar en el directorio lib; ClienteLBY.zip; copialo a algún lado y descomprimilo). Mira la fecha de modificación/creación de este zip; tiene que tener la la fecha en que ejecutaste el ultimo Configurar.exe (si no me equivoco, este zip se crea cada vez que se ejecuta ese proceso; adentro van a parar .jar’s que tiene que tener todas las librerías necesarias para que ande el cliente pesado).
-Si te sigue sin andar, subí el cliente pesado a algun lado y pasa el link; es facil ver si existe la clase GenAttSetInstCombinations (si queres chequealo vos mismo; descomprimi los .jars que hay dentro del cliente pesado como si fueran un zip; este te tiene que generar un estructura de directorios como muchos archivos con extensión class; alguno de ellos tiene que ser GenAttSetInstCombinations.class y debería estar bajo un subdirectorio de la forma org/libertya/attributeSet/process). Si esa clase no existe, bueno el cliente pesado se genero de manera incorrecta; si se genero de manera incorrecta debe ser por que el configurar.exe no encontró los .jars necesarios (el jar que originalmente contiene a esta clase) y… si no lo encontró… bueno, ya no se, pero por ahí debería andar la cosa (probablemente sea porque no lo hallo en el subdirectorio “plugings” o como se llame el directorio en el que hay que poner los jars de los plugins)

Si con el cliente pesado te anda, bueno, por el momento deja de usar clientes livianos, mas si tenes algún cliente liviano que lo trajiste desde la versión vieja (acá estoy tocando de oido; pero me da la sensación que el cliente liviano puede cachear clases y en particular .jars en la maquina local; la otra seria vaciar la cache de Java).

[Javier Ader]

(este post iba a ser mas largo y explicativo… pero se me corto la luz…. despues, en cuanto me haga un poco de tiempo libre, hago un documento en pdf explicando un poco mas la idea y lo subo)
Bueno me habia quedado pensando en lo que planteo Antonio y lo retome porque pienso que la idea que se puede aplicare no solo Infos si no en general a otros tipos de ventanas que muestren pequeños busquedas/reportes (no necesariameten contra una tabla simple; si no algo en general).
Mi idea ataca a las dos formas de customizacion que planteo Antonio; la primera parte (acceso en relacion a perfiles) no requiere modificar tablas existens (obviamente si requiere agregar tablas y relativamente bastante codigo); la segunda requiere que se modifique AD_Column para que en el caso de que el tipo sea TableDir (esto es, el tipo que se mapea al control que permite disparar un InfoXXX), se permita agregar que “columnas externas” (depues explico un poco mas esto) se van a mostrar.

Las tablas seria basicamentge
-AD_Info: tiene bastantes cosas, pero la mas importante es una AD_Table_ID; esto es para saber que AD_Info usar en un determinado Lookup; de toadas maneras pienso que no requerir que sea NOT NULL; en realidad estas AD_Info puede usarse para pequeñas ventanas que no esten asociadas a una tabla en particular. Tampoco se requiere que AD_Table_ID sea unico, pero pienso que deberia NO ser necesario hacer mas una para una determinada tabla; la razón es que el control a nivel de perfil se da a nivel de que columnas se muestran (igual agregar tambien controal de acceso a este nivel no traeria mayores problemas).
Otro dato importante son : la sentencia sql “interna”, y el alias sobre esta. Si miran el codigo van a ver que las sentencias sql finales toman la forma

Code:

Select FROM
( SELECT INTERNO
WHERE INTERNO — depende de los parámetros de búsqueda, de “sql dinamico” que tiene el Tabledir, y posiblemente de las las restricciones “Role.addAccess”
ORDER BY ALGO — esto es requerido para que la paginación sea consistente
LIMIT X, OFFSET Y — esto aplica la paginación, actualme siempre en salto de 100
) AS NombreTablaExterna — este nombre es al que me refiero como “alias”

Un determinado AD_Info tiene uno o mas AD_InfoColumn; estas AD_InfoColumns son las que se van a usar para inferir lo que llame .

-AD_InfoColumn: esta es la representación en diccionario de datos de lo que en el código definí con la clase Info_ColumnNew (el “New” porque la clase Info_Column ya existia…). Los datos mas importantes son : la clase de “resullSet”(la clase con que se tiene que leer desde la base de datos) como la clase con que se muestra en el grid (esta clase sirve por ej para distinguir entre el conjunto de AD_InfoColumn cual va a ser la que va a tener el “id” de la entidad siendo mostrada; esto es necesario para saber que columna es la que tiene por ej, el M_Product.M_Produt_ID en InfoProduct); si se tiene que mostrar en el grid y en que posición “relativa”; si se tiene que mostrar en el panel de detalle y en que posición “relativa”; la posición relativa en el resultSet (“relativa” significa que lo importante es el orden entre las varias AD_InfoColumn dentro de una determinada AD_Info; desde codigo, esto luego se normaliza a secuencias de la forma 1,2,3,4… o 0,1,2,3…. según sea el caso), y finalmente una expresión de columna sql arbitraria (eso si, la expresión usada para calculara tiene que hacer referencia “NombreDeTablaExterna”, no al nombre de la tabla que se haya usado internamente ). Esta ultima expresión es la que va a ir parar como un elemento en y por defecto NO tiene que tener parametros sql (si se requieren parametros, se tiene que poner dentro de la expresion sql interna; no en la expresion de las columnas).
Ademas, hay que agregar un campo Value (esto es para la customizacion a nivel de ventanas; explico mas adelante), y otras que son mas cosméticas (ancho preferido de las columans; nombre corto en las columnas; tooltip).

-AD_InfoColumnAccess : esta es simplemente una relación de acceso entre roles y AD_InfoColumn. Como todos estos tipos de acceso la semantica es: si no hay ninguna restricción sobre un AD_InfoColumn, entocnes todos tienen acceso; si hay uno o mas SOLO los Roles especificados tienen acceso. La columnas importantes serian las obvias: AD_COlumnInfo_ID y AD_Role_ID (posiblemente también IsActive)

Ahora bien, el tema del “filtrado por contexto”, funciona agregando una sola columna string a AD_Column (se podría crear oooootra tabla solo para esto, pero no lo veo muy necesario) y “creando una convención” de filtrado. Llamemosle a esta columna InfoColumnFilter. La semantica detras del valor de esta string prodria ser:
-vacia, null o “*”, no se filtran ninguna
-“+CalueInfoColumn1,ValueInfoColumn2, etc” : se muestra SOLO las columnas que tengan estos “ValueInfoColumnX” en su “value”.
-“-ValueInfoColumn2,ValueInfoColumn2, etc” : se muestran todas las columnas salvo las que tengan un Value especificados en la lista
Esto es, la primer forma es “sin restricción”, la segunda (la que tiene prefijo +) es “sola estas”; la tercera (prefijo -), todas menos las que especifico.

Bien; el algoritmo de “restricción” seria mas o menos
1) Obtentgo el AD_Info (filtrando por AD_Table_ID)
2) Obtento todas sus AD_InfoColumn (menos la inactivas) relacionadas al AD_Info (filtrando por AD_Info_ID obtenido en 1)
2) Filtro la AD_InfoColumn segun el rol actual (este paso y el anteriro se puede hacer usando una sola sentencia sql; y en realidad queda mas claro hacerlo asi.
Conceptualmente la sentencia sql seria

Code:

select * from AD_infoColumn IC
where (
O AD_InfoColumnAcces no tiene registrro para AD_InfoColumn
O AD_InfoColumnAccess tiene una entrada para AD_infoCOlumn y el id del rol actual
)
AND IsActive = ‘Y’ AND AD_Info_ID =

Esto básicamente obtiene una lista de InfoColumn_New; tomando esta lista y el filtrado de acceso a info (el cual la clase VLookup pasa como parametro al InfoXXXX), se consigue otra lista aplicando el filtrado de “contexto”. Esto es, esta lista final, previa “normalización” de indices (indices en resulset, que comienza en 1; e indices en “grid” y en “panel” de detalles que que comienzan en 1). Va a ser la que finalmente , forme las en el sql final.

A esto, se le agrega un par de cosas mas que actualmente no estan soportadas y “deberia salir andado”. En particular la ordenación: el tema aca es que el ordenamiento se tiene que dar ANTES de aplicar la paginación, si no no tiene sentido (no tiene sentido ordernar mediante ; se tiene que hacer sobre las columnas que resueltan del select interno).
Para esto, pienso que hay que agregara a AD_Info otra columna, tambien una string que tambien siga una convención simple. Lo mas simple que veo eso esto:
OrderAvailables::Columna;: Columna2>, etc.
Con esta string la GUI puede generar un pequeño control visual que le permita al usario aplicar el ordenamiento.

Doy un ejemplo para que quede mas claro: info para MBParner:
AD_Info:

Code:

AD_Table_ID:Id de AD_Table_id de C_BParner
InnerSql: “SELECT * FROM C_BPartner”
NameExternSelect: “EC”
OrdersAvailables:”Nombre:C_BPartner.Name;CUIT:C_BPartner.CUIT”
LimitPagination: 100
(notese que OrdersAvaliable depende de la como se conforme InnserSql)

Algunos AD_InfoColumn

Code:

AD_InfoColumn1:
-value:Id
-Class: “ID”
En grid: si, en detalles, no
-Orden visual: en grid 1, en detalles 0 (si no va en detalles este valor no se va a usar),
-orden result set: 10
-ExternCol : “EC.C_BPartner_ID as ID” (el as no es strictametne necesario)
(notense que el externCol uiliza EC; esto es, AD_Info.NameExternSelect)

AD_InfoColum2:
-Value: Name
-Class: String
-En grid, si, en detalles, si
-orden: en grid 20, en detales 20
-orden result set: 20
-ExtenrnCol: “EC.Name as Name”

AD_InfoColumn3:
-Value:CUIT
-Class: String
-En grid, si, en detalles , si
-orden visual ; en grid 30, en detalles 30
-orden result set: 30
-ExternCol:”EC.CUIT as CUIT”

AD_InfoColumn4:
-Value:TaxIVA
-Class:String
-En Grid, NO, en detalles , si
-orden visual: en grid 0; en detalles 40
-orden result set: 40
-ExternoCol :
“(Select Name form C_TaxCategory where C_TaxCategory_ID = EC.C_Tax_Category_ID) AS CatIVA”
(notese que esta ultima columna externa es calculada; pero es calculada a partir de EC.C_Tax_Category_ID; NO de C_BPartner.C_BPartner_ID;

Bueno, en que sql resultaria todo esto? Asumiendo que no hay fitlrado por rol ni por contexto y que esta visulaizando la segunda pagina, ordenana por nombre (por defecto se ordena por la primer entrada en “OrdersAvailables”, la sentencia final seria algo asi

Code:

SELECT
EC.C_BPartner_ID as ID,
EC.Name as Name,
EC.CUIT as CUIT,
(Select Name form C_TaxCategory where C_TaxCategory_ID = EC.C_Tax_Category_ID) AS CatIVA
FROM
–aca viene el select interno, el filtrado, el orden y la paginación
(
SELECT * FROM C_BPartner — select interno
WHERE xxxxx — este valor depende de los paramtros de busqueda
ORDER BY Name — este se toma de alguna de las opciones en OrdersAvailables
LIMIT 100, OFFSET 99 — limit se toma de AD_Info; offset del estado interno del Info haciendo simplemente la cuneta (LIMIT * pagina que se quiere ver) – 1
) AS EC — este es el “alias” tomado de AD_Info

Con el resultado de esta query, y los datos dados en la lista normalizada de InfoColumn_New formada a partir de las AD_InfoColumns se puede mapear cada uno de los valores a sus respetivas posiciones tanto en el grid como en el panel detalle.

Notese:
1) el sql interno puede ser realmente complejo; puede ser tranquilamnete un “join” un “union” de varias tablas.
2) lo unico que se cambia entre busqueda y busqueda y que depende de los parametros de busqueda, es WHERE xxxx; este WHERE xxx contiene tanto el filtrado del usuario, como el filtrado “dinamico” de los table dir (validación de table) como las restricciones de acceso dadas a un permir sobre determinadas filas de determinadas talbas (ver MRole.addAccessRole(String); a metodo hay que llamarlo con el sql intenro, NO con el sql final)
3) Actualmente la logica de paginación no contempla retonrar el total de items “sin paginación” ; esto es facil de agregar haciendo el acceso en dos pasos: el primer generar una string final interna sin paginación y “redondeada” por un “SELECT Count(*)”; esto es algo como

Code:

SELECT COUNT(*) FROM
(SELECT INTERNO CON WHERE xxx , pero sin ordenamiento ni LIMIT y OFFSET) AS NombreExterno

Este select no calcula las columnas externas, ni las ordenas; solo aplica el WHERE xxx a la sql interna y al resultado de esto le obtiene la cantidad.

4) Todas estructuras de datos y la logica detras no tiene porque estar estrictamente asociada a un InfoXXXX en particular. Es facil utilizar todo esto para ventanas de consultas en general ; digamos, ver las facturas adeudadas. Utilizando esta estructra se puede generar rapidamente un “form” que tenga casi todo el trabajo echo por este miniframework diseñado originalmente para Info’s. De aca que AD_Info.AD_Table_ID pueda ser null (esto es, no esta necesariamente asociada a una tabla).

5) Siguiendo la idea de 4, a los infos o estas ventanas de consulta rapida, se les puede agregar reportes jasper “on the fly” (aunque aca no se si es tan facil) que tome como dataSource algo generado por la misma sql final (posiblemente sin paginación). El formato del reporte puede ser, a falta de otra informacion, de un formato por defecto; incluso con opciones simples como “mostrar tambine los detalles?”; “imprimir información de parametros?”. Fijense que hay bastante información como para generar un reporte Jasper generico (ancho de columnas, clases, si esta en detalle, si esta en el grid)

6) Uniendo 4 y 5 se logra algo que para mi puede darle a todo esto mucho más valor agregado: se elimina para muchos escenarios el reporteador interno, con la siguientes cualidades:
-uno tiene un preview directo (piensen el resultado de una busqueda de una InfoXXXX como un preview de que datos se van a imprimir)

-uno puede “reejecutar” todo el informe sin que siquiera se invoque a Jasper (porque lo que un hace es en realidad reejecutar la query y ve los resultados en una grilla Java)

-los parámetros no se piden de entrada; el usaurio los va probando y reejecutando la busqueda hasta que logra haber listado lo que realmente quiere reportear. Recién ahi apreta un boton “Print” (de aca en mas entra Jasper y el reporte generado al “vuelo”; lo unico que hay que darle es o la sentecia sql final, o directamente el resultSet)

Ok, 5 y 6 se van un poco de las manos, pero no lo veo para nada imposible y faltaría para igualar al reporteador interno actual, la habilidad de “zoom”. Esto creo que se puede hacer fácilmente via la columna “class” en AD_InfoColumn; por ej, una convención es que la “clase” ID_XXXX es de tipo entero y en realidad refiere a un id de la tabla XXXX; por ej, si el InfoProduct (o en un reporte de productos en general) aparece una columna (una AD_InfoColumn) con clase “ID_C_TaxCategory”, toda la lógica lo trata como un entero (y en general no lo visualiza, ni el grid ni el detalle), pero al seleccionar una determinada fila se activan botones de zoom (con un nombre descriptivo), uno por cada ID_xxx que se haya encontrado en el proceso de generación las InfoColumn_New; si el usuario presiona el botón zoom asociada ID_TaxCategory, se busca el valor asociado con la fila actual y se invoca el el método de zoom correspondiente para la tabla “C_Tax_Category” con el valor encontrado). Esto ultimo esta bueno independientemente de se implementa 5 y 6 ya que sirve para los Info.

Que opinan?

PD : bueno, termine escribiendo mas de que antes de que se me corte la luz….

[Javier Ader]

por lo que vi rxtx es una librería en Java para acceder a los puertos seriales; el tema de soportar los controladores fiscales EPSON viene mas que nada por como implementar el protocolo de comunicación (por ej, como “traducir” una factura a una secuencia de comandos específicos de EPSON sobre el puerto seríal); aunque obviamente, alguna libreria (o un programa externo) hay que usar para llevar a cabo la comunicación física. Yo hace un tiempo habia investigado un poco, y use otra librería de acceso; es más, implemente el envío de algunos comandos. Esta acá http://www.libertya.org/comunidad/foro-libertya/8-desarrolladores/746-clases-que-usan-el-puerto-en-serie-contr-fisc#791 ; fijate que ahi habla de “spooler” Hasar (este es el programa externo que realmente lleva a cabo la comunicación física).
Bien, como soporta Open Bravo los EPSON, la verdad que no se; lo ideal sería que tengan algún tipo de “spooler”. De todas maneras, seguro que se pueden tomar bastantes ideas. Estas interiorizado en como implementa la comunicación?

[Javier Ader]

Perdón, no lei nada… pero bueno; doy algunas ideas:
-que se “cuelgue” (no responda ni un error), no será porque un tema de concurrencia? El preinstall se ejecuta dentro de una trasnaccion; si por alguna razón hay otra transacción desde otro lado accediendo a la misma base de datos (digamos el procesador contable) se pueden bloquerar … medio raro igual.
-“Las instrucciones a mano funcionan”: las instrucciones del preinstall.sql las ejecutaste antes a mano? Bueno, no te va andar la instalación si las ejecutas sobre la misma base de datos (estarías ejecutando el preinstall dos veces); no creo que lo hayas hecho así, pero por las dudas.
También, si el preinstall.sql anda a mano, lo que podes hacer es: las ejecutas a mano (pero logueandote como el usuario correcto de postgres, el mismo que usa libertya (por defecto “libertya”); si no te van a quedar mal los permisos de las tablas); descomprimís el jar con cualquier compresor zip; le sacas el preinstall.sql (dejale uno preinstall.sql vacio por las dudas); volves a comprimir todo como un zip; le cambias la extensión a .jar y probas con este nuevo.
Ahí obviamente el preinstall los vas pasar….
Si te pasa lo mismo en la etapa postistall haces lo mismo, pero usando postinstall.sql.
(igual esto seria un hack… el problema real debe venir por otro lado…)

PD : el tema del UTF8 en los archivos no será?
PD 2: mientras se esta haciendo la instalación de un plugin, podes mirar el log desde libertya mismo (creo…); antes de iniciar la instalación anda a preferencias y pone el nivel de log a alguno bajo (ALL creo que se llama el mas abarcador); cuando ves que la instalación se cuelga, deberías poder ir Preferencias y ver el log. De esta manera, no importa si después se cuelga la ventana de instalación; el log lo vas a tener (y supongo que pasandole las ultimas entradas a Federico va a poder mejor por donde va la cosa)

[Javier Ader]

(bueno, ahí edite; me había faltadp un NO… si no afirmaba lo contrario que quería).

Si… tiene sentido tu escenario; pero no se si es el más común. Yo creo que lo mas normal es que una empresa desee saber exactamente cuanto le debe un cliente, y ahí si no tenes que contar los pedidos. Imagínate una cobranza…. también, tene en cuenta que podes tener pedidos desde hace 3 meses que simplemente quedaron ahi; no se facturaron ni se remitieron ni nada… Es pedido te cuenta en el balance; uno tiene que andar buceando entre pedidos “no facturados” (algo que no es tan simple de encontrar, salvo que ejecutes una query sql…) para cancelarlos (y en ese caso probablemente tengas un problema de periodo cerrado…).
Otro problema aparejado (aunque no se si tan importante) es que los pedidos no se contabilizan (con todo sentido a mi entender) y por ej, una balance contable te va a diferir de lo que dice el “balance libertya”.

De todas maneras, aún en tu caso, si uno quisiese llevar el total de “pedidos a credito” simplemente habría que agregar una columna a MBParnter; TotalOrders (que ya va de la mano con el nombre que usa el código), y ahi almacenas el valor que esta calculando ahora el código en el 4to campo de la query; ahora, ese TotalOrders no se debería sumar en ningún momento a cosas como “crédito usado” (en donde ahí si entran pagos de facturas o factura sin saldar parcial o totalmente, por ej); es mezclar peras con manzanas. Incluso mas, si queres tener un control de valor máximo sobre este campo, se agrega TotalOrdersLimit, y este si se chequea en de manera similar al credito al momento de completar pedidos a crédito (sería algo como “podes realizar pedidos a crédito sin facturar hasta cierto monto”; no se igual si tendría mucho sentido de control…).

Bueno…. ahora, si me preguntas, entre que sea parametrizable y agregar 2 columna (mas!) a C_BPartner, no se… me parece que que prefiero lo primero (ando medio reticente a agregar columnas o incluso tablas… es mas, si me preguntan, no se si entraría a eliminar muchos campos sin uso…); pero bueno, esto es solo porque muchas tablas , con muchos campos, me complica la vida a mi… no porque sea lo correcto.

[Javier Ader]

Ok, igual me sigue sin cerrar la idea de que un pedido genere “una deuda”; estas se deberian generar al momento de facturar si es que no se esta pagando en el momento (e.d hay alguna forma de pago a credito en el pago de la factura). Fijate que ademas el pedido afecta el balance solo si el “termino de pago” en el pedido es “A Crédito”; si no, no hace nada….
El termino de pago en un pedido, a mi entender es solo informativo: “cual es el termino de pago que se tiene que usar al facturar este pedido”, pero no en ningún sentido tiene que representar alguna forma de “contrato” entre el la EC y nosotros.

El tema viene por el TPV… (bueno, muchas de las cosas que estoy posteando últimamente vienen por código relacionado al TPV). Ahí se crea un pedido de forma automática que tiene un termino de pago sobre el cual el operador no tiene control (creo que lo toma del termino de pago seteado en la EC… otro valor que es solo informativo, o si se quiere, “indicativo”; pero para nada “obligatorio”). Entonces, lo que termina gobernando si se afecta o no el balance de una EC, son valores “informativos” (esto por ej, te obliga a que muchas veces tengas que configurar “En efectivo” como termino de pagos en TODAS las EC; asi no falla en el TPV cuando se esta el total en efectivo…. este lleva a que simplemente no tenga sentido este campo en la EC, ya que te vez obligado a ponerlo siempre en el mismo valor….). Ahora bien, como se supone que el pedido esta relacionado con el estado de credito de la EC, codigo en MOrder chequea si la EC tiene credito; y ademas le actualiza el balance… algo que 1) ya lo chequea el TPV (y de mejor manera, porque chequea solo por la cantidad que sabe que se va a pagar a credito; NO por el total) 2) lo va a hacer de todas maneras la futura factura generada desde el pedido (si es que el tpv esta configurado para hacerlo automaticamente; si no, cuando se facture el pedido). Esto no solo, se repiten chequeos y actualizaciones, si no que ademas, el chequeo que hace el pedido es por un importe mayor al necesario….

Por todas estas cosas (y principalmente porque semánticamente pienso que un pedido, sin importar el termino de pago, NO debería afectar el balance de la EC) pienso o que se debería sacar esto, o por lo menos que sea configurable.

Yo actualmetne opte por esta ultima forma, poniendo este codigo en MBParnter

Code:

/**
* Determina dependiendo de la configuración del sistema si los pedidos afectan
* el estado de crédito de los clientes.
*
* @return
*/
public static boolean ordersAffectCredit()
{
//TODO: simplemente se retorna false; deberia
//tomarlo y cachearlo desde la configuracion del sistema
return false;
}

Despues modifique el codigo en setTotalOpenBalance() para que dependiendo de setTotalOpenBalance() genere una string sql distinta (en ralidad, simplemten el select que calcula el total en ordernes simplemente lo saque).
Tamien estoy modificando codigo en MOrder para que saltee codigiciones y acutalizaciones del balance dependiendo de lo que retorne este metodo….Me da la sensación que por comentarios en el codigo voy a tener que tocar algo en “AllocationLine.processIt”, porque se lee en MOrder el comentario:

Code:

// Update total revenue and balance / credit limit (reversed on
// AllocationLine.processIt)

No creo que los cambios necesarios vayan mucho mas alla de esto.

De cualquier manera, me da la sensación de que esta configuración es fácilmente reversible; a lo sumo hay que hacer un proceso que cada vez que se cambie esta configuración, recorrer cada una de la EC y le invoque el setTotalOpenBalance(), el cual va a tomar la nueva configuración y por lo tanto tener o no en cuenta a los pedidos y finalmente salvarla (es mas creo que ya hay un proceso que hace esto, aunque me parece que lo hace para una sola EC)

[Javier Ader]

mmm eso ultimo no se si es tan así… lo escuche muchas veces, pero creo que lo que hay que hacer no es reiniciar el servidor, si no el cliente…. El tema creo que es porque el cliente internamente cachea información sobre los periodos abiertos o cerrados (o la configuración del procesador); es mas, yo casi nunca tengo el procesador contable corriendo así que obviamente no tuve que reiniciarlo (no estaba corriendo de entrada…).

[Javier Ader]

Y si… ademas de por el bug que te comente, una misma linea de pedido es ingresada mas de una vez; en realidad una vez por cada beforeSave y afterSave() de MorderLine…. (la razón: el select count(*) se hace sobre transaccion “null”; pero la creacion de las entradas en la tabla se hace sobre la transacción que esta usando la linea….).
Ahora, seguro que comentado estas invocaciones (yo ya lo hice y no vi nada raro) se mejora la performace el tpv…. cada linea del pedido es salada cerca de 10 veces; estas 10 veces generan 4 accesos a estas tablas (dos en el before, 2 en el after)… Es decir; 40 accesos adicionales por linea de pedido que no tienen mucho sentido.

Fijate también en MOrder.afterSave (creo…); que llama a un método “afterSaveSync” la primer parte de este método tiene que ver con esta tabla; también la comente… Después de eso te tira un error, porque el código que sigue actualiza codigo que realmente “deberia” estar sincronizado entre el pedido y sus lineas… el tema es que el afterSync es llamado con “DocStatus”; una columna que no existe en las lineas; por lo tanto tambien comente la invocacion afterSaveSync( “DocStatus” ). (las demas invocaciones “parecen” estar bien…)

Ok, ahi con esto la ganancia es minima (un sql update por cada save en una Morder) pero bueno… es lo correcto.

Un tema relacionado: si estas con la optimización del TPV (algo en lo que tambien estoy…) mira por los afterSave de MorderLine (iba a hacer un thread sobre esto, pero bueno, lo pongo aca…). Ahi se actualiza los C_OrderTax del pedido y el total (en 10.09 se hace de una manera un poco distinta a 10.03, pero termina sineod lo mismo). Ese codigo no solo ralenta mucho el TPV si no que es ….. incorrecto.
Por que? y bueno, uno modifica una linea, no se deberia tocar NADA de la cabecera, principalmente porque la cabecera puede estar completa (si uno recalcula los impuestos, va a estar modificando un pedido que NO deberia modificarse, ya que esta completo y posiblemente contabilizado; y el resulta puede ser distinto, si por ej, algun producto cambio de cat. iva ). Es decir, se viola el “pricipio” de que los documentos completos no se modifican. Se puede dar esto? Y si….. se da todo el tiempo; el punto mas evidente es cuando se completa un remito o una factura asociada a un pedido (sus lineas son modificadas, pero solo ciertas partes como la cantidad entregada y facturada; eso esta bien; el tema es que el after save no mira para nada esto….
De donde viene este actualizacion de un header por parte de una linea? Y… no se, pero debe venir de que sirve a la gui, ya que te mantiene actualizados los totales cuando uno modifica o agrega una linea….
Que solucion veo? Que esto solo se lleve a cabo cuando el pedido que contitne a la linea este en estado drafted… En realidad es una situación tan común modificar un documento cuando NO esta en drafted (externamente via el codigo de otro documento, por ej, de un remito, sobre las lineas de un pedido), que pienso que habria que poner un metodo directametne en PO, que sirva para todos estos casos; algo como

Code:

public boolean isHeaderDrafted(String TableHeader, int IdHeader)
{
if (idHeader <= 0) false; //igual , se supune que es llamado desde el afterSave //o del beforeSave pero cuanod no "isNew"; asi que no deberia darse ya que se deberia haber setedo en la linea String sqlST = "SELECT DocStatus FROM " + TableHeader + " WHERE " + TableHeader+"_ID = " + getId(); PreparedStatement pstmt = DB.preparedStatement(sqlST,getTrx_Name()); String ST = null; //try.... y toda la bola ResultSet rs = pstmt.executeQuery(); if (rs.next()) ST = rs.getString(1); else //se loguea algun error, return "DR".equals(ST); }

(fijate que el el preparedStatement corre sobre la transacción que esta usado el objeto actual… si no, se rompe todo; va a pasar los mismo que el select que te dije antes…)
Entonces, el codigo del afterSave, no puede hacerse mas eficiente:

Code:

afterSave…. sobre el final
….
if (isHeaderDrafted(“C_Order”,getC_Order_ID())
{

//SOLO ahora actualizo los totales y los impuestos…
//si esto es necesario claro; SI NO, no se toca nada del
//header, ya que no esta en estado Drafted

}

Lo ultimo, como te dije, no solo es por eficiencia, si no también por correctitud, y pienso que se debería aplicar a MInvoceLine y MInOutLine (bueno , en realidad , a casi cualquier cosa que se una “linea” de un documento; incluso tal vez a otras cosa relacionadas, como COrderTax, o CInvoiceTax).

Incluso mas… en el beforeSave o afterSave se podria llegar a dispara un error si se descubre que se esta modificando algo que no deberia poder ser modificado sobre un pedido/remito/factura no drafted. Por ej, desde la linea del pedido se deberia chequear que cosas como la cantidad o el producto NO estan siendo modificadas en un pedido NO drafted (en el caso del pedido creo que hay solo 2 o 3 columnas que deberias ser permitidas modicadas desde codigo: la cantidades ordernadas, entregadas y facturadas; todo lo demas, SOLO si el pedido esta en DR). También por ej, en el before o afterSave de registro nuevos se debería poder evitar la inserción sobre no documento no DR (algo similar en before o after delete).

La ganancia que tenes ahi de efincia es de 2 o 3 accesos por cada modificación de linea de pedido luego de que este esta en estado completo (hay que contar que el chequeo te come 1 acceso, asi que la ganancia no es tan grande).

Finalmente, esto no afecta la correctitud (en realidad, el código que afecta a la cabecera puede ser elminado completamente; salvo que desde la gui no se va a tener los resultados calculados hasta que hasta que uno lo complete), ya que el prepareIt de Morder, recalcula todo de nuevo, asi que las COrderTax y los totales van a estar ok.

[Javier Ader]

Buenas, me uno al tema…
Estuve mirando que en la versión 10.09 se utiliza (cuando se compila con ant) otra librería iText (que tengo entendido que es usada para generar previews o exportar a PDF), mayor a la que se usa en 10.03 (es decir,pararon de una version de iText mas reciente a una mas vieja…. eso es lo raro, se en general se supone que las versiones mas reciente arreglan bugs viejos… bueno, y meten nuevos). Por ahí puede andar la cosa? Luis esta usando la versión 10.03.
En los fuentes de 10.09 están las dos librerías; en 10.03 solo la nueva (o sea, al reves….).

Finalmente, no pude testear porque no tengo una base con esta cantidad de facturas, pero simule sentencias sql similares a las que usa el reporte, y no tardaron tanto… así que me parece que por ahí no va. Después debuggueo un poco el código y veo si las clases de Jasper intentan en algún momento cargar alguna clase de iText, y de cual versión.

PD : de paso, en LauchLibroIVA (si no recuerdo mal el nombre) hay un mini bug; la sentencia que calcula los totales no se hace sobre una transacción; la segunda , la que lee los facturas en si misma, si se ejecuta sobre la transacción del proceso; bueno, es muy raro que se de, pero es posible que los totales calculados difieran del lo que se podría inferir de de las lineas dadas en la segunda sentencia (por ej, un pago antes de que comience la segunda sentencia, pero en paralelo o justo después de la primera, va a generar dados incorrectos). Las dos sentencias se deben ejecutar bajo la misma transacción.

[Javier Ader]

Mira, yo bajo 10.03 siempre que veia este problema lo soluciona yendo a la configuración del procesador y poniendole mas dias “hacia atras y hacia adelante” (bueno , lo que intentaste vos…) y siempre me anduvo. En 10.09 no me paso, no tuve mucho tiempo para probar la nueva versión.

Ahora bien, que pasa si por ej generas un pedido o una factura “a crédito” desde las ventanas comunes?
Si no te pasa, es casi seguro porque desde el tpv estas intentando facturar en efectivo; el tema que al facturar en efectivo (creo…) intentar cerrar el Libro de Caja asociado a la configuración del TPV si cambio de dia (creo….); y seguro que cambio de dia, porque el libro de caja que viene preinstalado debe tener años casi ….
Si va por ese lado, intenta crear una nueva configuración de libro de caja (en pesos, y todo igual a la que viene preinstalada); la vieja configuracion directamente deshabilitala si podes (me parece que no te la va a dejar eliminar), y el configuración de TPV pone el nuevo libro de caja.

En cuanto al procesador contable , te diria que lo dejes en automatico, al menos mientras probas el sistema (de ultima , cuando todos los meses, poneles un poco de mas dias “gracia”; pero en general no es necesario); a mi nunca me trajo problemas, salvo casos raros como puede ser el anterior.

[Javier Ader]

en que versión? 10.09 o 10.03?. Me da la sensación que lo que vos encontraste es algo relacionado con un funcionalidad reciente para afectar el stock (uno da de baja un producto, se elimina del stock; y al mismo tiempo se carga la suba del stock del producto “relacionado”), y en cualquier caso, con la tabla M_Substitute.

Bueno, mirando las dos tablas son casi “identicas” (las diferencias de los productos relacionados es que te permite especificar en que sentido esta “relacionado” (y en este sentido, un producto X puede estar relacionado con otro producto Y de mas de una manera); realmente no se cual deberías usar… posiblemente cualquiera de los dos !?. Ok, el termino “substitutos” parece mas recomendable para tu caso, si nos guiamos solo por el nombre…

[Javier Ader]

Mucho no investigue, pero lo primero que se me viene a la mente es el concepto de “artículos relacionados” (una relación muchos a muchos arbitraria); Libertya tiene alguna tabla relacionada a esto, pero dudo que este “usable”. Se llama m_relatedproduct, y seguro que se puede activar en la ventana de Productos.

Ahora, suponiendo que esta tabla este usable, otra cosa muy distinta es que desde la ventana de selección de productos te permita visualizar y seleccionar un producto relacionado rápidamente; hacer se puede hacer, pero no debe ser un cambio menor. Igual, uno siempre puede conformarse con : Abrir selección de Productos; se seleccionar un producto; se apreta la “lupita” zoom que abre la ventana del producto; en esta ventana, en la supestaña “productos relacionados” (asumiendo que se puede activar) se pueden ver los productos relacionados; se mira el código, se vuelve a la ventana de información de producto, se busca por el código del producto seleccionado y se selecciona….. Muchos pasos, es verdad, pero si este tipo de cosas no se da muy a menudo, puede llegar a alcanzar.

La otra es generar un reporte que dado un producto, de muestre los relacionados, pero no te va a servir para seleccionar de manera “automática” los productos (vas a tener que ejecutando el reporte de manera paralela cada vez que quieras ver que productos relacionados existen).

[Autor]

Entradas