Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
Showing results for 
Search instead for 
Did you mean: 

This blog is for whom is implementing the “eDocument: Electronic Invoicing for Italy” solution having only one SCPI (HCI) tenant and needs to have both production and test environment running in parallel. This is a nice-to-have option but after reading the following prerequisites you might understand this is not 100% applicable to your scenario. I’m just sharing my experience hoping it could help.



You have already deployed and tested the original package “eDocument: Electronic Invoicing for Italy” (version 1.0.2).

You have registered at SdI by indicating different endpoints for production and test at SOAP resource level, not at domain level. For example:



The reason is you cannot deploy two iFlows with the same endpoint (the sender side endpoint, the one called by the external application). That’s why we need to differentiate it when you copy a standard package in order to have it deployable.

To achieve it, you might:

  • Register at SdI with different endpoints (different at SOAP level), carry out the interoperability test, move to production and ask for the SdI experimental environment

  • If you've already registered your company (and even moved it to production), register a second company of the same group (if possible) indicating a different endpoint (same custom domain though); this new registered channel will be running up to 15 days (as per the SdI service agreement, then it could last more but not for good); after registering a new channel, you will get different certificates and they must be uploaded again, this is doable by following the instructions in the SAP note 2583309

If you registered the same endpoint for test and production endpoint, you might find interesting this blog.



Go to Discover, look for the “eDocument: Electronic Invoicing for Italy” package, copy it. Click on “Create copy”.

Provide a suffix.

Then it will appear in the Design section.


Before deploying all, I’ve done the following two steps.

1) Configure endpoints

Configure all the endpoints: not only those called by SdI but also those called by your SAP backend (remember you cannot deploy two equal endpoints). Here below some examples.

Italy Receive Invoice – Receive Invoice

Italy Receive Invoice – Pull Invoice

Italy Receive Notification – Pull Notification

Repeat it for the remaining endpoints.


2) Configure/Edit the Process Direct call

Configure your Process Direct call in the iFlows (I had to edit my iFlow to achieve this but if you have it among the Externalized parameters, just configure it, it’s better):

  • Italy Receive Invoice

  • Italy Receive Notification

Deploy all but the Italy Sign Service Aruba iFlow (you can use the original one, but if you need to customize this part, do it in accordance with what has been shown above).


Check iFlows after deployment

The iFlows are duplicated but notice the ID: the suffix TEST makes them different.



Adjust your Consumer Proxy settings (tcode SOAMANAGER) to call the new TEST endpoints. In this case your test SAP backend will call the iFlow with TEST mode configured, whereas the iFlow with PROD mode configured will be called only by your production SAP backend.


Test the solution

Send an invoice from tcode EDOC_COCKPIT, check the message in the SCPI Message monitoring. Notice, the TEST iFlow has been called.


Notifications are stored in the new TEST datastore. Notice the datastore are all duplicated but the copy reports the TEST suffix.


Pull Notifications

Run tcode EDOC_INBOUND_MSG with the message type IT_NOTIF_OUT_PULL.

And check the result.

Thanks for reading.


1 Comment
Labels in this area