Respuestas de foro creadas
-
Entradas
-
y si… la condición que chequea no es la ideal; el tema es que Libertya maneja “subcontextos” a nivel de ventanas completas (Env.getContext( m_vo.ctx,m_vo.WindowNo,”Processed”)). Esta claramente pensado bajo supoción de que en cada ventana va a existir un solo “Documento” (la columnas Processed y creo que un par mas son tratadas de manera especial, DocumentNo creo ).
Mas alla de esto, tené en cuenta:
-el nivel de la pestaña solo es algo visual (si no me equivoco); no tiene una semántica mas allá de mostrarte la pestaña identada.
-No entendí muy bien como tenes las pestañas, esa asi?:
A (order 10, nivel 0)
-> C (order 20, nivel 1; “hija” de A)
B (order 30, nivel 0)
-> D (order 40, nivel 1, “hija” de
La frase “C y D hijos en comun de A y B” me confunde un poco ; en particular “hijos en común”.
-Si estas teniendo este problema es porque en una misma ventana tenes mas de una pestaña asociada a algún tipo de documento; es medio raro esto….
De todas maneras; un “hack” podría ser cambiar la condición por
if( m_vo.TabNo > 0 && “el nivel de la tab actual” >0) {“el nivel de la tab actual” porque no se que tendrías que mirar (m_vo casi seguro que lo tiene en algún campo); también tal vez la condición no tenga que ser >0 si no >1 . Lo “ideal” seria “buscar en las pestañas padres” y ver si tienen en la fila actualmente seleccionada con Processed = Y… pero lo veo muy complicado y no se si tan necesario (tal vez un hack mas “simple” seria no mostrar en A y B las columnas Processed; creo que de esa manera no se guarda nunca valor en el contexto, y la condición de error nunca se daría…. igual, es medio “sucio”; porque te permitiría agregar filas “hijas” cuando Processed es realmente “Y”) .
Gracias Federico. Te comento que a lo que habria que tal vez prestarle atencion es a
ReportEngine.get( Properties ctx,int type,int Record_ID )
porque ahi si se cambio un poco la funcionalidad; antes se terminaba buscando otro formato de impresión en el caso de los pedidos y facturas no completadas (el tema viene por C_DocTye es 0). Más alla de que no pude testear esa modificación especifica (FIX 13 en el codigo) la nueva sentencia sql creo que esta bien (no la testie porque este metodo es llamado para impresiones “especiales” de facturas/pedidos/remitos y un par de documentos más, los ids de reportes que afecta están hardcodeados por ej proceso 119 para las facturas si mal no recuerdo); no afecta (o no debería) a la impresión de facturas normal.
Otra cosa a tener en cuenta es que el nuevo código usa la libreria iText directamente (por eso hay que incluirlo en el classpath en el print/build.xml, si no, no compila por ant), via la clase DocumentPDF; vi que en 10.09 estan iText 1.5.4 mientra que 10.03 esta usando 2.1.5 (o sea, se paso a una libreria mas vieja); yo lo probe exportando un informe con 2.1.5 y anduvo bien. Lo que si, DocumentPDF explícitamente setea la versión de documento pdf a generar a 1.2 (miras las propiades del documento pdf y te muestra esta versión), el código anterior no especificaba esto (y generaba un documento pdf version 1.4); Jasper no se a que versión estará exportando, pero debería andar con iText 2.1.5 (creo haber exportado mas de una vez).Más allá de esto, acá subo las ultimas modificaciones (ya que me había olvidado de tocar ArchiveEngine):
-modifique ArchiveEngine para que utilice DocuemntPDF para generar la exportación
-elimine directamente iText interno (para sanear un poco el código) ; esto es todo el directorio org.openExpertya.print.pdf (no confundir con org.openXpertya.pdf; ese paquete nuevo tiene a DocumentPDF).
-tuve que tocar ArchiveDesign (en client) porque esta era la ultima clase que usaba el iText interno (y por lo tanto, me tiraba errores de compilación); de todas maneras, esta clase se podría directamente eliminar (no se usa en ningún lado)
-finalmente, los archivos true.gif y false.gif en org.openXpertya.print.layout estaban corruptos (no eran gif validos), los reemplace con los gif que encontré en adempiere (que supongo que son los mismos, salvo que antes de corromperse). Esto gifs se usan cuando se reportean columnas booleanas (algo con lo que nunca me tope pero seguro se iban a mostrar mal).Finalmente, hice con éxito un build completo desde ant por si algún otro código que no vi estaba usando el iText interno. Las modificaciones deberían andar tranquilamente en 10.09, con cualquiera de las versión de iText (bah, con 2.1.5 seguro; creo que igual se debería usar esta versión ya que la exportación pdf desde el Jasper de 10.03 no parecía tener problemas); salvo como ya dije antes, el subpaquete fiscal NO hay que usarlo (tiene nuevos drivers Hasar y otras modificaciones pero para 10.03; tal como están, seguro que trae problemas para 10.09).
http://www.mediafire.com/?4zktf3ocbn0rc1m
build.xml -> pirnt/build.xml (pra que incluya itext 2.1.5 en el class path)
src->print/src (pero NO pisar el subpaquete fiscal)
En-client-Src-org-openXpertya-print -> archivos modificados de suproyecto client (son 4 nada mas; en dos de ellos solo agreque comentarios y genericidad cuando era necesario; los que realmente importan son Viewer y ArchiveDesign)Saludos
Los informes (internos o no) a nivel de permisos se tratan como procesos; por lo tanto no solo tenes que agregar la entrada al menu, si no también, darles permisos al usuario contra el “proceso/informe”; si no , no te aparecen.
Una cosa adicional (que no creo que pase, y no tiene que ver con la entradas del menú), es si una vez que te aparece en el menú, cuando lo abris te tira otro error o no te lo muestra, es que tal vez le tengas que dar permiso al perfil contra la vista asociada al informe (pero no creo que esto te pase, porque creo que por defecto siempre se tiene acceso… lo digo por las dudas).
De paso, justamente hace unos dias hice una modificaciones al reporteador interno que postie en Desarrolladores, tal vez te interese (eso es para 10.03…. si tenes 10.09 me vas a tener que aguntar un poco o aplicar los cambios manualmente; si la tenes un poco clara a nivel de código, es solo cuestión de pisar archivos y agregar org.openXPertya.print.DocumentPDF (ojo, no los del paquete openxpertya.print.fiscal; esos dejalos tal como los tengas actualmente, si no me parece que se rompe todo… ahi hay oras modificaciones que vienen por otro lado)
Disculpa la tardanza; al final me olvide…
El tema tal vez venga le estas errando de pestaña; la pestaña Cliente es distinta a la de Entidad Comercial, aunque se basen en la misma tabla. Probablemente no le haya puesto de tipo tableDir para la pestaña Cliente.La verdad que no lo chequie; pero verifica que la nueva configuración tenga los tipos de documentos bien seteadas (y si podes hace una verificación a nivel de tabla de base de datos; la ventana de configuración puede que no te este mostrando algun campo que despues usa el TPV; en la nueva configuración probablemente te quede con valor null).
y… lo veo complicado; más que nada porque vas a tener que programar (no se puede hacer, si no me equivoco, desde el diccionario de datos).
Supongo que la forma más conveniente es en beforeSave de MBPartner, y generar automaticametne la clave (campo “value” internamente, solo si estas creando una nueva instancia (bajo modificaciones de entidades no se debería tocar la clave) y “culcular” cual debería ser el proxima clave a partir de la ejecución de select sobre la base de datos (dado el id del grupo de la entidad siendo guardada buscas todas las entidades existentes dentro del grupo y te quedas con el que tenga “mayor clave” (que va a depender de tu convención para generar las claves del grupo), dada esa clave “generas” la proxima en la secuencia y la setea al campo “value”.Es complicado…
no veo la imagen adjunta….
Igual, veo algo raro:Code:CONSTRAINT cbp_tipo_cbpartner FOREING KEY (c_bp_tipo_doc_id) REFERENCES openxp.c_bp_tipo_doc (c_bp_tipo_doc_id) MATCH SIMPLE ON UPDATE NO ACTION ON DELETE NO ACTIONEstas segura que esa referencia se creo? porque el “openxp” es muy dudoso (salvo que estes usando OpenXpertya); te debería haber tirado un error y no te creo la ref. foranea o peor, no te creo la columna. Debería ser REFERENCES libertya.c_bp_tipo_doc (c_bp_tipo_doc_id).
Más allá de esto; en la definición de la columna de C_BPartner.c_bp_tipo_doc_id necesariamente tenes que permitirle (al menos al principio) que tenga valor nulo; si la referencia no se va a crear. Despues a nivel de tabla-libertya, proba cambiando si permite o no valor nulo (seguramente, vos necesitas que NO permita valor nulo… el tema es que la entidades comerciales previas van a tener null en estas columnas).
Mmm la verdad que no se, en principio todavía no lo probe para 10.09 (pero debería andar, ya que el infoProduct de esta versión no cambio con respecto a 10.03); el tema es que en 10.03 NO anda para para productos con instancias de producto (la ventana info para productos con instancias la muestra otra clase distinta, que hereda de InfoProduct; como modificamos InfoProduct algo se termino rompiendo), por lo tanto para este tipo de productos tampoco va a andar en 10.09.
Supongo que este plugin hace uso de instancias de producto, asi que te va a traer problemas (ahora bajo el plugin y miro que hace más o menos).Si te interesa intentamos hacer las modificaciones, pero no las veo simples…
Ok, en la solución “generica” que plantie tampoco avance (anduve medio complico en otras cosas) y no creo que logre salir en el futuro próximo, asi que tal vez valga la pena hacer el esfuerzo de que al menos para los productos con instancias y EC salga andando (despues de todo, estos son los info que mas se usan) para algun proximo release.No entiendo exactamente a que te estas refiriendo; Tienda web, b2b y b2c son muy amplios. Actualmente, por lo que yo conozco, el sistema no soporta muuucho de b2b y b2c; en cuando a tienda web, te diría que investigue la integración con Sugar CRM (pero no tengo mucha idea; no lo mire mucho a este componente).
No esta encontrando el directorio base del JDK de Java. El JDK te lo debería haber instalado el instalador automatico (si mal no recuerdo); actualmente esta apuntando al JRE de Java (que no sirve para ejecutar el compilar.exe). Fijate si no tenes un directorio cuyo nombre comience con jdk, por ej, jdk1.6.0_14 en el directorio de instalación de Java (por ej, C:Archivos de programaJavajdk1.6.0_14); si lo encontras pone ese directorio en el primer campo.
Deshabilitada te aparece? Como si estuviese solo lectura?
No habras creado la c_bpartner.c_bp_tipo_doc_id como coomo columna calculada no?
Para que sea un columna normal lo que tendrias que haber hecho con respecto a C_BPartner es:
-esto en Postrgres: agregar un columna, clave foranea c_bp_tipo_doc_id en C_BParnter de tipo int apuntando a c_bp_tipo_doc.c_bp_tipo_doc_id; que permita null (si no queres que permita null, tenes que agregarle un valor inicial…)
-desde Libertya agregar esta columna a la tabla C_BParnter, de tipo “table” o “table dir” (o search, alguna de esas).
-asegurarte que en la definición de columna de libertya para C_BPartner.c_bp_tipo_doc_id tenga “sql” (la que esta arriba a la derecha) vacia; esto es lo debería pasar salvo por alguna razón le hayas puesto algún valor a este campo, ya que por defecto queda vacio.El tema del “Sql” es que Libertya lo utiliza para detectar que columnas son calculadas (esto es, columnas que no están realmente en el tabla a nivel de Postgres); si tiene algún valor entonces es calculada y no te la deja editar.
No, un libro de caja debe ser para un solo día (en realidad pienso que no debería permitirte cambiar el día una vez creado…).
La idea es que crees un libro de caja todos los día (pensalo si queres como “abrir caja del dia”).Es tal como decís; la diferencia viene que el TPV intenta inferir el impuesto a usar para el producto y para eso hace uso (entre otras cosas) del tilde “predefinido” en los impuestos (el problema viene cuando no encuentra ninguno “predefinido”, ya que la linea de pedido/factura generada se intenta generar sin especificar ningún impuesto, lo cual falla necesariamente); desde la ventana tradicional de facturación o generación de pedidos, la forma en que busca el impuesto por defecto es distinta; en particular siempre termina eligiendo uno sin importar el tilde predefinido (en realidad, también te permite cambiar el impuesto a usar; otra cosa que tampoco es soportada por el tpv).
El paso 3 de la restauración lo tenes que hacer sobre una base de datos vacía. Digamos, creas una base de datos con nombre libertya2, codificación UTF8, owner usuario Libertya; sobre esa disparas la restauración y listo (obviamente después tenes que reconfigurar el cliente y/o el servidor para que accedan a esta base de datos; la otra es simplemente renombrar las base de datos ara que la nueva queden con el nombre estandard libertya).