Vista en BVista 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.
...
Se han creado tres tipos de comunicación con la AEAT: Comunicación por PI asíncrona, comunicación Cloud por FUSE asíncrona (TO_DO) y comunicación Cloud PT (pasarela) por FUSE síncrona.
...
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 PT síncronaasíncrona
Para este tipo de comunicación, se provee por defecto la clase clase /EDGE/CL_SII_COM_AEAT_CLOUD_PTAS. 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 SOA Manager SOAMANAGER y se configura el EndPoint del Proxy.
Se selecciona el proxy: El servicio para el que hay que configurar el endpoint es el /EDGE/CO_SII_CLOUDPROCESAR_LOT
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),
| Advertencia | ||
|---|---|---|
| ||
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).
Comunicación Cloud asíncrona
TO_DO
Equivalencia entre estados MW y eDoc
...
- /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.
Es 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. Para ello, inicialmente, es necesario crear 2 Webservices asociados a ellas. Se indican los pasos para una de las RFC, la otra es completamente análoga:
Una vez configurados ambos Web Services, debe configurarse un endpoint para cada uno de ellos 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:
...
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:
| Advertencia |
|---|
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.