Orden del QR
 

Sinceramente no veo cual es el problema de imprimirla en la primera, en la última o en todas.
La NO Ley porque todavía no es Ley hasta que salgan todos los detalles técnicos, en sus prolegómenos indica que el DOCUMENTO debe llevar un QR que por cierto tampoco hay indicaciones de qué datos debe llevar. En uno de sus weminar aparece un QR y si se lee puede ver un pequeño puñado de datos. Que se le supone van a ser los definitivos.
No sé si se refiere a que en sus algoritmos sólo puede tener el número de documento y la serie al final de la impresión o si no puede imprimir el QR hasta el final. No veo cual es el problema de imprimirlo al final si así lo desea. Es el documento el que lleva el QR asignado. Al igual que puede imprimir lo acumulado de los importes en cada página previa y en el final los totales generales o solo imprimir totales generales al final.

Al menos tal y como yo lo veo es indistinto.


Un saludo.

Igual lo tengo mal entendido, pues... si finalmente voy a utilizar el sistema VERI*FACTU, debo enviar los "datos" de la factura, importe, cliente,y los que me solicite el sistema, y es hacienda quien se encarga de la guarda-custodia, trazabilidad, firma, huella... con lo que me responde con una huella que una vez disponga de ella, SI puedo imprimir la factura, pues se da como válida.

¿De qué me serviria imprimir una factura de la que no dispongo del registro OK de VERI*FACTU y su huella???

Vaya, es como veo yo que debería de trabajar mis datos para ahorrar fallos o errores.

Siempre todo esto asumiendo que el funcionamiento va a ser similar a TicketBAI (que parece que si).
Imagina una tienda cualquiera que genera tickets cuando compras una barra de pan, una prenda de ropa o cualquier otra cosa; Y que en ese momento se cae la conexión a internet o simplemente durante esa mañana tu operador ha tenido una incidencia y no tienes conexión.
¿No vendes? ¿No generas tickets/facturas?

Se asume que tus facturas son correctas y por eso para generarlas no necesitas conexión a internet o conexión con la AEAT.

Si la tienes bien, las envías, pero si no la tienes tu sistema DEBE seguir funcionando con normalidad y deberán "encolar" esos envíos para cuando puedas comunicarlas.
Es una de las premisas.

Si luego por lo que sea tu factura es incorrecta, pues deberás rectificarla y comunicarlo a la AEAT.
Entiendo que si es un cliente al que le puedes "reenviar" la factura corregida (como se hace ahora), pues se la enviarás de nuevo. Y si es un cliente que se ha ido con un ticket, pues en ese caso no creo que se pueda hacer nada.

Código de retorno
 

No creo que la AEAT suministre un código de retorno para identificar cada documento que se le envíe.
Si así fuera sería un cachondeo. Por un lado la AEAT dice que esperemos a tener 1000 documentos para hacer un envío o bien que pasen dos horas antes de enviar lo acumulado.

Me imagino que una gran superficie o simplemente un supermercado de tamaño medio, o una ferretería, o una muebleria, o.... tengan que esperar para imprimir un ticket a un cliente dos horas.
Sería sinceramente un puro cachondeo.
Los datos del QR no tienen nada que ver con un código de retorno. Y menos mal !
Al menos es como yo lo veo.


Un saludo.

Dictamen del CES (Consejo Economico y Social de España)
 

Aunque este dictamen versa sobre la Facturación Electrónica, hace varias puntualizaciones que creo que nos afectan. La que me parece más significativa es:

"El CES considera necesario que el Proyecto de Real Decreto garantice de forma explícita la coherencia con la propuesta de la Comisión Europea “IVA en la Era Digital”, "VAT in the Digital Age" en inglés, publicado el 8 de diciembre de 2022, y cuyo objeto es modernizar el sistema del iva de la Unión Europea, abordando los retos relacionados con la economía de plataformas e introduciendo un registro único a efectos del iva para evitar registros múltiples dentro de la Unión Europea. De esta forma, el sistema de declaración del iva para las transacciones transfronterizas de la Unión Europea se basará en la facturación electrónica y en la norma europea de facturación electrónica, y además a los Estados miembros que deseen establecer un sistema de declaración del iva para las operaciones nacionales, se les exigirá que también lo basen en la facturación electrónica. Así, la facturación electrónica se convertirá en el método de facturación por defecto antes de enero de 2028."

Según entiendo yo, va a ser la Facturación Electrónica el punto de partida también para la declaración del iva, y no temas independientes y separados. Esto me genera aún más confusión.
¿ Que pensáis vosotros ?

Podéis verlo en el siguiente enlace:
https://www.ces.es/documents/10180/5.../Dic032024.pdf

Ley crea y crece vs ley veri*factu
 

Son cosas paralelas y no excluyentes. Al igual que lo es el SII (sistema de información inmadiato)


Aquí cada cual va por su lado. Por un lado se saca la ley "antifraude" o veri*factu para conocer lo que a la AEAT le interesa que no es mas que los importes del IVA, las bases imponibles para hacer cálculos de beneficios y que nadie pueda "extrapolar facturas".
Eso ya lo había hecho con el SII para empresas de un cierto volumen de operaciones. Aunque el veri*factu es mucho mas restrictivo. En mi opinión el SII se eliminará y quedaremos todos en el veri*factu.
(Es solo una opinión particular aunque algo parecido escuché en un weminar de la AEAT al respecto)


Otra cuestión bien distinta es la denominada "ley crea y crece". En teoría es para que no se disparen los cobros y lo pagos en sus vencimientos respectivos. Esto lo promueve el Gobierno. NO sé donde ha quedado esa Ley de 60 días máximos de pago en los mismos estamentos del Estado. Otra cuestión que en teoría se persigue es automatizar los procesos de entrada y salida de documentos de forma semiautomática. En mi opinión solo sirve para contabilizar facturas de compra puesto que los procesos de entrada, pedidos y albaranes, son procesos previos a la emisión de la factura por parte del proveedor. Así que no se podrá verificar nada, salvo que la factura tenga las mismas condiciones que el albarán.
La AEAT se ha prestado "desinteresadamente" para crear un portal con los webservices necesarios y el archivo de las facturas obligatorias.

Por lo tanto se perfila mas que como un sistema de automatizacion, como un sistema de control, no solo de los cobros y pagos sino también de la totalidad de la factura. Precios, ofertas, condiciones, zonas, proveedores, tipos de artículos, etc.etc. Con todo lo que esto conlleva.
En estos modelos van a hacer su agosto algunas plataformas de intercambio automático entre diversos tipos de facturación electrónica. Aquí si hay ya intercambio de pedidos, albaranes, tarifas, etc. pero el costo es algo abusivo, al menos para la mayoría de empresas.



Para terminar, al final se terminará por anular la factura electrónica de cada país miembro de la Comunidad Económica Europea y se tenderá a un solo sistema unificado. Que de hecho ya hay, pero sin obligación por el momento de usarlo en cada país. NO recuerdo ahora mismo si este formato es el que hay que usar para las facturas intracomunitarias. Tendré que revisar la documentación, pero creo que de momento no.



Disculpe, ese PDF ya lo leí en su día y antes de contestar no lo he leído de nuevo. Hablo pues de memoria, por si se me escapase algo.


La opinión personal tal y como vd demanda no tiene mayor importancia. Eso es lo que va a ocurrir en breve.


"Cosas mayores veréis, amigo Sancho" :)



Un saludo.

Mmmm. Un organismo emite un informe sobre un proyecto de texto (que se redacta desde 2022, y posiblemente antes), para criticar de forma velada que este proyecto no está suficientemente alineado con una propuesta de directiva de la Comisión (en tramites de adopción). Me parece correcto que lo haga, pero no veo en qué nos afecta.

Luego si se lee la propuesta de la comisión (COM(2022) 701 final), se ve que hay una diferencia importante entre las facturas intracomunitarias, dónde la comisión quiere que pasen al 100% electrónico, y las facturas nacionales (donde la comisión no tiene las mismas competencias, si leo bien), donde se dice que hay que «modernizar las obligaciones de notificación a efectos del IVA mediante la introducción de requisitos de notificación digital, que normalizarán la información que deben presentar, en formato electrónico, los sujetos pasivos a las autoridades tributarias sobre cada operación» (1º parágrafo 3ª página, en la exposición de motivos).
Para mi, esto suena muchísimo más a SII o Veri*factu que a facturas electrónicas tipo Factura-e.
Entonces estoy en desacuerdo sobre el texto que has puesto en negrita: para mi entender no se exige pasar a la facturación electrónica en nacional; y no veo que será por esta razón si la facturación siga electrónica por defecto en 2028.

Ahora bien, entiendo que se está generando confusión.
Y lo veo así desde el principio, cuando surgen casi al mismo tiempo dos normas, con objetivos similares pero distintos, con implementaciones también distintas (hasta el punto que con lo que hay actualmente sobre la mesa, cada factura se debe declarar dos veces a las administraciones públicas, la cual cosa parece una locura), viniendo de dos ministerios distintos.
Y creo que la clave está en lo último: detrás de esto hay luchas de poderes.

Estoy de acuerdo, lucha de poderes, pero el objetivo más fuerte no es tener acceso a la información que enviamos a uno u otro ministerio, es algo mucho más antiguo, lo han colado en la ley anrifraude y apenas le hemos prestado atención, es tener libre acceso al domicilio del sujeto pasivo para revisarle la contabilidad(el software), sin tener que depender de una orden judicial.
En ello están ahora las asociaciones de empresarios en denunciar esto.

Buenas, alguien ha podido revisar los cambios que han subido hoy?

Yo he descargado y revisado los 2 documentos.

En el DRAnexoOM_RD1007 vers. 0.13.1, en la pag. 0, como siempre aparece la lista de supuestos cambios en el resto de páginas, pero no se si estoy ciego pero no veo a que hace referencia.

En el documento de Validaciones y Errores, explica más concretamente que permiten algunos campos, como y cuando rellenarlos y también detalla algo con respecto a las "altas" y "anulaciones", que yo no había visto antes. Concretamente dice que, aunque en un mismo envío VERI*FACTU, se pueden incluir ALTAS y ANULACIONES, deben estar en diferentes bloques de "RegistroFactura", es decir, hacer como mínimo, un bloque de "RegistroFactura" para los "RegistrosAlta" y otro bloque de "RegistroFacturas" para los "RegistroAnulacion". No me queda claro si los puedo ir alternando según se hayan generado las facturas o debo agruparlos en 2 bloques para enviarlos. Esto lo puedes ver en el apartado "3.1.2 Validaciones de negocio del bloque RegistroFactura" del PDF de Validaciones.

Hay más validaciones que aclarán las posibilidades de algunos campos.

Un saludo.

Gracias
Van soltando poco a poco para que no nos aburramos;)

Firma digital
 

Usando algo de ironía le daría la razón. Pero creo que los tiros no van por ahí.

Cuando ya tienes algo hecho van y te fastidian el código. Como si se disfrutara de tiempo libre o si esto fuese un jobi.
O no lo tienen claro o demoran el tiempo para que coincida con la implantación in-situ en los clientes.
Personalmente nunca entendí que los desarrolladores tuviesen que tenerlo antes que los clientes. ¿ Cómo se puede hacer para tenerlo listo antes y no seguir actualizando a los clientes ? Y si se actualiza a los clientes entonces ya estarían obligados.



Aparte de esta discusión que tampoco lleva a ningún puerto, ¿ alguien está trabajando en firmar el xml ?
No me refiero a usar la firma digital para el canal de comunicaciones del webservice sino a la firma en el propio xml.

En el documento sometido a trámite de audiencia e información pública el 4 de enero de 2024 en la página 18 artículo 14 se habla de firma electrónica de los registros de facturación.

No detalla ni especifica si es para NO verifactu exclusivamente. Entiendo que sí. Pero aunque no se requiera en verifactu, ¿ alguien lo va a usar ? ¿ Sabe como hacerlo ?
No encontré ninguna información al respecto.


Un saludo.

Con respecto a las fechas diferentes para desarrolladores y clientes, supone llevar paralelamente 2 programas, uno el que puedes instalar a los clientes hasta la fecha de entrada en vigor para ellos, y otro el que vas desarrollando con todo lo que necesitas incluir para cumplir la OM.

En el documento que publicaron de preguntas realizadas en el último webinar, dejan claro que la firma de los registros de facturación SOLO ES PARA NO VERIFACTU.

Por último comentar que, hasta hace poco en mi empresa se pretendía desarrollar una aplicación DUAL, es decir, para VERIFACTU y para NO VERIFACTU, pero con los últimos cambios que están introduciendo en todos los diseños y en la operativa, así como en la problemática de que el cliente sea el depositario de los Registros de Facturación, perdiendo los desarrolladores el control aunque no parte de la responsabilidad, estamos prácticamente decididos a desarrollar la aplicación como SOLO VERIFACTU, con la única salvedad de controlar la posibilidad de que el OT esté excluido de presentar los registros, como por ejemplo si está sujeto al SII.

Firma digital
 

Gracias por su respuesta. Llevar dos códigos de soft en paralelo es bastante costoso. Al menos para nustra empresa.

No tengo claro si al final voy a sacar el soft dual o no. De momento intentaré cumplir toda la normativa del modelo dual. Seguramente bloquearé los ejecutables para que solo soporten verifactu. Pero dejo la puerta abierta a utilizar NO verifactu en un futuro si el mercado así me lo exige. Si esto sucede tendré dos versiones, una dual y otra no. Mas que nada será la misma versión bloqueada para que nadie se pueda columpiar con los datos y diferenciada en sus identificadores. Desde luego no voy a asumir directamente la responsabilidad de la custodia y no alteración de los datos de ningún cliente. En último recurso habrá que hacer un contrato, etc.etc. Los abogados saben de eso. Pero poner mi pequeño patrimonio en una balanza para cumplir los caprichos de un cliente, ni de coña.

Si tiene nociones sobre como usar una firma digital en el xml me sería de gran ayuda. O si usa algún producto del mercado para tal fin.



Gracias.

Podéis revisar, si os queréis hacer una idea, el sistema de firma que se usa en TciketBAI (firma del XML) que imaginamos que va a ser similar a la que nos pedirán aquí.
Así podéis haceros una idea de los diferentes sistemas o componentes (SecureBlackBox , TElXMLSigner, Autofirma, Chillkat,...) que se pueden usar para firmar un XML y ver también algo de código.
Revisad este mensaje en la parte de Firmar XML.

NOTA DEL MODERADOR: Lo que si os pido es que no mezcléis referencias de ese hilo -TicketBAI- en este; Que nos sirva como consulta, pero hasta que no podamos discutir aquí sobre la firma en LeyAntifraude, no hagamos suposiciones ni demos por hecho que va a ser igual que allí (gracias).

Firma digital
 

Voy a echar un vistazo.
Gracias. ^\||/

No sé si me estoy perdiendo algo pero yo veo claramente que los programas hay que prepararlos para ser VERIFACTU y simplemente poner una opción para que los registros se envíen de forma automática o no. De esta manera el que quiera que envíe y el que no que tenga una opción para enviar los registros (entre fechas imagino) si se los requieren.


Saludos.

no es así del todo.
con verifactu NO tienes que firmar el xml , simplemente lo generas y se lo envías a la AEAT, de manera mas o menos inmediata
sin verifactu SI que tienes que firmar el xml (como hace ticketbai) , guardártelo , y enviarlo a la AEAT cuando lo soliciten (y encima la responsabilidad es tuya como comentan los compañeros)
Por eso al final siempre va a ser mejor con VERIFACTU, ya que haces el xml (sin firmar), envías y listo

No verifactu
 

Sinceramente creo que se está perdiendo en un laberinto de normas. NO verifactu es mucho mucho mas restrictivo que verifactu. Encima el responsable de la autenticación, conservación y verificación de los datos del cliente es usted no su cliente.
Se firman los registros en NO verifactu, en cambio en verifactu no.
Se firman los eventos. Los requerimientos de la AEAT van a ser continuados, etc.etc.etc.

No tengo a mano ahora mismo toda la documentación al respecto pero ante la duda yo también aconsejo usar "solo verifactu". Opción en la que se renuncia a usar NO verifactu. Si el programa tiene las dos opciones debe cumplir la mas restrictiva que es NO verifactu.
En mi anterior comentario he aludido a que generaré dos ejecutables. Uno para dual verifactu / NO verifactu y otro ejecutable para solo verifactu. Solo verifactu es apriori el que pondré en producción.

No sé si al final sacaré el dual a producción porque tengo serias dudas de la responsabilidad que puedo adquirir, inclusive teniendo precios significativamente mayores para dar dicho soporte que tal vez no me compense el esfuerzo y riesgo.

En mi opinión debería leerse la documentación de la AEAT antes de poner en producción su proyecto. Mi consejo es que se acoja a solo veri*factu si tiene dudas.


Un saludo.

¿ Hay alguna forma de controlar que una empresa está en el SII para que el programa no envíe las facturas ya que se enviarán en 4 días como muy tarde? y en caso contrario (no están en el SII) qué lo envíe inmediatamente. Actualmente nuestros clientes son los que nos dicen que tienen SII y le activamos el módulo de envío, pero el envío es manual. El cliente un año puede estar en el SII y al año siguiente no.

¿Cómo lo tenéis pensando vosotros? para que el programa siempre funcione en verifactu pero tenga esa excepción con los del SII y no haya un control manual por parte nuestra. Gracias!!