Creo que ahí está el detalle (y la diferencia que vemos).
Diferenciar entre "generar" la factura y "enviarla". En eso estamos de acuerdo.

El problema es que cuando "firmes" la factura ya no puedes modificarla y entonces si hay que cambiar algo, la cosa se complica, por eso la idea (la nuestra al menos) según lo que hemos entendido es "retrasar hasta el último momento el firmado de la factura". Es decir, intentar firmarla en el memento de enviarla.

Esto es lo que nos han comentado en la hacienda vasca (pregunta y respuesta):

PREGUNTA: ¿El usuario podrá modificar/borrar una factura que aun no se ha realizado la impresión QR, ni se ha generado xml o enviado? RESPUESTA: Sí. La factura se puede modificar en tanto en cuanto no se haya firmado.

Es decir, ellos asumen que puedes generar una factura en tu sistema, pero no firmarla en ese momento (o lo que podría ser una prefactura).

Yo cuando hablo de generar que refiero a generar el fichero XML, que es cuando realmente se genera la factura original y se la das al cliente.

Depende mucho del tipo de aplicación que estés desarrollando. Si por ejemplo es un TPV que tiene que generar el TICKET/FACTURA al momento para darselo al cliente, no quedará otra.

Eso esta bien cuando es una factura, pero cuando es un ticket, me supongo que habrá que firmarlo al generarlo, para que al imprimir el ticket venga el qr impreso. Son las cosas que todavía no han aclarado por ningun lado.

Correcto.
Ese sería el momento.
El sistemas ERP supongo que "generar" es el momento en que se la envías al cliente. Debes:
1) EnviarXML
2) Generar QR
3) Imprimir
4) Enviar al cliente.

Correcto. Es que estamos pensando en cosas diferentes.
En el caso de los tickets, si parece que TODAS las máquinas con impresora van a tener que estar con certificado.

Creo que el paso 1 sería Generar Fichero Xml, ya que a hacienda hay que enviarlo posteriormete.

Chicos, que componente estaís usando para firmar el xml?

Nosotros tenemos comprados los componentes SecureBlackbox que también los utilizamos para firmas la efacturas.

Es el que usamos nosotros tambien para la efactura, pero veo que firma del ticketBai es diferente al de la factura electronica, no?

Es muy parecida y a nosotros nos han servido.

Ok, gracias por la info

por cierto veo que también eres de Bilbao. ;)

Si, somos vecinos. :D

Si claro, sin eso no hacemos nada...:):):)

0) Generar XML
1) EnviarXML
2) Generar QR
3) Imprimir
4) Enviar al cliente.

+1
SecureBlackBox

Solo por tocar las narices , que estamos a viernes. :)

El paso Enviar Xml, no tiene por que ser en ese orden. Se puede enviar despues, los plazos no los han definido.

Yo lo que voy a hacer es:

0) Generar XML
1) Firmar XML
2) Generar QR
3) Imprimir
4) Enviar al cliente.
5) EnviarXML

Nosotros el envío tambien lo vamos a hacer a posteriori, ya que si por ejemplo es un tpv, como tengas que esperar a que hacienda te responda, el proceso puede ser un poco lento.

De todas formas el problema de todo esto esta en encadenar las facturas, ya que cada factura tiene que hacer referencia a la factura anterior y coger unos datos del fichero xml de la factura anterior.

Cierto, bien apuntado.

Bueno, una vez generados los XML ya sólo tienes que coger datos de la anterior factura.
A priori parece fácil (si todo es ideal), luego llegarán los problemas cuando pasan "cosas" que se salen de lo normal.

Si si obtener el valor si es más o menos facil. El problema es que eso te hace que no solo no puedes modificar una factura, sino que tampoco puedes modificar todas las facturas siguientes a esa, ya que eso hace que cambie el fichero de todas las facturas siguientes.

Correcto.

Justo eso es lo que están buscando, que una vez generada no modifiques nada.
La única solición es generar una factura ractificativa de la anterior, que volverá a subir como las demás.

NOTA IMPORTANTE: Estas modificaciones sólo afectan a los campos "importantes" de la factura (los que van añadidos en el XML) que no son todos. Por ejemplo, si quieres modificar la "dirección del cliente" o su "teléfono" puedes hacerlo. Como ese campo no va en el XML puedes modificarlo sin problemas.

Hola,

He buscado (pero no he encontrado) módulos de TicketBAI para aplicaciones estandar de comercio online (Prestashop, Woocommerce de Wordpress, Magento, ...)
¿Alguien está desarrollando módulos para estas aplicaciones?
Gracias por adelantado

Saludos

Una pregunta, cuanto os tardaron los de Lantik en enviaros los certificados? Llevo desde el Jueves de la semana pasada esperando y todavía no me han respondido...

No es mi caso, un saludo

Ami me tardaron unos 15 días.

Ayer pedí documentación a ticketbai@ticketbai.eus
Todo lo que me enviaron coincide con lo que ya hay publicado en el primer mensaje de este hilo.
Salvo un documento más que dice:

Criterio de Ampliación de cara a la Implantación Definitiva del Proyecto TicketBAI
De la experiencia adquirida en el desarrollo del piloto y teniendo en cuenta las observaciones
recibidas en el mismo, se pone en conocimiento a los participantes que, en la implantación
definitiva del sistema, se admitirá la firma del fichero xml TicketBAI, además de con el
certificado de dispositivo, con otros tipos de certificados electrónicos, facilitando la solución a
las diversas arquitecturas de software.

(No puedo subirlo al foro porque sólo se me admite subir ficheros PDF de hasta 283,1 KB)

Me has dejado loco, 15 dias? que pasada? Gracias por la info.

Ya lo he encontrado y lo subo aquí con el enlace en el hilo original donde están el resto de documentos.
Gracias.

Parece que, a pesar de que por la nota aclaratoria última, se va a permitir que se firme el XML de la factura con cualquier certificado instalado en la máquina que emite la factura, por ahora, no parece que se vaya a eximir de la instalación del certificado de dispositivo en toda máquina que emita facturas.
Se va a exigir que se pueda hacer una verificación presencial de dicho certificado de dispositivo.
Y quieren disponer de un mapa de los dispositivos de cada empresa o negocio.

Para obtener el certificado de dispositivo se necesita un código único que identifique cada dispositivo.
Y la primera idea que han tenido es que dicho código sea el ID de la CPU.
Esto, con procesadores Intel y AMD, vale.
Pero nosotros tenemos una red de clientes con TPVs basados en microordenadores Raspberry Pi.
Éstos tienen una CPU Broadcom BCM2837 que no tiene ninguna identificación única (al menos yo no he sido capaz de encontrarla).
Todos tienen la misma ID de CPU.
Así que no hay un código único que identifique, unívocamente, cada CPU.
He propuesto a los de TicketBAI que se pueda utilizar la MAC de red que sí es única.
Veremos que contestan.

Y por los emails intercambiados con los chicos de TicketBAI me da la impresión de que tampoco han tenido en cuenta las tiendas online.
Me han llegado a decir:
El dispositivo emisor de la factura siempre se considera el cliente, aunque hablemos de un cliente ligero (como un navegador). Por lo tanto, el número de serie que identifique al dispositivo en el fichero TicketBAI tendrá que ser siempre el del cliente.
Les he tenido que aclarar que, en el caso de los comercios online, el visitante-cliente lo hace con su propio navegador y no se le puede instalar nada (aparte de una humilde cookie) y sólo se dispone, como datos de su dispositivo, del nombre de su navegador y de la IP desde donde hace la compra.
Espero que lo reconsideren y se den cuenta del error y de que, en este caso, el que emite (y debe firmar) la factura es el servidor.

También les he planteado el tema de que muchas tiendan online están en un servicio de hosting en el que no pueden obtener identificador de CPU ni instalar certificado de dispositivo.
Y, por otro lado, puede que compartan dirección IP con otros comercios online instalados en el mismo servidor.
A ver qué se les ocurre para identificar y certificar el dispositivo en este caso.

Perdonad por el ladrillo que os he metido.

Sobre los certificados:
Llamé a IZENPE para preguntar los precios y períodos de validez que tendrán los certificados para cumplir con TicketBAI.
Me remitieron al email de TicketBAI.
Les consulté y me contestaron:
- Certificados de dispositivo
Se estima que 5 años. Este plazo aún no es definitivo. El coste de los certificados de dispositivo no se ha decidido.
- Certificados de aplicación
- Certificados de firma de código
Con respecto a estos certificados lo que se va a requerir es un certificado de la empresa fabricante del software siguiendo los usos normales del mercado.
El certificado de la empresa fabricante se relaciona con el requisito de autoría del software y no aplica a la fase piloto. En la primera quincena de diciembre les enviaremos cómo funcionará en la implantación definitiva el requisito de autoría de software.

Lo de "se va a requerir es un certificado de la empresa fabricante del software siguiendo los usos normales del mercado" no me deja tranquilo.
¿Alguien me puede aclarar a qué se pueden referir?

Respecto a los certificados, me da la impresión de que van a tirar, en exclusiva, de IZENPE.
A mí, particularmente, no me gustan los certificados de IZENPE, además de que siempre me han parecido caros.
A todos nuestros clientes siempre les gestionamos los certificados de FNMT que son más fáciles de obtener, más baratos y funcionan mejor.

He escrito email a FNMT, con la documentación de TicketBAI, preguntándoles si van a disponer de certificados de los tipos exigidos para TicketBAI.
Estoy a la espera de que me contesten.
Os mantendré al día.

Gracias por la info, nosotros también estamos a la espera de que nos respondan cómo hacemos con los certificados de maquinas de los clientes que se conectan por terminal server. Yo creo que no lo tienen muy bien estudiado, la verdad.

Si es así como tu dices, ¿para que sirve el certificado de la maquina?, ya que según la nota permiten firmar con cualquier otro el fichero. Yo creo que no será necesario certificar la máquina, pero si tener un id unico de la maquina en el fichero (Por cierto a mi me dijeron que abriera la cpu para mirar el número de serie, ya que no eran capaces de sacar ese número por código). Pero Bueno el tiempo lo dira.

Por otra parte no creo que sea algo exclusivo de IZENPE, nosotros por ejemplo estamos haciendo el envío con un certificado de la FNMT y según la nota, ese mismo certificado servirá para firmar el XML.

Otra cosa será el certificado de la aplicacion, pero como de este tampoco se sabe nada. El tiempo lo dira.

SALUDOS

Buenas a todos, estoy probando a enviar información al web service y estoy teniendo problemas, haber si alguien me puede decir que estoy haciendo mal. Me he creado un programilla de pruebas donde leo el contenido del fichero de una factura firmada en Base 64 y lo envío, pero siempre me da error "Los elemento esperados son <{}ticketBai>. Es cierto que en el contenido de fichero solo esta la factura en base 64, pero también he probado a enviarlo con y nada el mismo error. Realmente no sé como es la estructura a enviar, me estoy haciendo un lío la verdad.

Os pongo el código fuente del procesillo que uso, por si me podéis decir algo.

¿Has probado a enviar ese fichero con la herramienta que proponen ellos? SoapUi

Si, desde su herramienta me lo envía.

Yo no he conseguido enviarlo directamente como tu estas haciendo. Lo que hacemos es en el evento OnBeforeExecute generar otro fichero en BASE64 y enviarlo.

Código Delphi [-]
var
  ss:TFileStream;
  i : Integer;
  NficheroTemp : STring;
  ListaFichero : TStringList;
  Base64: TBase64Encoding;
  Salida : Ansistring;
begin

  //FIChero es el fichero original 
  NficheroTemp :=  Copy(Fichero, 1 , Length(Fichero) - 4) + 'TMP.XML';

  
  ListaFichero := TStringList.Create;
  ListaFichero.LoadFromFile(Fichero);
  Base64 := TBase64Encoding.Create;
  Salida := Base64.Encode(ListaFichero.Text);
  Base64.Destroy;
  ListaFichero.Clear;

  ListaFichero.Add('');

  ListaFichero.Add('');
  ListaFichero.Add('');
  ListaFichero.Add('');
  ListaFichero.Add('');
  ListaFichero.Add('');
  ListaFichero.Add('');
  ListaFichero.Add(salida);

  ListaFichero.Add('');
  ListaFichero.Add('');
  ListaFichero.Add('');
  ListaFichero.Add('');

  if FileExists(NficheroTemp) then
   System.SysUtils.DeleteFile(NficheroTemp);

  ListaFichero.SaveToFile(NficheroTemp);
  ListaFichero.Destroy;


  SOAPRequest.Size := 0;
  ss := TFileStream.Create(NFicheroTemp, System.SysUtils.fmOpenRead);
  SOAPRequest.Position := 0;
  SOAPRequest.CopyFrom( ss, ss.Size);
  ss.Free;
  SOAPRequest.Position := 0;

  if FileExists(NficheroTemp) then
   System.SysUtils.DeleteFile(NficheroTemp);

Gracias por la info, he creado un proceso BeforeExecute y ya va. Sí en verdad es como el SII, pero ni lo he analizado bien, estoy atontado. Muchas gracias estaba bloqueado.
Os pongo el proceso entero por si os vale de algo.

Recien recibido de TicketBai

Estimados participantes en el piloto TicketBAI:

Les escribimos para informales de que en el mes de noviembre ha finalizado la fase piloto en el proyecto TicketBAI.

Agradecemos enormemente su participación en esta fase del proyecto. Gracias a sus aportaciones, hemos podido revisar las especificaciones del mismo con el fin de que se adapte lo mejor posible a los diferentes modelos de negocio.

Les informamos de los siguientes pasos del proyecto:

• A mediados de diciembre se remitirá a los participantes la documentación definitiva del proyecto TicketBAI, a la vista de las conclusiones obtenidas en el piloto.

• Además, se informará de los canales que cada Administración abrirá para comunicar las novedades relativas a la implantación del sistema TicketBAI y para que las empresas formulen las dudas de todo tipo que tengan. En estos nuevos canales se inscribirá de forma automática a todos los participantes en el piloto TicketBAI. Para formular consultas sobre el sistema definitivo habrá que esperar a la apertura de estos nuevos canales.

• De momento, se mantiene abierto el buzón TicketBAI pero no se atenderá a nuevas consultas. Se podrán registrar nuevas empresas para acceder a la información definitiva del proyecto.

¡Muchas gracias!