[Javier Ader]

Los asociación y el seteo de precios lo podes hacer desde la ventana Articulos, solapa (si mal no recuerdo), Precios. Ahi podes crear un entrada por cada lista de precios y asignarle 3 precios: el de referencia (que en realidad no es tan “de referencia” tal como estan las cosas), el de lista y el precio limite.
Tene en cuenta que en realidad, los precios se asignan a “Versiones de listas de precios” (una lista de precios, puede tener mas de una versión). Libertya viene con algunas listas precreadas; pero te diria que empieces de cero y a esas las deshabilites (debilitando Activo) asi no te confunden y creas un Lista de Precios (digamos “Costos Pesos”)y una version de lista dentro de esta (digamos “Costos Pesos – 19 Julio”). Esto lo podes hacer desde el perfil de Compras (de paso desde esta misma ventana , en la tercer solapa, podes agregarle el precio a un producto; esta es la segunda forma de hacerlo).

Ok, igual, date una vuelta por la wiki que seguro esta mejor explicado.

[Javier Ader]

Tengo mis dudas con respecto a LDM, nunca lo investigue demasiado, pero me parece que aunque no existe la funcionalidad de automatica o semi-automaticamente setear estos precios “compuestos”, el precio que por ej te muestra al ventana “Información de Productos” y por ej, el precio que se setea en los pedidos contempla el cálculo al que haces referencia.

La idea basica es asi: si el producto tiene precio en la lista, se usa ese; si no, y es un producto “compuesto” de otros, se busca en el precio de estos últimos y se hace el calculo tomándolos como base.

Todo esto viene porque el código en general no mira el precio en las listas de manera directa, si no que llama a una función pl/java para obtenerlo (por ej, mira desde pgAdmin las funciones que comienzan con “bom”; esa son las usadas; por ej, bomPriceStd). Estas funciones hacen lo que dije antes (si no tiene precio, mira los precios de los componentes)

Hacé alguna prueba creando un producto compuesto que no tenga precio asociado en una lista pero si sus componentes, y despues buscalo en la ventana Información de Producto o crea un pedido que lo contenga. Según mi “hipótesis” te debería dar el precio calculado.

Finalmente, hacer un proceso que sugiera estos precios y permite de manera “mas o menos” masiva setear físicamente el precio en la lista (e.d, dar al usuario el precio calculado como un forma de “sugerencia”), estaría bueno (a mi en lo personal no me gusta mucho que haga el calculo automático via pl/java, ya que ademas es algo muy costoso; se empieza a notar cuando uno tiene mas de 2000 productos por decir algo).

PD : todo esto que puse es asumiendo que LDM es lo mismo que BOM (Bill of Materials, si no me falla la intuición), pero creo que es asi.

[Javier Ader]

La lista de precios que elegís en la ventana de selección de producto no tiene relación con la lista de precios del pedido; es un filtro y a la vez una opción de visualización (el precio que se muestra es la ventana es el precio del producto en esa lista).

Lo que te dice Antonio, es que aun agregando o modificando el precio manualmente en la linea del pedido, se hace la validación “el producto esta en la lista de precios del pedido?”. Si eso no es asi, se tira el error que estás viendo. Es una validación que se da a nivel de codigo y no se puede modificar o saltear realizando configuraciones del diccionario de datos.
A mi entender es una restricción demasiado “fuerte”; y te obliga a que el producto este en la lista de precios.
Supongo que la modificación a nivel de código no es tan complicada de llevar a cabo (para mi la mejor opción es “si la linea no tiene precio asociado o es cero, y no pertenece a la lista de precios-> error”; después de todo es el precio en un pedido), pero bueno, estas modificaciones no son tan simples como solo tocar del diccionario.

[Javier Ader]

Si, el nombre del proceso es incorrecto por un lado y por el otro, como decis borra cosas. El tema es que seguramente te borro un solo nodo; el de la raiz, y por lo tanto todos los demas no se pueden visualizar.
El tema es mas o menos asi:
-los nodos se almacenan en una tabla (AD_TreeNode en general, por ej, para el arbol de las cuentas contables; en otros AD_TreeNodexxx, para otros)
-estos nodos apuntan a los elemetos en si (pueden ser cuentas contables, por ej).
-lo que hace el procesos es eliminar aquellos nodos que no apuntan a ningun elemento (por ej, te va a borrar los nodos que no apunten a una cuenta contable) y agregar nodos raiz para aquellos items

Bueno, lo que pasa es que muchos arboles que vienen predefinidos tienen la peculiaridad de que el nodo raiz no apunta a nigún elemento, y es borrado por este proceso (lo hijos de este nodo siguen apuntando al borrado….). No me queda claro cual es la convención para consideran un nodo como raiz, pero una forma de solucionarlo es agarrando aquellos nodos que apuntaban al antiguo padre y setearle 0 (o a null, no recuerdo exactamente) en el campo que se usa para mantener esta referencia (parent_id), lo cual los convierte en raiz; otra es crear en nodo padre. Por esto, no se si el proceso es incorrecto o los arboles que vienen estan mal formados…

Si me decís que arbol fue el que “verificaste” te paso la sentencia sql que “debería” solucionarlo.

[Javier Ader]

Y si, es muy interesante la idea (bueno, sería una opción mas). Yo en algún momento me interiorice bastante en Joomla! , pero bueno, fue hace bastante y quede bastante de lejos de lo que se puede llamar un “experto”… Tambien habia mirado en esa misma epoca a VirtueMart; me acuerdo que estuve a punto de invertir tiempo en intentar hacerles algunas modificaciones, pero tampoco me pude interiorizar mucho (de todas maneras me quedo la sensación que era una extensión bastante completa y compleja).

Tengo entendido que VirtueMart tiene la capacidad de importación de artículos y precios por si misma; no llegue a poder ver cual era el formato requerido del mismo, pero pienso que una forma de estudiar “integración simple” podría ser definir una forma de exportación desde libertya a este formato y bueno, no es propiamente una “integración”, es un “puente” en todo caso, pero pienso que le puede dar valor agregado a Libertya y a VirtueMart y no creo que cueste mucho (la integración con Magento seguramente va a ser mas poderosa, pero en muchos casos probablemente sea innecesario; en general, si aun cliente le das un forma relativamente simple de mostrar sus productos en la web, le alcanza y le sobra).

Para una integración mayor (digamos, permitir realizar “pedidos Libertya” desde Joomla!), ya requetiría entrar en detalles mas profundos tanto de Joomla! como de VirtueMart. No lo veo imposible, pero ya es otra cosa.

[Javier Ader]

Si no, invoca al servidor desde la consola cmd (en XP, es Inicio -> Ejecutar -> “cmd”; en W7 creo que hay un acceso directo en el munu). Ahí no debería cerrarte la ventana.

[Javier Ader]

1) Jaja bueno, no se si te comprendo totalmente, pero si, casi seguro que el tema es libertya “cachea” los valores de las listas. Mas alla de que no estoy seguro si la validación sql es correcta (no es mas simple?: validacion = campo_con_dato_que_indica_utilizado IS NULL ), estoy casi seguro que los campos tableDir con visualización de listas desplegables se cargan al momento de apertura de la ventana; y como decis una forma de que se “recarguen” es cerrar y abrir la ventana. La otra forma que veo, de manera aun manual, pero más simple (creo que debería andar) es dar click derecho sobre el campo tableDir y darle actualizar (en la lista debería NO aparecer lo ya usados). Chequeame esto, pero estoy casi seguro que viene por este lado.
Otra “solución” es no usar visualización de tipo “listas”, si no usar visualización “search” (búsqueda). Las diálogos de búsquedas calculan los filtros cada vez que son abiertos.
Otra forma, un poco más compleja (y que tiene otras contras…), es setear este campo indirectamente via un proceso. El campo lo haces de solo lectura a nivel de diccionario de datos, pero agregas un campo Boton (digamos “Especifiar campo X” y un proceso asociado que que lo que hace es abrir un dialogo mostrandole las posibles valores a elegir (pero en este caso la “validación” no estaría en el diccionario de datos, si no en el código del proceso…). El proceso, luego de tomar la selección del usuario modifica la fila asociada en la base de datos con el valor apropiado. Ahora, fijate que esta solución y usar visualización “busqueda” es casi idéntica funcionalmente (y tiene otras desventajas ya que te obliga a guardar la fila antes de disparar el proceso); la única diferencia podría venir por lo visual.

2) Por lo que se, no hay forma de especificar ese funcionamiento a nivel de diccionario de datos. Lo que estas pidiendo sería un suerte de “Logica de inserción” a nivel de tabla, en el que uno podría especificar un logica arbitraria para determinar cuando es posible agregar un fila. Si no me equivoco, estoy casi seguro que tal versatilidad no existe.
Se me ocurre, si esta funcionalidad es muy importante, algo similar a la ultima opción que te di en el punto anterior: basicamente las filas “hijas” no las creas de manera convencional, si no mediante un proceso asociado a un campo en la tabla “padre” (la duda que se me presenta en este momento es si el diccionario de datos permite especificar la subpestaña como “no se permite inserciones”, pero si “ediciones”; si esto no existe, estas obligado a hacer la subpesataña como solo-lectura)

Ahí te agrego a mi lista de contactos del MSN y chateamos; ando medio ocupado últimamente, pero dos por tres me libero un poco.

[Javier Ader]

Buenas. El punto 1, no te termino de comprender, pero supongo que es asi:
1) campo 1: digamos que podes elegir A o B
2) campo 2: tiene un filtro relacionado con un tabla pero dependiente de si en el campo anterior se escogio A o B (por ej, suponiendo que la tabla con el filtro sea la de articulos: “si se escogio A, que solo se puede seleccionar Productos, si selecciono B, solo Servicios”)

Es asi más o menos la idea? En ese caso, supongo que en el filtro estas referenciando a variables de ambiente y que no hay forma de autoamticamente obligar a recalcular la validación. Lo unico que se me ocurre es poner un callout en el campo 1 y en caso de modificarse este valor simplemente “borrar” el campo 2 (otra forma un poco más compleja es simular la validación desde el callout y solo “borrar” en caso de que no pase la validación el valor actual en el campo 2).

En cuanto al punto 2, creo que libertya, para lograr este funcionamiento (relación 1 a 1) requiere ciertas restricciones a nivel de base de datos. La tabla “hija” tiene que tener por un lado la misma clave que la tabla padre y ademas tiene que ser una clave foranea a esta última. Estas restricciones se tienen que dar no solo a nivel de base de datos si no también a nivel de diccionario. Exactamente como se tiene que dar no lo tengo presente pero podes mirar las tablas AD_OrgInfo o AD_ClientInfo (estas son las tablas que te aparecen en la segunda solapa de Organización y de Empresa; estas solapas te permiten agregar a solo sumo una sola fila “hija”).

[Javier Ader]

Probablemente no sea una solucion muy “santa” pero se me ocurrio mientras leia asi que capaz que sirve.
Definis como el precio del servicio (de todos si queres) como la unidad; esto es, digamos, “Propaganda con Panfletos”, valor 1$. Al momento de hacer una factura o un pedido, lo que haces es variar la “cantidad”; si le queres cobrar 33,50$, le pones como cantidad 33,50 (33,50 x 1$ = 33,50$).
Jaja, una locura, pero yo que se, tal vez tenga sentido (seguro que lo tiene para aquellos empresas que principalmente venden artículos, y solo prestan un conjunto limitado de servicios).

De todas maneras, que en los pedidos no te deje ingresar los precios manualmente pero si en las facturas, es algo que se soluciona a nivel de configuración interna de Diccionaro de Datos.

[Javier Ader]

Supongo que si, pero por las dudas: “completaste” los dos remitos? (si estan en estado de borrador no afecta en el stock, solo lo hacen cuando se completan)

[Javier Ader]

Es muy probable que tenga el procesador contable usando el “apertura/cerrado automatico de periodo”; creo que bajo esta configuración no importa si abrís o no manualmente el periodo. Una cosa que podes hacer sin necesidad de pasar al modo manual es cambiar los dias de “historia” (creo que asi aparece). Por ej, ponele momentáneamente que puedas contabilizar con 15 días antes del periodo actual (los dias en el pasado que requieras dependen de la fecha contable del docuemnto con respeceto a la fecha actual; con 15 casi seguro que alcanza).

[Javier Ader]

que situación rara jaja, se esta entrando un bucle infinito a nivel sql….
El tema creo que viene porque al no tener instalado PL/Java lasfunción bompricestd(integer,integer) no existe (esta función se define con LANGUAJE ‘java’); y solo existe la función similar llamada bompricestd(numeric,numeric) que esta definida con LANGUAGE ‘plpgsql’. El tema es que bompricestd(numeric,numeric) simplemente llama a bompricestd(integer,integer) (y aca, Postgres al no encontrar exactamente esta fución, piensa que estas llamando a bompricestd(numeric,numeric); esto es, termina llamando recursivamente a la misma función, y no retorna nunca).
Fijate esto: desde pgAdmin abrí la base de datos, el esquema libertya y vas a Functions; ahí te va a aparecer bompricestd(numeric,numeric), pero, según mi hipotesis, no te va a aparecer, el bompricestd(integer,integer).
La forma correcta de verificar pl/java desde pgadmin creo que es ejecutando algo como
set search_path to libertya;
SELECT bompricestd (0::Integer,0::Integer) from ad_client;

(el ::Integer creo que obliga a llamar a la función correcta, si no se cae en la versión “plpgsql”).

No se como habrás creado la base de datos, pero me da la sensación que al momento de hacerlo pl/java no estaba registrado como un lenguaje para tu postgres, y las funciones definidas para el lenguaje java simplemente tiraron un error y no se crearon.

[Javier Ader]

jaja bueno, ese columna es en donde especificas cuanto vas a pagar del monto pendiente; dale doble click e ingresa el monto que queres saldar (tip: si debes digamos 67,85 y queres pagar todo, podes ingresar un numero mayor, digamos 1111111; le das enter y te pone 67,85)

[Javier Ader]

No se si te referís, a directamente facturar un producto que no “existe”, pero bueno:
La facturas (no por TPV, que yo sepa) no requieren seleccionar un producto; uno puede escribir la descripción y listo.
Ahora, esto tiene la implicación contable que la linea de la factura al no estar asociada a un producto, no puede obtener la configuración contable del mismo. Aca entra en juego al configuración contable de las subfamilias; en particular (y de manera medio rara a mi gusto), al contabilizar un linea de un facutra que no esta asociada ni a un producto (sea servicio o no) ni a un cargo, se basa en la configuración contable de la primer “subfamilia que encuentra”, dandole preferencia a aquella que esta marcada como “predefinida” (algo que no tiene mucho sentido… a lo sumo se debería usar otro campo a nivel de subfamilia, digamos algo como “usar la configuración contable de esta subfamilia para aquellos productos no especificados en lineas de documentos”….)
Ahora, si vos te referis a seleccionar un producto y ademas poder modificar la descripción del mismo en la descripción de la linea creo que se puede ya que la la linea de las facturas tiene un campo Description , aunque parece que no esta siendo usada (habría que habilitarla en el diccionario de datos).
Ok, lo que no se es como hacen los reportes y la impresion via controladores fiscales para encontrar la descripción a imprimir (me parece que obtienen la descripción de la linea a partir del producto, asi que me parece que se requieren hacer otros cambios un más complejos…)

[Javier Ader]

Si, la mayoría es código relativamente viejo (y probablemente muchos no esten en uso). Lo que si vi mucho de esto en la parte relacionada con la contabilidad; fijate que todo esto vino porque me puse a mirar como se contabilizaba una factura y creo que el equals que me incito a buscar todos los demas estaba en
org.openXpertya.acct.DocLine_Invoice.setAmount(BigDecimal, BigDecimal, BigDecimal)

Un método que se llama cada vez que se contabiliza un factura.
Otro creo que debe estar relacionado con el bug que por lo menos estaba hasta la versión anterior que ocurria cuando uno cargaba asientos contables de manera manual. Casi seguro que era este:
org.openXpertya.model.MJournalLine.beforeSave(boolean)

Bueno, y otros relacionados con el “costing”.

Hay muchos otros “equals” (en realidad Eclise me busco todas las llamadas a Object.equals…), pero en general se dan entre referencias “object” o con respecto a una Strings (o.equeal(“algo”)). Esos, salvo que justo las instancias en tiempo de ejecución vengan a ser BigDecimal, no deben traer problemas.

[Autor]

Entradas