Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[delphiGar]

Empezado por nincillo

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

Buenas nincillo.

Importe el wdsl del soap con la version 1.2 y a continuacion hice lo que comentas, o sea sustitui

InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioSOAP12);

por estos dos:

InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioDocument);
InvRegistry.RegisterInvokeOptions(TypeInfo(sfPortTypeVerifactu), ioLiteral);

y con esto me funciono

[unomasmas]

Empezado por sglorka

...Y la segunda es nuestra querida amiga la Factura Rectificativa. Si nos rechazan una factura porque el tipo impositivo no existe, te tienes que olvidar de ese registro de facturación y emitir una factura rectificativa por sustitución haciendo referencia a esa factura rechazada para corregir ese error. Quedará un hueco en las facturas que tiene la Aeat (nos ha rechazado la factura) pero eso es normal ya que NO PODEMOS modificar facturas para arreglarlas. Haciendo referencia a dicha factura a través de la rectificación justificamos en la Aeat la existencia de ese hueco.

Creo que me he despistado un poco. Rechazan mi factura por error en el tipo impositivo y envío rectificativa por sustitución pero yo entiendo que no queda el hueco en la numeración; esa factura rechazada sigue estando en mi sistema y seguirá contando con su número. ¿Cómo es que queda el hueco? ¿Por eliminar la factura? Para contrarrestar sus valores... ¿Cómo he de hacer con la incorrecta además de generar otra adicional rectificativa? ¿Hago otra complementaria con el tipo también incorrecto pero en negativo para contrarrestarla?

[jguarda]

alguien ha conseguido instalar la unidad como componente "VerifactuHTTPRIO"


error:
HTTPWebNode.ClientCertificate.Stream := Certificate;
HTTPWebNode.ClientCertificate.Password := CertPassword;

[sglorka]

Empezado por unomasmas

Creo que me he despistado un poco. Rechazan mi factura por error en el tipo impositivo y envío rectificativa por sustitución pero yo entiendo que no queda el hueco en la numeración; esa factura rechazada sigue estando en mi sistema y seguirá contando con su número. ¿Cómo es que queda el hueco? ¿Por eliminar la factura? Para contrarrestar sus valores... ¿Cómo he de hacer con la incorrecta además de generar otra adicional rectificativa? ¿Hago otra complementaria con el tipo también incorrecto pero en negativo para contrarrestarla?

La factura rechazada siguen en tu sistema SIF pero el hueco queda en la Aeat, en tu SIF la factura reza como anulada, sin huecos. El procedimiento para rectificar en dos pasos que es el que yo utilizo sería :

1.- Emitir una Anulación del Registro con la marca SinRegistroPrevio = S (ya que no existe en la Aeat) y la marca RechazoPrevio = S
2.- Emitir Factura Rectificativa por sustitución donde se indica la rectificación de la factura que ha sido rechazada

Esta información que aporto está contrastada con el Verifactu@correo.aeat.es

[sglorka]

Empezado por antoine0

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

Gracias Antoine0.
En resumen, se pueden emitir Facturas completas y Facturas Simplificadas cualificadas (con identificación de destinatario) y ambas se informan con la clave F1, sólo en caso de factura simplificada cualificada se marca la opción FacturaSimplificadaArt7273=S

Y la marca FacturaSinIdentifDestinatarioArt61d se pone a "S" cuando emites una factura simplificada a un cliente que no necesitas identificar por el artículo "6", punto "1" apartado "d", pero que normalmente, si la venta a es público esta marca no se utiliza

[delphiGar]

Empezado por sglorka

Gracias Antoine0.
En resumen, se pueden emitir Facturas completas y Facturas Simplificadas cualificadas (con identificación de destinatario) y ambas se informan con la clave F1, sólo en caso de factura simplificada cualificada se marca la opción FacturaSimplificadaArt7273=S

Y la marca FacturaSinIdentifDestinatarioArt61d se pone a "S" cuando emites una factura simplificada a un cliente que no necesitas identificar por el artículo "6", punto "1" apartado "d", pero que normalmente, si la venta a es público esta marca no se utiliza

Hola sglorka, el primer caso es correcto, es decir:

se pueden emitir Facturas completas y Facturas Simplificadas cualificadas (con identificación de destinatario) y ambas se informan con la clave F1, sólo en caso de factura simplificada cualificada se marca la opción FacturaSimplificadaArt7273=S

pero en el segundo caso, tanto la factura simplicada no cualificada como la factura ordinaria sin identificar se informan con la clave F2, pero para el caso de la factura ordinaria sin identificar se pone la clave FacturaSinIdentifDestinatarioArt61d a S.

Lo de Factura ordinaria sin identificar es porque se utiliza un identificador que no lo recoge la AEAT, por ejemplo un pasaporte o un documento de identificacion de otro pais. En este caso en destinatario habria que poner el IDOtro en vez del NIF.

[sglorka]

Empezado por delphiGar

Hola sglorka, el primer caso es correcto, es decir:

se pueden emitir Facturas completas y Facturas Simplificadas cualificadas (con identificación de destinatario) y ambas se informan con la clave F1, sólo en caso de factura simplificada cualificada se marca la opción FacturaSimplificadaArt7273=S

pero en el segundo caso, tanto la factura simplicada no cualificada como la factura ordinaria sin identificar se informan con la clave F2, pero para el caso de la factura ordinaria sin identificar se pone la clave FacturaSinIdentifDestinatarioArt61d a S.

Lo de Factura ordinaria sin identificar es porque se utiliza un identificador que no lo recoge la AEAT, por ejemplo un pasaporte o un documento de identificacion de otro pais. En este caso en destinatario habria que poner el IDOtro en vez del NIF.

Sí, tiene sentido lo que dices.
Gracias

[rci]

Hola, tengo una pregunta:

Las empresas del País Vasco están exentas de VeriFactu porque ya envían TicketBAI?
O tendrán que cumplir tanto a TicketBAI como VeriFactu y enviar las facturas a dos agencias tributarias?

Lo he buscado por internet pero en diferentes páginas web dicen cosas distintas.

Muchas gracias

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

En el caso de los territorios forales del País Vasco y Navarra, el reglamento solo será aplicable a los obligados tributarios correspondientes que tengan su domicilio fiscal en territorio común.

Entiendo que los que están haciendo TBAI (porque son empresas con sede en el país Vasco) están exentas de hacerlo aquí.

[delphiGar]

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

En el caso de los territorios forales del País Vasco y Navarra, el reglamento solo será aplicable a los obligados tributarios correspondientes que tengan su domicilio fiscal en territorio común.

Entiendo que los que están haciendo TBAI (porque son empresas con sede en el país Vasco) están exentas de hacerlo aquí.

Exacto, eso depende de donde tenga el domicilio fiscal, se aplicara uno u otro sistema.

De hecho, conozco de empresas del Pais Vasco que cambiaron su domicilio fiscal para no estar en el sistema de TICKETBAI.

[rci]

Ok es lógico

Muchas gracias Neftali y delphiGar por vuestra respuesta!

[Sistel]

Empezado por delphiGar

Exacto, eso depende de donde tenga el domicilio fiscal, se aplicara uno u otro sistema.
De hecho, conozco de empresas del Pais Vasco que cambiaron su domicilio fiscal para no estar en el sistema de TICKETBAI.

Hola,

Una cosa a tener en cuenta:
Las empresas, con domicilio fiscal en el País Vasco, y que están en el SII, siguen obligadas al SII a pesar de estar también obligadas a TicketBAI.
En el resto del estado, si se está en SII, no se está obligado a Verifactu.

Saludos

[RanNav]

Buenas, se sabe cuándo saldrá al final la orden ministerial? se suponía que tenía de fecha para el 1 de octubre y no se ha dicho nada más sobre el tema.

[espinete]

¿Alguien sabe si en las facturas con Recargo de Equivalencia hay que indicar "ClaveRegimen = 18" (Recargo de Equivalencia) o no?

Estoy enviando facturas con Recargo de Equivalencia y me las acepta sin errores tanto con ClaveRegimen = 01 como con ClaveRegimen = 18

Otra cosa:

Estoy recibiendo este error...

Codigo[4112].El titular del certificado debe ser Obligado Emisión, Colaborador Social, Apoderado o Sucesor.

...cuando intento enviar una factura como persona física, usando mi NIF y Nombre reales.

Lo curioso es que ya he enviado varias igual, y han sido aceptadas, pero de repente ahora me da ese error

Confirmado: he vuelto a intentarlo 10 minutos después y ya no me da el error

[Delphier]

Por si alguien sabe la solución , si la tiene... mientras seguiremos investigando...


Generar el XML RegistroAlta con IXML.

var FacturaIXML : SuministroInformacion.IXMLRegistroFacturacionAltaType;


  FacturaIXML := NewXMLDocument.GetDocBinding('sum:RegistroAlta', SuministroInformacion.TXMLRegistroFacturacionAltaType, '') as SuministroInformacion.IXMLRegistroFacturacionAltaType;

  FacturaIXML.DeclareNamespace('sum','https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd');
  FacturaIXML.DeclareNamespace('sum1','https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd');


  // Si lo defino así , se le queda el Prefijo sum: de RegistroAlta en lugar de sum1: que es lo que interesa para Verifactu
  FacturaIXML.IDVersion := '1.0';


  // Para que el Prefijo sea sum1: se puede hacer así 
  FacturaIXML.AddChild('sum1:IDVersion').NodeValue := '1.0';


  FacturaExpedida := NewXMLDocument.GetDocBinding('sum1:IDFactura', SuministroInformacion.TXMLIDFacturaExpedidaType, '') as SuministroInformacion.IXMLIDFacturaExpedidaType;

  FacturaExpedida.IDEmisorFactura        := DTFactura.FieldByName('EmisorNIF').AsString;
  FacturaExpedida.NumSerieFactura        := ReferenciaDocumento;
  FacturaExpedida.FechaExpedicionFactura := StringReplace(DTFactura.FieldByName('FECH').AsString,FormatSettings.DateSeparator,'-',[rfReplaceAll, rfIgnoreCase]); // (dd-mm-yyyy)
  FacturaIXML.ChildNodes.Add(FacturaExpedida);


  Resto del fichero....

El problema que me he encontrado es que como el XML Tiene dos Prefijos , sum: en RegistroAlta y Sum1: En IDVersion y el resto , luego no puedo Recuperar el Objeto SuministroInformacion.IXMLRegistroFacturacionAltaType Correctamente.

var FacturaCargadaIXML : SuministroInformacion.IXMLRegistroFacturacionAltaType;
var XMLVerifactu : String;


       XMLVerifactu := 'El XML creado con anterioridad...'   

       FacturaCargadaIXML :=
       LoadXMLData(XMLVerifactu).GetDocBinding('sum:RegistroAlta', TXMLRegistroFacturacionAltaType, '') as SuministroInformacion.IXMLRegistroFacturacionAltaType;

FacturaCargadaIXML.XML es correcto, varga el XML , la carga , pero el FacturaCargadaIXML.IDVersion , etc... esta vacío , parece que no coloca los nodos en su sitio.


Antes de no poder usar LoadXMLData igual alguien tiene una solución.

Gracias y Saludos

[keno_71]

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

Pero tú puedes tener un cliente en SII, por lo tanto tu programa funcionaría sin enviar a verifactu, pero el cliente al año siguiente a lo mejor (por error o por lo que sea ) no avisa que no está en el sii y no estás enviando las facturas, yo no tengo claro que no haya que realizar todo lo de los eventos.

Ayer hice una consulta a hacienda donde preguntaba si hay alguna consulta donde podamos saber si un cliente está en el SII o no y nos dijeron que no, que con el certificado del mismo cliente si, pero no existe tal consulta y que por lo tanto es el cliente el que debe controlar si un año está en el SII o no está en el SII y si debe realizar verifactu o no por ese tema.

Hice otra consulta que si podíamos realizar verifactu con un cliente con SII pero todavía no me han respondido.

[novatico]

Como se ha comentado mucho sobre las diferencias entre las obligaciones entre un Sistema Informático de Facturación VERI*FACTU y otro NO VERI*FACTU, he elaborado una lista con las obligaciones añadidas a NO VERI*FACTU, como punto de partida para que podamos añadir, quitar o corregir si he cometido errores.


- Obligación de conservar los registros de facturación y de eventos, asegurando su inalterabilidad e integridad
- Firmar con certificado cada factura del registro de facturación y cada evento (Art.6.c OM)
- Poder comprobar, bajo demanda, si la firma electrónica es válida (Art.6.d OM).
- Poder comprobar, bajo demanda, si toda o una determinada parte de la cadena de registros de facturación es correcta (Art.6.e OM).
- Poder acceder a consultar, comprobar y exportar la información del Registro de Facturación, en un formato legible y fácilmente accesible.
- Poder remitir, por requerimiento, los registros de facturación y de eventos a la AEAT.
- Generar el Registro de Eventos de:

- Inicio del funcionamiento del sistema informático como «NO VERI*FACTU».
- Fin del funcionamiento del sistema informático como «NO VERI*FACTU».
- Lanzamiento del proceso de detección de anomalías en los registros de facturación.
- Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de facturación.
- Lanzamiento del proceso de detección de anomalías en los registros de evento.
- Detección de anomalías en la integridad, inalterabilidad y trazabilidad de registros de evento.
- Restauración de copia de seguridad, cuando ésta se gestione desde el propio sistema informático de facturación.
- Exportación de registros de facturación generados en un periodo.
- Exportación de registros de evento generados en un periodo.
- Registro resumen de eventos
- Otros tipos de eventos a registrar voluntariamente por la persona o entidad productora del sistema informático.

En la detección de anomalías en los registros de facturación y en los de eventos, se concretará si el fallo detectado es por:

- Integridad-huella
- Integridad-firma
- Integridad - Otros
- Trazabilidad-cadena-registro - Reg. no primero pero con reg. anterior no anotado o inexistente
- Trazabilidad-cadena-registro - Reg. no último pero con reg. posterior no anotado o inexistente
- Trazabilidad-cadena-registro - Otros
- Trazabilidad-cadena-huella - Huella del reg. no se corresponde con la 'huella del reg. anterior' almacenada en el registro posterior
- Trazabilidad-cadena-huella - Campo 'huella del reg. anterior' no se corresponde con la huella del reg. anterior
- Trazabilidad-cadena-huella - Otros
- Trazabilidad-cadena - Otros
- Trazabilidad-fechas - Fecha-hora anterior a la fecha del reg. anterior
- Trazabilidad-fechas - Fecha-hora posterior a la fecha del reg. posterior
- Trazabilidad-fechas - Reg. con fecha-hora de generación posterior a la fecha-hora actual del sistema
- Trazabilidad-fechas - Otros
- Trazabilidad - Otros
- Otros


Un saludo.

[Sistel]

Empezado por espinete

¿Alguien sabe si en las facturas con Recargo de Equivalencia hay que indicar "ClaveRegimen = 18" (Recargo de Equivalencia) o no?

Estoy enviando facturas con Recargo de Equivalencia y me las acepta sin errores tanto con ClaveRegimen = 01 como con ClaveRegimen = 18

Otra cosa:

Estoy recibiendo este error...

Codigo[4112].El titular del certificado debe ser Obligado Emisión, Colaborador Social, Apoderado o Sucesor.

...cuando intento enviar una factura como persona física, usando mi NIF y Nombre reales.

Lo curioso es que ya he enviado varias igual, y han sido aceptadas, pero de repente ahora me da ese error

Confirmado: he vuelto a intentarlo 10 minutos después y ya no me da el error

Hola,

Son 2 cosas diferentes:
- Una es el régimen de IVA en el que está dado de alta, en la AEAT, el emisor de la factura: régimen normal, régimen simplificado, régimen de recargo de equivalencia, etc
- Y otra es emitir una factura a un cliente que está en régimen de recargo de equivalencia y por tanto hay que emitírsela con RE.

Saludos

[espinete]

Empezado por Sistel

Hola,

Son 2 cosas diferentes:
- Una es el régimen de IVA en el que está dado de alta, en la AEAT, el emisor de la factura: régimen normal, régimen simplificado, régimen de recargo de equivalencia, etc
- Y otra es emitir una factura a un cliente que está en régimen de recargo de equivalencia y por tanto hay que emitírsela con RE.

Saludos

Gracias, Sistel

El problema, o mi confusión, viene porque creo recordar que en TicketBAI, la suma de los importes, cuotas, etc. era distinta si el emisor está en régimen de Rec. Equiv. o si es solo el cliente final el que está acogido al Rec. Equiv. O al menos cuando ambos (emisor Y receptor) estaban acogidos al RE.

Pero VeriFactu "parece" más sencillo a la hora de hacer los cálculos, no sé si es apreciación mía o es que realmente es así.

Total, recapitulando...

Si el Emisor está en Regimen de Recargo de Equivalencia, hay que marcar la Clave Regimen "Recargo de Equivalencia"
Pero si solo es el cliente quien está acogido al RE y debemos emitir una factura acogida al RE, entonces eso no es necesario, y basta con indicar los porcentajes y cuotas del RE en el desglose.
Y si ambo están acogidos a RE, pues ambas cosas.

¿Correcto?

Quiero tener claro estas cosas antes de meterme a hacer pruebas con rectificativas, sustitutivas, inversión del sujeto pasivo, etc.

[espinete]

Tengo una duda con respecto a las "validaciones" del XML antes del envío. Me gustaría saber cómo lo planteáis vosotros...

Para evitar facturas rechazadas y tener que estar emitiendo sustitutivas, anulaciones, rectificativas, etc. lo ideal sería comprobar que todas las validaciones (del documento de validaciones) son correctas.
Como son un rollo bastante complejo, con opciones enlazadas unas con otras, algunas que no pueden marcarse juntas pero con excepciones, etc... ¿cómo lo hacéis vosotros? Porque yo hoy casi termino con dolor de cabeza.

En nuestro software, el usuario elije en un desplegable algunos de estos datos (tipo de rectificativa R1, R2, R3, motivo de factura exenta, etc.) y otras son automáticas (según la configuración del programa, según tipo de empresa (regimen iva...), según la provincia (IVA, IGIC o IPSI), etc.).

Por lo tanto, cuando llega el momento del envío, antes hay que comprobar que lo que ha elegido el usuario para cada documento, es compatible con lo demás.

Yo actualmente genero el XML primero y una vez generado, antes de enviarlo, lo "valido" y, o bien lo envío o muestro un error y cancelo el envío, pero no sé si es la mejor forma de operar o no.

Encima hay que revisar uno a uno los porcentajes de iva y re, con la fecha de la factura, etc. En fin