La facturación es parte de la contabilidad y por ejemplo ticketbai ha empezado por control de las facturas emitidas pero ya han dicho que el próximo paso son las compras, así podrán cruzar emitidas y recibidas, con lo cual más fallos y más ingresos por sanciones para las arcas, el camino ya está andado por muchos, así que la lógica apunta a que se empezará por las facturas de ventas o servicios emitidas

Tendríamos que volver a los años 80, que casi todo seguía llevándose en papel :rolleyes::D

https://www.boe.es/diario_boe/txt.ph...OE-A-2022-1453
Pues ya empezamos. Inspecciones a todo plan.
Una de ellas es Inspección del iva bien repercutido

Resolución de 26 de enero de 2022, de la Dirección General de la Agencia Estatal de Administración Tributaria, por la que se aprueban
las directrices generales del Plan Anual de Control Tributario y Aduanero de 2022.

c) Ejecución, en el entorno de aquellas actividades económicas en las que se
detecte una presencia intensiva de consumidores finales, de las actuaciones de control
que resulten precisas para evitar que se produzca una falta de repercusión efectiva del
IVA en la última fase de la cadena de comercialización.

soluciones digitales integrales para el cumplimiento de las obligaciones de facturación y
registrales y la obtención progresiva por los autónomos y PYMES de predeclaraciones o
borradores de declaración cada vez más completos en la medida en que el sistema de
facturación posibilite también el envío automático de la información a la Agencia
Tributaria.

Lo mismo va a ser opcional, jajajsja
Me río por no llorar.

No creo que esta sistema siga tan malo como lo parece a primera vista. Yo lo partiría en dos: por una parte va la factura que haces hoy en día, identificando cliente, declarando y pagando IVA (que es la que importa a Hacienda, como se ha dicho) y que es la que se cobra (que es lo que importa al cliente y al vendedor). Sola diferencia, meramente contable: para mí es una factura de anticipo.
Luego viene la entrega a los dos meses, con modificación de lo entregado, indicación de lote y números de serie, de paletas etc. Que da lugar a un albarán (que contablemente es lo que constata la salida de existencias).
Pues solo te queda por añadir una segunda factura, al mismo cliente, que recupera el pago y el IVA de la primera, por tanto la segunda factura saldrá con importe a pagar nulo, y contablemente matará la salida. Esta factura con importe cero no tengo claro si se tiene que subir al S.I.I. 1.1; lo que sí tengo claro es que a Hacienda no le importa. Y al cliente tampoco, obviamente.

Evidentemente, haciéndolo de esta manera, el día que tienes una incidencia en la entrega, la segunda factura puede empezar a ser más compleja y a tener un importe (y a declararse, a presentarse, a usarse como abono etc.) Dicho de otra forma: el proceso de esta factura a cero ya lo tienes previsto, es el mismo que si hay que hacer un abono o cosas parecidas; solo que será más sistemático y saliendo a cero, no tiene más recorrido.

Gracias Antoine0 por exponer tu punto de vista. Creo que el tema lo tomaré por ahí. Ahora meto demasiados datos en un registro de factura, y permito meter todas las modificaciones que el usuario necesite registrar con respecto a esa factura, siempre que no se cambie la fecha de la factura, las bases imponibles, cuotas de IVA, retenciones, NIF/CIF del cliente, tipo de factura (venta, servicio, alquiler, rappel...) ni el número de factura (año/serie/numero). Todo lo demás permito que se modifique, ya que aunque la factura esté presentada en el SII, a hacienda le debe dar igual que cambie un producto por otro en caso de ruptura de stock, que registre la fecha en la que el cliente se ha llevado cada uno de los artículos adquiridos, o que registre el nº de serie o el lote del producto que se sirve en postventa... Repito: esas actualizaciones no afectan fiscalmente a la factura. Entonces, para certificar que el software no permite editar ni borrar datos del registro de facturación, sólo me queda sacar esa información del fichero de facturas y crear un fichero paralelo con los datos de la logística asociado a esa factura, que pueda ser modificado siempre que no afecte a la fiscalidad de la factura original, es decir, no quitar/añadir productos o cambiar precios.

Lo analizaré cuando se publiquen las necesidades mínimas que tiene que cumplir un software de facturación.

Creo que es buena idea, eso, tener documentos internos para tu control más específico de stock. En la factura declarada puede ser una descripción más genérica y te evitas de repetir la factura. Ya que si la repites estas obligado a entregarsela al cliente, tanto la anulación como la nueva y vas a necesitar una logística compleja. Y cuando salga el reglamento estoy seguro que harán como los demás, habrá que subir todas las facturas emitidas de todas las series con el número correlativo y además tendrás que subirlas en el mismo orden del numerador, no creo que puedas subir antes la 3 que la 2 y además dentro del orden numérico debe coincidir con un orden cronológico de emisión , eso te va a complicar esa gestión que tienes que primero asignar un número y después la mercancía, que en ese caso tiene que estar seguro que todas los números sean correlativos y subirlos a hacienda por orden se complica, el número mejor asignarlo al cerrar la factura. Es más si lees el reglamento de facturación, esto de anular facturas e incluso de rectificarlas ya es un tema más delicado y si detectan muchas rectificaciones o anulaciones vas a tener a los Sres inspectores muy a menudo, cada vez que les salte la alerta y no creo que pongan a nadie en lista blanca fácilmente. Por su operativa. O sea, vigila:
Contador facturas y hora fecha correlativos.
No hacer facturas con fechas ni horas anteriores a una fecha hora de la última emitida ni a la de hoy y ahora
No hacer facturas con fecha hora futura.
Entregar todas las facturas emitidas a un cliente a su cliente, incluidas rectificaciones, las anulaciones solo se pueden hacer si no se ha llegado a entregar y por motivos de errores recogidos en el reglamento de facturación.
Y ten en cuenta otra cosa, la factura tendrás que firmarla digital mente y encadenar la firma con la anterior, cualquier carácter que se modifique de la cadena rompe la cadena.
Si puedes cumplí todos estos requisitos antes de enviar la factura a hacienda podrás editarlas.
Saludos

Pensad que ya la tendencia es usar tecnología block chain, firmas encadenadas. No caben modificaciones

No hay modificaciones. La primera factura no se modifica nunca; solo se paga, y sirve de referencia para la otra. El albarán, o los albaranes, pueden ser alterados si hay variaciones de entrega, pero esto sí debe ser permitido por la ley (si hay que guardar histórico al respecte, cosa que no me parece lo más evidente que va a pasar, entonces se tiene que guardar todas las versiones; no es problema, los sistemas de seguimiento de existencias ya lo hacen sin problema). Y la segunda factura acaba toda la operación, atando todo junto. Después no se modifica nada; mejor dicho, si hay otra variación más tarde, habrá otra factura rectificativa, también puntual e inalterable. Todo es linear, por tanto la lógica del blockchain no tendrá problema.

Perdona, pero es que no acabo de entender eso de primera factura y después la que modiiffca.
Lo lógico es un recibo de pago y después la factura, o un recibo a cta parcial. Pero 2 facturas para el mismo servicio o entrega de mercancías no es lo normal
Creo que algo no estoy entendiendo bien de la logística que usas.
Saludos.

La verdad es a mi me ha costado entender todo esto al principio, por qué en Francia funciona de manera diferente. :)

En España tienes que pagar el IVA en el momento que pides un pago, y por esto estás obligado a emitir factura. Si quieres que el cliente pague por adelantado, entonces la única forma de hacerlo es emitir una primera factura al pedir. Esta factura no tiene el por qué de describir correctamente la mercancía (lote, referencia, número de serie etc.), ya qué todavía no se ha entregado. Por tanto lo habitual es poner «factura de anticipo», aunque en realidad no hay obligación qué sé de mencionarlo. Contablemente la base imponible de esta factura va en una cuenta especial (438).

Si la operación discurre sin problema, luego habrá la entrega con su albarán, y luego un documento contable que mata la primera factura contra la entrega. Esto documento lista el material realmente entregado, y luego le resta el importe de la primer factura ya pagada; es este documento que llamo factura. Es posible que del punto de vista del reglamento de facturación, no se llame «factura». Pero del punto de visto del informático, realmente se comporta como una factura que cierre una operación de entrega, teniendo en cuenta un pago por anticipo.

Dado que los importes son iguales, la segunda factura sale a 0; y a menudo hay empresas que no la emitan, dado que «no sirve para nada»; el IVA ya está pagado, no entra en esta guerra; y al cliente una factura a 0 no le interesa, por tanto tampoco se le remite (salvo que hay alguna mención que necesita lo contrario, por ejemplo el principio del periodo de garantía). Solo tiene un objetivo, satisfacer al señor contable.

Técnicamente la segunda factura es complementaria de la primera (o al revés, es igual), por tanto no se trata de dos operaciones distintas. Además, hay otros casos dónde vas a tener dos o más facturas para un mismo pedido, como por ejemplo si hay varias entregas (típico de los pedidos por Amazon), o una rectificación de precio.

Ya. Eso es lo que algunas asesorías dicen y otras que no. Que los pagos a cta que van a la 438 cuando haces la factura pones el movimiento contrario en la 438 y listo y no hay que pagar iva hasta que entregues la mercancía. No hay una entrega ni de bienes ni de servicios por lo tanto no es una factura.
Cuando ya se entrega la mercancía entonces si..
Es in tema que hemos visto con varios fiscales y al final parece que con hacer un recibo y llevarlo bien contabilizado es suficiente. Y si tienes algún cliente que te deja el dinero y nunca lo recupera si hay que declararlo, no recuerdo a qué iva.

¡Ya! Lo que tu describes es lo que aprendí en Francia. :) (El número de la cuenta es distinta, 419 o 4191, pero es la única diferencia).
Ahora bien, desde que estoy en España, todo el mundo me ha explicado que hay que pagar el IVA a Hacienda cuanto antes (y desde el punto de vista del residente español que disfrute de los servicios del estado, me vale).

Al final de todas las maneras para nosotros va a ser lo que decide el cliente, en base a sus relaciones con Hacienda (en aquel momento) y sus asesores.
Entonces veo varias posibilidades, y intento hacer que todas, o muchas, se pueden cubrir con el esquema general. Y el caso de afxe me pareció entrar en mi esquema; desde luego prefiero mi solución a tener que modificar los datos de una factura.

Vaya tela, me estoy releyendo foros fiscales y parece que todos dicen como tú, 438 de puente y emitir factura inmediata.
Al final los temas complejos de asesoría no se puede fiar uno de muchos asesores y hay que releer reglamentos . Pero es la leche, hay que tenerlo en cuenta para la 438 después descontará de la factura y generar el movimiento contrario en 438 y si cambia el a cuenta aún más movimientos. Tela para comercios pequeños

Esto no es del todo cierto. El artículo 75 de la ley 37/1992 del IVA dice que si se recibe pagos anticipados hay que hacer obligatoriamente una factura por el importe percibido:
Contablemente, puedes llevar una 438, o no, solo depende de si la factura final la haces por el importe pendiente o la haces por el total y descuentas lo que te ha entregado. De locos....

Pero no hay nada nuevo entonces....?

Sobre la nueva reglamentación nada

Sobre la nueva reglamentación de software en los temas de trazabilidad de registros etc... nada

Y entonces de que hablan?, algo concreto o sólo las multas a autónomos aunque lo hagan bien?

Saludos.

Hay que tener paciencia, estas cosas van despacio porque son muy complejas de poner de acuerdo a todo el mundo. Ya avisarán, y entonces será el momento de preocuparse.

Unas preguntas, sobre todo para los que ya tienen experiencia con TicketBAI.


1. ¿De que forma se organiza este sistema para tener en cuenta (por ejemplo) la imposibilidad de enviar los datos si te quedas sin internet, fallo de ordenadores, etc.? ¿Hay que comunicarlo, hay que enviarlo después, ....?
2. ¿De que forma se trata a aquellos obligados tributarios que no tienen un ordenador o tpv físico?, por ejemplo gente que trabaja en mercadillo, muchas veces sin acometida de luz.
3. Parecida a la anterior... ¿de qué forma tratan a los que, por ejemplo, tienen una tienda o negocio en un pueblo de montaña con una comunicación por internet casi nula?.


Gracias!

Puede que te contesten mejor en el hilo sobre el tema: Ticket BAI

Ah, vale, gracias.

Contestada en el foro;

Por favor, revisa la Guía de estilo y no repitas preguntas en varios foros.
https://www.clubdelphi.com/foros/sho...postcount=2755

Primero y tercer casos igual, se van metiendo en una cola de envío y se envían en orden Fifo cuando se restablezca el servicio
Segundo caso no lo he mirado mucho. Pero creo que se puede solicitar otras formas de cobro si se puede demostrar que es imposible cumplir normativa. Teniendo en cuenta que hay muchas herramientas y programas que funcionarán a través de una tablet con batería.
En caso de fallar todo de manera temporal te dimiten usar unn talonario de facturas con números correlativos en el que se detalle el motivo de la imposibilidad, avería en cualquier caso, y previamente informando a un correo de la hacienda de cuando pasó y cuando termine igual, y cuando se vuelva a tener en marcha el programa meterlo en el mismo orden y dar o enviar al cliente que lo solicite la factura ya mecánizada.
Más o menos parece que han cubierto todo (por supuesto con sus complicaciones)

Gracias por las respuestas!

Hola,

Ya se ha abierto el plazo de presentación de observaciones al proyecto de RD del Reglamento de Digitalización Facturación por parte de la Agencia Tributaria.
Podéis ver el texto en https://www.hacienda.gob.es/Document...talizacion.pdf
La cosa va a traer cola ... para nosotros.

Saludos

Gracias por la información.

Sí alguien se ha leído las 79 páginas y puede hacer un resumen, se lo agradecería.

Son 19 páginas, no 79 :D
El resumen:

Cuñu.... ya podían haber dado algo más de plazo a ver si me daba tiempo a jubilarme. :D:D

P.6 cáp. VII:
Hay que certificar los sistemas, pero cada uno puede hacer lo suyo.

p.8 DF3ª
O siga, hay que considerar que este documento de «consulta pública» es realmente exponer lo que será aplicable a los desarrolladores informáticos a los dos días de la aprobación. Ese día, los antiguos sistemas, no conformes, serán ilegales a la venta e instalación.

El mismo articulo sigue con
Para los clientes, hay tiempo :) hasta 2024. Tenemos un año y medio para desarrollar y poner en marcha sistemas nuevos de facturación. Una nueva versión del Año 2000 + euro.

p.9 art.3.1
Todo el mundo está afectado; hasta el vendedor del mercado.

p.11 art.6
Los operadores del cloud podrán competir también.

p.11 art.7
Habrá una aplicación web de Hacienda para el «vendedor del marcado» arriba y demás.

p.11 art.8.1
Se remite información en tiempo real de las facturas a Hacienda.

p.12 art.8.2
Solo se pueden grabar facturas de una sola vez

Nota mía: esto no es demasiado detallado, yo pienso que va a ser precisado más tarde.

(Esta también se veía venir)

art 8.4
La log debe ser extensa (y encadenada, e inalterable, y se puede consultar por Hacienda, por supuesto).

p.13-14 art.10 Contenido del registro de facturación de alta.
A 1ª vista todo lo que está obligatorio en una factura, más la fecha-hora (timestamp) y las demás cositas informáticas que son de esperar.

p.15 art.11 Generación y contenido del registro de facturación de anulación.
Las anulaciones de facturas están previstas. Aparte.
Nota mía: no he visto menciones de las rectificativas.

p.15 art.12. Huella o «hash» y firma electrónica de los registros de facturación informáticos.
Aún no está claro qué hash usar...

+ Firma electrónica, excepto las facturas «verificables» que se remiten automáticamente a Hacienda.
Éste sistema «verificable» no está completamente definido.

Disclaimer: no soy letrado ;) este resumen solo es mi entendimiento a la luz de una 1ª lectura rápida del documento. Por favor léanse el documento por completo si están afectados. No son 79 páginas, solo son 19 y las 4 primeras son muy poco interesantes.

Cuidado aquí: es cierto que para los clientes (usuarios finales) la fecha tope sería 2024 (que vendrá muy deprisa). Pero el mismo artículo dice

Y los del artículo 3.2 son los que fabrican y comercializan los sistemas, es decir, los informáticos. Que se supone que son los que leen este foro...

(Vale, es cierto que para los programadores del Open source, no es de aplicación.)

Pero lo mejor es esto :)

"Los obligados tributarios que ... utilicen sistemas informáticos para el cumplimiento de la obligación de facturación ".
Pues nada, a no usar sistemas informáticos, mejor esto:

Primero muchísimas gracias por la información.

El documento (PDF) está fechado del 21/02/2022 12:35:08. Sin embargo, en el texto de la página 7 (parte no normativa), 2º parágrafo, se lee:
No es que me importa presentar observaciones o nada, pero se deduce del texto tal cual que ya está cerrado el plazo de la consulta pública. No estoy muy al tanto de las maneras de la administración Española, pero tengo la idea que pudiera ser un defecto de forma ;)
En realidad la fecha tope es el 14 de marzo de 2022.

La cuestión, al final, es, ¿qué plazo debemos esperar para la presentación del proyecto en Consejo de Ministros y posterior aprobación? (a no ser qué vaya a pasar por la vía parlamentaria previa, pero no lo creo, no se estila hoy en día). ¿Diciembre? ¿Junio/julio de 2022?

Buff, yo veo 2 cosas complicadillas para según que tipo de negocio:
Será obligatorio tener preparado el software para el envío inmediato de las facturas antes o la vez de su generación, espero que no sea obligatorio por que en sistemas lentos o con comunicación lenta (por ejemplo zonas con router de datos por 3g-4g) los clientes se pueden cabrear por una espera indeterminada de varios segundos, si además le añadimos un sistema de facturación centralizado con varios dispositivos generando facturas a la vez y hay que enviarlos en oden fifo.. Buff
Por otro lado el tema de las logs garantizado inviolabilidad etc, que eso nos lo dejan a nosotros, claro ahora en sistemas que no contemplen esa automatización en sus bases de datos búscate la vida y rompete la cabeza y que lo que hagas este dentro de los parámetros que ellos piensan que son inviolables. Por que yo puedo pensar que enviarle los datos a un webservice firmado puede ser suficiente, pero me pongo a pensar la de los logs que se generan según lo que piden y son muchísimos más datos que las facturas.
Los routers van a Petar del calentón y me veo un sin vivir todo el día acojonados con las averias

Creo que se contemplan dos clases de sistemas:

1. por una parte sistemas con buena conexión, con los cuales se suben los registros en directo a Hacienda; son los que llevan una buena conectividad (en base a las esperanzas de los clientes); estas facturas son las que son «verificables», indicadas con una mención VERIF*FACTU especifica, a las cuales son de aplicación el capítulo III artículos 15 y16
2. por otra parte las facturas donde los registros no se suben de inmediato; entonces no es un problema si tu conexión no te da tiempo a subir las facturas a Hacienda. La contrapartida: estas facturas se tienen que firmar electrónicamente (artículo 12, 2º alinea).
3. además está la aplicación web de Hacienda (que tienen los mismos requisitos de conectividad que las del 1.)