Skip to Content
Overview

E-Mail is one of the most favored approaches to distribute NF-es with your business partners. One way to achieve this is using the B2B interfaces from GRC NFE combined with the approach described by Henrique Pinto in his article Using SAP PI Lookup API and Dynamic Configuration in SAP GRC NFE Outbound B2B Interface for Dynamic E-mail Determination.

With GRC NFE 10.0 the CNPJ is not necessarily part of the payload, but comes within the XI header of the message (field SAP:Service, e.g.

<SAP:Service>CNPJ01234567800300</SAP:Service>). This is problematic for the Cancellation message when there is no CNPJ inside the payload anymore. Therefore, the approach describe in Henrique’s article must be a little bit amended.

With newer releases of SAP Process Integration (7.1 and above) it is recommended to use the additional attachment in order to pre-populate the email addresses and set them directly in a message mapping. In order to get it working in XI 3.0 / PI 7.0 again, we have to use the Enhanced Receiver Determination to set the Dynamic Configuration. However, the approach which is described in the remainder of the document works for all releases.

Enterprise Services Repository

First, go to the Repository and create a new Message Mapping from the Cancellation External Definition govProcCancNFe to Message Type Receivers from the SAP BASIS 7.xx SWCV. Since one usually has one generic mail channel where the email address is dynamically set we can populate the Receiver Party with a constant.

For the field Receiver Service we have to use our existing UDF (User-defined Function) that makes the lookup of the mail address from the CNPJ and writes that mail address into the Dynamic Configuration. The CNPJ is now read from the already populated receiver field (available in the mapping under Functions -> Constants -> receiver) which can be used to lookup the corresponding mail address. The output of that UDF can be a constant for the Receiver Service.

MM_procCancNFe_TO_Receivers.PNG

The next step is to create a corresponding Interface / Operation Mapping for that Message Mapping. Sender Interface is CTB2B_procCancNFe_OB and the Receiver Interface is ReceiverDetermination from the SAP BASIS 7.xx SWCV. Finally, save and activate all your changes.

Integration Directory

In the Directory you have to amend the Receiver Determination using your freshly created mapping as shown in the screenshot below. Save and activate your changes.

ReceiverDetermination.PNG

That’s it. The approach from the original article will now work  in GRC NFE 10.0 as well.

Technical background

With a generic mail receiver you will overwrite the receiver in the standard Receiver Determination that is executed prior to the mapping. Therefore, the standard message mapping has no chance to read CNPJ value from the Receiver because it is already overwritten with your own Receiver Service. If you create an own B2B party / service for each receiver you have to populate the Receiver Service field with the Context Object ReceiverService. The pre-populated receiver will then be taken.

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

  1. Rafael Vieira

    – You said: “Since one usually has one generic mail channel where the email address is dynamically set we can populate the Receiver Party with a constant.”

    Receiver Party, you mean, is it the Message Mapping structure (Receivers > Receiver > Party – agency / – scheme)? So we would mapp a constant to them both? Why not leaving them with no value, since they’re optional fields?

    “The CNPJ is now read from the already populated receiver field (available in the mapping under Functions -> Constants -> receiver) which can be used to lookup the corresponding mail address.”. Could you put some light here to help me understand how I could retrieve the CNPJ from the Receiver field? Would it be inside the UDF? I’m not a Java expert so I don’t know exactly how I could retrieve it.

    – Lastly, since we are able to get the CNPJ, do you thing we could, instead, retrieve the Access Key field? I’ve requested the RFC development based in the Access Key content so it would make things easy for me.

    Thanks for this great post!

    (0) 

Leave a Reply