- Este debate está vacío.
-
Entradas
-
Buenas gente, he cargado los datos de un cliente como responsable inscripto ya que me pide factura A (hasta ahora todas fueron a consumidor final) y al momento de emitir el ticket con el TPV me sale el siguiente error:
Datos no válidos en un campo. Uno de los campos del comando recibido tiene datos no válidos. (diferencia de tipos, etc).
(Petición: { 62 “RubxE9n” “12345678901” “I” “C” “P. Palacios SN , Palacios” }, Respuesta: { 62 “C080” “8610” }).NOTA: el cuit lo cambie acá por cualquier problema que pueda tener, pero lo cargo correctamente.
Pero ese no parece ser un CUIT válido; posiblemente pase algoritmo de chequeo del dígito verificador, pero los dos primeros dígitos no son 20,27,23 ni 30.
Hola javAd, el CUIT lo pongo bien en el software. Por eso aclare que en el post lo cambio por cualquier cosa, como no es mío…
Hace un rato estuve pensado si tal vez sea un problema de la impresora que no la hayan configurado para imprimir ticket tipo A. Sinceramente no se de que lado puede estar el problema.
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.
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…
- Debes estar registrado para responder a este debate.
