The Ajuste SINIEF #8, from 07/09/2010 has introduced a new requirement to the NFE B2B communication interfaces. The companies which issue NFes are now required to send the NF-e XML files to both the Nota Fiscal receiver (identified by the <dest> tag, within the XML) and to the carrier which was hired to transport these goods (identified by the <transp>/<transporta> tag, within the XML).
At a first glance, it might seem a bit complicated to support this scenario out-of-the-box, since the standard NTB2B and CTB2B (outbound b2b) interfaces just include an identifier for the receiver's CNPJ, making it hard to route the message to the carrier. However, for those companies which handle the B2B outbound communications through e-mails and have implemented the Dynamic determination of the receiver's e-mail address, according to the definitions from this article, supporting this scenario becomes quite simple.
The required modifications from the original proposal presented in the article are discussed below.
The solution proposed in this wiki considers that the Dynamic Configuration of communication details has been implemented. The details on this scenario are discussed in this article.
Additionally, this proposal considers that the adapter used in the B2B communication is of the type Mail (i.e., the communication to both the receiver and the carrier happens through an e-mail address). This is required due to the fact that the proposed solution does not create separate receivers for both the receiver and carrier. It continues to use a single generic receiver in PI, and hence just one single communication channel will be triggered. By using the Mail adapter, it is possible to send a message to multiple e-mail addresses, by including these addresses separated by semi-collons in the "TO" field.
A more complex solution will be proposed afterwards, including a separate handling of different generic parties for the receiver and carrier, hence supporting the possibility to use any desired protocol (adapter) for each communication partners.
Furthermore, in order to trigger the sending of the XML to the carrier, as per this proposal, it is mandatory that the receiver of the NF-e is already maintained as a valid B2B partner in the /XNFE/TB2B table (i.e. it wouldn't be possible to trigger the B2B interface for just the carrier).
Finally, notice that this proposal just works for the NF-e XML outbound B2B (NTB2B) interface, i.e. it will not support sending the cancellation XML file to the carrier. However, due to the fact that the law above does not mention the sending of cancellation XML files to the carrier, and since in the case of the carriers, the B2B communication will most likely not be integrated within a complete business process (they just want the XML to derive necessary information to be included in the CT-e XML files), this is not a major issue at this point.
Below, the necessary changes to the implementation sugested in the discussed article are presented.
3.1. RFC Parameters update
In order to support the retrieval of both the receiver and carrier communication details, it is necessary to update the RFC structure proposed in the article.
After you have changed the RFC in the ABAP backend, reimport it in your custom SWCV in the Integration Repository / Enterprise Service Repository of PI and activate the changes.
Notice that if this RFC was alredy being used, it was probably cached, and your subsequent attempts to communicate through the new interface will fail. In order to refresh the cache, go to the Integration Directory / Integration Builder of PI and re-activate the RFC communication channel that connects to the ABAP backend where this RFC is being executed.
The implementation of this RFC is not subject to discussion in this proposal. However, notice that differently from the receiver case, where the communication details is usually read from the Customer Master Data, for the carrier it will probably be the case to search it within the Vendor Master Data.
3.2. Message Mapping
Within the message mapping, a couple of modifications are required.
First, notice that it is no longer possible to use the <CNPJRec> field to derive the CNPJ code to retrieve the communication details. This is due to the fact that this field just holds the Receiver CNPJ, but not the Carrier CNPJ. Hence, it is necessary to first derive the CNPJs from the actual NF-e XML message and just later call the RFC and set the dynamic configuration.
In order to achieve that, replace the location of the UDF from the <CNPJRec> tag to the <procNFeStr> tag, as shown below.
The UDF (called setMail in this example) needs 3 input parameters, similar to the one proposed in the article (but in this case, the 1st input parameter is the XML content, and not the CNPJRec field).
The packages to be imported are the same as in the original article.
The signature (input parameters) of the UDF must be as shown below.
A sample code for the UDF is shown here: Sample code for the setMail UDF (Carrier B2B)
And that's it. Save and Activate your changes.
In order to test the enhancements, first you'll need to create an NFe with the data from the carrier mapped to the <transp>/<transporta> tag. If you're using SAP ERP, you can just create a new NF-e and, before saving it, include a Vendor with type Carrier as a Partner in the Nota Fiscal.
Once this NF-e is approved, you'll be able to see the carrier data in the XML.
After you create a sample NF-e with carrier data, you can create a new test message in the Test Message interface in the Component Monitoring of Runtime Workbench, in order to further execute the test (not requiring to create an actual NF-e in ERP every time you want to reproduce the test for the B2B interface).
After you execute your test, in SXMB_MONI, you can find the logs generated by your UDF code in the Mapping trace, helping you identify whether your mapping was executed successfully.
And if everything works ok, you'll be able to see both addresses in the "To" field of the e-mail.