Respuestas de foro creadas
-
AutorEntradas
-
Federico CristinaSuperadministradorExacto… debido a que importaste productos la tabla es I_Product, I_BPartner es de Entidades Comerciales (desliz con los nombres)
Saludos,
Federico13 abril, 2010 a las 11:35 am en respuesta a: PROBLEMAS IMPORTACION DE FAMILIAS Y SUBFAMILIAS #34370
Federico CristinaSuperadministradorCintia,
Según pude observar, ciertas traducciones al español son incorrectas en función de la semántica de las tablas para la jerarquía de productos. Tenemos:
Code:m_product_lines <- linea de producto m_product_gamas <- familia m_product_category <- subfamilia m_product_family <- marcaEl proceso se llama Import Product Categories y la tabla I_MProduct_Category, con lo cual es correcto que impacte en M_Product_Category, la cual es la tabla de subfamilias y NO la de familias (tal como se indica en la entrada de menú y ventana de importar). Además de esto, el combo al que referencias, justamente apunta a la tabla de Familias (M_Product_Gamas_ID), lo cual está en concordancia con el resto de errores en las traducciones.
Ya he tomado nota de ésto a fin de corregirlo para el próximo release de Libertya.
En definitiva, no contás con un importador de familias, pero sí contás con un importador de subfamilias

Saludos,
Federico
Federico CristinaSuperadministradorBuenas,
Tenés dos alternativas. La primera es ejecutar el query para eliminar las tuplas de la tabla de importación:
Code:DELETE FROM I_BPARTNERLa otra alternativa es checkear el tilde Borrar registros antiguos ya importados, en la próxima importación de artículos que realices (es uno de los parámetros del proceso correspondiente).
Saludos,
Federico
Federico CristinaSuperadministradorJavier,
Este thread da para charlar bastante al respecto!
Quisiera enfocarme en un tema específico, sobre las líneas de DB… parece que estamos frente a un caso de “miedo al setter”. Lo he visto en algunos beforeSaves de POs que vienen de las viejas versiones, en los cuales es un error seguro. Aquí no estaría seguro de afirmar que está mal, si la operación setTransactionIsolation fuese mucho mas costosa en tiempo que el getTransationIsolation, entonces estaría bien evitar hacer el set lo mas posible.
En definitiva, ¿notaste una diferencia en la performance al forzar el set, en lugar de consultar todas las veces? El siguiente paso sería debatir sobre el set propiamente dicho… pero bueno, un paso a la vez

Saludos,
Federico9 abril, 2010 a las 11:04 am en respuesta a: Ejecucion arbitraria de sentencias sql en bloque #34365
Federico CristinaSuperadministradorJavier,
Muy interesante tu aporte!
Sobre el convert que comentás, esto se debía a que el framework original soportaba el uso de sentencias escritas en Oracle y Postgres, y dicho convert realizaba la conversión correspondiente según el DBMS utilizado. En fin, el tema es que sin ese bypass (noConvert) en la conversión ocasionalmente se rompía la instalación. Como actualmente estamos seguros que las sentencias escritas están en Postgre, obviamos toda conversión.
Cuando me haga un tiempo veré más en detalle este tema a fin de pulirlo para el próximo release.
Saludos!
Federico
Federico CristinaSuperadministradorBuenas,
A fin de descartar posibilidades…
¿probaste todas las alternativas al especificar el servidor? O sea, indicar el nombre del host, la IP o localhost? En ciertas ocasiones es posible que funcione una sobre la otra.
El puerto especificado en la ventana de configuración de login coincide con el especificado en la configuración del servidor de aplicaciones?
Saludos,
Federico
Federico CristinaSuperadministradorJuan,
Los Conjuntos de Atributos te permiten definir una serie de propiedades (como por ejemplo talle, color, numero de serie, etc.) para que luego se la apliques a un artículo específico.
Por ejemplo, puedo definir un conjunto de atributos que contenga las propiedades Talle y Color. Luego indico que el artículo camisa tendrá este conjunto de atributos.
Posteriormente, en el remito, puedo definir la recepción de mercadería especificando estas propiedades en las líneas del remito: 2 camisas XL azules, 5 camisas S rojas, etc.
Saludos,
FedericoPD: muevo el thread a ayuda
Federico CristinaSuperadministradorGlenn,
Respondo brevemente a tus consultas:
1) Es correcto lo que indicás sobre la semántica de los campos pricepo y C_Currency_ID
2) Hay que distinguir si estas propiedades son características del artículo general o si son específicas de cada una de las instancias existentes en el almacén (por ejemplo el talle o el color de una camisa). Si es el segundo caso, deberás trabajar precisamente con Conjunto de Atributos. Sin embargo, para cualquiera de los dos casos, deberás ampliar el importador para adaptarlo a tus necesidades (tabla I_Producto, formato de importación, y clase ImportProduct).
Saludos,
Federico7 abril, 2010 a las 11:44 am en respuesta a: Ejecucion arbitraria de sentencias sql en bloque #34350
Federico CristinaSuperadministradorJavier,
Buenas! El problema que te comentaba previamente sobre las referencias, se nos presentaba bajo un escenario en el que intentábamos impactar modificaciones estructurales y referencias posteriores sin el uso de un stored procedure dinámico como comentás.
Fijate el comentario de la clase PluginXMLBuilder método executeUpdate():
Code:Procesa el contenido completo del SQL que recibe (simple o multiples sentencias)Para el preinstall.sql, este método impacta todo el contenido del archivo (por ahora con la limitación de los comentarios, pero eso debería arreglarse mejorando el método readFromJar()). Con lo cual el PreparedStatement sí permite múltiples sentencias. El problema es en el caso en que dichas sentencias hagan referencia a tablas todavía no existentes (escenario en el que te comentaba previamente).
Es por esto que, en lugar de impactar todo en un único script, se realiza un impacto independiente para el preinstall. Tu aproximación es interesante justamente en casos donde sea necesario sortear dicha limitación.
Saludos y gracias por comentar!
Federico
Federico CristinaSuperadministradorCintia,
La ventana de Entidades Comerciales podés encontrarla bajo el nombre Business Partner.
Suerte,
Federico6 abril, 2010 a las 12:06 pm en respuesta a: Ejecucion arbitraria de sentencias sql en bloque #34338
Federico CristinaSuperadministradorBuenas,
La alternativa que comentas fue una de las tantas que evaluamos al momento de implementar el instalador de componentes.
Aun cuando habiamos logrado ejecutar multiples sentencias en un unico envio al DBMS, esto no nos era de utilidad, ya que lo primero que éste hace es parsear el contenido del SQL, y toda referencia inexistente es devuelta como erronea (suponer por ejemplo un CREATE TABLE y luego un INSERT en dicha tabla)
Es por esto que fue necesario enviar sentencia por sentencia inevitablemente. El resultado es el mismo debido al uso de una unica transaccion. La mejora en la performance creo que debe ser notoria y de ahí nuestra primera intencion en resolverlo con dicha aproximación.
Saludos,
Federico
Federico CristinaSuperadministradorPodrías brindar más información al respecto? Bajo qué plataforma realizaste la instalación? Estás utilizando un instalador automático?
Fijate la siguiente imagen. Una vez en la ventana de login, accediste a las propiedades de la conexión mediante el botoncito remarcado en rojo?

Fijate que justamente al final de este artículo de la wiki se habla al respecto.
Saludos,
FedericoPD: muevo el thread a instalación y configuración.
Federico CristinaSuperadministradorBuenas,
La manera más facil de saber que base de datos tenés, es mediante una consulta que indique la fecha de release:
Code:select version from ad_systemAsí, la versión 9.10 tiene fecha 26-10-2010, la versión 10.03 tiene fecha 15-03-2010, etc.
En cuanto a los binarios, podés verificarlo en el archivo build.xml de ServidorOXP, dentro del apartado Instalar Librerias EAR.
Code:Respecto al error que mencionás, qué más indica en la pantalla? Ejecutaste primeramente el script de actualización de 9.10 a 10.02rc?
Es importante recordar realizar TODA la actualización de 9.10 a 10.03 con el servidor detenido, y sin inicio via JNLP; sino con el arranque mediante Libertya.bat o Libertya.sh.
Saludos,
FedericoPD: muevo el thread a Instalación y configuración
Federico CristinaSuperadministradorLuis,
Parece que se nos pasó este thread!
Quote:Necesitamos lanzar varios reportes hechos en Jasper desde la ventana Entidad Comercial, por ejemplo: Cuenta Corriente del Cliente, Facturas adeudadas, Articulos mas comprados, etc..Lo más sencillo sería tener un botón por cada informe a disparar. Sin embargo, si la intención es que con un botón directamente se disparen varios reportes, deberías implementar un proceso que invoque a todos los procesos restantes.
La nueva clase VPluginInstallerUtils del release 10.03 hace uso de esta funcionalidad. El método doPostInstall(), invoca desde código la ejecución de otro proceso.
Code:/* Insertar el parametro para el XML */
ProcessInfo pi = new ProcessInfo( ” Post Instalacion “, postInstallProcessId);
ProcessInfoParameter xtraParam = new ProcessInfoParameter(PluginConstants.XML_CONTENT_PARAMETER_NAME, xml, null, null, null);
pi.setParameter(addToArray(pi.getParameter(), xtraParam));/* Habilitar al usuario System para que pueda disparar el postinstall */
postInstallprocessAccess(ctx, trxName, postInstallProcessId);/* Invocar la ejecución del proceso, si el mismo devuelve null es porque se cancelo en los parametros */
ProcessCtl worker = ProcessCtl.process(installer, installer.getM_WindowNo(), pi, Trx.getTrx(trxName));Tené en cuenta que para cada proceso invocado, se abrirá la ventana de diálogo correspondiente a los parámetros requeridos por el proceso (en caso que de que los mismos tengan definidos parámetros).
Para “inyectar” los parámetros por código y que directamente no se presente la ventana de diálogo, deberías utilizar alguno de los métodos execute() de la clase MProcess. Por ejemplo algo así:
Code:// setear los parámetros
HashMapparams = new HashMap ();
params.put(“Parametro 1”, XXX);
…
params.put(“Parametro X”, XXX);// ejecutar el proceso
MProcess.execute(getCtx(), launchProcessId, params, get_TrxName());Quote:Estos reportes los deberia largar desde un boton y que no abran ningun proceso de seleccion sino que use los argumentos de la ventana, como id de EC, para no tener que seleccionar nada, sino que el reporte salga directoPara ésto, fijate por ejemplo la clase LaunchInvoice (impresión de factura), en el prepare() recupera la tabla y registro donde se encuentra el usuario en ese momento:
Code:AD_Table_ID = getTable_ID();
AD_Record_ID = getRecord_ID();Saludos!
1 abril, 2010 a las 10:57 am en respuesta a: Que paso con el campo de carga de CUIT de las EC? #34317
Federico CristinaSuperadministradorJavier,
Gracias por comentar.
Es muy probable que el número de secuencia se utilice únicamente para dar el orden de despliegue a los campos (clausula ORDER BY del query), a fin de recorrer el ResultSet correspondiente e ir incorporándolos a la pestaña, con lo cual no creo que esto pueda llegar a generar problemas.
Saludos!
Federico -
AutorEntradas