Respuestas de foro creadas
-
Entradas
-
Buenísimo. Creo que el tema viene porque la factura al ente recaudador al crearse nunca se especifica la lista de precios; entonces al intentar guardar la factura, se busca la lista por defecto (esta lista luego se usa para ver si tiene la misma moneda que la seteada con la factura; si no se busca una conversión… el tema es que nunca se chequea si realmente existe esa lista por defecto, y la conversión falla).
Es raro entonces; el tema es que no esta pudiendo hacer la conversión entre divisas, lo cual ya de entrada es muy raro (salvo que estes facturando en varias monedas).
Cambiaste algo con respecto a las listas de precios? (en particular con respecto a la moneda; por ej, creaste un nueva lista de precios es dolares). Estas generando un pago en una moneda distinta a la factura original?Pero hiciste la migración a 11.05?
Si la hiciste, por alguna razón seguis usando el código de 10.09 (los números de linea que aparecen el dump de stack que diste corresponden a esta versión, no a la 11.05). Suponiendo que hiciste la migración, si estas usando un cliente pesado viejo, déjalo de usar (usa uno nuevo), si estas usando el cliente liviano, limpia la cache de java y volvelo a bajar.De nada. Ahí probé de nuevo (sin cerra la caja anterior, así fallaba), haciendolo fallar varias veces; el primer fallo no tomo el lock; pero los siguientes si… aun mas, ahora me aparecen locks sobre c_bpartner (pero no siempre…); sobre ad_sequence solo me aparecio un solo lock. Tal vez este comportamiento medio “errante” se deba a que hay alguna cache, pero sigo sin saber bien…
TPV para en la linea 1466 de PoSOnline: throwIfFalse(cash.getC_Cash_ID() > 0); pero el error se genera la linea 1463: cash = MCash.get(…..) (falla en el beforeSave de MCash, y posiblemente antes de volver PosOnline, la transacción ya este rollbakeada… pero tampoco estoy muy seguro).Lo que si, ante cada fallo que genera un lock no liberado, quedan conexiones TCP también colgadas (esto es, abiertas pero sin uso; despues de 3 o 4 fallos el cliente tenia 11 conexiones tcp al servidor).
PD: otra cosa que también es posible es que haya un bug en el server que uso o en la versión del driver JDBC; tal vez bajo ciertas condiciones no se hacen roolbacks de manera completa y quedan un par de locks dando vueltas.
Lo que he visto en este y otros threads (que no se si viene por ahí pero bueno…) es que bajo Linux usan ‘file:///ServidorOXP/lib/sqlj.jar’; esto ultimo me parece que es para Windows; en Linux creo que debería ser algo como ‘ServidorOXPlibsqjl.jar’.
Bueno, no avance mucho mas en el análisis; solo agrego que cerre el cliente (el que ejecuto el TPV) y el lock sobre ad_sequence desapareció (e.d, lo había tomado via TPV seguramente). Entre de nuevo, y complete otra factura desde el TPV, esta vez sin error (el libro de caja ya estaba abierto), pero esta vez no estaba ni lock ni la transacción sobre ad_sequence; esto es, al parecer bajo situacion “normal” (sin error al intentar completar un documento), no parece quedar este lock.
Buenas. Me resulta raro que no largue ni un solo mensaje; tene en cuenta que el spooler no soporta mas de una conexión (a nivel de TCP) a la vez; me parece que bajo esta situación (una conexión tpc contra el spooler ya existe y que no se cierra), las nuevas conexiones quedan a la espera “eternamente”, pero no estoy seguro.
Mira las conexiones actuales que tiene el spooler (netstat creo que sirve tanto en Linux como Windows para ver esto; en Widndows también el aplicativo TCPView).
También, posiblemente, mira la salida por consola que genera el spooler o el archivo log que genera (spooler.log creo); ahi te tiene que aparecer por cada conexión un par de entradas del estilo “recibiendo conexión des ip tal, puerto tal”/”finalizando conexiones con ip tal, puerto tal” (si falta un “finalizando”, hay un cliente que no cerro la conexión).Pero, se puede hacer eso? Me da la sensación que no; bah yo nunca vi un comando de “reimpresión de cierre Z”… Igual, si se puede, debe ser fácilmente llevado a cabo enviandole los comandos al spooler directamente (hay aplicativo de hasar llamado sndcmd que lo hace).
Setea Dias de Historia para que llegue a mayo partiendo de primero de Julio (90 dias deberia andar; si no poner 120); la apertura manual del periodo no era necesaria (en realidad, no cambia nada cuando esta en modo control automático; eso ni se mira).
No intente el upgrade, pero tal vez, agregando a lo que dijo Federico de no estar corriendo mas de una instancia, pienso habria que hacer el upgrade sin que este corriendo el servidor de aplicaciones (en particular, el procesador contable); me da la sensación que podría generar bloqueos (no tanto por los datos en si, si no por las modificaciones a las estructuras de tablas).
Ahí vi en el 3er screenshot algo raro; no deberías especificar el permiso para cada una de las pestañas (aunque haciéndolo así, si lo haces para todas, y en particular para la pestaña principal, no debería haber problemas…. tal vez hay un bug o un chequeo aparte que no conozco). Deberías eliminar todo estos permisos específicos por pestañas y debería andar (funciona asi: si no se especifica ningún permiso especifico a nivel de pestaña, entonces tiene acceso a todas; si se especifica al menos una, bueno, solo las que se especifiquen; el tema de las pestañas contables/avanzadas, también se aplica, pero posteriormente). Así es como viene por defecto.
Saludos
mmm lo deberías tener… Ahí me fije (en 10.09); bajo perfil Administración; Contabilidad->Elemento Contable.
Ahora, si tenias destilado “Mostrar pestañas contables” y lo tildaste, es muy probable que tengas que reloguearte (por las dudas también tilda “mostrar pestañas avanzadas”).ok, el primer bug no es tal… No me di cuenta que estaba llamando a la función getTaxedAmmount (aunque esta ultima función debería siempre aplicar la multiplicación, ya que deberia ser siempre llamdo con montos sin impuestos)…. igual, el tema de getPrice(), creo que sigue estando mal; esto siempre debería retornar un monto unitario sin impuestos, al menos según su declaración.
Mira vos…
Sabia que había un problema con ciertos caracteres (Hasar soporta acentos, pero en otro codigo de “pagina”; Libertya se los envía tal como los representa Java internamente) pero no que ocasiaran un error; las impresoras Hasar, al menos casi seguro los modelos mas recientes, los caracteres que no reconocen lo “traslandan” a , creo, “?”; pero me parecen que no tiran un error. Que modelo es?Una cosa que tal vez puedas probar es correr el spooler con el parámetro -W; eso hace que se haga un conversión de caracteres pero a nivel de spooler; a la impresora fiscal le llegan siempre caracteres validos, aunque no necesariamente bien “traducidos” (por ej, é representado bajo el versión de unicode que usa internamente Java, difícilmente lo maneje correctamente).
Lo ideal, ideal, seria mejorar la parte de Libertya para que traslade (en la medida de lo posible) los caracteres unicode al código de pagina que usa Hasar (y en ese caso dejar de usar el parámetro -W); alguna vez lo encare, pero bueno…
Ahí mire el código y libertya no valida los 2 que los dos primeros dígitos sean los que dije; esto es, para libertya tu CUIT esta ok. El tema es que probablemente la impresora fiscal si haga esta validación… Si es por probar, proba con alguno que empiece con 20.
En cuanto lo de facturas A, es probable que si la impresora fiscal esta inicializada para cierta categoría IVA (monotributistas, si no me equivoco nunca emiten facturas A… pero nunca me acuerdo bien) no va a imprimirlas… Pero no “debería” ser el problema, por dos razones:
-en Hasar, la apertura del documento fiscal va después de que emitis la información del cliente; vos no estas pasando el primer paso.
-aun cuando no puedas emitir facturas A, siempre deberías poder facturar a un responsable inscripto; en todo caso, la impresora emite otro tipo de factura. Si mal no recuerdo, Libertya, nunca le indica que tipo de factura (letra) debe imprimir; eso lo determina la impresora por sí sola (llevando a cabo el mismo algoritmo que ejecuta Libertya, pero de manera independiente).
Otra cosa que puede llegar a ser, pero no creo, es que el nombre que le estas enviando tiene un acento.
Si cambiando el CUIT te sigue pasando, le pego una mirada a los manuales de Hasar; creo que cuando hay un error de campo en un comando te indica cual en la respuesta.