Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[pablog2k]

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

[keno_71]

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

[espinete]

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í
Va a estar la cosa simpática.

[RUBEN_SP]

Empezado por espinete

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...

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

[ermendalenda]

Empezado por sglorka

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

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.

[ermendalenda]

Empezado por Sistel

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

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

[Delphier]

Empezado por espinete

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í
Va a estar la cosa simpática.

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

[bmfranky]

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...

[Neftali [Germán.Estévez]]

Empezado por RUBEN_SP

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

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".

[RUBEN_SP]

Empezado por Neftali [Germán.Estévez]

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".

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.

[Neftali [Germán.Estévez]]

Empezado por RUBEN_SP

Si las empresas que desarrollamos SIF no implementamos el No Verifactu no le va a quedar otra opción al cliente.

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).

[ermendalenda]

Empezado por Delphier

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

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

[ermendalenda]

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.

[[newtron]]

Empezado por Neftali [Germán.Estévez]

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).

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

[antoine0]

Empezado por espinete

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.

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.

Me centré en la parte "difícil" y ahora esta otra variante no me deja tranquilo...

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

[antoine0]

Empezado por Neftali [Germán.Estévez]

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).

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.

[antoine0]

Empezado por sglorka

FacturaSimplificadaArt7273", este campo es opcional y si lo pones a SÍ indica que la factura es completa (F1) pero no se identifica al destinatario, por ejemplo en ventas a la Unión Europea a un cliente final no empresario o profesional.

FacturaSinIdentifDestinatarioArt61d, este campo es opcional, si lo pones a SÍ, significa que vas a emitir una Factura Simplificada con Identificación de Destinatario por que así te lo ha exigido éste.

Empezado por sglorka

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”.

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):

VALORES	DESCRIPCIÓN
F1	Factura (art. 6, 7.2 y 7.3 del RD 1619/2012)
F2	Factura Simplificada y Facturas sin identificación del destinatario art. 6.1.d) RD 1619/2012
[...]

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).

[nincillo]

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.

<?xml version="1.0" encoding="UTF-8"?>
<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
	<env:Body>
		<env:Fault>
			<faultcode>env:Server</faultcode>
			<faultstring>Codigo[1207].Se esperaba nodo {http://schemas.xmlsoap.org/soap/envelope/}Envelope y ha venido {http://www.w3.org/2003/05/soap-envelope}Envelope</faultstring>
		</env:Fault>
	</env:Body>
</env:Envelope>

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

[jguarda]

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 ?

[nincillo]

Empezado por delphiGar

Ese error me lo dio a mi cuando el componenente httprio generaba el xml con una cabecera como esta en el soap:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body xmlns:NS1="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">

cuando corregi la forma de generarlo la cabecera es esta

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAP-ENV:Body>

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);