Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Empezado por Sistel

Posiblemente no entendieron la pregunta.

Es lo que en facturación se llama "Factura sustitutiva de facturas simplificadas".
Antiguamente se llamaba "Factura de canje de tickets"

Si de esas hacemos decenas al día
Y se pueden pedir hasta 4 años después.per9 para poder declarse ese iva El cliente tiene que hacerlo en las condiciones que he puesto antes. Mismo mes para consumidores finales y hasta el día 15 los demás.

[sglorka]

Empezado por ermendalenda

Si de esas hacemos decenas al día
Y se pueden pedir hasta 4 años después.per9 para poder declarse ese iva El cliente tiene que hacerlo en las condiciones que he puesto antes. Mismo mes para consumidores finales y hasta el día 15 los demás.

Pero la factura a cliente final la has emitido en el mismo momento de la entrega de bienes (te obliga el reglamento), luego el cliente te pide una recapitulativa de todas sus operaciones en el mismo mes natural, esta es otra factura que como límite tiene el último día del mes. Pero las diferentes operaciones dentro del mes las has tenido que emitir en el momento.

[ramherfer]

Hola buenos días. En la estructura SistemaFacturacion.wsdl dentro de registro facturación existe el nodo Destinatario y que IDDestinatario puede ser (1..1000). Por favor alguien me podría ayudar con el código para uno y para dos destinatarios en una misma factura. He intentado reproducirlo como me indicó Nefta para una factura con dos codigos de iva distintos, pero, con el tema de destinatarios no lo consigo. Gracias.

[ramherfer]

Empezado por ramherfer

Hola buenos días. En la estructura SistemaFacturacion.wsdl dentro de registro facturación existe el nodo Destinatario y que IDDestinatario puede ser (1..1000). Por favor alguien me podría ayudar con el código para uno y para dos destinatarios en una misma factura. He intentado reproducirlo como me indicó Nefta para una factura con dos codigos de iva distintos, pero, con el tema de destinatarios no lo consigo. Gracias.

Me respondo a mi mismo:

Código Delphi [-]
  

  //----- Destinatarios
  var destinatario1 := PersonaFisicaJuridicaType.Create;
  destinatario1.NombreRazon := 'GALLEGO SENDRA LUIS';
  destinatario1.NIF := '20444555N';

  var otro1: IDOtroType := IDOtroType.Create;
  otro1.CodigoPais := CountryType2(68);
  otro1.IDType := PersonaFisicaJuridicaIDTypeType(0);
  otro1.ID := '20444555N';
  destinatario1.IDOtro := otro1;


  var destinatario2 := PersonaFisicaJuridicaType.Create;
  destinatario2.NombreRazon := 'GARCIA BEREN ALBERTO';
  destinatario2.NIF := '16444555N';

  var otro2: IDOtroType := IDOtroType.Create;
  otro2.CodigoPais := CountryType2(68);
  otro2.IDType := PersonaFisicaJuridicaIDTypeType(0);
  otro2.ID := '16444555N';
  destinatario2.IDOtro := otro2;

  var destinatario: destinatarios := destinatarios.create();
  SetLength(destinatario, 2);
  destinatario[0] := destinatario1;
  destinatario[1] := destinatario2;
  fact.RegistroFacturacion.destinatarios := destinatario;

De esta forma el xml quedaría así:

<Destinatarios xsi:type="SOAP-ENC:Array" SOAP-ENC:itemType="NS3:PersonaFisicaJuridicaType" SOAP-ENC:arraySize="2">
<item SOAP-ENC:id="8" xsi:type="NS3:PersonaFisicaJuridicaType">
<NombreRazon xsi:type="xsd:string">GALLEGO SENDRA LUIS</NombreRazon>
<NIF xsi:type="xsd:string">20444555N</NIF>
<IDOtro SOAP-ENC:id="9" xsi:type="NS3:IDOtroType">
<CodigoPais xsi:type="NS3:CountryType2">ES</CodigoPais>
<IDType xsi:type="NS3:PersonaFisicaJuridicaIDTypeType">02</IDType>
<ID xsi:type="xsd:string">20444555N</ID>
</IDOtro>
</item>
<item SOAP-ENC:id="10" xsi:type="NS3:PersonaFisicaJuridicaType">
<NombreRazon xsi:type="xsd:string">GARCIA BEREN ALBERTO</NombreRazon>
<NIF xsi:type="xsd:string">16444555N</NIF>
<IDOtro SOAP-ENC:id="11" xsi:type="NS3:IDOtroType">
<CodigoPais xsi:type="NS3:CountryType2">ES</CodigoPais>
<IDType xsi:type="NS3:PersonaFisicaJuridicaIDTypeType">02</IDType>
<ID xsi:type="xsd:string">16444555N</ID>
</IDOtro>
</item>
</Destinatarios>

[CarlosR]

Muy buenas, compruebo que el hilo es largo. No lo he leido todo -todará entre hoy y mañana-.
Por eso si pregunto algo que ya haya sido tratado pido disculpas de antemano.
Mi pregunta si es que hay respuesta sería, ¿ cómo solucionásteis el problema de tener los datos propios de veri*factu en una tabla si las tablas suelen tener un buen número de campos y desde luego muchos mas que los que veri*factu necesita ? La Agencia Tributaria en su Ley dice que solo quiere ver esos datos, ningún otro.
En mi caso, llevo ya mas de 1 año trabajando en ello -entre otras cosas-, lo he solucionado aumentando un campo de contenido XML a las tablas de cabeceras de factura, exactamente igual al que se subiría a la AEAT mediante su servicio, con encadenado, etc. Por lo que es verificable desde la aplicación tanto los datos del registro como el contrastado campo XML.
Por ello tanto que la empresa se acoja a veri*factu como que no, el campo contendría los mismos valores.

¿ Cómo lo veis ?
Gracias de antemano y un saludo por el árduo trabajo de mantener este foro.

[antoine0]

Empezado por CarlosR

Mi pregunta si es que hay respuesta sería, ¿ cómo solucionásteis el problema de tener los datos propios de veri*factu en una tabla si las tablas suelen tener un buen número de campos y desde luego muchos mas que los que veri*factu necesita ? La Agencia Tributaria en su Ley dice que solo quiere ver esos datos, ningún otro.

Creo que tienes que contemplar los registros de Veri*factu como unas tablas paralelas a los datos de tu factura natural. Y el proceso de encadenación y demás corren contar estas tablas paralelas, no contra la(s) tabla(s) que contienen los numerosos datos de las facturas.

Digo tablas porqué en la mayoría de los casos hay por lo menos 2: una tabla con una fila por factura, y una tabla con una fila por tipo de IVA aplicable y cuota. Este modelo sirve en el caso que hay más de un tipo de IVA aplicable, la suma de estas bases imponibles para una determinada factura siendo el importe "bruto" de la factura.
Evidentemente, una vez que te has puesto en un modelo de datos donde hay más que una tabla, pueden haber muchísimo más que 2 tablas. Aquí vienen rectificativas, múltiples destinatarios y demás casos extraños.

[CarlosR]

Gracias por la rapidez. Tiene lógica, no obstante tenía entre ceja y ceja la impresión de que los datos de veri*factu deberían estar en la misma tabla.
Si es lo que otros están haciendo seguro que es así. Cien ojos ven mas que dos.
Revisaré mi código lo antes posible.

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

Empezado por CarlosR

Tiene lógica, no obstante tenía entre ceja y ceja la impresión de que los datos de veri*factu deberían estar en la misma tabla.
Si es lo que otros están haciendo seguro que es así. Cien ojos ven mas que dos.

Nosotros también tenemos tablas separadas para estos datos.
Es más normalizado.
Además de esa forma no penalizas con esos campos extra en la tabla de FACTURAS (aunque estén vacíos) a clientes que no los necesitas o que no tienen VERI*FACTU.

[keys]

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

Nosotros también tenemos tablas separadas para estos datos.
Es más normalizado.
Además de esa forma no penalizas con esos campos extra en la tabla de FACTURAS (aunque estén vacíos) a clientes que no los necesitas o que no tienen VERI*FACTU.

Que yo sepa Veri*Factu no dice que tengas que tener esos campos en la base de datos, sólo dice que el programa tiene que ser capaz de generar unos ficheros con esa estructura para poder enviarlos a hacienda, ademas de garantizar el hash y otra serie de cosas de las facturas.

Otra cosa es que este mejor o peor estructurada la base de datos por tener unas tablas diferentes, ya que al final estas guardando datos en tablas distintas y al final puede influir en el rendimiento de la aplicación.

[CarlosR]

Corrígeme si me equivoco, pero el aplicativo debe poder acogerse a veri*factu o no, es decisión de la empresa acogerse o no. El aplicativo debe tener las dos versiones.
En el caso de que te acojas a veri*facto deberás enviar las facturas a la Agencia Tributaria de forma casi inmediata, y poco mas. En el caso de que no te acojas a veri*factu no podrás poner ningún QR en tus facturas y debes tener todos los protocolos de encadenamiento, cifrado, garantía de no cambio, archivo, exportación de logs..., etc.etc.
Como el aplicativo debe tener las dos, en mi caso he optado por seguir todos los pasos tanto si se envía a la Agencia Tributaria como si no.
Sigo teniendo dudas de si hay que llevar dos o mas tablas separadas de la tabla de cabecera de factura y pies de documento o bien serviría con encadenar las mismas facturas en un campo XML en la misma tabla de cabecera de facturas que es como realmente lo tengo diseñado. Creo entender que no hay una norma fijada a tenor de lo que estoy leyendo.
He estado en numerosos weminars y aparte de hablar de fechas de entrada en vigor y algún link de la AEAT poco mas se dice.
Aprecio enormemente la colaboración de foros como este, que en determinados momentos se vuelve una necesidad.