Prefacturacion, Proformas y Borradores de facturas (Faq Verifactu)

[jguarda]

To tengo una pregunta.


Si hago una factura a la 10:00 de la mañana ... que es lo que me impide enviarla a hacienda a las 17:30h.


Lo digo xq yo no guardo en nigún sitio la hora en la que emito la factura, y pienso, como van a saber los de la AEAT que se la dí al cliente, ( *** o no, xq se la puedo enviar x correo 2 días después ***), la hora en la emiti la factua.

[jguarda]

Alguien se cree, que un chino, te va a dar, un ticket con un QR como que ha pasado por la AEAT., estos de hacienda flipan.

[CarlosR]

Empezado por jguarda

Alguien se cree, que un chino, te va a dar, un ticket con un QR como que ha pasado por la AEAT., estos de hacienda flipan.

Que remedio les queda. No hay otra.
A los chinos también se les sanciona y en determinadas ocasiones se les cierra el negocio.
Saludos.

[Sistel]

Empezado por jguarda

Alguien se cree, que un chino, te va a dar, un ticket con un QR como que ha pasado por la AEAT., estos de hacienda flipan.

Hola,

Tengo unos 150 bazares chinos como clientes en TicketBAI.
Y todos ellos emiten todos sus tickets con el correspondiente QR de TicketBAI.

Mis clientes chinos son mucho más cumplidores que la media del resto de clientes.

Saludos

[pablog2k]

justo iba a comentar que los compañeros que ya han instalado ticketbai podrían dar fe que al final todos los comercios han implantado su tpv con su QR y su subida casi inmediata a la hacienda vasca, y han seguido trabajando con normalidad

[bmfranky]

Hasta donde entiendo, y me he comido toda la documentacion , hasta el momento.
En el momento que asignas el numero de factura y permites su impresion o envio al cliente(Crey que hasta su impresion en pantalla por lo de enviar capturas...), has de comunicar a hacienda por medio de verifactu los datos de esa factura, para cumplir con la ley tanto anti fraude, como la de crea y crece(+Cuando toque), puesto que segun su entendimiento del sif, has de generar el registro para enviar a hacienda y el de tu factura interna a la vez, ello quiere decir que dede el momento de "Crear" la factura has de enviar en menos de 120".

[antoine0]

Empezado por bmfranky

En el momento que asignas el numero de factura y permites su impresion o envio al cliente(Crey que hasta su impresion en pantalla por lo de enviar capturas...), has de comunicar a hacienda por medio de verifactu los datos de esa factura, para cumplir con la ley tanto anti fraude, como la de crea y crece(+Cuando toque), puesto que segun su entendimiento del sif, has de generar el registro para enviar a hacienda y el de tu factura interna a la vez, ello quiere decir que dede el momento de "Crear" la factura has de enviar en menos de 120".

Estoy contigo para lo de imprimir o enviar al cliente.
Ahora bien, la asignación del número de factura, ¿dónde has visto que debe ser en el mismo momento?

Sí, el registro debe contener este número (y debe cumplir las normas, ser monotónico etc.)
Sí, hay sistemas que van a hacer las dos operaciones al mismo momento por razones de sincronización (multi-tareas, serialización, transacciones, llamadlo como quieren). Aunque solo es una opción operativa.

Pero entiendo que puedes perfectamente asignar los números con anterioridad, presentar las pre-facturas con los números ya puestos (el registro sin generar), y cumplir; emitiendo luego los registros en orden en el momento de imprimir o enviar.

[bmfranky]

Empezado por antoine0

Estoy contigo para lo de imprimir o enviar al cliente.
Ahora bien, la asignación del número de factura, ¿dónde has visto que debe ser en el mismo momento?

Sí, el registro debe contener este número (y debe cumplir las normas, ser monotónico etc.)
Sí, hay sistemas que van a hacer las dos operaciones al mismo momento por razones de sincronización (multi-tareas, serialización, transacciones, llamadlo como quieren). Aunque solo es una opción operativa.

Pero entiendo que puedes perfectamente asignar los números con anterioridad, presentar las pre-facturas con los números ya puestos (el registro sin generar), y cumplir; emitiendo luego los registros en orden en el momento de imprimir o enviar.

Estoy de acuerdo, siempre que , en el ultimo momento el usuario no decida cancelar una de las no impresas, y se genere un hueco..., a partir de ahi no se, usemos la imaginacion de que puede llegar a pasar.

[antoine0]

Empezado por bmfranky

Estoy de acuerdo, siempre que , en el ultimo momento el usuario no decida cancelar una de las no impresas, y se genere un hueco...

Un programa conforme no puede permitirlo. así de sencillo.
Un usuario podría cancelar todas las pre-facturas; o las últimas; pero no podrá cancelar una (si no es la última).
Y evidentemente, el programa deberá ajustar el contador de la próxima factura para que estas pre-facturas que no llegasen a imprimirse, no se tienen en cuenta.

[CarlosR]

Empezado por Sistel

Hola,

Tengo unos 150 bazares chinos como clientes en TicketBAI.
Y todos ellos emiten todos sus tickets con el correspondiente QR de TicketBAI.

Mis clientes chinos son mucho más cumplidores que la media del resto de clientes.

Saludos

Totalmente de acuerdo. Tampoco les queda otra, como a los demás.

[CarlosR]

Empezado por jguarda

To tengo una pregunta.


Si hago una factura a la 10:00 de la mañana ... que es lo que me impide enviarla a hacienda a las 17:30h.


Lo digo xq yo no guardo en nigún sitio la hora en la que emito la factura, y pienso, como van a saber los de la AEAT que se la dí al cliente, ( *** o no, xq se la puedo enviar x correo 2 días después ***), la hora en la emiti la factua.

La norma indica lo siguiente :


Al llegar a 1000 documentos debes enviarlos. Si no has llegado a 1000 en un plazo máximo de 2 horas debes enviar lo que tengas.
La excepción es que no tengas comunicación con la AEAT o cualquier otro motivo de fuerza mayor, como que se corte la corriente antes de enviarlos, o un fallo en el router, switch, etc.

En este último caso debes generar uno o varios eventos y cuando envíes datos al registro has de indicarle el porqué no has podido enviarlos antes si es que no has cumplido la norma.
Las sanciones a priori son sustanciosas. Supongo que al principio harán la vista gorda. Pero que la AEAT sea benévola con el incumplimiento es otra cosa.

Saludos.

[ermendalenda]

Empezado por CarlosR

La norma indica lo siguiente :


Al llegar a 1000 documentos debes enviarlos. Si no has llegado a 1000 en un plazo máximo de 2 horas debes enviar lo que tengas.
La excepción es que no tengas comunicación con la AEAT o cualquier otro motivo de fuerza mayor, como que se corte la corriente antes de enviarlos, o un fallo en el router, switch, etc.

En este último caso debes generar uno o varios eventos y cuando envíes datos al registro has de indicarle el porqué no has podido enviarlos antes si es que no has cumplido la norma.
Las sanciones a priori son sustanciosas. Supongo que al principio harán la vista gorda. Pero que la AEAT sea benévola con el incumplimiento es otra cosa.

Saludos.

Creo que te has liado.
Hay que cumplir enviar cuando te diga el parámetro [t] que te retornan, por defecto 60 segundos. Pero si tienes los 1000r3gistros antes de ese tiempoos tienes que enviar también.
Lo de las 2 horas no se de donde lo sacas, supongo que será el tiempo máximo que te pueden devolver en [t] Creo recordar, pero no nos liemos

[CarlosR]

Empezado por ermendalenda

Creo que te has liado.
Hay que cumplir enviar cuando te diga el parámetro [t] que te retornan, por defecto 60 segundos. Pero si tienes los 1000r3gistros antes de ese tiempoos tienes que enviar también.
Lo de las 2 horas no se de donde lo sacas, supongo que será el tiempo máximo que te pueden devolver en [t] Creo recordar, pero no nos liemos

Yo creo haber leído que debes enviar lo pendiente si en 2 horas no llegas a los 1000. Es mas fue una discusión pasada en este mismo foro.
Y de los 60 segundos no he hablado, eso es otra historia.
Pero puedo estar equivocado. Esto estuvo cambiando día a día así que ya no aseguro nada.
¿ Tienes algún link para afirmar que lo de 2 horas no es así ?
Me gustaría saberlo porque estoy en plena faena con lo de veri*factu y NO veri*factu y quiero acabar cuanto antes con esta programación infinita.
Gracias.

[ermendalenda]

Empezado por CarlosR

Yo creo haber leído que debes enviar lo pendiente si en 2 horas no llegas a los 1000. Es mas fue una discusión pasada en este mismo foro.
Y de los 60 segundos no he hablado, eso es otra historia.
Pero puedo estar equivocado. Esto estuvo cambiando día a día así que ya no aseguro nada.
¿ Tienes algún link para afirmar que lo de 2 horas no es así ?
Me gustaría saberlo porque estoy en plena faena con lo de veri*factu y NO veri*factu y quiero acabar cuanto antes con esta programación infinita.
Gracias.

Bueno realmente demostrar lo que no es con un Link más bien será al contrario, dime donde has visto lo de las 2 horas

[CarlosR]

Empezado por ermendalenda

Bueno realmente demostrar lo que no es con un Link más bien será al contrario, dime donde has visto lo de las 2 horas

Como te he dicho, en este mismo foro.
Supongo que lo de linkedin fue problema del corrector.

http://www.clubdelphi.com/foros/showthread.php?p=556357
Ahi puedes buscarlo.


De todos modos lo que realmente me interesa es la Ley actual no un comentario de un foro, eso es solo una aportación personal.
Si tienes un link me gustaría verlo, para cambiar mi programación.
Saludos.

[pablog2k]

en la reunión virtual del otro día comentaron lo de los 60 segundos o 1000 registros , lo que se cumpla antes

sacado del BOE que sacaron con la orden ministerial:
2. Los sistemas informáticos «VERI*FACTU» deberán implementar un mecanismo de control de flujo basado en el tiempo de espera entre envíos, el cual tomará inicialmente el valor de 60 segundos, y en el número máximo de registros admitidos en cada envío.

[jguarda]

Yo perdoname pero no me entero.


Vamos a suponer un cajero de mercadona que puede ser el que más movimientos tenga en 60 segundo, mas o menos, una factura simplificada como mucho.


Según esta gente, para enviar, hay 2 posibilidades.
1.- consumir el tiempo ( t ) y proceder a enviar lo que tengas.
2- consumir 1000 operaciones antes de que se cumpla el tiempo (t), quien cojones hace 1000 facturas simplificadas en 60 sg, 120 sg, o lo que cojones quieras poner.


Es decir, como es incontrolable, como dijo uno de otro foro, yo haré lo que el, cada 10 minutos miro, y envio lo que tenga y punto pelota.


Eventos.
Para generar el evento de que se me ha ido el suministro electrico, como lo haria el que tiene que emitir las facturas, crearia el un XML con dicho evento a pelo en un TXT y cuando vuelva el suministro enviarselo a la AEAT.


No entiendo como se puede implementar esto en determinados casos. ( que serán muchos )., el router no furula, no tengo suministro electrico, le han pegado una pata al cable y no saben que pasa, no me enciende el monitor y no tengo otro .. un monton de casuisticas incontrolables. .... como se genera el evento de errores ???

[ermendalenda]

Empezado por jguarda

Yo perdoname pero no me entero.


Vamos a suponer un cajero de mercadona que puede ser el que más movimientos tenga en 60 segundo, mas o menos, una factura simplificada como mucho.


Según esta gente, para enviar, hay 2 posibilidades.
1.- consumir el tiempo ( t ) y proceder a enviar lo que tengas.
2- consumir 1000 operaciones antes de que se cumpla el tiempo (t), quien cojones hace 1000 facturas simplificadas en 60 sg, 120 sg, o lo que cojones quieras poner.


Es decir, como es incontrolable, como dijo uno de otro foro, yo haré lo que el, cada 10 minutos miro, y envio lo que tenga y punto pelota.


Eventos.
Para generar el evento de que se me ha ido el suministro electrico, como lo haria el que tiene que emitir las facturas, crearia el un XML con dicho evento a pelo en un TXT y cuando vuelva el suministro enviarselo a la AEAT.


No entiendo como se puede implementar esto en determinados casos. ( que serán muchos )., el router no furula, no tengo suministro electrico, le han pegado una pata al cable y no saben que pasa, no me enciende el monitor y no tengo otro .. un monton de casuisticas incontrolables. .... como se genera el evento de errores ???

No hay que enviar eventos ni es obligatorio generarlos en tu sistema si estás enviando.
Si tienes una incidencia marcas el registro como incidencia y ya lo mandaras cuando se pueda.
Los 1000 registros se puede dar en los casos en los que un obligado tributario centraliza los envios a través de un servidor (lo he descubierto hoy en el foro)
Normalmente no puedes/debes mandar fuera de los tiempos que te indican
Si te dicen que mandes en 60segundos, llegado ese momento manda lo que tengas, te Dan unos segundos para enviarlo, aunque lo acepten fuera de ese tiempo te van poner una "x" como en el cole(es metaforico)cada vez que lo hagas
No se cuantas "x" te dejaran acumular para que no sea leve. O sea si pasa de vez en cuando y tienen mucho trabajo no creo que te digan nada, y creo que no se van a aburrir durante una larga temporada, aunque seguro automatizan algún aviso al correo.

[CarlosR]

Empezado por ermendalenda

No hay que enviar eventos ni es obligatorio generarlos en tu sistema si estás enviando.
Si tienes una incidencia marcas el registro como incidencia y ya lo mandaras cuando se pueda.
Los 1000 registros se puede dar en los casos en los que un obligado tributario centraliza los envios a través de un servidor (lo he descubierto hoy en el foro)
Normalmente no puedes/debes mandar fuera de los tiempos que te indican
Si te dicen que mandes en 60segundos, llegado ese momento manda lo que tengas, te Dan unos segundos para enviarlo, aunque lo acepten fuera de ese tiempo te van poner una "x" como en el cole(es metaforico)cada vez que lo hagas
No se cuantas "x" te dejaran acumular para que no sea leve. O sea si pasa de vez en cuando y tienen mucho trabajo no creo que te digan nada, y creo que no se van a aburrir durante una larga temporada, aunque seguro automatizan algún aviso al correo.

1º Ese tiempo (t) es el tiempo que debe esperar entre envíos.
2º Después de ese (t) que son 60 segundos actualmente o eso se espera, cuando junte 1000 registros ya puede enviarlos.

3º Si en un plazo de 2 horas -insisto- no ha juntado 1000 registros entonces ha de enviar lo que tenga. Este punto ya se ha discutido anteriormente y mientras no vea un documento oficial que lo desmienta me quedo con estos datos.
4º Si junta 1000 registros cada 60 segundos en una única instalación entonces es una gran empresa. Caso que hizo alusión a Mercadona, aunque este no sería un caso representativo porque cada instalación según yo recuerdo tiene los datos por separado y luego sube tablas todos los días hacia una base de datos general. Lo que indica que el verifactu tendrá que usarlo por instalación. 1000 registros cada 60 segundos sería algo así como 24000 registros por día. dudo que los tenga un Mercadona. Pero le pondré un caso que si los tiene, por ejemplo Telefónica que tiene la facturación centraalizada en un solo sitio.

5º De cualquier modo me da la impresión de que estas grandes empresas optarán por el NO veri*factu. Eso es una conclusión que saco yo, nada mas. Encima los responsables serán ellos mismos porque el fabricante o bien son ellos mismos o bien tendrán sendos contratos con alguna firma de renombre para delegar la responsabilidad desde el fabricante al cliente.
6º Los eventos (creo) hay que tenerlos disponibles en las dos modalidades tanto veri*factu como NO veri*factu, otra cuestión es que se suban a la AEAT. -Si estoy confundido que alguien me corrija por favor-
7º Caso de NO veri*factu: No se suben los registros uno a uno, solo se suben los registros que solicite por requerimiento la AEAT. También pueden exigir subir los registros de eventos.


No sé si alumbraré o crearé mas oscuridad con este post, espero que sea lo primero.


Saludos.

[CarlosR]

Empezado por CarlosR

1º Ese tiempo (t) es el tiempo que debe esperar entre envíos.
2º Después de ese (t) que son 60 segundos actualmente o eso se espera, cuando junte 1000 registros ya puede enviarlos.

3º Si en un plazo de 2 horas -insisto- no ha juntado 1000 registros entonces ha de enviar lo que tenga. Este punto ya se ha discutido anteriormente y mientras no vea un documento oficial que lo desmienta me quedo con estos datos.
4º Si junta 1000 registros cada 60 segundos en una única instalación entonces es una gran empresa. Caso que hizo alusión a Mercadona, aunque este no sería un caso representativo porque cada instalación según yo recuerdo tiene los datos por separado y luego sube tablas todos los días hacia una base de datos general. Lo que indica que el verifactu tendrá que usarlo por instalación. 1000 registros cada 60 segundos sería algo así como 24000 registros por día. dudo que los tenga un Mercadona. Pero le pondré un caso que si los tiene, por ejemplo Telefónica que tiene la facturación centraalizada en un solo sitio.

5º De cualquier modo me da la impresión de que estas grandes empresas optarán por el NO veri*factu. Eso es una conclusión que saco yo, nada mas. Encima los responsables serán ellos mismos porque el fabricante o bien son ellos mismos o bien tendrán sendos contratos con alguna firma de renombre para delegar la responsabilidad desde el fabricante al cliente.
6º Los eventos (creo) hay que tenerlos disponibles en las dos modalidades tanto veri*factu como NO veri*factu, otra cuestión es que se suban a la AEAT. -Si estoy confundido que alguien me corrija por favor-
7º Caso de NO veri*factu: No se suben los registros uno a uno, solo se suben los registros que solicite por requerimiento la AEAT. También pueden exigir subir los registros de eventos.


No sé si alumbraré o crearé mas oscuridad con este post, espero que sea lo primero.


Saludos.

Se nota que acabo de levantarme y aún no tomé un café. Im Sorry.
1000 registros cada 60 segundos sería algo así como 86,400,000 registros día.
Una gran cantidad, sin duda.