Respuestas de foro creadas
-
Entradas
-
Buenas,
Seguramente se deba a que, en el perfil de Administración, tenés que ir a Herramientas -> Preferencias y Tildar “Mostrar Pestañas Contables”
Saludos,
FedericoRespondido en este thread.
Cierro el thread.
Gracias por tus comentarios.
El nuevo release contendrá un check en las facturas para permitir la creación automática (o no) de entradas en el libro de caja. Obviamente que desde el TPV, éste será seteado de manera acorde automáticamente.
Saludos,
FedericoHermann,
Como estás.
Tu problema radica sencillamente en una cuestión de diseño. En Libertya, toda tabla (salvo excepciones) DEBE contener una columna _ID, que será la PK, cuya numeración es gestionada por MSequence. Esto es en definitiva un autoincremental que se apoya en las secuencias físicas de Postgres.El seteo manual de identificadores para la columna asociada con la PK no es correcto, y es por ello que no podés lograrlo utilizando las funcionalidades de PO.
Supongo que tu intención es tener una tabla de referencia con ciertos datos de tipo “Clave – Valores”, y en la columna _ID querés cargar las entradas específicas a la Clave (y éstos son ciertos valores específicos). Para ésto, además de la columna _ID, deberías tener una columna Value, a la cual podrás definirle una UK (para evitar repetidos) y cargar en ésta las Claves, pero abstrayéndote de la secuencia de la columna _ID (la cual recordemos es la PK). Luego podrás recuperar el ID mediante una simple sentencia SQL (o implementar un método getIDFromValue() o similar en la subclase M correspondiente).
Mas allá de este comentario, teniendo el código completo de Libertya, podrías ver cómo modificar el core para permitir lo que planteás. Sin embargo, estarías brindando una funcionalidad que me parece no debería ser utilizada.
Saludos,
FedericoBuenas,
isSoTrx justamente se refiere a toda transacción que sea de venta.
Específicamente en el beforeSave de MInOut, el comentario es incorrecto, debería decir de entrada, ya que:
1) Valida por !isSOTrx()
2) El query de existsDocNumber(), tiene una clausula: AND isSOTrx = ‘N’Luego está la discusión respecto de que quizás sea necesario realizar la misma validación para remitos de salida, pero en general éstas se manejan mediante secuencias.
Saludos,
FedericoBuenas,
Aunque no lo verifiqué, si está sucediendo ésto, efectivamente es debido a un error que será corregido en el próximo release.
Saludos,
FedericoFijate que para ciertas tablas ACCT, hay una tabla intermedia de configuración por defecto (al insertar un nuevo registro no va a buscar la configuración contable directamente a C_ACCTSCHEMA_DEFAULT).
Por ejemplo para C_BP_CUSTOMER_ACCT primeramente lee la configuración de C_BP_GROUP_ACCT. Esta última sí lee C_ACCTSCHEMA_DEFAULT.
Lo mismo pasa con M_PRODUCT_ACCT -> M_PRODUCT_CATEGORY_ACCT -> C_ACCTSCHEMA_DEFAULT.
Probablemente sea por ésto que no se están actualiando los valores.
Saludos,
FedericoSi te fijás en la versión internacional, el callout apunta a CalloutInvoice, pero en la versión AR el callout apunta a CalloutInvoiceExt que extiende de la primera.
Esto se debe básicamente a que existe un conjunto de validaciones y lógica funcional extra para las facturas, debido a las normas vigentes del país.
Actualmente, las bases de datos para cada versión difieren en ciertas cosas, y ésta es una de ellas. A partir del próximo release, la intención será disponer de una versión internacional, a la cual se le podrá instalar componentes (plugins), y entre éstos, la localización AR.
Saludos,
FedericoHemos estado desarrollando una funcionalidad para temas relacionados (por ahora solo para desarrolladores, aunque creo que igualmente está presente en la versión 9.10), la cual sería posible utilizar en caso de ser necesario.
Hay un proceso Actualizar Tablas de Cuentas, que permite seleccionar una tabla _Acct (tablas de configuracion contable como C_CASHBOOK_ACCT), y en función de la configuración de cuentas por defecto, pista las entradas existentes en dicha tabla.
Fijate si contás con dicho proceso desde el perfil System Administrator, y si contás con la clase UpdateAcctTablesProcess.
Saludos,
FedericoAprovecho para mencionar que dicho fix funcionará únicamente para la localización AR (ya que utiliza exclusivamente la clase CalloutInvoiceExt). De tener que corregirlo en una version Internacional, habría que modificar la superclase CalloutInvoice.
El error se presenta debido a que la clase no existe. Muy probablemente fue quitada del proyecto y se omitió la eliminación del botón.
Sin embargo, a fin de cambiar la cuenta predeterminada no es necesario utilizar dicha funcionalidad.
Saludos,
FedericoBuenas,
La clave del error está aca:
Code:at org.openXpertya.model.M_Table.getPO(M_Table.java:528)O sea, no puede recuperar el PO correspondiente. Podés poner un brake ahí a ver que está ocurriendo. Corroborá además algunas cosas:
1) Si la tabla se llama M_Juguetes, la clase debe llamarse MJuguetes (a veces se nos escapa una S final).
2) La tabla creada deberá tener los campos obligatorios: M_Juguetes_ID (respetar mayusculas y minusculas!), CreatedBy, AD_Client_ID, etc…
3) A nivel SQL deberás setear la PK de M_Juguetes.
Saludos,
Federico