ANFAVEA is the Brazilian National Association of Automotive Vehicle Manufacturers. It is usually responsible for defining standards that are used throughout the automotive Supply Chain (parts suppliers and OEMS). For example, historically ANFAVEA has been responsible for defining EDI message standards that are used in the Data Exchange processes between companies in the automotive supply chain.
With the upcoming of NF-e B2B messages exchange, ANFAVEA has proposed an extension to the standard NF-e layout, including information that would avoid double messages exchange. This proposal (Portuguese only) can be found in the following path:
- access http://www.anfavea.com.br/;
- select "EDI" on the left menu;
- go to the "XML / NF-e" option; and
- follow to the "Extensão NF-e" link.
Alternatively, you can go to the direct link: http://www.anfavea.com.br/documentos/Extens%C3%A3oNF-e_v1.0-00.pdf.
This document includes some samples which show the use of CDATA tags to enclose the inner ANFAVEA specific fields, as shown below:
Within SAP NFE, by default, it is not possible to create contents with the CDATA tags, because all content that is sent from the backend ERP system is escaped automatically.
This happens when the ABAP variables content is converted to the ABAP Proxy XML content (e.g. t "<" characters are replaced by the "& lt;" entity reference).
According to XML standards, however, all XML compliant applications need to be able to interpret both escaped special characters and CDATA tags contents in the same way, so this shouldn't be an issue at all. This is also corroborated by the Government NF-e Implementation Guide ("Manual de Integração do Contribuinte"), in the section 5.3, where the escaping of special characters is described as mandatory (though the Government SEFAZ applications are able to interpret both escaped and CDATA tags).
However, since the ANFAVEA document is not clear regarding this, some companies are demanding that their suppliers send the NF-e fields with CDATA tags and don't accept escaped tags. Though this is not feasible by simply filling the fields in the fields of the function that triggers the NF-e creation in SAP NFE, it is possible to achieve this by developing a Java Mapping and making some simple configurations to make use of this mapping in the NF-e standard interfaces.
Notice however that this will never become an SAP "standard" feature, being customer specific, and hence it is not due to any kind of support or maintenance. This proposal is to be interpreted as a project accelerator and is intended to show SAP NFE customers that it is possible to make use of the underlying SAP NetWeaver platform (in this case specifically, making use of SAP PI) to achieve such specific requirements and to enhance the customer experience of SAP standard solutions.
This proposal considers that the regular NFE scenarios are already in place, meaning that just the delta development/configurations will be discussed here.
Also, this proposal considers that the developer is familiar with the development of Java Mappings on SAP PI.
2.1. SLD Configuration
In the SLD, it is necessary to create a Software Component Version (SWCV) that will contain our custom developments. However, in order to make our job a lot easier and avoid redefining standard objects which we'll not change, it is possible to add the standard SLL-NFE SWCV as a dependency of our customer SWCV. This way, we'll be able to refer to all objects in the standard SWCV in our custom objects.
In order to add a dependency, go to the SLD home page and click on Software Components (under the Software Catalog section). Browse your custom SWCV and, on the Dependencies tab, search and include the standard SLL-NFE SWCV, as pictured below. The Dependency Context is not really important for us, so you can leave it in the default option (Installation Time dependency).
Make sure that your SLD CR Content Version is at least 3.10, or else you won't be able to see the SAP NFE Product and Software Components in the SLD Software Catalog. In order to check that, go to the SLD home page -> Administration -> Details -> Data tab and check the SAP CR Content Version value.
3.1. Java Development
Create a new Java Project in SAP NetWeaver Developer Studio and add the SAP Java Mapping API (aii_map_api.jar from SAP PI server) as an External Jar Library. Create a new package with the name com.sap.sdn.nfe. Within this package, create 3 classes with the following details:
Implements: StreamTransformation interface (com.sap.aii.mapping.api package)
Your project should look like the one below.
This proposal uses the old Java Mapping API from PI 7.0 which works for both PI 7.0 and PI 7.1.
Your Mapping class must implement the StreamTransformation Interface, as described here:
JAVA Mapping API (SAP NetWeaver 2004 and 7.0)
Add the following codes to the classes:
Save all files and export the project to a .jar file (include just the 3 classes, there is no need to include the Model and the .classpath and .project files). Export both the source and the generated files.
As of SAP PI 7.1, you can use the new SAP Java Mapping API. Your Java Project should include the new API façade and the Mapping classes should extend the AbstractTransformation class, as described here: Runtime Environment (Java Mappings)
In case you decide to use the new Mapping API, the code above needs to be adjusted accordingly.
3.2. Integration Repository
The idea is to modify an existing Interface (Operation) Mapping to execute the Java Mapping above to modify the NF-e XML content before actually sending it to the Digital Signature web service.
3.2.1. Imported Archive
In your custom SWCV, create a new namespace. Within this new namespace, create a new Imported Archive and import the .jar file that you exported from the NetWeaver Developer Studio as described above. Save and activate it. It should look like this:
3.2.2. Interface (Operation) Mapping
Since we've added the standard SLL-NFE SWCV as a dependency of our customer SWCV, we can create modified versions of the standard objects without actually modifying the standard SWCV. For more details, check this link: Modifying an Object
Once you've added the dependency, a new Basis Objects node should appear in your custom SWCV, right below your namespaces and Imported Objects. Within this new node, you can find all the standard objects in the SLL-NFE SWCV, however here they're included in your custom SWCV. It's more or less like if the system had automatically created Z versions of all standard objects within your custom SWCV.
Go to the SIGNN_SignNfe_TO_signIn_doc interface (operation) mapping in the Basis Objects node. Enter into Edit mode and click on Modify. In the Mapping Program list of the Request mapping, include a new Java Class and search for the AnfaveaNFeExtension class that you imported in the previous step. Notice that it must be the first of the list; click on the arrows if necessary to move the mappings across the list.
Save your interface (operation) mapping, click on Modify again and activate it. It should look something like this:
Also, notice the icon right next to your modified object. It means that this object was modified from the standard version. If you delete your modification, it will just retrieve the original version of the object.
3.3. Integration Directory
In the SAP PI Integration Directory, it is necessary to replace the interface mapping added to the Interface Determination of the NFE Signature scenario with the interface mapping that was modified in the custom SWCV.
3.3.1. Interface Determination
Considering that you've already run the Configuration Scenario wizard for the standard NFE Signature Integration Scenario (NFE_SIGNN_WebAS_Outbound_SignNFe), it is necessary just to replace the Interface (Operation) Mapping by the one you've customized. Open the Interface Determination for the SIGNN_SignNFe_SYNC interface, enter on Edit mode and replace the Interface (Operation) Mapping in the standard SLL-NFE SWCV with the one you modified in your custom SWCV.
The mapping was developed in a way to ignore any content in the <infAdProd> and <infCpl> tags sent from ERP unless it starts with the literals "ANFAVEA" (case sensitive). If it doesn't start with that string, the generated XML will have the exact same content that was sent from ERP.
The Anfavea structures were defined in the code as instances of the AnfaveaField and AnfaveaAttribute classes. A possible improvement in the current code would be to define XML Schema Definitions (.xsd) files for the Anfavea layouts and read the Anfavea structures from these files.
The Anfavea fields contents must be sent with a pipeline separator ("|") right after the "ANFAVEA" string. The mapping expects for the exact same number of fields that is described in the layout within the Anfavea NF-e Extension document (9 for the <infCpl> tag; 25 for the <infAdProd> tag). So, even if the field doesn't need to be created, it is necessary to send the field as empty (two consecutive pipelines, e.g. "||").
For example, filling the INFCOMP and INFADPROD fields (in the FILL_HEADER and FILL_ITEM methods of the CL_NFE_PRINT BAdI in ERP, respectively) with the contents below:
would result in the following XML (after SEFAZ approval):
The choice of the SIGNN_SignNfe_TO_signIn_doc Interface (Operation) Mapping was done because this mapping is executed during the synchronous communication between SAP PI (Integration Process) and the Digital Signature Web Service. If there is an error during this mapping execution, the Integration Process will send a negative acknowledgement back to the GRC NFE system, which will then let the signature process of this NF-e to be available in the Restart tab. In this way, it is possible correct the content back in the ERP backend system (e.g. correct any errors in the CL_NFE_PRINT BAdI implementation) and restart the signature process from the point it was erroneous, avoiding unnecessary NF-e number skipping.
As commented above, the mapping will ignore any content of the <infCpl> and <infAdProd> tags that are not started by the literals "ANFAVEA". In case the literals are in place but the subsequent contents are not as expected (e.g. fewer number of fields then the expected, no pipeline separators etc.) an exception will be thrown, what will trigger the negative acknowledgement and set the process as able to be restarted.
Finally, notice that even if it is technically possible to achieve these requirements, since the Anfavea requirements are not aligned with the Government Implementation Guide requirements, it is possible that some SEFAZ systems will reject the NF-e which contains CDATA tags within its contents. This is a situation that needs to be handled between Anfavea and the respective SEFAZ authorities.
The intention of this proposal was not necessarily to address this topic specifically but just show that, even if some specific requirement is not addressed by the standard SAP solutions, it is possible to use the underlying NetWeaver platform to enhance the standard features and meet the custom requirements, without impacting in the standard solution and the subsequent updates/releases.