Ley antifraude 2021 (VERIFACTU) - Programas informáticos

[ermendalenda]

Empezado por novatico

Si, lo que han cambiado es que, en algunos nodos pasa de "sum" a "sum1" y viceversa.
Por ejemplo:
- la cabecera antes era "<sum1:Cabecera>" uy ahora es "<sum:Cabecera>"
- "RegistroAlta" justo al reves,

y sigo mirando.

Uno más:
- "<sum:RegistroAnulacion>" pasa a "<sum1:RegistroAnulacion>"

Ok muchas Gracias
Pero aún no lo deben haber actualizado, por que me da error.

[novatico]

Empezado por ermendalenda

Ok muchas Gracias
Pero aún no lo deben haber actualizado, por que me da error.

Acabo de probar con lo antiguo y funciona bien.

Ahora probaré cambiando.

Pues de momento, con lo nuevo falla.

[ermendalenda]

Empezado por novatico

Acabo de probar con lo antiguo y funciona bien.

Ahora probaré cambiando.

Pues de momento, con lo nuevo falla.

Ok, pero gracias, ya he tomado nota. habrá que esperar que lo pongan en el apartado de desarrolladores, de momento no se ven cambios.

[novatico]

Empezado por ermendalenda

Ok, pero gracias, ya he tomado nota. habrá que esperar que lo pongan en el apartado de desarrolladores, de momento no se ven cambios.

Yo solo lo he notado comparando el nuevo xsd con el antiguo.

[bmfranky]

An cambiado algunas chorradas, por ejemplo antes Se llamaba -> ahora.

Cabecera -> CabeceraType
CabeceraRemisionVoluntaria -> CabeceraTypeRemisionVoluntaria
CabeceraRemisionRequerimiento -> CabeceraTypeRemisionRequerimiento.
Han cambiado los namespaces generados en la importacion.


Xml Generado y enviado.

<?xml version="1.0" encoding="utf-16"?>
<RegFactuSistemaFacturacion xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<ObligadoEmision xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<NombreRazon>OBLIGADO</NombreRazon>
<NIF>XXNIFXX</NIF>
</ObligadoEmision>
<RemisionVoluntaria xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<FechaFinVeriFactu />
<Incidencia>N</Incidencia>
</RemisionVoluntaria>
</Cabecera>
<RegistroFactura xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">
<RegistroAlta xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">
<IDVersion>1.0</IDVersion>
<IDFactura>
<IDEmisorFactura>XXNIFXX</IDEmisorFactura>
<NumSerieFactura>VC1-24-100011</NumSerieFactura>
<FechaExpedicionFactura>25/10/2024</FechaExpedicionFactura>
</IDFactura>
<NombreRazonEmisor>OBLIGADO</NombreRazonEmisor>
<TipoFactura>F2</TipoFactura>
<FechaOperacion>25-10-2024</FechaOperacion>
<DescripcionOperacion>Venta de materiales servidos cliente contado.</DescripcionOperacion>
<Desglose>
<DetalleDesglose>
<ClaveRegimen>01</ClaveRegimen>
<CalificacionOperacion>S1</CalificacionOperacion>
<TipoImpositivo>21.00</TipoImpositivo>
<BaseImponibleOimporteNoSujeto>12.23</BaseImponibleOimporteNoSujeto>
<CuotaRepercutida>2.57</CuotaRepercutida>
</DetalleDesglose>
</Desglose>
<CuotaTotal>2.57</CuotaTotal>
<ImporteTotal>14.80</ImporteTotal>
<Encadenamiento>
<RegistroAnterior>
<IDEmisorFactura>XXNIFXX</IDEmisorFactura>
<NumSerieFactura>VC1-24-100010</NumSerieFactura>
<FechaExpedicionFactura>22-10-2024</FechaExpedicionFactura>
<Huella>FF2116821784D657D18CAF5EE5FD3B61E480EBE3187415DFB8E4F52A335692D3</Huella>
</RegistroAnterior>
</Encadenamiento>
<SistemaInformatico>
<NombreRazon>Yo mismo</NombreRazon>
<NIF>Mi Nif</NIF>
<NombreSistemaInformatico>Facturas Taller 2024</NombreSistemaInformatico>
<IdSistemaInformatico>A1</IdSistemaInformatico>
<Version>5.1.531.1509</Version>
<NumeroInstalacion>001</NumeroInstalacion>
<TipoUsoPosibleSoloVerifactu>S</TipoUsoPosibleSoloVerifactu>
<TipoUsoPosibleMultiOT>N</TipoUsoPosibleMultiOT>
<IndicadorMultiplesOT>N</IndicadorMultiplesOT>
</SistemaInformatico>
<FechaHoraHusoGenRegistro>2024-10-25T16:10:58+02:00</FechaHoraHusoGenRegistro>
<TipoHuella>01</TipoHuella>
<Huella>402CCF9B22FDB0F599C80AA3D5B677423B63060D3E76DAF34E48D5D44A56662C</Huella>
</RegistroAlta>
</RegistroFactura>
</RegFactuSistemaFacturacion>

Da Ko, con el nuevo dice que justamente no se ha encontrado la cabecera en el envio...

Codigo[4102].El XML no cumple el esquema. Falta informar campo obligatorio.: Cabecera

Hbra que esperarse un par de dias a ver si actualizan?

[novatico]

Empezado por ermendalenda

Si alguno puede traducir donde se produce el cambio, a nivel del xml, se lo agradeceria, ya que yo genero los xlm a pelo y me cuesta muchisimo leer el xsd

Yo trabajo igual que tú, genero el XML "a pelo".
Para ayudarme, cada vez que publican cambios en la estructura, me descargo el "wsdl" y los "xsd", en una carpeta nueva y vacía cada vez, y usando "SoapUI", tal como explicó algún compañero en este mismo foro, se puede generar un "xml" a modo de plantilla, lo que permite revisar más facilmente.

[ermendalenda]

Empezado por novatico

Yo trabajo igual que tú, genero el XML "a pelo".
Para ayudarme, cada vez que publican cambios en la estructura, me descargo el "wsdl" y los "xsd", en una carpeta nueva y vacía cada vez, y usando "SoapUI", tal como explicó algún compañero en este mismo foro, se puede generar un "xml" a modo de plantilla, lo que permite revisar más facilmente.

Llevas razón , desde el inicio del hilo
ll han dicho varias veces. Me tengo que instalar la herramienta y aun no la he puesto

[ermendalenda]

Por cierto sabéis que significa esto

...entendiéndose la necesidad de generar y realizar validaciones registros de facturación de forma independientemente, sin necesidad de incluirlos en un envío para ello...

Puede ser que haya que quitar el encapsulamiento soap?

[bmfranky]

Hombre algo an cambiado.
Antes.

<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroInformacion.xsd">

Ahora.

<Cabecera xmlns="https://www2.agenciatributaria.gob.es/static_files/common/internet/dep/aplicaciones/es/aeat/tike/cont/ws/SuministroLR.xsd">

[ermendalenda]

Empezado por ermendalenda

Por cierto sabéis que significa esto

Puede ser que haya que quitar el encapsulamiento soap?

Ya lo he entendido.
Bufff me cuesta
Significa que necesitan validar el xml contra xsd o wdsl sin tener que enviar.. y con el nuevo esquema lo.permite.

[bmfranky]

Empezado por ermendalenda

Ya lo he entendido.
Bufff me cuesta
Significa que necesitan validar el xml contra xsd o wdsl sin tener que enviar.. y con el nuevo esquema lo.permite.

Osea, para verifica la estrucktura del envio e integridad antes de enviar... y para los pobres mortales como yo, eso como se hace??

[bmfranky]

Hola, alguien sabe que es esto ?

ServicioVerifactu.IdOperacionesTrascendenciaTributariaType

Otra cosa ahora an añadido suministro de factura...

EstadoRegistroSFType
AceptadaConErrorres
Anulada
Correcta

Se viene envio de facturas tambien ademas de los registros?

[ermendalenda]

Empezado por bmfranky

Osea, para verifica la estrucktura del envio e integridad antes de enviar... y para los pobres mortales como yo, eso como se hace??

Tienes que tener opciones de importarte el xml y validarlo contra el xsd cada sistema de desarrollo lo tiene: vb, php...
Las funciones te devuelven si es correcto o donde tiene algun error,.por ejemplo un formato numérico que.le falte algún decimal obligatorio en el esquema xsd... eso te da más tranquilidad al enviar por que haces una co.probacion previa,y ea lógico que hayan solicitado a verifactu que modifiquen el esquema por que no se podía validar sin enviar, y lo lógico es que se pueda validar previamente

[bmfranky]

Empezado por ermendalenda

Tienes que tener opciones de importarte el xml y validarlo contra el xsd cada sistema de desarrollo lo tiene: vb, php...
Las funciones te devuelven si es correcto o donde tiene algun error,.por ejemplo un formato numérico que.le falte algún decimal obligatorio en el esquema xsd... eso te da más tranquilidad al enviar por que haces una co.probacion previa,y ea lógico que hayan solicitado a verifactu que modifiquen el esquema por que no se podía validar sin enviar, y lo lógico es que se pueda validar previamente

Pues a GooGlear se a dicho, a ver como se puede hacer con C#.

[bmfranky]

Por cierto, acabo de entregar el vehiculo a un cliente asesor fiscal, que venia de hacer un cursillo con los responsables de hacienda, y en tre otros "Palos", han hablado del verifactu, les han dicho que la entrada en vigor, obligatoria se aplaza hasta el 1 de enero de 2026, y que nos van a dar de tiempo hasta Julio de 2025, para que adaptemos los sistemas de facturacion y 6 meses desde ahi hasta enero para que los usuarios se acostumbren al uso hasta que porfin entre en vigor.
Supongo que no tardaran en comunicarnos a nosotros algo por el estilo.

[ermendalenda]

Empezado por bmfranky

Por cierto, acabo de entregar el vehiculo a un cliente asesor fiscal, que venia de hacer un cursillo con los responsables de hacienda, y en tre otros "Palos", han hablado del verifactu, les han dicho que la entrada en vigor, obligatoria se aplaza hasta el 1 de enero de 2026, y que nos van a dar de tiempo hasta Julio de 2025, para que adaptemos los sistemas de facturacion y 6 meses desde ahi hasta enero para que los usuarios se acostumbren al uso hasta que porfin entre en vigor.
Supongo que no tardaran en comunicarnos a nosotros algo por el estilo.

Si nuestro asesor nos ha dicho lo mismo, esperan aprobar el boe en breve y poner esas fechas,
Jejeje, ya verás de retrasos que meten después.
Ellos lo saben, pero tienen que ir poniendo plazos para que nos apretemos el culo.

[ermendalenda]

Empezado por bmfranky

Pues a GooGlear se a dicho, a ver como se puede hacer con C#.

Yo lo he intentado en vb y de hecho me comprobaba algunos xml/xsd antiguos, las nuevas versiones de xsd como tengan twngan referencias extrrnas me dan error. Estoy en el prerromano.
El año que viene tengo curso de .net pero ya se me hace tarde para pasar todo el software. He dedicado horas a buscar soluciones gratuitas y todo pasa a comprar apis etc. Paso de gastar para esos total si me devuelve error de estructura no se lo van a comer y la única diferencia es que me devolverá el error el envío, por que parar de facturar por eso no lo voy a hacer si lo demás está correcto, qr...
Y el qr es bastante difícil que sea erroneo, son pocos campos y ya está superverificado, así que desistí de esa validación. Además si hay que verificar contra un xsd con referencias a otros xsd externos hay que tener conexión y tendría que hacer más pruebas de 1ue pasa cuando no hay conexión cuanto tarda en devolver el error etc, más retardos
.aunque supongo que también los nuevos desarrollos te importan todas las referencias externas a tu sistema y se comprueba todo localmente, ya me contarás cuando pruebes.

[ermendalenda]

Sí, he dicho subsanación .
Buenas noticias para este lío.
Cuando me dé tiempo analizo respuesta que me ha dado verifactu para los distintos escenarios de errores en el cliente, y de principio parece que es con registro de subsanación.
Facil no?
Leo más detenidamente la respuesta y después os pongo la copia.

[bmfranky]

Empezado por ermendalenda

Sí, he dicho subsanación .
Buenas noticias para este lío.
Cuando me dé tiempo analizo respuesta que me ha dado verifactu para los distintos escenarios de errores en el cliente, y de principio parece que es con registro de subsanación.
Facil no?
Leo más detenidamente la respuesta y después os pongo la copia.

Pasate la info cuando puedas, mañana me tenia que poner justo a eso, cambiar destinatario de factura por error en el mismo...

[ermendalenda]

Empezado por bmfranky

Pasate la info cuando puedas, mañana me tenia que poner justo a eso, cambiar destinatario de factura por error en el mismo...

Hola, estaba de copas jeje, pero como veo que la necesitas y me has ayudado mucho te la paso, yo creo que es fácil de analizar pero erra largo de leer:

Integración VERIFACTU - Duda Funcional

*

Buenos días:

Le respondemos a los casos planteados:

Caso 1:
* *Incidencia:
* *El cliente solicita factura de una simplificada (tipo F2), para lo cual emito la sustitutiva o canje de la misma (tipo F3).

* * El usuario se equivoca y selecciona un cliente erróneo, pero no se le entrega al cliente


En cuanto el usuario corrige el NIF y emite una nueva factura, el SIF debe generar un nuevo registro de alta del tipo "ALTA DE SUBSANACIÓN", corrigiendo el NIF, *siempre y cuando no corresponda la emisión de una factura rectificativa. No es necesario realizar previamente una anulación de ese registro ya que deberían generar entonces dos registros sobre ese mismo IDFactura, uno de anulación y el posterior registro de alta de subsanación.


Caso 2:
* *Incidencia:
* *El cliente solicita factura de una simplificada (tipo F2), para lo cual emito la sustitutiva o canje de la misma (tipo F3).
* *El usuario se equivoca en algún dato del cliente pero en ese momento no lo sabe,
* *Se le entrega copia al cliente
* *Al siguiente reclama que se le subsane, cuando observa el error en por ejemplo Nombre de Empresa

Mismo procedimiento que en el caso anterior, en cuanto tengan conocimiento del error y emitan la nueva factura con el nombre de empresa corregido, el SIF debe generar un registro de ALTA DE SUBSANACION sobre ese IDFactura con el dato corregido, siempre y cuando no corresponda la emisión de una factura rectificativa.

Les recomendamos revisar los apartados de la documentación respecto a estas cuestiones. En concreto, pueden revisar el documento de diseño de registro y las hojas correspondientes a los cuadros de las operativas de altas y anulaciones. También pueden revisar en el documento de descripción del servicio web, el apartado "8. Anexo II: Operativa de «VERI*FACTU».*" donde se detalla la operativa en caso de altas iniciales, de subsanación, anulaciones, etc.

Además, le planteamos nuevos ejemplos para tratar de aclararlo en la medida de lo posible:

1. Usuario rellena factura y envía.

• Se rechaza en el momento de envío por algún motivo de error.

• Si el error no está contemplado en el registro de facturación (ejemplo: rechazo porque el NIF del destinatario es erróneo porque se han confundido al teclearlo) procede alta por rechazo. Se crea un NUEVO registro de facturación *con los datos corregidos, pero que sigue tratándose de la misma factura (mismo número de serie, NIF obligado y fecha de expedición). Se envía usando "Alta por rechazo" (· <Subsanacion>=S *<RechazoPrevio>=X).

• Si el motivo del rechazo es un error contemplado en el registro de facturación, y que se debe solucionar con una NUEVA FACTURA (con otro numero de serie, etc) entonces no procede el alta por rechazo, sino, que se deberá generar un nuevo registro de facturación que corresponderá con una nueva factura (distinto número de serie, NIF y fecha que correspondan), tendrá el indicativo de tipo de factura RX, y será un "alta" sencillo.



2) Supongamos que es el USUARIO quien se da cuenta de que emitieron la factura errónea, pero en su momento se aceptó correctamente. La casuística sería:

• Si el error que detecta el usuario posteriormente no está contemplado en el registro de facturación, (por ejemplo, quieren corregir el nombre que está mal, pero los apellidos estaban bien y por similitud se aceptó el registro) procede alta por subsanación. Se crea un NUEVO registro de facturación *con los datos corregidos, pero que sigue tratándose de la misma factura (mismo número de serie, NIF obligado y fecha de expedición). Se envía usando "Alta por subsanación" (<Subsanacion>=S y No informar <RechazoPrevio> o informarlo con valor N).

• Si el error que detecta el usuario es un error contemplado en el registro de facturación (se equivocan en el tipo impositivo) y que se debe solucionar con una NUEVA FACTURA (con otro numero de serie, etc). entonces no procede el alta por subsanación sino, que se deberá generar un nuevo registro de facturación que corresponderá con una nueva factura (distinto número de serie, NIF y fecha que correspondan), tendrá el indicativo de tipo de factura RX, y será un "alta" con la información que establezca el reglamento de facturación.



Es importante tener claro que el RD no modifica el reglamento de facturación. La misma forma de "solventar errores" que existía es la que se debe aplicar ahora. Esto requiere de conocimientos de la persona que emite una factura (igual que lo ha requerido anteriormente) para discernir si debe o no hacer una factura rectificativa, o si puede hacer una subsanación.

Para ello se publicarán FAQS con todas estas situaciones y documentación de ayuda, antes de la implantación obligatoria, en la SEDE de la AEAT.


Atentamente,
Atención al Usuario
Departamento de Informática Tributaria
Email:*[email protected]