Respuestas de foro creadas
-
Entradas
-
Buenas,
Es extraño. Lo único que se me ocurre en función de lo que comentás es que C_Currency tiene como AD_Client_ID = 0 (la cual es System, dado que es información para todas las compañías). Podrías probar a acceder al WS con dicha compañía a ver si en ese caso sí devuelve la información. De ser así, es probable que en algún lugar se esté aplicando algún filtro por compañía.
Slds,
FedericoPodrías probar a debuggear el servidor entonces, a fin de determinar si al menos encuentra/instancia el proceso en cuestión.
Buenas,
No se ya lo comentaron, pero una alternativa rápida es la de deshabilitar todos los triggers de cada tabla:
Code:ALTER TABLE tabla DISABLE TRIGGER ALL
DELETE FROM tabla
ALTER TABLE tabla ENABLE TRIGGER ALLIdeal para casos donde se presenta referencias cíclicas. La desventaja es que puede llegar a quedar alguna inconsistencia, dado que no hay validación referencial alguna bajo este método.
Saludos,
FedericoBuenas,
Fijate otros ejemplos ya existentes en BBDD. Por ejemplo la lógica de despliegue para un campo de una pestaña se almacena en displyalogic:
select displaylogic from ad_field where displaylogic is not null
De manera similar hay filtros para otros casos, como filtrado de registros, etc. Son campos relacionados con AD_Table, AD_Tab, AD_Column, AD_Field, etc.
Saludos,
FedericoBuenas,
Quizás no entendí bien la consulta, pero en la ventana de Entidades Comerciales, existe una pestaña llamada Contacto (usuario), en la cual se pueden cargar usuarios asociados a la entidad comercial. Incluso es posible que estos usuarios accedan al sistema, especificando datos adicionales más allá de la dirección de correo electrónico.
Slds,
FedericoBuenas,
Este feature se encuentra funcional, dado que lo utilizamos frecuentemente.
Para que funcione es necesario tener el servidor de aplicaciones corriendo (dado que es el server quien las ejecuta a las tareas programadas), y adicionalmente, para cada proceso que quieras programar, necesitarás darle los permisos correspondientes (desde ventana Perfil) al usuario que hayas indicado en la configuración de la tarea programada.
Luego de cualquier cambio en la configuración te recomendaría que reinicies el servidor de aplicaciones. Pasados unos 4 minutos luego del inicio del mismo, ejecutará las tareas programadas que tenga pendientes, y en intervalos según lo especificado.
Slds!
FedericoBuenas,
Efectivamente debería comportarse tal como mencionás: si estás queriendo redefininir lógica de persistencia, hay que extender de MPluginPO e implementar – por ejemplo – el método preBeforeSave().
Si esto se encuentra correctamente configurado, quizás pueda deberserse a algún comportamiento anómalo de la lógica de componentes bajo una tabla cuya Primary Key se encuentra compuesta por dos Foreign Keys (M_ProductPrice no contiene un campo M_ProductPrice_ID, sino que la PK se forma mediante M_Product_ID y M_PriceList_Version_ID. M_Inventory sí contiene un campo PK con nombre M_Inventory_ID).
Esto podría llegar a ser el motivo, pero es una idea únicamente. Para validar si efectivamente es así, podrías implementar una clase M que extienda de MPluginPO sobre otra tabla cuya PK sea el típico campo M_XXX_ID (son la mayoría de tablas) y validar si ahí no se presenta el problema. Por otro lado, validar si el problema también ocurre sobre otra tabla similar a M_ProductPrice, como por ejemplo AD_User_Roles (PK formada por dos FK). Si por ejemplo al implementar MUserRoles que exientede MPluginPO se presenta mismo problema, entonces ya tenemos determinado el origen del problema.
Slds!
FedericoBuenas,
No recuerdo haber trabajado sobre ese botón, pero podés ver cual es el proceso accediendo como System Administrator y ver qué proceso tiene definido el botón a nivel tabla/columna en metadatos (luego el proceso tiene definido el nombre de la clase que estás buscando).
Saludos,
FedericoBuenas,
Podés resolver el problema de otra manera, sin necesidad de esperar por una nueva versión. La versíon más actual de LYWS cuenta con la operación recordQuery(). Mediante esa operación podés recuperar uno o varios registros de una tabla a partir de un criterio especificado, e incluso filtrar sólo un número de columnas a retornar.
Code:/**
* Devuelve una serie de registros de una tabla dada
* @param data parametros generales de acceso y columnas a recuperar
* @param tableName Nombre de tabla (M_Product, C_BPartner, C_Order, C_Invoice, M_InOut, C_AllocationHdr, etc.)
* @param whereClause criterio de filtrado
* @param includeNamedReferences para las foreign keys, devolver además del ID, el name, value o identificador correspondiente al registro referenciado
* @return MultipleRecordsResultBean con OK, ERROR, los registros correspondientes
*/
public MultipleRecordsResultBean recordQuery(FilteredColumnsParameterBean data, String tableName, String whereClause, boolean includeNamedReferences);Es posible por lo tanto, recuperar el ID de un BPartner a partir de su Name, y luego utilizar la operación bPartnerRetrieveByID() para recuperar todos los datos del BPartner. También podrías utilizar directamente recordQuery() para recuperar un registro de la tabla C_BPartner, pero la operación bPartnerRetrieveByID() incluye datos adicionales, como su localización.
Saludos,
FedericoBuenas,
La jerarquía para los beans es la siguiente:
PO
|
X
|
M
|
LP
|
M.._extDonde X es un POJO autogenerado (generalmente de CORE) a partir de la información en metadatos de columnas, y M es una clase opcional con lógica de persistencia/documentos (también de CORE). LP es un POJO autogenerado a partir de la información de metadatos de tu componente, y M.._ext es opcional conteniendo lógica ad-hoc, pero NO de persistencia/documentos. Esas clases deben extender de MPluginPO o MPluginDocAction, como se muestra en los ejemplos.
En cuanto a la lógica de PluginHandler.getLPluginPO():
Code:// Primero busco la M.._Ext
…
// Si no existe, busco la LP_
…Esa lógica se utiliza únicamente en el handler de persistencia o lógica de documentos, a fin de recuperar el POJO correcto (y con la información cargada adecuadamente), fijate por ejemplo PluginDocActionHandler.processAction() y PluginPOHandler.processPO(). Sin embargo, para determinar la clase de helper a instanciar (clases que extienden MPluginPO y MPluginDocAction), esta lógica no tiene incidencia alguna (no debería estar buscando la clase M..Ext para instanciar helpers).
Saludos,
FedericoBuenas,
Ampliando un poco lo que comenta ccarranza, en terminos generales las operaciones de gestión de documentos (completar, anular, etc.) tienen una ventana genérica, la cual en caso de querer incorporarle parámetros requeriría un desarrollo ad-hoc que en realidad no se justificaría, principalmente porque los parámetros podrían variar de documento en documento, y también según el estado del mismo. Además deberías implementar los cambios tanto para el cliente Swing como para el Web.
Es por esto que te sugirieron una alternativa bastante viable, que es la de tener un conjunto de checks en la tabla misma, los cuales podrás leer y utilizar al comento de aplicar la lógica de documentos correspondiente (ejemplo: completeIt(), voidIt(), etc.).
De esta manera no se requieren cambios a nivel GUI, únicamente estructurales y en el modelo; solución reutilizable tanto para Swing como para Web.
Saludos,
FedericoBuenas,
Lamentablemente el debug desde Eclipse solo es posible basándose en el build realizado mediante Compilar.sh, realizando un remote-debug. No existe actualmente una configuración de ejecución/debug iniciando JBoss desde Eclipse mismo (debido a las tareas que implica el build del Compilar.sh).
Saludos,
Federico
