Aún no se sabe, pero supongo que será una totalizacion de cada trimestre por cada tipo impositivo y sus bases y envío a los servidores que dispongan, teniendo en cuenta como fechas las facturas, ya que habrá negocios que tengan su propio cierre (zeta) y en un cierre puede tener 2 días de 2 periodos impositivos distintos (día 31 y 1) no se puede usa la fecha de los cierres propios

Pero es referido solo a las ventas, no?, porque si el programa sólo gestiona ventas, o el que lo usa no mete las facturas de compra?.
Y para un kiosko como dicen aquí, que periodos tiene?.


Saludos.

Sí, solo ventas.
Pues supongo que cada uno tendrá un periodo según las condiciones dependiendo de como esté dado de alta que será equivalente a cuando realicen las declaraciones de IVA y un quiosco igual.

Borrador
 

Hola, el borrador está en:
https://www.hacienda.gob.es/Document...talizacion.pdf

según eso, dice, en la página 8 "Disposición final tercera. Entrada en vigor y efectos"
"El presente Real Decreto y el Reglamento anexo entrarán en vigor al día siguiente de su
publicación en el Boletín Oficial del Estado y resultarán de aplicación para los obligados tributarios
a que se refiere el artículo 3.2 del Reglamento en relación con sus actividades de producción y
comercialización de los sistemas informáticos"

y el Artículo 3. Ámbito subjetivo. dice:
2. Los productores y comercializadores de los sistemas informáticos a que se refiere el artículo 1
de este Reglamento en las cuestiones relativas a sus respectivas actividades de producción y
comercialización de los sistemas informáticos puestos a disposición de los obligados tributarios
mencionados en el apartado 1 de este artículo 3.


Entiendo, según eso, que el día que salga en el BOE, mi programa ya ha de estar adaptado totalmente a lo que diga dicho BOE?, porque yo lo entiendo de esa forma.


Gracias.

No, la fecha será la que indiquen en el BOE, ya que se puede publicar mañana y decir que entrará en vigor dentro de 20 años, por decir algo.

Nuevas noticias
 

Hola, hay un video nuevo:

https://www.dailymotion.com/video/x89tixv

Por si interesa.

Los de leyantifraude, hacen mención a más cosas para el cumplimiento de la ley, que no están es este borrador, backups, entornos de desarrollo..... alguien sabe algo de ello?.

Saludos.

Hola sigo sin entenderlo bien, pone:
El presente Real Decreto y el Reglamento anexo entrarán en vigor al día siguiente de su publicación en el Boletín Oficial y resultarán de aplicación para los productores y comercializadores.

Entonces eso que significa, no es lo que yo digo?, que los programas han de estar adaptados al día siguiente de publicación en el BOE?

porque también pone:

No obstante, los obligados tributarios a que se refiere el artículo 3.1 de dicho Reglamento deberán
tener operativos los sistemas informáticos adaptados a las características y requisitos que se
establecen en el citado Reglamento y en su normativa de desarrollo a partir del 1 de enero de
2024. (es decir, a las empresas que hacen facturas, un quiosco por seguir con el ejemplo.....)

Sí, entrará en vigor al día siguiente de su publicación, pero lo que entra en vigor es la publicación. En el texto habrá que mirar las fechas que indique para cumplir cada norma, que podrá ser la misma o cualquier otra.

Todo esto es hablar por hablar.

Es lo que entendí también. Más bien, que se supone que tu programa ya tiene que estar adaptado, o incluso en vía de adaptación. No creo que nadie, incluso los inspectores de Hacienda, aún cree por estas fechas que los programas informáticos pueden ser perfectos y totalmente seguir las especificaciones en un día cualquiera: esto solo se lo creen algunos comerciales, y los jefes de los informáticos (que no son ellos informáticos).

Pero ¡ojo! es un borrador, que se ha publicado para que lo revisan muchas personas. Y puede ser que (parte de) estas muchas personas se les ocurren que esta disposición siga demasiado dura. O que da demasiado poder a los compradores de programas para denegarse a pagar cuotas suplementarias muy altas en concepto de «actualización a la nueva norma», si el BOE está diciendo que todos los programas cumplen el día de su publicación...

También puede pasar, como ha sucedido con anteriores normas, que Hacienda, en su gran magnitud, decide que el primer año (por ejemplo), no habrá sanciones ejemplares contra tú (y los demás como tú) que están trabajando en la adaptación, intentando cumplir con la normativa publicada en versión 0.7 72 horas antes del decreto, y cuya versión 1.1 estable llegará... un poco más tarde, digamos el segundo año. Siempre como ejemplo, claro.

Como va a estar algo adaptado a lo que no han dicho como, porque bueno, lo que esta en el borrador vale, o la norma anterior, pero no dicen como ha de justificarse nada, es un poco choteo.

Vale, por lo menos han aclarado lo del SII que no entendía el párrafo sobre ello en el proyecto.
También hablan de la factura electrónica que el nuevo proyecto que va a ir integrado en este. Si tenéis información del proyecto de la factura electrónica os lo agradecería.
Aunque no han dado fechas concretas para sacar los aspectos técnicos del reglamento, parece que quieren antes de que llegue Agosto, tal y como suponíamos.
Respecto a lo de la obligatoriedad de que los sistemas estén preparados han dejado claro que en principio es el 1 de enero de 2024 para los que tengan dudaa sobre lo del siguiente día de puesta en el Boe haya dejado dudas
Y por último parece que aunque den las 2 posibilidades de envío o no envío, van a estar más contentos si les enviamos, por razones obvias y mejor "no defraudarles" en este sentido, que de eso se trata de no defraudar.

Saludos

Hoy me he puesto el video "en segundo plano" y me ha llamado la atención algo que han comentado, tal vez porque yo no lo había entendido bien en un primer momento.
Aquí habíamos hablado de que había 2 posibilidades:

Opción a) Guardar la factura en local, firmada, sin enviarla a la administración (evitaba tener que programar nada de envíos en la aplicación -esto había entendido yo-).
Opcion b) Enviar las facturas a la AEAT a medida que se generan.

Yo había entendido que la (opción a) evitaba de tener que lidiar en la aplicación con todo el tema de envíos, pero segun el vídeo he visto que no.

50.50 A partir de aquí explica las 2 alternativas.
51:35 Habla de que la remisión es opcional.
51:40 Hable de algo que es obligatorio en el proyecto (sea cual sea la opción escogida):

"La potencialidad de envío. TODOS los sistemas deben tener la capacidad de enviar. ... de forma que si la agencia tributaria se interesara por un contribuyente, podría llegar a decirle, oye por favor enviame tu registro de facturas del mes de Abril, en este formato legal, y la AEAT lo recibirá y lo tratará. Eso es un requerimiento...
Si el día de mañana por medio de una ampliación normativa llegara a ser obligatorio, en ese caso ya el sistema ya estaría capacitado para realizar el envío..."

Por lo tato me parece claro que se escoja la opción que se escoja, el sistema debe tener implementado todo lo necesario para enviar.

Si así es. Además van a presionar para que se haga el envío, si no tacatá inspección tras inspección o requerimiento tras requerimiento, por que eso es otra, aunque elijas el modo pasivo te pueden hacer requerimientos de que mandes de tal fecha a tal fecha, sí sí enviarlo. Van a ahorrar en combustible.

Si yo también he llegado a la misma conclusión después de ver el video.

Es decir que las aplicaciones obligatoriamente deberán ofrecer la opción de envió de las facturas a la agencia tributaria y el cliente es el que podrá escoger que opción quiere adoptar.

Desde el punto de vista de un desarrollador de una aplicación de facturas, creo que la mejor opción es enviar siempre las facturas a la agencia tributaria y olvidadarse de los problemas de posibles alteraciones de la base de datos, logs, …

En el video en el minuto 64 (1h:03). También afirman que las empresas acogidas al sistema SII, ya están cumpliendo la ley por lo que no deben cambiar nada.

En el caso del SII los usuarios tienen hasta 4 días para remitir las facturas por lo que entiendo que el nuevo sistema también dará un plazo parecido para el envío de las facturas.

Tienes toda la razón, obviamente el sistema está diseñado en este sentido: la vía de menor esfuerzo para el desarrollador debe ser la qué permite a Hacienda tener la «mejor» información posible (de su punto de vista, claro). Si no fuese así, el dispositivo sería mal diseñado.

Añadiría otra aspecto: debe resultar que siga lo mismo para el cliente también: es decir, la vía de menor esfuerzo (y menor gasto) para el cliente debe ser la qué permite a Hacienda tener la «mejor» información posible.

Cambio en la informatica
 

Que pereza tanto cambio que habrá que rehacer en poquísimos años con las nuevas tecnologías (ver estado procesadores cuánticos, quantum cryptography.. ), el sha2, sha3 etc se va a quedar para primero de infantil. Está claro que las inversiones en cambios de equipos que tendremos que hacer en pocos años va a ser bestial, así que si podéis estrujar al máximos los equipos que tengáis para esto del verifactu no os recomiendo el uso de vuestra pasta ni la del kit digital, si lo podéis usar en otros finesque no sea la adquisición para renovar la flota de equipos a no ser que ya sean muy viejunos.

No obstante hay un detalle importante. Con la opción b tienes que remitir las facturas de forma «inmediata» (cada pocos días como máximo). El 15.1 lo describe como «de forma automática». La cual cosa significa para la aplicación que al menos un operador habitual debe tener conexión a internet y un certificado válido para remitir.

En la opción a, si surge la casuística de Hacienda que requiere un envío, no veo obligatorio que la aplicación sigue el mismo modus operandi. Desde luego no lo veo como «de forma automática».
Yo lo había entendido como que en tal caso se hace una operación especial (registrada en la log) de «exportación» de las facturas en el futuro nuevo formato legal, y el fichero resultante esté puesto a disposición (en el 14.2 aluden explícitamente que puede ser en soporte físico, el otro nombre de CD-ROM o llave USB). Y ya no es un operario habitual que lo hace.

Hay otra diferencia de lenguaje: en el 14.2 (página 16) dicen que Hacienda puede recibir copia de los registros (mi énfasis). Cuando en el 15.1 describen la remisión automática como operando sobre todos los registros. Normalmente los que redactan estos documentos prestan atención a estas diferencias de lenguaje. Ahora bien, aquí puede ser que quieren enfatizar la diferencia entre el caso a dónde los registros se quedan oficialmente en sistema de la empresa, cuando en el caso b los registros (parecen ser) hospedados en los sistemas de Hacienda; sería la misma lógica qué en el SII, oficialmente definido cómo los empresarios cuyos libros registros del IVA los llevan Hacienda; pero en tal caso, ¿por qué no usar la misma terminología que para el SII? :confused:

O siga, creo que lo que todos los sistemas deberán tener es un proceso de «exportación» o «generación» de las facturas en el futuro nuevo formato legal (aún por definir).
Yo veo «envío» cómo siendo un proceso más amplio (en mi experiencia del SII, diría el doble).

Puede equivocarme, pero no me parece posible que Hacienda exige de todas las empresas españolas que tengan una conexión a internet que permite enviar registros de facturas cada X días. Pensar en los aislados, los con requisitos de seguridad elevada, los que operan en China (Great Firewall) u otros países con restricción y demás casos raros. Y sí, he leído el artículo 5 del borrador, que podría aplicarse en tales casos; pero... me parece más que sorprendente si resulta tal exigencia.

Esto sí que deberán explicármelo con detalles. Y es que le veo muchísima lógica a la idea. Pero por el otro lado está el texto del borrador...

Para empezar, hoy en día yo no calculo ningún hash (art. 12) ni hago ningún encadenamiento explicito (art. 10.1 ñ).

Claramente la DA3ª nos exime del artículo 8, y no es poca cosa. Pero no dice que estar en el SII significa automáticamente cumplir lo dispuesto en 16.1; con lo poco que sería añadirlo... Así se cubriría gran parte del problema: los registros pasarían a ser los que hemos subidos al SII, Hacienda sería él que encadena, y calcula los hashes (pequeño problema añadido aquí, el 16.3 dice exactamente el contrario). Pero de momento, nada de esto está escrito.

Y luego está el texto del 10.2 (bajo de la página 15). Se refiere a los del SII (vía art 62.6 del RIVA). Dice que sus registros de facturación deben cumplir con lo del RIVA (63.3, que solapan en gran parte lo del 10.1), cómo no puede ser de otra forma; y añade
Si realmente los del SII no debemos cambiar nada, este texto sobraría completamente.

Es cierto que solo es un borrador, puede ser que en el final, hay que esperar, paciencia etc. etc.
qP:-) También es posible que pronto veamos un SII versión 1.2, con todas estas novedades de la ñ) a la r) añadidas en los registros, con fecha de aplicación, por ejemplo, 1/1/2024. :(

Hola antoine0,

No te extrañe lo más mínimo que exijan que cualquier sistema que facture tenga conexión permanente a Internet.
Con TicketBAI, en el País Vasco, es lo que se exige.
En el caso de Álava y Gipuzkoa, las facturas emitidas deben enviarse inmediatamente.
Y en el caso de retrasarse deberán dar explicaciones.

Y es aplicable lo mismo a una gran empresa (esté o no en SII) como a la balanza electrónica de la frutería o pescadería, el TPV del bar o al fontanero que va a casa a hacerte una chapuza (y ya no podrá hacerte una factura con el cuadernillo de facturas del bazar chino): envío inmediato de la factura por Internet.

Eso ha desencadenado la venta masiva de softwares de facturación, TPV y balanzas de frutería que cumplan con TicketBAI.
Te dan una subvención de 60% del gasto que tengas que asumir para adaptarte, pero no te queda otra.
Y en Álava y Gipuzkoa es ya obligatorio este próximo otoño.

Saludos