Preámbulo

Estudio basado en la Edición 0 revisión 5 de la AEAT, de fecha 27 de Enero del 2017, verificados en la reunión del 15 de Febrero del 2017, en la que se definen los últimos cambios de esquema y la creación de WSDL.

A nivel resumido, los contribuyentes deberán remitir a la Agencia Estatal de Administración Tributaria la siguiente información sobre la facturación:

• Registro: Libro registro de facturas recibidas y expedidas, bienes de Inversión, operaciones en metálico y libro de registro de determinadas operaciones intracomunitarias

• Tipo de operación: a identificar mediante CLAVES y SUBCLAVES. (Las claves serían similares a las actuales del modelo 340: factura simplificada, factura rectificativa, Inversión del sujeto pasivo, IVA de caja y resto de regímenes especiales..)

• Datos de la factura / factura simplificada (art. 6 y 7 del RD 1619/2012): NIF, identificaciones, Fecha devengo y expedición, tipos, bases y cuotas….

• Otros datos: cuota deducible indicando si la operación corresponde a bienes corrientes o de inversión, periodo de deducción, rectificaciones,…

El envío se realizará por vía telemática, concretamente mediante Servicios Web basados en el intercambio de mensajes XML. La estructura de dichos mensajes constará de una cabecera común con información sobre el titular de cada libro de registro y a continuación se incluirá un bloque con los datos de las facturas. Todos los mensajes mencionados se devuelven de forma sincrónica.

Para cada tipo de libro de registro se podrán realizar las operaciones de alta, baja y modificación masivas.

Para los libros de facturas recibidas y expedidas se podrán añadir cobros/pagos. La inclusión de cobros/pagos debe ir en un mensaje XML de envío independiente al del suministro de facturas emitidas y recibidas. La anulación de cobros/pagos se realizará enviando los cobros/pagos que se pretende anular con importe negativo, es decir, no existe un envío específico para bajas de cobros/pagos.

Una vez enviado el mensaje XML, la AEAT procederá a realizar automáticamente un proceso de validación, tanto a nivel de formato XML, como de reglas de negocio.

Si el mensaje no supera alguna de las validaciones a nivel de formato XML, AEAT devolverá un mensaje de tipo SoapFault, en el que se especificará el error concreto.

Si el mensaje supera las validaciones a nivel de formato XML, AEAT procederá a realizar las validaciones de negocio, devolviéndose un mensaje de respuesta con el resultado de la validación y de su aceptación o no por la AEAT.

En esencia el mensaje XML enviado por las empresas es un contenedor de facturas, con sus datos asociados, identificadas con una clave única. Es posible realizar modificaciones y bajas en los datos de las facturas enviadas. El número máximo de facturas por envío es de 10.000.

La unidad de información, factura, podrá ser aceptada, rechazada o aceptada con errores, consecuencia de las validaciones que se realizan en el momento de la presentación.

Si las facturas contuvieran errores, AEAT sólo se aceptará aquellas facturas para las que no exista motivo de rechazo. En caso de rechazo, se deberán realizar las correcciones necesarias y proceder a una nueva presentación en la que se incluirán las facturas que en su momento fueron rechazadas.

El mensaje XML de respuesta enviado por la AEAT contendrá la relación de facturas aceptadas, aceptadas con errores y rechazadas junto con la expresión del motivo por el que no hayan sido aceptadas o rechazadas con errores. En la respuesta también se informará del código seguro de verificación (CSV) que servirá para dejar constancia de la presentación, excepto en el caso de que se rechacen todas las facturas enviadas.

A su vez, en la respuesta también se incluye un resultado global de la presentación, que puede ser aceptada (si no existen errores en ninguna factura), aceptada parcialmente (cuando existen facturas aceptadas y rechazadas o aceptadas con errores) y rechazada (cuando todas las facturas han sido rechazadas).

Las operaciones de alta y modificación que se pueden realizar sobre la factura están recogidas en el campo del mensaje <TipoComunicacion> de envío. Todas las facturas enviadas en un mensaje XML deben tener el mismo tipo <TipoComunicacion> , es decir, en un mismo envío solo se pueden incluir facturas que respondan al mismo <TipoComunicacion> "altas" o "modificaciones". Nunca puede contener altas y modificaciones a la vez.

Las operación de baja de facturas se realizará en un mensaje XML específico para bajas, que contendrá una cabecera común y la relación de todas las facturas que se quieran dar de baja en un mismo envío. Cada factura estará identificada mediante el contenido de la etiqueta <IDFactura> . Además se deberá informar el ejercicio y periodo de la baja de cada factura.

La etiqueta <IDFactura> contiene los campos que identifican de manera única a una factura. Cuando en una presentación posterior desee realizarse una modificación de dicha unidad de información deberán enviarse las facturas a modificar y el valor de la etiqueta <TipoComunicacion> con valor modificación.

Las peticiones masivas realizadas a través de los servicios web definidos para cada unos de los tipos de libros de registro devolverán una respuesta en la que se indicará tanto, el resultado global del envío, como el resultado específico de cada factura/registro. El resultado global del envío estará incluido en uno de los siguientes estados:

• Aceptación completa

• Aceptación parcial

• Rechazo completo

El resultado parcial de cada factura/registro incluido en la petición se encontrará en uno de los siguientes estados:

 

Aceptada

Una presentación cuyo resultado sea la aceptación completa de la misma, indicará que todas las facturas o registros incluidos en la misma han pasado tanto las validaciones sintácticas, como las de negocio y que por tanto han sido registradas de manera satisfactoria por la Agencia.

Para las empresas inscritas en el REDEME que no deseen estar en el SII se ha previsto aprobar un plazo extraordinario para ejercitar la renuncia durante el mes de junio de 2017.

Aceptada con errores

Una presentación con Aceptación parcial, indicará que no todos las facturas o registros incluidos en la misma han sido aceptados correctamente y que por tanto los no aceptados no han pasado algún tipo de validación de las establecidas.

Será necesario el envío de una nueva presentación corregida que permita la aceptación de las facturas o registros erróneos.

Este tipo de respuesta se originará cuando existan en un mismo envío facturas/registros aceptadas o aceptadas con errores y también facturas/registros rechazadas

Rechazada

Una presentación con un rechazo completo de la misma puede deberse a dos casuísticas:

1. O bien la estructura definida en la presentación no es conforme al esquema definido (no cumple las validaciones estructurales), o bien, existen errores sintácticos en la cabecera y por ello toda la petición ha de ser rechazada. La respuesta se devolverá un mensaje de tipo SoapFault, en el que se especifica el error concreto.

2. Todas las facturas/registros incluidos en la petición no cumplen las validaciones sintácticas o de negocio (de la cabecera) asociadas y por tanto todas ellas han sido rechazadas.

 

Estándares Utilizados

La estructura de los mensajes se basa en la creación de esquemas XML utilizando la recomendación W3C de 28-Octubre de 2004 en http://www.w3.org/TR/xmlschema-0 y referenciada por el namespace http://www.w3.org/2001/XMLSchema.

Con relación a SOAP se utilizará SOAP V1.1 disponible como NOTA W3C de 08Mayo-2000 en: http://www.w3.org/TR/2000/NOTE-SOAP-20000508/ y referenciado por el namespace http://schemas.xmlsoap.org/soap/envelope/ .

En SOAP-1.1 existen dos estilos para implementar servicios, modo “rpc” y modo “document”. En línea con las recomendaciones actuales se utilizará siempre el modo “document” (style = ”document”) sin ningún tipo de codificación (use = ”literal”). Es decir el mensaje de entrada y salida estará descrito íntegramente por su respectivo esquema XML.

En la descripción de los servicios se usará WSDL 1.1 disponible como NOTA W3C de 14-Marzo-2001 en: http://www.w3.org/TR/2001/NOTE-wsdl-20010315 y referenciado por el namespace http://schemas.xmlsoap.org/wsdl/

• Protocolo: HTTPS

• Mensajes: Web Service con SOAP 1.1 modo Document.

• Certificado: Autenticación con certificado de cliente. El uso de los servicios requiere tener instalado un certificado electrónico reconocido admitido por la Agencia Tributaria, en el ordenador desde el que se produzca el envío de la información.

• Firma: Los  XML intercambiados no irán firmados.

G2K SII.