Respuestas de foro creadas
-
Entradas
-
en Configurar.exe, cuando te pide nombres de maquinas, o pones el nombre de tu maquina o directamente la ip; por ej, 127.0.0.1 debería andar siempre; creo que el instalador por defecto deja una configuración inicial con el nombre de tu maquina para Windows; eso trae problemas… ante la duda siempre pone direcciones de ip.
En cuanto al Wamp y TeamViewer puede ser que te traigan problemas si usan alguno de los ports; me decis que probaste con estos servicios cerrados asi que es probable que no sea este tema (igual, deberías haber cerrado los servicios Y reiniciado el servidor de Libertya); el port 8080 es muy usado como port web auxiliar; ponele otro si tenes dudas (digamos 10000); o si no bajate este programa http://technet.microsoft.com/en-us/sysinternals/bb897437.aspx que te muestra que programas estas usando que puertos.Le estas errando de port; hay dos ports que usa libertya en su forma de “servidor”; uno es para entra a un server web interno, que es desde donde podes descargar los clientes; el otro es para hacer solicitudes remotas (este ulimto port no es para accederlo con un browser; lo usan los clientes libertya bajo un protocolo particular).
Para entrar al servidor web de Liberyta tenes que poner localhost:80 o localhost:8080 o lo que sea que hayas puesto como “puerto web” al momento de instalar o en la configuración (abrí Conrifurar.exe ; te va mostrar los ports usando actualmente).la clave que pones en la instalación no es la clave para acceder al sistema como usuario (la clave que te pide se usa internamente, por ej, es la clave que Libertya para acceder a la base de datos en postgres; esto es, es una clave de usario de Postgres; nada que ver con el password que tenes que poner para loguearte a Libertya).
Para ingresar a libertya, cuando te pide nombre de usuario y contraseña tenes que poner (si no lo cambiaron) AdminLibertya ; y password, lo mismo (es decir, el nomre del usuario y su password son iguales).Para darte una idea de los callouts mira los callouts existentes; por ej, el que decis de la dirección asociada a una Entidad comercial:
-desde el perfil System (o Administrador del Sistema) abris Tablas, vas a C_Invoice, mira la definición de la columna C_BPartner_ID (creo que se llama asi), vas a ver que tiene especificado un campo llamado Callout, con el nombre de un metodo de una clase Java (digamos org.openXpertya.model.CalloutInvoice.bpartner).
-ese metodo (bpartner) tiene que tener un conjunto de parámetros predeterminados (si mitas otros callouts vas a ver que todos tiene la misma definición); ese metodo es llamado cada vez que el usuario modifica el campo asociado al mismo (en este caso el la entidad comercial) y puede por ej, modificar otros campos dentro de la pestaña; esto ultimo es lo que hace justamente el callout de la EC en las facturas.Y si, para crear un nuevo callout tenes que crear un nuevo método en una clase, compilar el sistema y referenciarlo desde el campo Callout en la definición de la tabla. Desde pgAdmin no tenes que hacer nada.
Alguna vez estudie el proceso de importación de cuentas, y no se porque me pareció que si puede afectar las cuentas default…
Igual, creo que el proceso de importación puede modificar las cuentas ya existentes, incluyendo a las “por defecto”. Quiero decir el proceso de importación puede usarse no solo para crear nuevas cuentas, si no también para editar las actuales. Si es asi, el resultado no sería el mismo? Obvio que tendrías que saber cuales son las cuentas por defecto actuales para poder referenciarlas en el proceso de importación.
Bueno, agrego otra cosa (la iba a poner antes; se ve que se me traspapelo…).
Libertya no “cuesta mas” porque sea usado por mas personas (bueno, puede ser que el soporte ponga un limite de x estaciones de trabajo de las que se hace cargo; pero no hay un restricción “fisica” de limite de usuarios); Tango cobra licencias de uso por estación de trabajo. Bueno, esto parece una obviedad por el hecho de que Liberta sea gratuito, pero creo que desde un punto de vista económico vale la pena resaltar (si tenes 2 empleados no hay tanta diferencia; ahora si tenes o vas a tener digamos 10 personas usando el sistema, bueno, ya cambia un poco la cosa).Y bueno, como dijo Antonio; el grado de “customización” posible en Libertya es terriblemente superior; una parte por diseño (Tango por lo que tengo entendido no tiene algo parecido al Diccionario de Datos de Liberyta; ni el sistema de privilegios a nivel de perfiles; para nombrar algunas cosas) y por otra, porque se puede meter mano en el código.
Hace rato que no manejo Ubuntu… pero bueno, https://launchpad.net/ubuntu/lucid/i386/postgresql-8.3/8.3.8-1 ahi parecen haber paquetes binarios para tu Lucid. Son .deb y muy bien no recuerdo como se instalaban, pero deberían andar.
Ahora, alguien ya no habia hecho andar libertya usando postgress 8.4? Sabes de donde viene el problema de pl/java para 8.4?
Me da la sensación de que ya es hora de migrar (en realidad, creo que habria que comenzar a hacer updgrades en muchos otros componentes…).
EDITO: bueno, el link anterior es especifico parao i386; si no es tu caso aca estan otras versiones https://launchpad.net/ubuntu/lucid/+package/postgresql-8.3
No lo chequie, pero creo recordar que el proceso de importación de artículos, tal como esta implementado actualmente, no setea los precios de los productos en un lista de precios, si no otro precio que no tiene nada que ver (el precio de venta de un proveedor del producto; e.d, el proceso te permite importar un proveedor del producto y el precio que este proveedor tiene para el articulo).
Los precios para una dada lista se deberían importar de otra manera (creo que hay un proceso de importación). Supongo que te va a pedir como parámetro a que versión de lista de precios afectar (salvo que esta información este implícita en el formato de importación).
Creo recordar que la impresión se asocia a las pestañas y no a las ventanas; mas allá de eso, puede ser que le hayas errado y hallas configurado la pestaña de fact. de proveedores en vez de la de fact. de clientes (o al revés; el tema es que hay dos ventanas, y por lo tanto dos pestañas en donde se puede configurar la impresión).
Todo se cachea en el cliente; el servidor de aplicaciones no se usa. Optimiza el tiempo de carga inicial de las ventanas y el sistema en general (ya que se evitan muchos accesos al servidor; esto mejora a todos los clientes, ya que compiten menos a nivel de postgres y de red); la contra de esto es que puede generar una carga de memoria un poco mas grande por parte de los clientes y que como dije, para el desarrollo, puede molestar un poco.
Todo este tipo de optimizaciones las encuentro intentando ver porque tarda en mi maquina cargar las ventanas; esta bien que mi maquina es lenta, pero accede a un servidor que recide en la misma (e.d casi no hay penalidades de red ni compentencia con otros clientes). Algunos tests me llevaban a que la ventana de EC tarde en abrirse cerca de 20 segundos; despues de la primer apertura (por que el codigo acutal algunas cosas si cachea) cerca de 10 segundos; con las mejoras bajaba a 14 para la primer carga y algo asi como 6.5.Bueno, aprovecho y pongo otra mejora de caches: la función de acceso a DB es MLookup.isRecordID; en el caso de la carga de la ventana EC esta funcion genera algo asi como 60 accesos al servidor. Esta función es llamada solo desde MLookup.getDisplay (asi que seguro que genera accesos innesarios incluso despues de la carga de la ventana). EL codigo proviene de una modificación de Dataware (al menos eso dice el coentario) y mas alla de si es de dudosa utilidad o no , la idea de isRecordID es obviamente cachaeble: es el nombre de una columna “Record_ID”? Los nombres de las columnas dificilmente cambien, asi que ir al servidor a cada rato para verificar esto es costo innecesario. Lo que hice fue modificar isRecordID y delegar siempre este chequeo a la clase UpdateRecord_IDReports (por que supongo que esta relacionada con la modificación hecha; pienso que es un lugar correcto). El nuevo isRecordID() es simplemente
Code:private boolean isRecordID() {///Ader: mejora: MLookup.isRecordID
//se delega SIEMPRE a UpdateRecord_IDReports
return UpdateRecord_IDReports.isRecordID(m_info.Column_ID);
}E.d no genera un acceso al servidor.
UpdateRecord_IDReports tiene el nuevo metodo isRecordID que tiene una cache de cuales ids de columnas tienen el nombre “Record_ID” (son muy pocas, asi que mantenerla en memoria es poco costoso). También tiene otra cache, pero esta vez asociada al metodo UpdateRecord_IDReports.HaveNameColumn ya existente (este metodo es llamado menos veces que el MLookup.isRecordID, pero bueno, de nuevo, no tiene sentido no cachear esta info).Acá les pongo el UpdateRecord_IDReports directamente; la modificación para la primer cache es poco mas complicada (UpdateRecord_IDReports se tiene que dar cuenta cuando la cache es vaciada; tengo un usar un Listener del evento que dispara CCache).
http://www.eltita.com.ar/libertya/caching/UpdateRecord_IDReports.java(Haaaa se me borro el post que estaba escribiendo…)
Gracias fcristina; en cuanto tenga un poco de tiempo pongo la cache de MFields asociadas a una determianda pestaña (el tema es que aca no es tan simple y tuve que hacer un par de modificaiones; agregar un par de campos en MField); con esta cache y un par de otras mejoras logro crear un MWIndowVO usando solo 2 accesos a la base de datos (que tambien se podrían evitar con otras caches!); paso de cerca de 6 segundos para la ventana a EC a algo asi como 0.5 segundos (ok, despues de esto, hay otros accesos a la base de datos, por lo cual la carga no es tan rapida como desearia).De cualquier manera pienso que hay que modificar o extender la funcionalidad de CCache, por que todas estas mejoras son buenas para el usuario final, pero para el desarrollador pueden joder (ya que la cache evita ver rapidamente los cambios de diccionario…). El proceso “Vaciar cache” debería andar; el tema es que tal vez sea bueno mejorar un poco esto para que una cache pueda declarar multiples tablas de pendientes (no solo una) y que el proceso (probablemente un Form mas que un proceso) permita visualizar datos de estas caches y opcionalmente vaciar solo algunas.
Otro tema, que dificulta este tipo de caches es que el codigo a medida que va construyendo estos objetos hace uso del contexto para ciertas cosas; esto esta bien, pero el codigo debería modificarse para que en general
1) busque en una cache determinada
2) si no esta en cache, genere el objeto, pero SIN tener en cuenta el contexto
3) guarde en cache el objeto si se ejecuto el punto
2 (esto es, la cache refleja algo inferido solo del diccionario de datos independientemente del los valores en el contexto
4) haga todas las modificacioens en los objetos que provengan del contextoSi no se hace en estos pasos, uno no puede cachear el objeto, ya que este tiene datos inferidos del contexto actual (el cual puede cambiar la proxima vez que se acceda a la cache). Esto es, la cache es una forma de cachear partes de la base de datos; no tiene que tener ninguna información que pueda, directa o indirectamente provenir del contexto. Muchas partes del codigo va “mechando” un poco de aca otro poco de alla…
OTRO TEMA (relacionado):
Ok, el tema es que MLookupFactory con o sin cache sigue accediendo una vez por cada MLookupInfo (240 veces en la ventana de EC, de manera serial y solo para generar los MLookupInfo); esto se da cuando se llama a MRol.addAccessSql; el cual parte de la información la cachea (la que proviene de AD_Record_Access), pero otra, es delegada a MPrivateAccess.getLockedRecord(AD_Record_ID, AD_Table_ID).
La idea de getLockedRecord retorne algo como “(1,23,33)” [estos seria los ids lockeados por otros usuarios para una determinada tabla), para que pueda usarse en un select de la forma “NOT in (1,23,33)”.
Para mi esto o no debería usarse para los Lookups (en general los Lookups se usan para editar datos de otras tablas relacionados, no para editar los datos del lookup en si) o usar una forma de cache temporal (la cache es temporal, pero es flusheada de manera “deteminisitica”; esto es, se hace explicitamente desde ciertos puntos del codigo) para almanecar entradas de esta formaCode:AD_Table_ID Where
——————–
23322 –> “(123,22,232)”
222 –> “12”
1002 –> “” (esto significaría que no hay restricción)(offtopic: etiqueta code dejo de andar?)
Esta chache esta asociada a un deteminada AD_User_ID; el tema es que se precalacula al momento de cargar una ventana, haciendo UN SOLO acceso al base de datos; se “flushea” al finalizar la carga.Ahora, MRol (o MPrivateAccess; habria que ver donde queda mejor), al buscar el where para una determinada tabla lo que hace es mirar en esta cache “temporal”; si encuentra una entrada todo bien, si no, accede a la base de datos (salvo en el enfoque “trae todo” que planteo mas abajo; ahi, si hay una cache para el usuario, y esta cache no contiene entradas, se asume que no hay registros lookeados).
Veo dos enfoques para precalcular esta cache; uno mucho mas simple, el otro un poco más complejo pero puede ser un poco mas eficiente si AD_Private_Access esta muy poblada (no creo que sea el caso general….)
El primero, mucho mas simple, basicamente ejecuta la siguiente sentencia sql
“SELECT AD_Table_ID, RecordId FROM AD_Private_Access Where Ad_User_ID <> “id del para el que se construye la cache” “
Posiblemente, si se quiere, ordenado por AD_Table_ID.Con estos datos va construyendo un hashmap de Int a List
, (desde AD_Table_ID a listas de RecordID); despues de tranforma esta mapa en uno de la forma que puse antes (de int a String con el where ya generado). Si esta cache no tiene una entrada para una determianda tabla, es porque no hay lookeos de registros en la misma. La otra, es que al principio de la carga de una ventana determinada, se “precalculen” la lista de los ids de una y cada una de las tablas que van a ser refenciadas (lo que pasa es que esto no es tan simple) desde la ventana y el select inicial seria algo como “SELECT AD_Table_ID,RecordID From AD_Private_Access where Ad_User_ID<>“id del usuaria” AND AD_Table_ID IN “lista de tablas que van a ser usadas en la carga de la ventana” “. La cache generada de esta manera, TIENE que generar entradas vacias para los ids de aquellas tablas que no tiene restriccion de acceso, pero que estaban en la lista IN (esto es diferenciar el caso “la tabla no tiene restricciones” de “la cache no tuvo en cuenta esta tabla al cargarse”). Lo que tiene de bueno esto este enfoque es no va a generar entradas en la cache para tablas que no tienen nada que ver con la ventana en cuestion (digamos, si uno carga la ventana Bancos, no me va a generar una entrada para Productos si es que algun otro usuario lookeo un producto…). Acá, si uno no encuentra nada en la cache temporal, debería ir a buscar a la base de datos (esto por que por un lado, el calculo de “tablas” dependientes puede haber sido incompleto quedando algunas tablas sin tener en cuenta y la otra porque potencialmente se pueden estar cargando otras ventanas o desde algun otro lugar solicitando información para otra tabla que no tiene ninguna relacion con la ventana para la que se genero la cache)
Me imagino que el primer enfoque es el mas simple y posiblemente el mas eficiente en aquellos escenarios en que la restricción de acceso privado se use poco o nada, en los escenarios en que el lockeo privado se de mucho (y por lo tanto la tabla AD_Access_Private puede ser bastante grande), es posible que el segundo enfoque sea mejor.
Ninguna de estas dos ideas las implemente, porque por ahora corte por lo sano y getLookedRecord retonar siempre null en mi codigo (e.d, efectivamete deshabilite la funcionalidad de acceso privado…). De cualquier manera, lo veo bastante simple de implementar; después si me hago un tiempito, implemento el enfoque simple.
Lo que yo me imagine es que el número de serie debería ir a parar a un atributo del producto y no a un campo directo del mismo. Quiero decir, 300 memorias identicas salvo por el numero de serie, no deberian generar 300 productos distintos, si no, un solo producto “base”; esto por ej, te permite tener facilmente a nivel de stock “cuantas memorias X” tenes.
De cualquier manera, el problema funcional sigue siendo como cargarlos; la idea de fcristina apunta a eso. La otra que me imagino, tal vez más simple, sería tener un proceso de importación que lo que haga se generar un remito o agregarle lineas a uno existente (lo que pasa es que este proceso tambien debería generar o los productos, o las instancias de atributos especificos).
Yo te diría que no intentes instalar pl/java por separado y por ej uses el instalador automático el cual te instala Postgres y PL/Java sin problemas (el instalador automático no te muestra el dialogo para seleccionar pl/java porque esta configurado para hacerlo automáticamente).
Como lo hace, exactamete no lo se, pero podes descomprimir el .exe del instalador (lo abris como si fuera un archivo .zip, por ej, como 7zip) y vas a ver que contiene en por un lado el instalador de Postgres y otro “subinstaldor” (es otro exe, que no recuerdo el nombre, te vas a dar cuenta), para instalar pl/java (creo que ademas instala otras extensiones de postgress).
Si queres usar ese instalador el modo de hacerlo es poner en un directorio el instalador base de postgress y el “subinstalador” dentro del mismo directorio y despues ejecutas el instalador base (este instalador “mira” si en el mismo directorio aparece un instalador de extensiones y lo invoca). Ahi creo que te va a aparecer el dialogo para seleccionar pl/java tal como lo muestra la wiki (el tema es que la wiki esta medio desactualizada…).
Igual, no te compliques y usalo de manera directa (e.d sin descomprimir el instalador) que es mas simple. El unico problema que podes llegar a tener es que tengas que desinstalar previamente el postgres (el instalador automatico detecta si hay una versión ya instalada, y si la hay saltea la instalación de postgres) ya instalado y eliminar el usuario postgres (busca en el foro que esta como hacerlo).Jaja bueno, te respondí cualquier cosa; me confundí el libro diario con el libo de iva (la confusión me vino porque dijiste que era un requerimiento legal; que yo sepa el libro de Iva si lo es, el libro diario, nunca vi que lo fuera).
Deberías “activar” la entrada en también a nivel de “menu global”; usando el usuario System: Configuración-> Configuración del Sistema-> Menú; ahí tildas Activo.
Realmente no se que mostrara (y que este deshabilitado tal vez signifique que no anda del todo bien…), pero lo que te dijo fcristina lo podes usar como “libro diario” (tenes que filtrar solo por fechas contables); pero claro, no te imprime nada (creo…)
El proceso de generación del libro de diario , no genera asientos contables (al menos en Liberya), solo utiliza asientos contables creados previamene por el procesador contables y los muestra (mmmm y ahora que lo pienso, me parece que tampoco usa los asientos contables, si no que mira directamente los documentos, como las Facturas). Lo que hace el proceso, es lo que haria cualquiera a mano: recorrer las facturas y otros documentos similares e ir llevando las montos en cada una de las alicuotas de IVA.
Si mal no recuerdo, el libro diario se encuentra en el perfil Administración y hay dos “versiones” (la diferencia es solo visual, muestran lo mismo), con nombres similares.