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