Me llegó el mismo dia, casi al momento

Los compañeros que hicieron el registro que yo sepa no recibieron nada (o no lo vieron).

Entrando en el propio panel de Hacienda les aparecía el registro como OK y podían descargar los acuerdos, licencia, etc...

Hola: En Álava presenté 2, el primero tardó mes y medio, el segundo una semana.

Ok, gracias

Gracias !,


Lo presentamos la semana pasada ..., no me llega para el miercoles, se va a liar :(

Hemos terminado el registro y en el momento nos lo han dado, menos mal.


He dejado a tres clientes preparados para el miercoles. Miedo tengo, una sensación de que algo a fallar ... :)

Gracias

Buenos días,


Conocéis algún software confiable para hacer las copias de las facturas en la nube?


Cómo lo hacéis vosotros?


Gracias

Hola: Yo uso Megasync. Y si quieres puedes usar a la vez dropbox, onedrive, etc

También puedes hacer una cuenta de email y enviar un mensaje con cada factura.

Gracias ^\||/

Batuz Facturas recibidas
 

Buenas,

Voy a empezar con Batuz con las facturas recibidas pero por mas que leo no entiendo. Lo que no entiendo si puedo generar lo XMLs de las facturas recibidas y luego mandarlas como en el capitulo de las emitidas haciendo el zip. Y tampoco si tengo que firmarlas.

No encuentro una documentación en que lo vea claramente como funciona el 240/140 de facturas recibidas.

Gracias

Hola. Las recibidas se envían de la misma forma que las emitidas pero a su capitulo correspondiente. Hay que comprimir el fichero igual, pero los xml no tienen que estar firmados.

Nosotros tenemos un proceso de facturación que a final de mes, por ejemplo, podemos emitir unas cuantas facturas todas con la misma fecha y hora. ¿Esto no sería un poco extraño, el que tengan todas la misma fecha y hora? No sé si os pasa a vosotros, que podáis tener varías facturas con la misma fecha y hora, si no dará ningún aviso el TicketBAI.
Gracias.

En la hora hay que poner hasta los segundos por lo que lo veo un poco improbable que te coincidan todas en el mismo segundo. De todas maneras igual te viene mejor meterle la fecha y la hora en la que generas el XML justo antes de enviarlas.

Según la normativa, las facturas se deben enviar a Hacienda en el momento en el que se emiten. Es decir, si tu factura no existe hasta ese día que comentas, en teoría no deberías enviar nada antes.

Ahora, lo que ya no sé cómo va, a nivel legal me refiero, que tú cobres 3.500€ un 2 de enero, y emitas la factura el 31 de enero... desconozco si les da igual, o si al haber recibido un ingreso, debes emitir la factura el mismo día...

Por ejemplo nosotros muchas compras las dividimos en dos pagos, primero un porcentaje del total a modo "fianza" o anticipo, y después el pago de lo restante al entregar el producto.

En nuestro caso emitimos una primera factura con línea de "anticipo pedido xxx", y después una factura con el total del pedido, y una línea de descuento "-xx€" por el anticipo.

Y el que la fecha/hora sea la misma no creo que vaya a ningún lado, mientras la numeración sea correcta. Piensa que empresas grandes, sobre todo que tengan muchos puntos de venta, van a estar generando tickets continuamente y muchos a la misma hora. O por ejemplo empresas que cobren un servicio de suscripción a fin de mes... no van a estar emitiendo una factura cada segundo o cada minuto, se generan todas de golpe.

Error envío Facturas Gastos a Vizcaya
 

Buenos días;

El día de hoy, estoy teniendo errores en el envío de Facturas de Gasto (Con y sin factura) a la hacienda de Vizcaya. No devuelve respuesta, sino que capturo un error en la aplicación:
"Se han producido uno o varios errores"..... Es muy poco representativo, pero es el mensaje del error que captura la aplicación.

Un poco más tarde, un cliente ha avisado que también tiene ese problema, algo que no había ocurrido antes.

¿Alguien sabe si hay problemas en el envío de facturas de Gasto a Vizcaya en el día de hoy o en los últimos días? ¿Se ha cambiado algo y no se ha avisado?

Muchas gracias.
Un saludo.

Los procesos de "Facturación automática" o "Facturación por lotes" (batch) son bastante habituales y es lógico que todas esas facturas se generen con la misma fecha/hora (en muchas de ellas).
No creo que eso genere problemas ya que como digo es bastante habitual.

Hola a todos.

Estoy intentando cambiar la forma de envío de los ficheros de Gipuzkoa, lo quiero hacer con el componente TsbxHTTPClient de los secureblackbox. A la hora de hacer el envío hago lo siguiente.

Código Delphi [-]
        //EnvioGipuzkoa2 es el componente TsbxHTTPClient
        EnvioGipuzkoa2.ClientChain.Clear; 
        EnvioGipuzkoa2.ClientChain.Add(cert); //Certificado seleccionado
        EnvioGipuzkoa2.TLSSettings.AutoValidateCertificates :=   True;
        EnvioGipuzkoa2.TLSSettings.Versions := csbTLS12;

        EnvioGipuzkoa2.RequestParameters.ContentType := 'application/xml;charset=UTF-8';
        EnvioGipuzkoa2.RequestParameters.CustomHeaders :=  'Accept-Encoding: UTF-8';
        
        EnvioGipuzkoa2.PostStream('https://tbai-prep.egoitza.gipuzkoa.eus/WAS/HACI/HTBRecepcionFacturasWEB/rest/recepcionFacturas/alta',RequestBody); //En   
                                                         requestBODY esta cargado el contenido del fichero

Pero cuando envío recibo el siguiente error.

Código Delphi [-]
10054: Failed to post data'#$D#$A'[EElSocketClientConnectionLostError] Connection lost due to error 10054 (10054/0x02746)

Creo que es algo de los parametros. ¿Alguien que use este componente puede decirme como lo configura para Gipuzkoa?

Envío a Gipuzkoa con SecureBlackBox 2020
 

Hola Keys,

Nosotros no tenemos problemas con el envío a Gipuzkoa. El componente lo tenemos configurado así (C++ Builder):

En el envío diferimos, nosotros hacemos:
pero entiendo que eso no debería influir.

Previamente, al componente sbxHTTPClient1 le hemos asociado un certificado digital:
Espero que te sirva.

Se me olvidaba el timeOut (inicialmente teníamos 60 seg. pero, por si acaso, hemos ampliado a 90)

Hola,
tengo una duda técnica a ver si me podéis aclarar.
Actualmente tengo funcionando el ticketbai Gipuzkoa y quiero empezar a implementar el de Alava (espero que no sea muy diferente...).
Para el de Gipuzkoa me base en el firmador.php de nuestro querido amigo bilbur ya que no controlo para nada ese tema y tenia:

Leyendo la documentación técnica de Alava veo que pone:
Política de firma: https://ticketbai.araba.eus/tbai/sinadura/
Hash de la política de Firma: 4Vk3uExj7tGn9DyUCPDsV9HRmK6KZfYdRiW3StOjcQA=

¿Ese hash te lo tienen que dar ellos o se calcula de alguna forma?
Lo pregunto mas que nada por entender mejor y saber si tengo que cambiarlo si el dia de mañana cambia la politica de firma o algo asi...


Igual la pregunta es un poco básica pero voy sacándome las castañas del fuego como buenamente puedo... :)

La firma con cualquier política de firma (BIZ, GIP, ARA) es válida para las tres provincias
El hash te lo dan ellos (aparece en su web de política de firma)


Suerte

El proceso es el mismo en Alava que en Gipuzkoa, lo unico que cambia es la politica de firma y los servidores a los que envías. El hash esta en la documentacion de Alava.

Código Delphi [-]
     'https://ticketbai.araba.eus/tbai/sinadura/';
     '88E82F917EFFC8720345188FCBF2D84345149FB415F3FD750F50456ECF3232E4';
     'https://ticketbai.araba.eus/tbai/sinadura/';

Gracias Compañero. Me ha sido de gran ayuda. Pongo como quedaria en delphi para enviar por las SecureBlackBox.

Código Delphi [-]
      //EnvioGipuzkoa2 es el componente TsbxHTTPClient


      //Asigno el certificado
      EnvioGipuzkoa2.ClientChain.Clear;

   
      for z := 0 to CertificateStorage.Certificates.Count - 1 do
      begin
        cert := CertificateStorage.Certificates[z];
        if Pos(AnsiUpperCase(Firma), AnsiUpperCase(Cert.Subject) ) <> 0 then //Buscar el certificado que esta seleccionado         
          begin
            EnvioGipuzkoa2.ClientChain.Add(cert);          
            Break;
          end;
      end;

      EnvioGipuzkoa2.TLSSettings.AutoValidateCertificates :=   True;
      EnvioGipuzkoa2.TLSSettings.Versions := csbTLS12;

      EnvioGipuzkoa2.RequestParameters.ContentType := 'application/xml;charset=UTF-8';
        
      EnvioGipuzkoa2.RequestParameters.AcceptCharset := 'UTF-8';
      EnvioGipuzkoa2.RequestParameters.Accept := '*/*';
      EnvioGipuzkoa2.RequestParameters.HTTPVersion := TsbxHTTPClientReqParamsHTTPVersions.chvHTTP11;
      EnvioGipuzkoa2.TLSSettings.RenegotiationAttackPreventionMode := TsbxHTTPClientTLSRenegotiationAttackPreventionModes.crapmAuto;


      EnvioGipuzkoa2.SocketSettings.DNSTotalTimeout := 0;
      EnvioGipuzkoa2.SocketSettings.Timeout := 90000; //60000;
      
      EnvioGipuzkoa2.PostStream(DevolverServidorGipuzkoa(anula),RequestBody);

     //guardamos el fichero de resultado
     stream := TBytesStream.Create(EnvioGipuzkoa2.OutputBytes);
     try
         stream.SaveToFile(Fichero);
     finally
         stream.Free;
     end;

Ese es el HASH que te dan ellos (como tú bien dices en la documentación).
Cada tributación tiene el suyo (para PRE y para PRO). Y ya se ha cambiado alguna vez.
En nuestro caso y en previsión de futuros cambios está guardado en un campo de la B.D.

Hash politica de firma
 

Muchas gracias a todos por la aclaración! :)

Buenos días,

Estoy leyendo estos últimos mensajes mencionando esto, y me estoy quedando un poco a cuadros.

Primero, no tengo recuerdo de haber aplicado en ningún sitio lo de la política de firma.

He buscado en el código, y en efecto veo que en el "firmador.php" está el hash "dTtPpv4fWTcejeVx7+91ILruFX3HysbngBlllJm4i/E=".

Antes de pasarme a esta librería, estuve usando Chilkat 9.5 para PHP, que funcionaba, y no tengo recuerdo de haber puesto ningún string... excepto que haya sido algo que hice muy a los inicios, hace meses, y ya ni me acuerde.

En cualquier caso, llevamos en producción enviando facturas desde el 24 de octubre, y no he cambiado nada en el firmador. Es decir, que estoy usando el mismo hash de "política de firma" que estaba usando en el entorno de desarrollo.

De hecho lo único que hice el día que pasamos al entorno de producción fue poner el número de licencia correcto, así como todo el tema de HuellaTBAI, pero poco más...

¿Me tengo que preocupar?

En el primer mensaje tenemos las políticas de firma.
https://www.clubdelphi.com/foros/sho...97&postcount=1

Creo que deben estar actualizadas (si no es así comentadlo).

Yo miraría de actualizarlas.
Recuerdo que nosotros estuvimos un tiempo enviando también con una política antigua sin problemas, hasta que un día empezó a quejarse (no recuerdo en qué tributación).
Supongo que aquel día alguien activó esa validación. Que no se esté quejando ahora no quiere decir que cualquier día no empiece a hacerlo.

Zuzendu Gipuzkoa
 

Hola!

Vosotros como habéis planteado el tema del zuzendu subsanar? Me refiero al caso que un fichero ticketBAI se ha rechazado por errores en el XML, "Fichero no cumple el esquema XSD".
Mostráis al usuario el codigo XML del fichero TicketBAI original (sin firmar) para que el mismo lo edite y corrija y se pueda enviar al servicio Zuzendu?:confused:

Porque claro, las posibilidades de errores a corregir pueden ser muchísimas para programar cada caso... y supongo que hará falta la interacción con el usuario para indicar el dato correcto... o no.
No me parece factible que el usuario de nuestro programa corrija a mano el XML con errores :(
Ando un poco perdido en este tema.

Gracias!

Por un lado, el XML que se envía no es sin más el original sin firmar. Aunque mantiene la estructura original, la definición del fichero y el bloque de "Cabecera" cambian.

Por otro lado, si hay un error en el XML, significa que hay un problema en el software que lo ha generado, o bien en la propia factura.

Es decir, corregir un XML a mano y enviarlo puede ser algo factible cuando tienes que enviar YA algo, y no tienes otra cosa preparada.

Lo correcto es corregir el problema que ha motivado un XML erróneo.

Por ejemplo, si le faltan las líneas de detalle, hay que enviarlo a Zuzendu-Subsanar. De nada sirve que abras el XML y las agregues a mano, porque te va a volver a pasar.

O abres la factura desde tu aplicación y agregas las líneas de detalle, y vuelves a enviarla, o bien corriges la programación que ha impedido la generación de unas líneas de detalle que sí existían.

En conclusión, ahora mismo no se me ocurre un motivo o razón justificada para editar un XML a mano.

Por ejemplo, en el sistema que tengo montado si hay un problema con el envío, me guardo el código de error, y además marco esa factura como a rectificar, o enviar a Zuzendu (según el error original), para saber qué hacer con ella. Además, dejo un registro de todos y cada uno de los envíos, con el XML original y el firmado para cada caso, con la respuesta obtenida. Pero cada intento de envío genera un XML y un registro nuevo, es decir, jamás reutilizo un XML ya generado.

No me parece correcto/lógico/seguro/... dar acceso al XML para que se modifique antes de enviar.
¿Podrías cambiar los importes y enviarlo? ¿entonces lo que envías no "cuadraría" con la factura?

No le veo sentido sinceramente y creo que te puede provocar muchos más problemas y errores de los que vas a solucionar.

impresión qr en impresora de tickets
 

Hola a tod@s, estoy liado con lo del ticketbai y necesito imprimir el qr en los tickets d caja. Alquien me puede ayudar con los comandos a enviar a la impresora de ticket???.
Gracias a todos d antemano

NOTA DEL MODERADOR: He movido tu pregunta a este hilo específico de TickeBAI, porque seguramente en este hilo habrá usuarios que se hayan encontrado con ese problema.

Hola, no todas las impresoras permiten imprimir un código QR, por ejemplo, las matriciales.
Por otro lado, según la marca y modelo de la impresora usará unos comandos u otros, epson, zebra, etc.
Tienes manual de la impresora? normalmente ahí suelen venir los códigos, si los admite.
Especifica algo más por favor.
Un saludo.

Bienvenido.
Revisa la Guía de estilo de los foros.
Si das el modelo de impresora será más fácil poder ayudarte.

Tienes razón Irreo, el usuario no puede editar el XML.

El caso es este, todavía no hemos desarrollado zuzendu y se ha rechazado una factura por un cif enviado con un guion, por un bug del programa. Ya hemos corregido el programa para no permitirlo pero claro, tenemos que enviar esa factura de alguna forma.
La idea es que no se rechacen facturas pero siempre puede ocurrir algo..


Vamos a ver como lo hacemos.



Muchas gracias

Tienes razón Neftali. Que el usuario edite el XML no es una opción.

Supongo que tendremos que programar una solución para cada posible error.
Muchas gracias

No creo que sea cuestión de programar una solución para cada posible error :)

A ver, las facturas normales en si no tienen mucho misterio (por suerte) ya que es solo remitente, destinatario, y unas líneas de detalle.

Lo importante es tener desarrollada la funcionalidad de Alta con su firma, y por otro la de Zuzendu, que simplemente genera un XML prácticamente igual, pero sin firmar y adjuntando parte de la firma de la factura original.

Por lo demás, "da igual" que errores genere la factura original. ¿CIF incorrecto? Lo corriges, y haces lo que corresponda.... ¿fecha aaaa-mm-dd en lugar de dd-mm-aaaa? Lo mismo.

Con esto quiero decir que lo importante es tener hechos los servicios de envío.

Lógicamente lo que si debes tener documentado en algún sitio es qué tienes que hacer con cada error, porque en unos casos será Zuzendu, y en otros requerirá crear una nueva factura rectificativa.

Por ejemplo, a nosotros nos pasó lo de un CIF con guión, y este fue el error devuelto:

1153 - El NIF del destinatario tiene un formato erróneo

El error "1153" yo lo tengo anotado como "a rectificar". Por lo tanto, la operativa fue corregir el CIF del cliente, y emitir una factura sustitutiva.

Ánimo y suerte.

A estas alturas ya tengo un lío en la cabeza importante y además ahora hace semanas que hemos apartado este tema, pero ¿esas facturas erróneas, una vez corregido el programa, no puedes enviarlas con el libro 240 sin software garante?

UPDATE:
Efectívamente me he echo un lío. 240SinSG sólo es para BATUZ y asumo que tú estás en una de la otras dos tributaciones.
En ese caso y según la documentación:

Artículo 1. Procedimiento para el envío de la información correspondiente
al fichero TicketBAI que ha sido rechazado.
1. La información correspondiente al fichero TicketBAI que ha sido objeto de rechazo
por no cumplir las validaciones mínimas establecidas en la Orden Foral 521/2020, de
23 de diciembre, por la que se regulan las especificaciones técnicas y funcionales del
software TicketBAI y la declaración de alta en el Registro de Software TicketBAI,
deberá ser objeto de subsanación a través del envío del fichero de subsanación, de
acuerdo con los requisitos de los servicios Zuzendu, el procedimiento y las
especificaciones técnicas y funcionales que se regulan como anexo I a la presente
orden foral.
2. El fichero TicketBAI rechazado no podrá sufrir alteración alguna, y deberá
conservarse en su estado original dentro del sistema informático para garantizar la
integridad, conservación, trazabilidad e inviolabilidad del fichero TicketBAI generado
por el software TicketBAI.

Exacto Irreo, creo que haremos esto, desarrollar la parte de generar el xml para zuzendu y la parte del envío y después ver en cada caso como lo gestionamos.
En nuestro caso se ha rechazado una factura en Gipuzkoa, hemos enviado un guion y se ha rechazado, han contestado:

"Fichero no cumple el esquema XSD. Detalle del error: cvc-pattern-valid: Value 'NIFEJEMP-R' is not facet-valid with respect to pattern '(([a-zA-Z]{1}\d{7}[a-zA-Z]{1})(\d{8}[a-zA-Z]{1})([a-zA-Z]{1}\d{8}))' for type 'NIFType'."


Por lo tanto tenemos que utilizar Zuzendu subsanar para volver a enviar la factura sin el guión en el nif y con los apartados nuevos de zuzendu


Gracias

Disculpa Neftali, no habia especificado que es para Gipuzkoa, que tienen Zuzendu y creo que es igual o muy similar que el Zuzendu de Araba. En cambio en Bizkaia no lo tienen pero hay este capítulo de "Sin software garante".

Ahora estamos con el Zuzendu y mas adelante ya entraremos con el Batuz apartado "sin software garante":p

Muchas Gracias

¿Pero ese error lo has obtenido desde el servicio KONTSULTA, o fue lo que te devolvieron al enviar la factura a Alta?

Yo mirando la respuesta XML que tuvimos, tengo esto:

00 - Recibido - ALTA PREP
1153
El NIF del destinatario tiene un formato erróneo

Es decir, el estado es "00", recibido, pero con errores.

Esto fue en Gipuzkoa.