Hola. A mi me funciona así.No sé si será por la versión de curl. Probaré con el -v tb.por si tengo que actualizar curl y falla.
Gracias por la informacion

Pot cierto redsara es el entorno de pruebas

Máximo minutos/registros
 

Aleluya, me ha costado pero ya lo tengo claro, en principio solo voy a enviar los registros si se cumple una de estas condiciones:
He acumulado 1000registros
Han pasado 120 minutos desde el último envío.
Con lo cual cumplo cualquier condición que pongan y un parámetro menos a tener en cuenta en caso de algún fallo puntual.

Hola ermendalenda,

¿No te sería más cómodo que se vayan enviando a medida que se generan?
A mí eso de guardar 1.000 registros esperando que no ocurra ninguna desgracia y se pierdan .... :(

Para eso está Internet, para que no tengas que esperar a que pase el cartero :D

Saludos

Cierto pero hay que tener en cuenta que te piden un número de registros mínimos a enviarbo o un mínimo tiempo de espera y esa información te la mandan después de cada envío, es fácil gestionarlo pero es más fácil no gestionarlo, como mucho voy a mandar cada 120 minutos que es el tiempo máximo de espera que vienen en el xsd.

Creo que Sistel tiene razón... la decisión de cuantos documentos tienes que enviar o el tiempo máximo de espera entre envíos te lo dirán en cada transmisión... y nuestros sistemas tendrán que acatar la orden. Imagino, que en una tienda de decoración, donde se hace diez o doce facturas a la hora, te dirán 1-0 (1 documento en cuanto esté hecho)... en un supermercado con 10 cajas generando 600 tickets por hora, te dirán 1000-120. De hecho, la indicación es que la primera transmisión sea 1-0, es decir, transmisión en cuanto se haga la primera factura. Imagino que cada inicio de jornada o caída del sistema, habrá que empezar con un 1-0... y luego esperar la respuesta de cómo seguir.

Lo que habrá que preguntar es qué pasa si no haces caso a su indicación y mandamos lo que nosotros decidamos... ¿provocará algún tipo de rechazo o error de incorporación?

Mmm.. no sé voy a esperar la doctrina pero creo que lo que yo voy a hacer tiene mucho sentido y no va a dar problemas. La orden no dice que tienes que enviar 1-0 obligatorimente, sino que ess el mínimo de registros y de tiempo de espera. Sólo hay que darle un par de vueltas para verle la lógica.

Lo el error lo lógico es que si se envia antes de tiempo, en la respuesta te vuelvan a indicar cuando/cuanto enviar.

Huella
 

Hola,a ver que entendeis de ésto:

Huella de la factura (Realizada sobre el nodo RegistroFacturacion)

¿Calculariais con el nombre del nodo o sin él?

O sea sha256 sobre
¿Incluido o sin incluir ?

Con; es decir, desde el primero < hasta el último >. El nodo incluye su identificador y sus delimitadores.

Creo que en la norma XML, el nodo se extiende un poco más, es decir, también recoge todo el texto que viene detrás del último > (¡cuidado, esto incluye los CR y LF!) y también eventuales comentarios que pueden venir después del último >.
Sin embargo, poner comentarios detrás del </RegistroFacturacion> me parece una extraordinaria mala idea :o
Y para evitar malas sorpresas de parte de paquetes XML que siguen la norma de forma más o menos estricta, creo que sería una buena idea pegar la etiqueta <DatosControl> justo detrás del </RegistroFacturacion>, sin nada entre las dos etiquetas.

Buena idea gracias.

Hola,

Esto es nuevo o es lo mismo:

www infoautonomos.com/blog/factura-electronica-obligatoria-autonomos/

Eso es otra cosa.

Una cosa es la ley antifraude (VERIFACTU) y otra es la forma de como les envias las facturas a tus clientes que es a lo que se refiere el articulo (Facturae, pdf, etc...).

Es otra cosa:
Ah, ya te ha contestado keys.

Hola... alguien tiene información de qué es lo que hay que imprimir en el dichoso QR ??? En hacienda sólo dicen que tiene que ir la información necesaria para que el cliente pueda comprobar que la factura ha sido declarada correctamente. Pensé que con la Huella sería suficiente, pero también he leído que la información contenida también debe ayudar al cliente a registrar esa factura en su sistema automáticamente, ¿¿¿ habrá que meter el <registrofactura> completo ???

Si es similar a TicketBAI (y por ahora las cosas se parecebn bastante) es una URL con la información suficiente para que el cliente "busque" su factura en el sistema y compare que es igul a la que tienes en las manos.

Es este caso es esta URL
https://tbai.prep.gipuzkoa.eus/qr/

Y a continuación concatenar esta información:
“?id=IDENTIFICATIVO_TBAIi&s=SERIE&nf=NUMERO_FACTURA&i=IMPORTE&cr=CODIGO_CRC”

Gracias Neftali. Nuevas dudas:

- El IDENTIFICATIVO_TBAI se supone que es el CIF o algo similar???
- El CODIGO_CRC es un código de redundancia que genera la administración o el programa? Si lo genera la administración... hasta que no está subido no se puede imprimir el QR ¿Correcto?

Correcto. En el caso de TBAI es el CIF con el que se ha generado la factura.

Lo generas tú con un algoritmo sencillo.

Se supone que este será algo similar. Al final de lo que se trata es de que ese QR tenga una URL con unos datos mínimos para encontrar la factura que está almacenada en hacienda.

Gracias de nuevo!!!! Empezaré a generar así el QR (con una URL inventada) para ir maquetando el sistema de facturación. Como he comentado, quiero sacar el SIF como un módulo externo al ERP... es decir, quiero que mi ERP no pueda emitir facturas... pero tiene que saber, es decir, registrar, qué facturas se han emitido (para la gestión del cobro, envío de facturas (EDI, FacturaE, email, correo...) contabilización y listados), por lo que no sé si al final el ERP tendrá que estar también certificado... o autocertificado.... a ver si sueltan más documentación de cómo las empresas deben emitir, imprimir y comunicar las facturas.

Si, para probar a generarlo/imprimirlo, por ahora que no hay documentación, puedes hacerlo con cualquier URL, aunque sea siempre la misma.
Y luego una vez impresa la factura/ticket probar a escanearlo con el móvil para ver si funciona.



;)

Sin pretender abusar de los que ya os habéis peleado con el TicketBai... ¿Cómo se gestionan las facturas que son emitidas por otros softwares y que son importadas al ERP? Por poner ejemplos:

- Prestashop, wordpress, wooCommerce.... Nuestro ERP recibe las facturas ya hechas y las incorpora al fichero de facturación. ¿Tiene que estar el Presta preparado para Veri*factu?

- Tengo con una distribuidora de pescado y marisco que vende a restaurantes y hoteles... pero además tiene un restaurante, y el programa de restauración (comandas, tickets y cobro) lo gestiona otra empresa... y las facturas simplificadas se importan a nuestro ERP. Imagino que esta empresa hará la comunicación con H.P... pero el tratamiento fiscal de dichas facturas lo hace nuestro ERP. ¿Podemos almacenar facturas de otros sistemas sin presentarlas?

- Una cadena de pescaderías tienen balanzas inteligentes. Hacen facturas simplificadas y por la noche transmiten las ventas realizadas que se incorporan como una única factura recapitulativa por cada balanza... por cierto, una vez un pillo aprendió a resetear una de las balanzas y de las 3 balanzas del local sólo se recibían ventas de dos de ellas. La tercera nunca tenía ventas. ¿Tenemos responsabilidad en esos casos?

¿Cómo habéis resuelto estas situaciones con el TicketBai?

Sin saber nada de TicketBAI la lógica me dice que el responsable de cumplir con la normativa es el programa que emite la factura originalmente y efectivamente hay muchas cosas de las que no se ha hablado como son facturas emitidas por webs, balanzas, registradoras, terminales móviles y tantos millones de dispositivos que andan por el mundo haciendo facturas simplificadas. No estaría mal ir enterándose de qué pasará con esas cosas.

Saludos.

En TicketBAI cualquier dispositivo que emita facturas (BALANZAS, TPV, Etc..) se tiene que adaptar a TicketBAI. Me imagino que en verifactu ocurrirá lo mismo.

En el caso de TicketBAI (que por algo lleva el prefijo de Ticket) cuando tú entregas un ticket, ya debe llevar impreso el QR con toda la información necesaria para que el usuario pueda validar esa factura en la web de hacienda. Por lo tanto el terminal que emite ese ticket (o el software asociado) son los que deben realizar la emisión/generación/envío de esa factura.

No se si mi mensaje anterior te aclara algo, pero en el caso de TicketBAI (que está pensado para tickets principalmente), si el usuario se lleva un "Ticket" (por ejemplo porque consume un café en un restaurante), cuando se ha generado ese ticket, ese software ya debe haber realizado todo el trabajo de generación del XML, firma, QR,... Por lo tanto, cuando tu software importe esas facturas , todo eso ya debe estar hecho.

En realidad es que TicketBAI se ha implementado (y por eso lleva el prefijo Ticket) para los negocios "pequeños" que generan tickets. Que son los que hasta ahora se les "descontrolaban" (en cuando a ventas y fiscalidad). Lo que pretenden es que todos esos negocios (bares, restaurantes, peluquerías, tiendas pequeñas, chinos,....) que hasta ahora te daban un ticket (no una factura) y a final de mes nadie sabía realmente lo que facturaban, ahora estén fiscalizadas igual que las grandes.

Hola afxe,

Te cuento cómo hemos resuelto nosotros los mismos escenarios que tú comentas en caso de nuestros clientes en TicketBAI:

En el caso de tiendas online se puede dar el caso de que emitan facturas directamente (al hacer el pedido y pago por tarjeta o Paypal) o se emitan, posteriormente, desde otra aplicación.
Para el caso de nuestros clientes con tienda online Wordpress-Woocommerce que emiten facturas directamente desde esa aplicación, sólo tienen que instalar nuestro plugin que hará todos los procesos, incluida la generación del PDF de la factura con los códigos TBAI y QR y el envío automático, inmediato, del XML firmado la factura a Hacienda Foral.

TicketBAI obliga a que se envíen las facturas emitidas, ya sean facturas simplificadas (llamadas habitualmente tickets) o facturas completas en el mismo momento de emitirse.
Por lo cual cualquier equipo emisor de facturas (incluidos TPVs, balanzas electrónicas o cualquier otro) debe tener conexión a Internet.
No pueden almacenarse las facturas para enviarse posteriormente.

Con TicketBAI se deben enviar todas las facturas simplificadas en el mismo momento de su emisión.
Aparte, pueden emitirse, posteriormente, facturas completas sustitutivas de facturas simplificadas (llamadas habitualmente facturas de canje de tickets) que agrupen a varias. Pero es una nueva factura y no exime del envío de las primeras.

Hay responsabilidad por parte del obligado tributario (la persona física o jurídica que debe emitir las facturas) así como por parte de la empresa desarrolladora del software garante TicketBAI (que debe haber obtenido licencia para ello).
El software no debe tener posibilidad de contabilidad "B", ni de borrado de facturas o de manipulación de facturas.
Una factura emitida es algo casi sagrado e intocable porque va encadenada mediante firma con la anterior y posterior.

Las sanciones son suficientemente fuertes como para que a nadie se le ocurra infringir las normas.

Saludos

Hola a todos.

Se supone que hay que evitar que los datos se alteren, pero si el usuario si es un poco listo podrá entrar en el fichero físico de la base de datos por su cuenta y borrar un registro.

Nuestra base da datos esta en firebird 2.5 y podemos cambiar la clave el usuario e incluso borrar el usuario SYSDBA. Pero si el usuario se lleva el fichero de la base de datos a otro ordenador con el mismo motor podrá acceder con el Usuario maestro (SYSDBA).

La pregunta es si hay alguna forma de evitar esto en firebird o si en alguna versión más reciente ha cambiado esto.

Un usuario no puede tener acceso a la BD para llevársela, copiarla ni nada por el estilo.
Por algo es un sistema cliente/servidor, los clientes no tienen que saber ni dónde está la BD.
Los clientes/terminales/usuarios no deben tener acceso al servidor. El servidor no puede tener compartida carpetas ni nada que permita a cualquiera entrar y copiar la BD.
Firebird solamente necesita tener abierto el puerto 3050 en el servidor, nada más.
Aparte de eso, es un tema que se ha tratado otras veces, a ver si lo encuentro... para no repetir lo mismo en este hilo que no trata sobre eso.

Hola,

Opino como tú.
Lo mejor es utilizar una arquitectura cliente/servidor donde el usuario no tenga acceso alguno al servidor donde se guardan las facturas.
La aplicación le muestra los datos que deba ver, cuando los pida, y punto pelota.

Saludos

Gracias a los dos.

Estoy de acuerdo con lo que decís, el sistema ya esta configurado de esa manera. Pero al tratarse de una aplicación comercial, es el usuario el que instala la aplicación en su servidor y lógicamente tiene acceso a todos los ficheros de su sistema.

Un Saludo.

A ver si encuentro esos enlaces...

Hola, te hago u pequeño resumen, el software que emita la factura, da igual que sea una balanza o un software de terceros , tiene que gestionar la generación del xml con sus respectivas las huellas , esos xmls o se podrán alterar ya que si envías uno alterado a hacienda se van a dar cuenta por el encadenamiento otra cosa es el envío, si se ha seleccionado la opción envio, esos xmls se pueden enviar desde ese software o desde otro pero el que genera el xml es el que principalmente debe estar dado de alta y referencia do que se envia con otra api, software, servicio...
Puedes importar posteriormente las facturas a otro ERP para gestionar la contabilidad y ese ERP puede estar separado del que emite las facturas. Si un empleado, empresa o autónomo, separa ese dispositivo de facturación de la generación de tiquets o facturas verificadas con su qr y no emite el xnl ni lo envía ni lo guarda con intención de no declararla, lógicamente, el distribuidor del software y/o empresa i staladora/mantenimiento no tienen responsabilidad siempre que no se haya participado en facilitarlo, que el software no tenga alguna trampa demostrable. Aún así entiendo que habrá situaciones dudosas, pero se entiende que so hay duda razonable cualquier acusación se quedará en nada.
Saludos

Con este sistema eso es lo que se intenta evitar y es lo que van a conseguir.
De todas formas no hace falta algo tan complejo. Simplemente en una tienda que emitía tickets, bastaba con "tirar a la basura" 1 de cada tres tickets que te han pagado en efectivo.

Ahora eso ya no será posible, porque el ticket debe lllevar el QR y eso significa que ha entrado en el sistema, se ha generado y se ha enviado a hacienda (y el usuario podrá escanearlo y comprobarlo). A no ser que no entregarás nada al cliente y a posteriori lo hicieras "desaparecer" (pero eso no es nada habitual).

Yo creo que en ese caso, si el cliente ha "tocado" la balanza y el sistema informático no ha facilitado las trampas, no es responsabilidad del software, sí del cliente.

Realmente, en el caso que he comentado, ni siquiera administración sabía que se estaba inicializando la balanza antes de comunicar... la trampa la estaba haciendo un empleado que consideraba que su sueldo no era justo.

Pero centrando en tema y sentar bases de trabajo (corríjanme si me equivoco):

1º El software que emite la factura tiene que generar inmediatamente el XML y un QR que identifique la factura. Se supone que el XML ya tiene que tener la huella generada y el encadenamiento.

2º Esas facturas emitidas pueden ser recogidas por otro software, como un ERP o una Contabilidad. Lo único obligatorio para estos receptores de facturas es que tenga registrado el XML generado por el SIF, el XML no debe ser generado (o recarlculado) a posteriori por ningún otro software.

3º La comunicación a los servidores de hacienda lo puede hacer cualquiera de los programa: el SIF que emite la factura, el que ERP que procesa la estadística, el SGA que gestiona la logística o la CONTABILIDAD que fiscaliza los ingresos. (¿existe algún plazo de entrega de dichas facturas?, ¿debe ser en tiempo real, al día siguiente o antes de 4 días, como el SII?)

4º La base de datos de facturas emitidas es responsabilidad nuestra (su acceso, seguridad, fiabilidad, transparencia...) por lo tanto dejar la base de datos en un "portátil" de un cliente no es aceptable... (no estoy pensando en grandes empresas ni en pymes... seguro que todos las tenemos bien controlados sus servidores... hablo de lo que hay que plantearle a pequeños autónomos que tienen una panadería, un ultramarino, una pescadería, un quiosco de prensa....)

¿Este planteamiento es correcto? ¿Un sistema calificado como VERI*FACTU puede NO enviar las facturas en tiempo real?

Quiero recordar que en una charla que dieron los de hacienda sobre este tema aclararon que, aunque el software siempre debe de estar preparado para enviar los datos, es decisión del usuario final enviarlos o no. Por supuesto aclararon que los que enviaran datos estarían menos controlados que los que no.

Hola afxe,

Contesto a tus preguntas (suponiendo que el reglamento de Verifactu sea, al final, similar al de TicketBAI)

1º Sí
2º Sí
3º En TicketBAI de Álava y Gipuzkoa el envío debe ser inmediato (en el mismo momento de generar la factura).
En Batuz-TicketBAI de Bizkaia en los mismos plazos de las declaraciones de IVA (trimestral en la mayoría de los casos, mensual en algunos otros y en 4 días para los anteriormente obligados al SII, al que también sustituye)
4º Parece poco aconsejable dejar la base de datos de facturas emitidas al alcance del cliente (que seguro que tiene un cuñado que sabe manipularlas).
Me parece que lo razonable es que se transfieran a un sistema más seguro y que se considere que las facturas "legales" son las almacenadas en dicho sistema seguro.

Creo que se comentó que habría posibilidad de no enviarlas, pero dejándolas, en ese caso, encadenadas y a merced de la inspección de cualquier inspector de Hacienda.
Por lo que .... mejor enviar que estar recibiendo visitas frecuentes inoportunas.

Saludos

Correcto.
En realidad el QR se puede generar en cualquier momento, hasta en el momento justo de imprimir, porque no cambia, es independiente del momento en el que se genere. Lo que sí debe ser inmediato es el XML.

En realidad no se puede. Porque al volver a generarlo cambiaría y eso afectaría al encadenamiento.
El encadenamiento justo es para asegurar que una vez generada la factura N, la (N-1) ya no se va a modificar (y así recursivamente hacia atrás).

No se si se especifica por ahora, pero la lógica es que el programa que realiza la factura, genera el XML y lo firma sea el que permite comunicar.
Por ahora para la LeyAntifraude parece que se podrá optar por enviar automáticamente (VERI*FACTU) o bajo petición cuando hacienda lo solicite.

La mayoría de Gestores de Base de Datos actuales disponen de seguridad, así que aplicada correctamente no veo porqué no se puede dejar una Base de Datos en un equipo de un cliente. Si está protegida correctamete sólo el programa(ERP) puede/debe tener acceso a ella. Estoy pensando no sólo en controlar el acceso sino en temas de encriptación (anti-cuñaos-sabiondos ;-D ).
Otro tema es como gestionar la seguridad en cuanto a copias de seguridad.

3º La comunicación a los servidores de hacienda lo puede hacer cualquiera de los programa: el SIF que emite la factura, el que ERP que procesa la estadística, el SGA que gestiona la logística o la CONTABILIDAD que fiscaliza los ingresos. (¿existe algún plazo de entrega de dichas facturas?, ¿debe ser en tiempo real, al día siguiente o antes de 4 días, como el SII?)


Hay que esperar al reglamento definitivo con todas las pautas bien definidas en su Doctrinas. Lo que pienso que van a decir es que debes enviarlo loables posible teniendo en cuenta las reglas de mínimos de facturas y tiempos, que esas reglas te las podrán ir cambiando después de cada enviom

4º La base de datos de facturas emitidas es responsabilidad nuestra (su acceso, seguridad, fiabilidad, transparencia...) por lo tanto dejar la base de datos en un "portátil" de un cliente no es aceptable... (no estoy pensando en grandes empresas ni en pymes... seguro que todos las tenemos bien controlados sus servidores... hablo de lo que hay que plantearle a pequeños autónomos que tienen una panadería, un ultramarino, una pescadería, un quiosco de prensa....)

Está claro que existen unas normas de seguridad mínima de acceso a datos y la nueva ley te dice que hay que intentar evitar la modificación de los mismos, pero
Si seleccionas la modalidad de envío te vas a evitar muchos quebraderos de cabeza. Si te sirve, mi software t4abaja en local pero lo que hago es enviar cada venta en un XML a un servidor externo con in servicio REST que guarda todas las ventas y el se encargará de enviarlas a verifactu. Con lo cual tengo garantizada la inviolabilidad.

Hola a tod@s.

Entonces... para ir aclarándome que me he despistado un poco de este tema. El asunto está en que a todas las facturas/facturas simplificadas de venta hay que ponerle una marca determinada, firmarlas y a partir de ahí no se podrán modificar. Por otro lado el programa tiene que tener la capacidad de enviarlas a un webservice y es el cliente el que decide si las envía o no.

¿Es correcto este resumen?

Gracias y un saludo.

Hola newtron,

En Verifactu está aún por definir hasta que se publique el reglamento.

Te puedo contar cómo se hace en TicketBAI (supongo de Verifactu al final será algo similar):
- Recopilas todos los datos de la factura (emisor, destinatario, líneas de detalle, régimen de IVA del emisor, serie, número, fecha, hora, etc)
- Creas un XML que contiene esa información junto con parte de la firma de la factura anterior + los datos de la licencia de software garante TicketBAI
- Firmas ese XML con un certificado digital
- Obtienes un código TBAI y un código QR, a partir de la firma del XML y los imprimes en la factura
- Envías el XML firmado de forma inmediata (salvo en Bizkaia, que con Batuz tienes un tiempo algo mayor)

En Verifactu parece ser que van a dejar la opción de que no envíes, pero que a cambio de que tengas la puerta abierta para que te visite el inspector de Hacienda, un día sí y otro también, para comprobar el correcto encadenamiento de las facturas.

Saludos

Hola, no exactamente, si el cliente decide no enviar, tiene que buscar un software que lo permita, ya que no todos los programas van a tener esa opción. La única opción obligatoria a incluir en el programa es la de envío y SE PERMITE, que tenga la opción de no enviar.
Yo por ejemplo, que como la mayoría de vosotros, soy desarrollador, no voy a incluir la opción de no enviar por 3 motivos evidentes: 1.no quiero problemas, 2.no quiero problemas, 3.no quiero problemas.
Por otro lado los tipos de facturas hay algunos mas:
Factura Simplificada
Factura Normal
Factura Simplificada Rectificativa
Factura Rectificativa de Factura normal
Factura recapitulativa
Factura de canje/sustituiva

Te lo digo por que cada tipo debe tener su numero de serie