Vista en b+SII:

En este punto se va a explicar las parametrizaciones Middleware que se deben hacer para la comunicación con la AEAT. Se tratan dos apartados: Parametrización Middleware en la tabla de SAP y las equivalencias entre los estados que devuelve el Middleware tras procesar eDocuments.

Parametrización MW en SII

En el apartado 8.1 se detallan los campos a informar para la parametrización con el Middleware.

Se han creado tres tipos de comunicación con la AEAT: Comunicación por PI asíncrona, comunicación Cloud por FUSE asíncrona y comunicación Cloud PT (pasarela) por FUSE síncrona.

Estas tres comunicaciones (clases) parten de una interfaz común: /EDGE/IF_SII_COMUNICACION_AEAT. Esta interfaz se compone de 5 métodos:

Método	Descripción
ENVIO	Envío de los parámetros necesarios sobre el Lote o Lotes que se generan y envían para comunicarse con la AEAT al Middleware.
INT_ENVIO	Interrumpir envío. Este método se utiliza para las comunicaciones asíncronas cuando el Middleware ha devuelto un error técnico. Si se desea descartar el lote, primero debemos interrumpir el envío para que no haya una inconsistencia entre los estados de los eDocuments. Cuando se realiza el envío, el Middleware por su cuenta intenta el envío tantas veces como se haya parametrizado. Si inicialmente ha llegado un error técnico, y queremos descartar el lote, si no ejecutamos antes la interrupción puede ser que en uno de los tantos intentos del Middleware alguno sea éxito y llegue este estado al monitor cuando nosotros hemos decidido descartar lote sin interrumpir el envío antes, lo que causaría una inconsistencia.
DESCARTAR_LOTE	Este método sólo se utiliza en las comunicaciones asíncronas. Cuando se ha producido un error a nivel de Middleware y se desea descartar el lote se debe informar al sistema Middleware de dicho descarte para que el estado de este lote sea consistente en todos los sistemas de la arquitectura.
INT_ENVIO_DESCARTAR_LOTE	Interrumpir envío y descartar lote. Es una suma de los dos métodos anteriores.
REENVIO	En las comunicaciones asíncronas este método se utiliza para forzar el reenvío cuando ha habido un error técnico.

Comunicación por PI

Para este tipo de comunicación se provee por defecto la clase /EDGE/CL_SII_COM_AEAT_PI. En el caso de que se trabaje con la versión 7.10 de la solución b+ SII PI se deberá parametrizar la clase /EDGE/CL_SII_COM_AEAT_PI_710.

Con esta comunicación, PI facilita la herramienta sproxy que agiliza la creación del Web Service por el cual se establece la comunicación con el Middleware.

Comunicación Cloud asíncrona

Para este tipo de comunicación, se provee por defecto la clase /EDGE/CL_SII_COM_AEAT_CLOUD_AS. Con esta comunicación es necesario configurar el Proxy para consumir el Web Service. Esta configuración tiene que ser configurada por el implantador de FUSE y ABAP donde el cliente tiene que informar del endPoint y el puerto.

Para ello se accede a la transacción correspondiente de SOAMANAGER y se configura el EndPoint del Proxy.

El servicio para el que hay que configurar el endpoint es el /EDGE/CO_SII_CLAPROCESAR_LOTE1.

Se crea el puerto lógico:

Finalmente, se añaden las configuraciones necesarias:

Usuario y contraseña de cloud (a facilitar por el implantador de Cloud),

Usuario Cloud

El usuario a incluir no es un usuario de SAP, es un usuario de Cloud (FUSE)

(Importante: Marcarlo como puerto por defecto).

(Importante: Seleccionar la opción "Supress ID Transfer").

(Importante: Normalmente se utiliza protocolo HTTPS para comunicación con FUSE).

(Importante: En el servicio asíncrono debemos cambiar la configuración de la pestaña "Transport Settings". En la URL de acceso tenemos que poner: /entrada_fuse/services/ProcesarLoteSII).

Equivalencia entre estados MW y eDoc

Se trata en el apartado 8.2.

RFCs

Se han creado dos RFCs capaces de tratar los mensajes de la AEAT recibidos a través del Middleware. Se ha elegido utilizar RFCs porque son invocables desde cualquier punto de un sistema SAP con conexión RFC o del propio sistema en el que se encuentran y porque se pueden implementar Servicios Web en base a ellas. Las RFCs que se utilizan son:

/EDGE/SII_ESTADO_LOTE_MW: creado como RFC, se utilizará para cambiar el estado de un lote en el contexto del funcionamiento de sus comunicaciones, para ello recuperará el estado Middleware y lo asociará al proceso eDocument, comunicando el proceso de paso al lote. Posteriormente recuperará y actualizará el contenido de la tabla /EDGE/SII_GUIDPI. En caso de que se esté registrando un error y de que se haya superado el número de errores parametrizado se disparará una alarma mediante la BAdI /EDGE/BADI_SII_ALERTAS. Por último en caso de que se haya recibido un fichero además de la información de cambio de estado pertinente se anexará dicho fichero al lote.
/EDGE/SII_RESPUESTA_AEAT: creado como RFC, se utilizará para recibir y tratar la respuesta de la AEAT a un lote. En función del parámetro IV_ESTADO_LOTE_AEAT con el estado de la respuesta se aceptarán, aceptarán con errores o rechazarán los lotes mediante llamadas a métodos estáticos de la clase /EDGE/CL_EDOC_SII.

La gestión de la respuesta desde el middleware se gestiona a través de dos servicios creados en base a estas RFCs arriba indicadas (se suministran en el propio add on y son válidos tanto para el caso CLOUD síncrono como para el caso CLOUD asíncrono). Los nombres de estos dos servicios son los siguientes:

/EDGE/SII_RESPUESTA_AEAT Servicio Web respuesta AEAT
/EDGE/SII_ACT_ESTADO_LOTE Servicio Web actualización estado lote

Por lo tanto, ya no es necesario configurar servicios asociados a estas RFCs para que estén disponibles a la hora de recibir las respuestas de la AEAT que gestiona el Middleware. Tan solo habrá que configurar el endpoint de los mismos a nivel de proyecto. La forma de hacer esto es a través de la transacción SOAMANAGER. Se ha de seguir el siguiente procedimiento:

Por defecto, se presuponen las características que se indican a continuación para los Web Services (HTTP, usuario/password). Otras características diferentes han de explorarse en cada implantación de forma específica (HTTPS, etc.).

Una vez se tienen los dos endpoints para los dos Webservices, se selecciona el enlace "Open WSDL document for selected binding" para cada uno de ellos, para acceder al fichero WSDL y obtener en una de las últimas líneas del mismo el acceso al servicio creado.

El usuario de comunicación que se utilice para estos dos servicios debe tener ciertos permisos. El usuario en SAP debe tener asignado el rol SAP_XI_APPL_SERV_USER o otro rol con los objetos de autorización que este contiene. Por otro lado el usuario también debe tener el objeto de autorización S_SERVICE con estos dos servicios:

Para que en la tabla aparezcan las entradas de los servicios hay que ejecutar el modulo de función AUTH_TRACE_WRITE_USOBHASH desde la transacción SE37

Se debe marcar SERVICE_TYPE con 'WS' y en el nombre de SERVICE.

Finalmente, el usuario debe tener el objeto de autorización ZESI_ADM (administrador del SII) o en su defecto, ZESI_RFC, que es el objeto de autorización para poder acceder a las dos RFCs asociadas a los servicios de respuesta.

Navegador incompatible