Gracias compañero. Le echo un vistazo.


Saludos.

El envío de la relación de las Facturas sustituidas en un registro con clave F3 no es obligatorio, por lo tanto, dudo mucho que hacienda sepa qué facturas estás sustituyendo. Yo no uso la clave F3, siempre anulo con simplificada y luego emito factura completa. Yo creo que debe ser desde el propio SIF y no desde la Aeat el que controle esta casuística que estás planteando. Y desde luego, debes controlar que no puedes sustituir una factura varias veces (sobre todo con distinto destinatario)

Entiendo que FacturaSinIdentifDestinatarioArt61d es al contrario de lo que has dicho: Factura NORMAL pero SIN identificación del destinatario (de hecho el dato S o N se llama "CompletaSinDestinatarioType").

No?

Tengo la sensación que has invertido las dos etiquetas.

Mira lo que dice el documento de validaciones

8. FacturaSimplificadaArt7273
- Sólo se podrá rellenar con “S” si TipoFactura=“F1” o “F3” o “R1” o “R2” o “R3” o “R4”

9. FacturaSinIdentifDestinatarioArt61d
- Sólo se podrá rellenar con “S” si TipoFactura=”F2” o “R5”.

Me he basado en el documento de validaciones
Lo he respondido más arriba

Pues entonces los que están un poco fatal son los de Hacienda. Menuda forma de liar.

Web desarrolladores caida.
 

Hola, buenos dias, no puedo acceder al area de desarrolladores de la AEAT, a alguien mas le pasa? , sabeis si han cambiado el elace o algo?

visto, han cambiado la direccion https://www.agenciatributaria.es/AEA...ERI_FACTU.html

Incongruencias con reglamento de facturación consolidado
 

Soy yo o han cambiado en el reglamento de facturación algunos elementos que no estaban antes y otro que no cuadra con verifactu:
Primero la obligatoriedad de desglosar las bases por item cuando hay más de un tipo de IVA(en las simplificadas), pues esto no lo hace nadie, ni carrefour ni nadie.



Y esto otro habla de ponerle datos del cliente si lo solic8ta (en la factura simplificada tambien)
Es que no cuadra que una factura simplificada te puedan pedir que añadas los datos del receptor, esto que es ahora?
Entonces para que coño sirve tener series separadas si al final se puede hacer lo que te salga de los h.. von la simplificada.
Espero que lo que querían decir es que si te piden los datos emitas una sustitutiva.
Es que parece que han metido párrafos en las simplificadas que no son de ahí.

Eso de eliminar o rectificar tiquet (aunque sea con una eectificativa) no es muy legal.y sobre todo como vengan con que te pidan una factura de un tiquet en distintas fechas y mucho mens en distintos periodos impositivos.
Para un día concreto no me parece mal, pero no como norma general, queda muy raro que no emitas ni una sustitutiva si la forma de vender habitual es simplificada.
Esa consulta a la aeat ya la vi alguna vez

He estado repasando en pdfs antiguos el reglamento y parece que en 2012 se redactó tal cual esa parte.
Sabéis si en verifactu admite como factura simplif8cada los datos del receptor?
Aunque yo tengo claro que no lo voy incorporar, menudo lío, tiquet emitido y que haya quenponerle los datos del receptor sin emitir sustitutiva, y ahora a mandar rectificación a verifactu.

Es más habitual de lo que crees, y además, está amparado por el Reglamento de Facturación y convertido en procedimiento habitual en el Reglamento del SII

2.30. ¿Cómo registra el emisor una factura emitida en sustitución de facturas simplificadas (art. 7.2 RD 1619/2012)?
Se deberá informar en el bloque “Tipo Factura” con la clave “F3: factura emitida en sustitución de facturas simplificadas facturadas y declaradas” y en el bloque de “Datos sustituidas” se identificarán las facturas simplificadas sustituidas con el número, serie y fecha de expedición. La identificación es opcional. En los campos “Ejercicio” y “Período” deberán consignarse los correspondientes al período de liquidación en que fue anotada la factura simplificada original. La clave “F3” supone que no se tendrá en cuenta el IVA repercutido en la factura para evitar una duplicidad con la factura simplificada inicial.

IMPORTANTE: En el caso de que se realice un abono de la factura simplificada (mediante el envío de un registro negativo con clave “F2”), la factura emitida en sustitución de esta tendrá que informarse con la clave “F1”.

https://sede.agenciatributaria.gob.e...023V-FINAL.pdf

Si el cliente te pide que pongas sus datos en la factura simplificada, simplemente emites una sustitutiva es ese momento. No hay que darle más vueltas. Yo no permito emitir facturas simplificadas con identificación de destinatario, ya que no podría agrupar las ventas del día de facturas simplificadas en un solo bloque para informalas al SII (clave F4, el bloque debe ser correlativo, emitidas en el mismo día y al mismo destinatario)

Hola,

Estos temas no son novedad de Verifactu.
Siempre han existido en la normativa de facturación:
https://sede.agenciatributaria.gob.e...lificadas.html
https://sede.agenciatributaria.gob.e...lificadas.html

Si emites una factura simplificada con productos o servicios con un solo tipo de IVA, puedes indicar el total y la frase "IVA incluído" e indicando el tipo de IVA.
Si la factura simplificada lleva varios tipos de IVA, tienes que desglosar las bases , tipos y cuotas de IVA (como en la facturas completas).

Si el destinatario de un factura simplificada te pide que pongas sus datos (para poder utilizarla para deducciones o desgravaciones propias), debes indicar en la factura simplificada dichos datos (nombre y apellidos, NIF y domicilio).
(Es lo que se suele llamar "factura simplificada cualificada" o con destinatario)
No precisas emitir una factura de sustitución de factura simplificada para poner los datos de destinatario, ya que esa factura simplificada con datos de destinatario tiene el mismo valor (aunque sea en formato de rollo de TPV)

Saludos

Este tema me chirría, hay que ponerlo en cuarentena e investigar. No logro que me acepte una factura tipo F2 con identificación de destinatario y la combinación de marcas FacturaSimplificadaArt7273 y FacturaSinIdentifDestinatarioArt61d. He hecho varias combinaciones y no hay forma. Lo retomaré más adelante. Si alguien quiere aventurase bienvenido sea

La aplicacion de ejemplo ya esta casi completa

Sube facturas F1 y F2 y la anulacion desde una lista en EXCEL
He revisado los mensajes de respuesta
Comprueba con la AEAT que la factura este subida
Y genera el codigo QR

Sigo teniendo problemas para generar el nuevo WSDL asi que lo estoy haciendo con el anterior.

Os pediria x favor, si es posible, que cuando se publicara un nuevo interface SOAP algun alma caritativa lo subiera y se chinchetara al principio del foro.

En mi caso no puedo descargarlos y eso me preocupa.

En fin...

Subire el programa a final de semana tras alguna comprobacion. (espero que le sirva a alguien).

Saludos !

He leido los posteos anteriores y creia tenerlo claro, pero ahora ya no tanto:

Una cuestion, para dejarlo bien en el ejemplo:

¿ Los tickets, son de tipo F2 ? ¿ con FacturaSinIdentifDestinatarioArt61d=S ?

Tickets F2
 

Buenos días, yo he realizado pruebas enviando solo F2 y F2 con FacturaSinIdentifDestinatarioArt61d=S y las dos me da correcto, pero no sé si en producción pasará lo mismo .

Un saludo

Hola. A estas alturas ya no sé si esto es off-topic o si hay otro hilo en el foro que hable del tema, pero...

¿En qué consiste realmente el llamado No-Verifactu?

En Verifactu ya está claro: envío de las facturas al webservice em "tiempo real", con generación del QR, consulta online de las facturas, etc. (vamos, como TicketBai).

Pero viendo los diseños de registro de facturación, veo que hay otros registros como el de "eventos", y algunos campos del XML para indicar si es o no verifactu.
Por lo tanto, entiendo que el No-Verifactu requiere la generación y guardado del XML, pero no el envío a Hacienda, y además, la generación de otros XML para eventos (que aún no entiendo del todo).

Todo esto añadido a la no posibilidad de modificar ni borrar facturas, etc. (Ley Antifraude) y a la de llevar un registro de operaciones (LOG), que nuestro software ya hace.

Entiendo también que lo ideal sería que el software tuviera las dos opciones para que el cliente elija: Verifactu y No-Verifactu. ¿O es mejor exigir VeriFactu y punto?

Pues eso, espero que alguien pueda aclarar esta duda básica. Me centré en la parte "difícil" y ahora esta otra variante no me deja tranquilo...

hasta donde llego:


el no verifactu es igual que el verifactu porque tienes que guardar los XML listos para enviar, con algun dato variado que indica sistema no-verifactu, lo que no se si hay que generarlos a requerimiento o dejarlos archivados segun se generar, pero ademas tienes que ser capaz de enviarlos si lo piden.

y generar el sistema de eventos.

saludos

Otro tema muy importante en el sistema NO-VERIFACTU es que la guardia y custodia de toda la información generada (registros de facturacion, eventos, etc...) recae también en el fabricante/vendedor/instalador del SIF, teniendo responsabilidad ante posibles "pérdidas involuntarias" de esa información.

Con el sistema VERIFACTU, la guardia y custodia recae directamente en hacienda.

además el no verifactu hay que FIRMAR los xml ( como en ticketbai ) , lo cual implica más dificultad ya de por si

clubes sociales y verifactu
 

Yo acabo de consultar a la aeat si los clubes sociales que no están obligados a emitir con IVA deben subir sus tiques y cuotas a socios a verifactu, y me han dicho que lo tienen que consultar, no sé si alguien de aquí ha hecho la misma consulta para saber si responden lo mismo. :)

También he acabado de hacer una prueba de generación del xml y envío y una subsanación por error en la huella y sin problema. Con el QR le he dado el formato de 40*40 pero a la hora de asignarle el data se me redimensiona más grande, tengo que echarle un vistazo.

Si alguien tiene por ahí un xml de varias facturas agradecería muy mucho que la mostrara si es posible, tengo varías dudas en cuanto a su formato :)

Hacernos responsables a nosotros de la "guardia y custodia" de esos archivos no creo que sea muy sensato. ¿Qué pretenden, que los subamos a una nube?

Si los subimos a una nube privada del fabricante, habría problemas serios con la "ley de protección de datos".
Además, la nube cuesta dinero.

Si se guardan en local, en el equipo del cliente, ya me dirás tu qué responsabilidad tenemos nosotros, con los equipos de gama baja que suelen comprar los clientes, o con lo que puedan hacer ellos con sus archivos, discos, etc.

Pues nada, pensaba que el No-Verifactu no me iba a quitar sueño, pero ya veo que sí :rolleyes:
Va a estar la cosa simpática.

Nosotros entendemos que es mejor Verifactu tanto para el cliente como para nosotros. No pretendemos implementar el modelo No Verifactu, mas que por la complejidad, que evidentemente tiene mas que el Verifactu, por la responsabilidad que asumimos

Gracias, según esto llevas razón respecto al SII y además tiene sentido ya que estas declarando el iva en el peirodo correcto y lo dejas a cero cuando emites la factura negativa f2 y positiva f1, lo que me extraña es que no encuentro esta situación en el reglamento de facturación.

Como dice sglorka, el permitir esto puede provocar inconsistencia de datos cronologicamente y dudas de si incluirlo en el 347 por que ese cliente sobrepasa los 3001 euros, ya que los datos del cliente no se lo has mandado a verifactuç puesto que es una anotación en un tiquet posterior y verficatu no admite datos de clientes en simplificadas ¿o sí?. asi que si lo admite hay que enviar la corrección por que si no al cruzar los 347 sucede que no cuadra.
Si hubiera que declararlo hay que hacer una declaracion complementaria de esos datos del 347.

Mi conclusión:
Si antes de generar el xml de verifactu lo informas y verifactu lo admite lo veria lógico (Para ello te lo tiene que avisar el cliente antes de cerrar el tiquet), en TIQUETBAI tengo entendido que si lo admiten
Si no te avisan con tiempo, pues factura sustitutiva

Yo consulté a Verifactu y me dijeron que el responsable de la custodia NO*Verifactu es el usuario del software , ha cambiado algo?

Especificacion firma registros
 

Hola no se a vosotros, pero a mi se me habia pasado que ya han subido las especificaciones para la firma de los registros de facturacion https://www.agenciatributaria.es/sta...t_BORRADOR.pdf.
Mennos mal que no es obligatorio firmar...

Hay que recordar que la propia AEAT recomiendo encarecidamente el modelo VERI*FACTU.
Es más, yo creo que han puesto el NO-VERIUFACTU tan complejo y con tanto requerimiento, para que nadie lo acabe escogiendo.
El problema es que igualmente en muchas empresas se va a tener que implementar por lo de que "el cliente manda". :mad::mad:

Si las empresas que desarrollamos SIF no implementamos el No Verifactu no le va a quedar otra opción al cliente.
Además las responsabilidades que adquiere una empresa fabricante de SIF "no verifactu" es incontrolable por parte de la misma, ya que depende en gran medida de las condiciones en que el cliente use dicho SIF.
Nosotros no estamos dispuestos a asumir eso, es mas, conociendo a las pymes españolas menos.

Bueno, como bien has dicho, eso depende de las empresas y en muchos casos quien lo decide no son los programadores.
En el caso de la mía han decidido que SI hay que implementarlo, porque a la hora de vender el producto eso le da valor. Y entiendo que en muchas otras será igual.
Poder decir que tu producto implementa ambos sistemas y que X de la competencia sólo implementa uno, es una baza a la hora de vender (eso piensan).

Claro. Pero depende del tipo de contrato que te ga el proveedor con el que lo usa puede tener algún tipo de responsabilidad. Y si hay requerimientos y falla algo puede que algo te cae. Mínimo horas de trabajo y dolor de cabeza.
Con verifactu si pasa algo será con los últimos registros y eso es un alivio

Algo no me cuadra
 

Nada error mio. Solo me preguntaba cómo van a controlar que se aplique correctamente el iva, pero supongo que como tengo que conservar los tiquets 4 años me pueden hacer un requerimiento de los libros de ivas desglosados y los tiquets, a parte del verifactu.
Otra cosa es que no tenga que guardar los xmls y encadenamientos.

Yo estoy seguro que como no implemente la opción "No VeriFactu" me quedo sin la mitad de clientes así que.... a pringar.

A ver: El formato de LOG (eventos) que pide Hacienda es bastante especifico y sería muy sorprendente que tu sistema actual de LOG sirve tal cual para los eventos de un sistema NO-Veri*factu. Por tomar un solo ejemplo, cada registro debe ir encadenado con el anterior y firmado.

Por supuesto, esto viene por encima de todos los demás puntos en "contra" de implementar el modo NO-Veri*factu que han llevados l@s compañer@s.


Si tu idea era que el modo Veri*factu era la parte "difícil", creo que te va a venir una sorpresa.

Este punto es exactamente lo que los de Hacienda (o del Ministerio) NO han sabido sortear en un principio, y ahora que se han dado cuenta del fallo, intentan remar a contracorriente de todas sus fuerzas; pero por mucho que lo intentan, es tal como Neftali lo dice, los responsables (muchos de ellos comerciales) de las empresas de software han tomado sus decisiones... :(

En mi opinión la opción NO-Veri*factu puede tener sentido para algunas empresas que tienen un sistema informático de facturación "grande", con muchas implicaciones en demás partes de la empresa, y dónde la adaptación al modelo Veri*factu sería muy costosa. Es decir, ¡todo lo contrario de un programa escrito en Delphi!
Pero es solo mi impresión. Y no hay nada en los textos oficiales que permiten hacerse una idea de ¿por qué han creado este dualidad? (Ni una palabra en las seis páginas de exposición de los motivos del RDL 1007/2023). Sobre todo qué la experiencia de TicketBAI demuestra que el modelo Veri*factu puede funcionar a gran escala, nada menos que Euskadi y Navarra.

Vale para el documento de validaciones. Pero ocurre que "F2" no es lo mismo que factura simplificada (y al revés para "F1").
Del diseño de registro, pestaña Listas, L2 (y es copiado del SII 1.1):O siga, una factura con indicación del destinatario va con F1 (o F3/R1-4), siga una normal o una simplificada con indicación del destinatario (y el campo FacturaSimplificadaArt7273 sirve para identificar el segundo caso).
Y una factura sin destinatario va con F2 (o R5), siga una simplificada o una normal con la opción del 6.1 d) (y el campo FacturaSinIdentifDestinatarioArt61d sirve para identificar el segundo caso).

Hola. He visto en post de días atrás, que había gente que tenía este mismo problema, pero no conseguí entender como lo solucionaron.

He intentado importar el WSDL de diferentes maneras (automático / 1.1 / 1.2) pero aparentemente todo sigue igual.

A ver si alguien me puede echar una mano para conseguir arrancar de una vez con el envío.

Gracias

duda
 

Alguien sabe si una factura con varias lineas de detalle, todas con el mismo IVA, cuando se genere el *.XML, hay que datallar cada una de las lineas, o solo con poner una linea con el importe total, cuota de iva y base imponible, ya sería suficiente ?

Ahora creo que estoy en ese punto yo también.

¿Cómo hiciste para general la cabecera de la 2ª manera que quiero entender que si te funcionó?


EDITO PARA INDICAR SOLUCION:

Añadida línea tras importar el WSDL tal y como indican en este hilo: https://clubdelphi.com/foros/showpos...postcount=2536

O sea, para que funcione bien, tras importar el wsdl tuve que hacer dos "retoques" manuales:
- Cambiar línea: InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioSOAP12) por InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioDocument);
- Meter línea justo a continuación: InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioLiteral);