NO es raro
 

Hace ya algunos meses que se hacen los suecos para contestar o te remiten a alguna norma o anteproyecto que tengan publicado.
No se pisan las uñas. Imagino que de algún modo querrán coordinarse también con la futura ley Crea y Crece de factura electrónica.

De todas formas hay mucha información disponible. Vídeo, preguntas y respuestas, boe, definición de servicio web, excell con formatos, etc.

Noticias frescas https://www.agenciatributaria.es/AEA...olladores.html

Gracias keys
A ver que nos encontramos.:confused:

Nuevo Formato
 

Veo algunos cambios, los más importantes que veo son estos:
* Nuevos Nodos
Subsanacion
RechazoPrevio

Hay que esperar que nos expliquen si estos se encadenan y como, además los conceptos se entremezclan, por que el de subsanación es muy parecido al de rechazo previo, pero no se si cuando te rechazan hay que marcar los 2 una vez subsanado. Tendrán que aclarar y poner ejemplos o cambiarlo. Por otro lado ¿Como se encadena este registro, justo con el anterior generado en el orden secuencial actual?


*Nuevo Nodo
Macrodato
Identificador que especifica aquellas facturas con base o importe de la factura superior al umbral especificado. Este ...
A ver si alguno sabe para que puede ser


Por otro lado, han informado que el calculo del hash lo harñan sobre una parte del contenido que ya informaran, tambén han cambiado el nombre de algún nodo, otros nodos lo han cambiado de sitio y otros lo han eliminado.
No voy a tocar nada hasta que pongan el Wsdl o el Xsd por que aun no lo veo.

Esto existe ya en el SII. Es para evitar errores con consecuencias.
Cuando tienes una factura con un importe muy grande (100.000 € en el SII si no recuerdo mal, el importe es parametrizable de aquí la redacción poco esclarecedora), tienes que documentar este nodo para significar que S(í), el importe es grande pero está comprobado que es así.

Duda Nodo ClaveRegimen
 

Hola. A ver si me podeis ayudar con la clave de Régimen
ya que lo normal es 01 pero si tiene recargo de equivalencia es 18,
mi duda es si el contenido de la clave 18 va el nodo del iva y el nodo del recargo o hay que crear 2 nodos de DetalleDesglose: 1 para el iva y otro para el recargo
Gracias

Por cierto han cambiado el numero, en la anterior version era el 15. Miedo me da cada vez que hacen un cambio, hay que revisarlo todo.

mas consultas
 

Ayer hice una consulta para certificar que el esquema que uso de un XML en una tabla de cabeceras con todos los datos que exige la AEAT, además de los hases si cumplirá normas o si bien debería usar tablas paralelas para el registro con los datos de la AEAT y me contestan que esté atento. Que toman nota de la consulta ¡ Y solo quedan 7 meses !
O sacan rápido la información definitiva o a alguno se le acercará de pronto la edad de jubilación.
Es cierto, ahora el hash se hará por partes y no por la totalidad. Aunque ahora no exigen firmar los xml a los que se acojan solo a veri*factu supongo que el tema queda abierto para un futuro.
Tampoco sé si los requerimientos son exportaciones de los xml de las altas, anulaciones y eventos que luego se suben a su portal web o bien habrá webservices para tal fin.

Todavía no hay un servicio de pruebas tal y como hubo en su momento con el SII.

Han relajado algo las normas para los NO Verifactu pero el hecho de que el productor informático sea el responsable de los datos del cliente durante 5 años es para pensarlo. Por mi parte intentaré cumplir con los requisitos de los dos modelos y decidiré a última hora si sólo me quedo con el veri*factu.
He visto que ya hay gente trabajando en el QR. Veo datos que se usarán en la página de la AEAT para consultar si hay el documento registrado pero no veo todos los detalles que debe tener la etiqueta. (tamaño, otros datos mas además de los que se usarán para la consulta de la página) Por otro lado la AEAT devolverá un código con cada factura que se suba por el webservice pero, además de que se archive en las tablas, ¿ se usa para algo ?
Si debe estar en el QR tenemos un problema a la hora de expedir cualquier tipo de factura incluida la simplificada puesto que no siempre pero a veces falla internet, o el router, o un switch, o la propia AEAT. ¿ Se paraliza entonces la expedición de tikets ? (simplificadas)

¡ Esto va lento !

Entiendo que así es
 

De todos modos puede darse el siguiente caso de factura por partes : Le haces una factura a un empresario que tiene dos partes separadas, una con recargo y otra sin el. En el caso de que el material lo asuma la empresa deberá llevar recargo de equivalencia si está sujeto a ello, en el caso de un gasto particular no.
Como esto va asociado a cada base y tipo de iva no será un problema. Es lo mismo que una factura con una parte exenta y otra no.

Hola,

Te contesto a esto último:

Supongo que será como en TicketBAI: el software genera los hash, firma el XML (en Veri*Factu no será obligatorio) y genera el QR.
Y ya tienes la factura emitida e imprimible con su QR.
Para ello no se precisa ninguna conexión con Hacienda.
Aparte, inmediatamente, debe enviar la factura a Hacienda.
Por lo que oí en una de las charlas de la AEAT, si no se puede enviar por problemas técnicos, habrá que enviarla más tarde (cuando se pueda) marcando en un determinado campo que se envía con retraso por incidencia.

No paralizas en ningún momento la emisión de facturas (ya sean completas o tickets)

Saludos.

En el envío así es
 

Sí, en lo del envío ya sé que es así. Lo único que lo descuadraría es si hay que usar el código que devuelve la AEAT para integrarlo en el QR. Imagino que es como en el ticketbai.

Mas campos y mas campos
 

Hay campos que estarán en el XML y que apriori no se están metiendo en cada registro de cabecera de facturas.
Por ejemplo el nif de la empresa expedidora y su nombre. (hablo de mi caso particular, claro)

En cambio si se está metiendo los datos del fabricante y del software en cada cabecera.
La pregunta es, ¿ debería estar también datos de la empresa expedidora de la factura ?
Se entiende que son datos redundantes, ¿ no ?
Lo que la AEAT quiere es ver que no se han tocado los datos que figuran en el XML del que se extrae el hash y por ende el encadenamiento. Pero se sobreentiende que la empresa no puede cambiar.

Como que quedan 7 meses?

No eran 9 meses a partir de la publicación definitiva de la Orden Ministerial, que yo sepa no se ha publicado todavía no?? O si?
No ha empezado la cuenta atrás de 9 meses no?

Gracias

Siguen quedando 9 meses. Cuentan desde que salga la orden ministerial definitiva.

Los cambios vienen de momento solo en el xls, el pdf de 55 páginas sigue siendo el mismo que había o lo estoy mirando mal?

pfff una ensalada de números
 

Si, se me fue la ensalada de números que llevo estos días en la cabeza a pensar en lo que salió en enero de este año.:eek:

En fin, mirar el Real Decreto 1007/2023 del 5 de diciembre. Yo entiendo que comienza ahí. Y que lo siguiente que se espera es el susodicho proyecto de orden ministerial que se estipula del 3 al 24 de enero del 2024.

https://www.agenciatributaria.es/sta...tEEDD-ONIF.pdf

Eliminacion de CE
 

En la nueva especificación de la hoja de cálculo se han eliminado las referencias a C-E o el archivo general de los que no se acojan a veri*factu. Con lo que intuyo que todo va al "mismo paquete".

Quedan 9 meses... si ¡sacan la OM hoy! :rolleyes:

Pues entonces mejor, porque al ritmo que van nos dan las uvas y aún siguen con las definiciones.

Cada fin de trimestre pienso: "ahora la sacarán", ahora mismo pienso que la sacarán después de semana santa y cuadrará con el inicio del año, pero sigue retrasandose... deberían poner un psicólogo del verifactu para todos nosotros

En las facturas no hay que poner ningún dato que te devuelva hacienda. Todo lo que pones en el qr lo puedes hacer offline o a través de un tercero que te genere el xml. El qr estará compuesto con partes del fichero xml que generes. Pero hacienda no genera nada de lo que le das al cliente/receptor de factura.
Los asesores fiscales también están creando confusión con esto, sup0ngo que ellos tienen su foro en el que comentan esto y se ha generalizado que hacienda tiene la factura antes que el cliente y es al revés y que en la factura hay que poner un dato que te dan ellos, eso es incierto y crean una gran confusión, a nuestro asesor lo corrijo constantemente con esto y lo he dejado por imposible.

Gracias. En este caso me viene muy bien,.

Gracias.lo tendré en cuenta para avisar que tiene que hacer 2 facturas:D. No me voy a complicar, además no creo que se nos dé el caso nunca . Pero gracias por la explicación, me viene bien saberlo.

Buenas,
Tengo una duda y es que si envío todas las facturas vía verifactu......¿que pasa con las facturas que se hagan a la administración y que hasta hora se enviaban por face ? Puedo crear dos series de facturas y enviar las de la administración por face y el resto por verifactu?


Gracias

Tienes que enviarlas a ambos lados
La de verifactu son el reporte fiscal y fac es para que te paguen.
Más adelante, con el desarrollo del punto de las facturas electrónicas de la Ley Crea y crece se verán algunos cambios en cuanto al control de las facturas, quieren controlar la morosidad, pero me resultaría raro que sancionarán tb los retrasos de pagos de las administraciones a los proveedores, esperemos que haya equidad en el control.
Bueno lo dicho
Verifactu : reporte fiscal a Ministerio de Hcienda
Face: envío de facturas a administraciones controlad/coordinada a por el Ministerio de Economía.

Una cuestión nada tiene que ver con la otra. veri*factu es un sistema que crea la AEAT para tener el registro de iva a tiempo real (o casi). La factura electrónica actual no la gestiona la AEAT. La nueva factura electrónica tampoco. Son cosas paralelas. Aunque si bien es cierto que el depósito de las facturas electrónicas futuras estará dentro de las instalacones de la AEAT. Pero no es lo mismo.
Aunque no lo menciona el caso del SII es "similar" a veri*factu, no obstante de momento quedan excluidos del veri*factu. De momento al menos.
Así que las facturas por face deberá seguir haciéndolas hasta que entre en vigor el nuevo modelo de intercambio de facturas generalizado tanto recibidas como emitidas así como sus pagos. Y veri*factu estará obligado a hacerlo como cliente final el 1 de Julio del 2025. Los desarrolladores antes. Aunque hay que recordar que algunos no estarán obligados a acogerse a veri*factu. (agricultura, ...)

Espero serle de aporte a su consulta.
Un saludo.

El SII me genera una duda, tengo clientes en el SII y otros no, mi idea es que el programa funcione siempre en verifactu. Con estos dos tipos de clientes ¿habría que poner una opción para que el cliente diga que tiene SII y entonces no enviar? el envío del SII en nuestro caso es una aplicación aparte (donde está instalado el certificado electrónico) y es el que se dedica a enviar las facturas normalmente por un responsable.

Claramente tendrás que distinguir si el usuario está en el SII o en VeriFactu y dependiendo de la configuración enviar por un lado o por otro.


Saludos.

Por lo que yo sé, los que tienen SII están excludos de usar el SIF. Y por lo que yo también he entendido no tienen que cumplir los requisitos ni del veri*factu ni del NO veri*factu.
Tengo mis dudas si en el futuro se eliminara el SII y todo el mundo funcionará con veri*factu.
Por otro lado en el veri*factu no es necesario usar el certificado digital para encadenar los documentos pero si hay que usarlo para comunicar con el web-service de la aeat.
Personalmente intentaré usar el certificado para encadenarlos por si lo piden en el futuro. Sea como fuere si se trata de un sistema cliente-servidor centralizado tendrá que isntalar el certificado digital en el equipo central.

Tampoco sé qué certificado hay que usar para encadenar los documentos pero quiero imaginar que será el del cliente y no del fabricante.

En mi caso tengo clientes con varias empresas. Hay PDF que ha sacado la aeat para ver como se pueden combinar.

Supongo que si en su caso tiene clientes con SII y otros con SIF cambiarán las normas para cada empresa. -esto último es imaginación mía y simplemente cuestión de lógica-
Por otro lado si se ha acogido a un modelo mixto de veri*factu y no veri*factu creo que podría tener problemas mezclando empresas con SII.

Espero serle de alguna ayuda.
Un saludo.

Gracias a los dos, tendré que controlar que si me marca que no quiere verifactu es porque tiene SII y está enviando, en caso contrario verifactu siempre.

Dios nos pille Confesados.
 

Porqué han implementado este churro de Sistema, cuando ni siquiera es práctico para ellos y mucho menos para las empresas. Porqué no se ha utilizado el Standard de Facturae y encapsulado dentro de SOAP. Es que no se dan cuenta de que para las empresas no nos sirve. Si todo es más simple....
1. Enviamos a través de SOAP (o de lo que prefieran) el XML con el lote de facturas. Pueden mantener lo del Hash, el encadenamiento, pero usando el Standard Facturae
2. Obtenemos las respuestas
3. Que se nos dé la posibilidad de importar las facturas completas de nuestros proveedores. Nos ahorramos un trabajo duro de mecanización.

En definitiva han diseñado una BRAGA (con mayúsculas) y nos dejan en pelotas con un sistema que no vale para absolutamente nada desde el punto de vista empresarial. Como habréis visto solo se envían bases imponibles y tipos impositivos. Ni se envían líneas de detalles, ni otro tipo de impuesto, ni nada referido a formas de pago, ni nada que para las empresas tenga algo de valor.

En definitiva.... La AEAT se ha lucido de esta vez. No dan aprendido de las agencias tributarias de otros países donde si se ha extendido e implementado el uso de la Factura Electrónica de verdad.

Con Verifactu lo que quieren es tener la información fiscal de las facturas (repercusión del IVA), datos que en Facturae no están. Para eso esta la ley crea y crece que se refiere a las facturas en formato FacturaE. Si que podían haber unido los dos desarrollos.

Totalmente de acuerdo.
Tenian que haber unificado y además, he visto videos de presentación en los que se ha expuesto. Hay organizaciones empresariales que también han insistido. Está claro que el hecho de que le metamos los items de las facturas les complica el trabajo, no por el hecho de agregar las lineas, cosas que como bien indicas ya estaria en Facturae, si no por los controles que a posteriori tendrian que hacer de esas lineas.
Lo que yo pienso es que va acabar en un unico formato (Facturae), con una nueva versión que contemple las nuevas necesidades y que contemple todas las opciones de la normativa de facturación, le faltaría el BlockChain(Encadenamiento....), las Sustitutivas (Actualmente en Facturae las sustitutivas no están expresamente como tal, hay algo parecido, las recapitulativas, pero son para albaranes, además de otros tipos de registros que están tanto en verifactu como en ticketbai, pero no en Facturae.

Resumen, creo que harán una nueva version 3.XX de Facturae con lo que falta y servirá para todo, pero ahora van con las prisas y nos toca jodernos e ir adaptando lo que vayan sacando.

En facturae se recogen los datos tanto de IVA repercutido como soportado, además de otros tipos de impuestos, por ejemplo IRPF. No es comprensible que tras años de desarrollo de Facturae... Portal Face, Autofirma, etc, etc.... Nos presenten este churro. Para las empresas este desarrollo es completamente inútil, además de engorroso. si os fijáis en las estructuras de datos os daréis cuenta de que ni ellos mismo lo tienen claro. Además hay que entender que no vivimos aislados del mundo, y con este desarrollo se nos aleja más de Europa. Con la iglesia hemos topado, perdón con la AEAT hemos topado.

Es solo un paso temporal
 

Hay muchas cosas que le faltan a FacturaE. Sin ir mas lejos líneas que combinan otras descripciones. Algunos las llaman kits. ¿ Cómo se va a tener en cuenta el detalle que engloba una línea de kit ?
O por ejemplo otros tipos de datos como una "resma", "lata", "plancha", etc,etc. Sinceramente que se pueda facturar un kilowatio le afectará a poca gente.
O tener en cuenta que las medidas pueden ser también longitudinales, superficie o volumétricas. Y que en cada caso habría que especificar también sus múltiplos, etc,etc.

No estaría mal que hubiera un buzón de sugerencias pero al fin y al cabo tampoco serviría de mucho.
Dentro de nada habrá que incorporar el formato europeo. Quisiera imaginar que una vez usado éste todos los demás quedarán inutilizados.
Me gustaría creer que el formato europeo estará mas completo, pero visto lo visto imagino que será mas de lo mismo.
Así que como argumentaba el encargado policial de Casablanca..."personalmente me adaptaré a lo que venga"
Un saludo.

Hash y firma
 

¿ Alguien tiene idea de la parte del xml sobre la que hay que hallar el hash ?
Parece ser que no es de todo el xml.

Por otro lado si se firma digitalmente el xml, ¿ qué formato habrá que utilizar ?
Gracias por anticipado.

Buenas,



En el post 1341 nuestro amigo ermendalenda (muchas gracias) nos pone un ejemplo según las ultimas directrices de sobre que partes del xml hay que tener en cuenta para crear el hash. Te recomiendo que lo leas



<sum1:NIF>00000006Y</sum1:NIF><sum1:NumSerieFacturaEmisor>150.3.1.5</sum1:NumSerieFacturaEmisor><sum1:FechaExpedicionFacturaEmisor>25-02-2024</sum1:FechaExpedicionFacturaEmisor><sum1:TipoRegistroSIF>S0</sum1:TipoRegistroSIF><sum1:TipoFactura>F2</sum1:TipoFactura><sum1:CuotaTotal>0.20</sum1:CuotaTotal><sum1:ImporteTotal>2.20</sum1:ImporteTotal><sum1:HuellaRegistroAnterior>8ADCCCBD8DBBF8A668C78571C7AC2768EB77C77468C49A44E1829 03CB4468FE5</sum1:HuellaRegistroAnterior><sum1:FechaGenRegistro>25-02-2024</sum1:FechaGenRegistro><sum1:HoraGenRegistro>11:15:24</sum1:HoraGenRegistro>



Respecto a la codificacion... creo que es SHA-256 o almeno yo lo tengo asi


Un saludo y ya queda menos

Calculo del hash en .net:

No es la estructura xml
 

La estructura está muy bien definida en las excell y algunos pdf de la AEAT.
Por supuesto debe cumplir normas.
No sé si te refieres a que la HUELLA debe hacerse sobre esa estructura que me envías. Imagino que no porque ahí faltan datos vitales de la factura. Si fuese así todavía se podría cambiar algún dato del xml y no creo que la aeat esté por la labor.
El hash por supuesto es sha 256 y debe ser traducido a hexadecimal.


Gracias igualmente.