Simplify EDI with SAP S/4HANA Cloud with SAP Trading Partner Management and Cloud Integration

 

Introduction

In this blog post I will demonstrate the feature provided by SAP TPM which can be provisioned in SAP CI. SAP TPM targets mainly EDI related integration and brings greater control and faster delivery by smartly orchestrating 3 technologies of integration suite.

1. SAP cloud integration.
2. SAP Integration advisor.
3. Partner directory – plays a major role, though is a part of SAP CI.

I will demonstrate an end-to-end EDI integration between external buyer system and SAP S/4HANA cloud using SAP TPM.

Objective

To create sales order in SAP S/4HANA cloud corresponding to EDI 850. I will read the EDI 850 file dropped in the SFTP server, convert it into Sales Order/Customer Return – Create, Update, Cancel (B2B) format and push into SAP S/4HANA using the communication arrangement created for the communication scenario – SAP_COM_0223.

Pre-Requisite

Following things needs to be setup:

1. Communication system and communication user for SAP CPI to interact with SAP S/4HANA cloud API.
2. Customer info records – mapping between the customer material and the SAP internal material is completed.
3. Number range – .I will show where this number range is used when we start designing the B2B scenario. ICN_DEFAULT.

High Level Process Flow

You can ask this question as to why the wrapper IFLOW was needed in the first place. This is because TPM as of now only supports the following adapters.

Sender Adapter	Receiver Adapter
AS2. AS2 MDN. SOAP 1.x. IDOC.	AS2. IDOC. SOAP 1.x. SOAP RM.

Since our requirement is to capture the EDI document from SFTP server, we need this wrapper IFLOW. Since we need raw EDI format as our source, we need to use AS2 adapter in the reciever side of the wrapper IFLOW.

Understanding the concepts

Company – this is the central entity which will be exchanging the EDI document with all the external buyer or seller parties.

Trading partner – this is the external party which will either send or receive EDI document from the company.

Identifiers – every trading partner and the company has a distinct set of identifiers that help in resolving the configurations that will be loaded during the runtime of the interfaces.

System – company and trading partner may have different systems which are exchanging messages. 1 TP/company : N systems.

Type system – this represents the data type that is being exchanged with the system. 1 system : N type.

Communication – this represents how the data is exchanged with the system. 1 system : N communication.

Agreement template – this design corrrespond to the company interfacing side.

Agreements – this design corresponds to the end to end scenario involving the company and the trading partner. The template created above can be reused to connect to several trading partners. 1 Agreement templae : N Agreements.

Wrapper IFLOW

The AS2 is configured to transmit encrypted and signed data. I will show where do we maintain the configuraiton to decrypt and verify data in the next steps.

Company configuration

The identifier set here must be part of the ISA segment that the trading partner is sending. Now create the type system as SAP S/4HANA Cloud SOAP (1905) and the communication arrangement.

make sure that the type system of the system and the type system of the identifier are same = SAP S/4HANA Cloud SOAP (1905).

Trading partner configuration

Similarly, create the identifiers for trading partner. Now a question must be coming to your mind – how does TPM knows which agreement to load for a given trading partner. Also 1 trading partner could be exchanging several EDI doctypes, so how does this resolution happen?

Trading partner resolution occurs using /AuthorizedUsers partner directory entity. This is evident when creating the system for the trading partner. The SapAuthenticatedUser linked to the TPM configuration is maintained.

Also since we are using AS2 for receiving the raw EDI from the wrapper IFLOW, the content is encrypted and signed – the decryption certificate and the trusted certificate needs to be configured in the adapter here. Download the entity certificate of sap_cloudintegrationcertificate and upload in the certificate tab.

Agreement Template Configuration

Here we only configure the company side details. Once we have done this, the same configuration can be reused for several trading partners.

The interchange step requires the target MIG from IA. Here we also need to set the number range created in the pre-requisite section. The purpose of this number range is to increment and is set in the payload to SAP S/4HANA cloud.

Agreement Configuration

I have explained above how the trading partner resolution happens, but how TPM knows that which confuguration to load for this EDI transaction for that trading partner.

Using the details available in the ISA segment and using them to identify that which agreement configuration to load for which trading partner.

Mark, there is a second pair of identification, these are set in the payload sent to SAP S/4HANA cloud.

Include the source MIG and the MAG from IA. We are now ready with the configuration, Activate configuration.

Execution

Finally, lets see the payload sent to S4:

Monitoring

There is a dedicated dashboard to monitor the EDI transactions. There is excellent provision to filter by the trading partner name with lots of other details in the details section of the logs.

Conclusion

I think I was able to explain the various features and the configuraiton of SAP TPM in order to realize an end to end EDI scenario.

Thanks for reading this blog.

Source: Simplify EDI with SAP S/4HANA Cloud with SAP Trading Partner Management and Cloud Integration | SAP Blogs

Using bgRFC for IDoc Inbound Processing

Situation

The partner profiles (transaction WE20) define the conditions for the interchange of data in an ALE environment with a partner using the IDoc interface. There are two ways of posting IDocs in ALE inbound processing:

Trigger by background program

IDocs are received and saved in status 64.  This IDocs will be processed using scheduled batch jobs for the report RBDAPP01.

Trigger Immediately (Default)

IDocs are received and saved in status 64. After the database commit, a second parallel process in which the application processes the IDoc is started. The result of this processing is then logged in the first process. So each IDoc requires at least 2 free dialog work processes. If no dialog process is currently free for application processing, report RBDAPP01 is scheduled for this IDoc and executed as a background process.

 

Problem

For a quick processing, the report RBDAPP01 must currently be scheduled at suitable frequency. On the other hand the “Trigger Immediately” option should not be used for high volume, noncritical messages as this can often lead to resource problems.

 

Approach

For immediate inbound processing additional options are provided that use bgRFC (background RFC). bgRFC offers quick processing of IDocs while using the available system resources in an ideal manner.

Transactional Processing

In the transactional processing, the inbound IDocs are processed in parallel. An asynchronous RFC call executes the further processing when using the priority “01” in another LUW. If no more resources are available to the RFC, a transactional bgRFC call carries out the processing. When you use the priorities “02” to “99”, the transactional bgRFC call generally carries out the processing using the inbound destinations that are assigned to the priorities.

Queued Processing

During the queued processing, the inbound IDocs are processed depending on their queue names. Further processing happens independent of the chosen priority. It is generally carried out by a queued bgRFC call using the inbound destinations that are assigned to the priorities. IDocs with the same queue name are processed sequentially and queues with different names are processed in parallel.

Implementation

Definition of Inbound Destination (transaction SBGRFCCONF)

Create an inbound destinations. If no prefix is assigned, the system uses the automatic queue names with the prefix ALE_INB. Alternatively, you can define your own prefix that is then used for the creation of the queue name. Destinations with multiple prefixes cannot be used.

Definition of Inbound Groups (transaction WE20BGRFC)

Inbound groups later classify the inbound partner profiles that you use. Create the required number of inbound groups. Assign a priority between “01” and “99” to the groups. You can assign the same priorities to different groups.

Assignment of inbound destinations to inbound groups (transaction WE20BGRFC)

Assign the inbound destination for all used priorities.

 

Only for queued processing: Formation of queue names (transaction WE85_INBOUND)

You can view rules or store your own rules. You can find the required interface in the assigned function modules IDOC_QUEUE_INB_CONST_ALE_QUEUE or IDOC_QUEUE_INB_MESTYP

Maintenance of partner profile (transaction WE20)

Assign the inbound group to the inbound partner profile. For queued processing assign a rule for the parameter RULE_NAME.

 

References

SAP Note 1793313 – ALE: IDoc inbound processing using bgRFC as standard

SAP Note 1872637 – Delays posting inbound IDocs (status 64) which have been configured to trigger immediately

SAP Note 1333417 – Performance problems when processing IDocs immediately 

Source: Using bgRFC for IDoc Inbound Processing | SAP Blogs

Customizing SAP EWM Warehouse Monitor Node

 Introduction:

I am a SAP EWM (Extended Warehouse Management) functional consultant with experience in Greenfield implementation and have served clients in Food Processing, Chemicals and Automotive industries.

 

About this blog:

This blog post is intended to help functional consultants learn how to customize SAP EWM (Extended Warehouse Management) Warehouse Monitor according to client needs by adding custom nodes used for monitoring warehouse activities or to display custom reports. In order to get the best out of this document I request to kindly read/explore about Category Node and Profile Node used in SAP EWM Warehouse Monitor. Please note that customizing SAP EWM Warehouse Monitor involves technical (List FM, Dynpro Program) and functional (Define Monitor, Categories, Nodes) aspects. This blog post is all about the functional customizing aspect.

 

Business Case:

Irrespective of any business, SAP EWM (Extended Warehouse Management) Warehouse Monitor is one of the most used object by any SAP EWM user. Standard SAP EWM ships the SAP EWM Warehouse Monitor with various nodes that are used for monitoring activities primarily. Apart from the standard one’s businesses sometimes requires custom nodes in order to execute custom reports which can help them gauge the corresponding Warehouse Operations. Consider in this blog post that we have a requirement to create a custom node in SAP EWM Warehouse Monitor.

 

Customizing:

Step1:  Create a Custom New Monitor and copy the existing SAP Standard Monitor Category Nodes.

Path: SPRO>SCM Extended Warehouse Management> Extended Warehouse Management> Monitoring> Warehouse Management Monitor> Customize Monitor Tree

Drag the Category Nodes one at a time from left part of screen which is your Standard SAP Monitor to the right which is your Custom Monitor. Drop each entry onto the “New Monitor” object located on the right part screen.

Define custom SAP EWM Warehouse Monitor

In addition to the standard SAP Category Node, we need to create custom Category Node which will accommodate our custom Profile Node.

Define a custom Node in custom SAP EWM Warehouse Monitor

While you save, the system prompts to save it using **** as the warehouse number which helps you to use the same monitor for all defined Warehouses in the SAP EWM System. This can be changed and using a specific warehouse number, you can save the monitor for a warehouse number exclusively.

System Prompt when saving the new custom defined SAP EWM Warehouse Monitor

The Custom Category Node is created under Custom Monitor.

 

Step 2: Check the Custom Monitor is created along with node hierarchies.

Path: SPRO>SCM Extended Warehouse Management> Extended Warehouse Management> Monitoring> Warehouse Management Monitor> Define Monitors

An entry with the custom monitor created in Step 1 can be viewed here.

The hierarchies are created as same as they are for Standard SAP Monitor. This is because we copied the Standard SAP Monitor Category Nodes into our custom Monitor.

Step 3: Define Object Class

Path: SPRO>SCM Extended Warehouse Management> Extended Warehouse Management> Monitoring> Warehouse Management Monitor> Define Nodes

 

Step 4: Check the Custom category created because of defining a Custom Category Node defined in step 1.

Path: SPRO>SCM Extended Warehouse Management> Extended Warehouse Management> Monitoring> Warehouse Management Monitor> Define Nodes

 

 

Step 5: Define a node profile and a node

Path: SPRO>SCM Extended Warehouse Management> Extended Warehouse Management> Monitoring> Warehouse Management Monitor> Define Nodes

 

As a result of defining Custom Category Node in Step 1 system creates a corresponding node as shown below.

Note: Only Profile Nodes have a Node Profile and that is why the Custom Category Node created in Step 1 need not have any Node Profile assigned to it.

We need to define a Profile Node for our custom object.

 

Step 6: Assign the Lower (Profile) node “ZOWO” to higher (Category) node “ZC00000001”

Path: SPRO>SCM Extended Warehouse Management> Extended Warehouse Management> Monitoring> Warehouse Management Monitor> Define Monitors

 

 

Result:

 

Conclusion:

The above customizing steps will help the functional consultants create custom nodes in SAP EWM Warehouse Monitor as per client needs.

References:

Warehouse Management Monitor – SAP Help Portal

 

Q&A:

Please use the link besides All Questions in SAP Extended Warehouse Management | SAP Community to submit your questions if any.

Source: https://blogs.sap.com/2021/07/18/customizing-sap-ewm-warehouse-monitor-node/

Cross delivery Handling units with unknown content and its hybridization with POSC & LOSC

 Recently I prototyped a somewhat below complex Inbound business requirement with the help of ” Cross delivery HU with unknown content and its amalgamation with POSC/LOSC

Multiple GR of manufacturing order from S/4 creates Inbound deliveries which is relevant for posting GR, moving into Room-I without HUS. Room-I will be used to create packing, HU creations, latter cross delivery HU will be moved to Room-II as HU. Once cross delivery HU reaches Room-II, it should decompose the final task as ”Product WT” because final storage types are non HU managed and storage bin combination of 1 Product 1 batch storage.

It could have been very easy had we started packing, building HUs directly at Production Goods receipt zone, and calling 2 step LOSC. However, this compromised with actual business needs as ”HU life cycle starts at Room-I not at GR zone. So, the HU starting point is Room-I

To my curiosity, I conceptualized to work with Cross delivery HU with unknown content and combining this with POSC/LOSC, and it worked perfectly:-).

The idea is just to hook the Collective HU/ HU with UKC at Production GR zone so that process enters into POSC/LOSC arena. However, the actual HU packing starts at Room-I when phantom HU will be packed into real HU.

Multiple partial GR of manufacturing order created multiple IBDS, taking help of /SCWM/GR or /SCWMGRPE, we can build cross delivery HU with unknown content.

 

Phantom HU( Collective HU) is created which is now relevant for GR and WT processing.

GR of Cross delivery is posted, you need to post GR at cross delivery HU level, posting at header level gives error.

Once GR is posted, system creates task for Room-I( Settings in POSC), confirm the task, Cross delivery phantom HU is now at Room-I( T830 Work center)

 

Now, business starts packing here, so idea here is to repack Phantom HU( Collective HU) into Real HU( HU with UKC). One both deliveries are packed into real HU, phantom HU is deleted from system.

Here I put 2 POSC recursive PACK step( PAC as internal step), the reason, the first PACK step will allow to repack HU with unknown content and 2nd PAC will trigger ”Product WT” FOR final Bin.

My 2 POSC steps are ZE01 and ZE02 both pointing towards ‘‘PAC” as internal step. Why I used first step as POSC because LOSC cannot be used for product modelling unless it is a pick point/ ID point. Since POSC can never be called inside LOSC, so my first step is POSC, latter you can call LOSC inside POSC.

 

The closure of HU at ZE01( Room-I) created HU task. Confirm this task and HU is moved to Room-II.

Final closure of Room-II HU decomposed the HU and created product WT.

 

Final putaway  can be triggered by scanning HU labels, and putting into the final Bin.

Hence 2 different IBDs were packed into 1 HU making it as cross delivery HU and finally decomposing it into product WT as 1 Bin can only contain 1 Product 1 batch.

 

Other solutions/ Work around

1. Directly create Handling units in Production Goods receipt zone and call 2 step LOSC, triggering 2 HU task and 1 Product WT. But this will compromise with actual business requirement where HU building starts at Room-I.

2. Call POSC HU with UKC, Pack(IPK1) and IB03 Putaway. In between IPK1( Room-I) and final           Bin( IB03, call LOSC. ( Though it did not work me :))

 

Hope you liked the blog:) Appreciate your reply.

 

PS: All testing is performed in S/4 HANA Sandbox 1709 system.

Source: https://blogs.sap.com/2021/02/02/cross-delivery-handling-units-with-unknown-content-and-its-hybridization-with-posc-losc/

Using Custom Display Profile for SAP EWM RF screens

 

Introduction:

During the implementation project, I noticed that standard Display Profile in the EWM RF Framework is well suited for RF device with keypad. But with modern touch screen devices the message displayed on the device overlaps the on-screen pushbuttons. Now, the warehouse Professionals cannot access the screen pushbuttons.

Problem Statement: Device Messages overlaps the On-screen pushbuttons.

Solutions: Create a custom display profile to display all the RF device messages on a separate screen (message screen 0002).

 

RF Framework – Screen Manager

T-code to access the Screen Manager: /SCWM/RFSCR

In the above screenshot the standard display profile has Message Display value as 1, which means the message is displayed on the same screen.

An example of the above problem

---

Solution Implementation:

Step 1: Create a new Display Profile

• Goto T-code /SCWM/RFSCR.
  •  Copy the standard display profile  **

 

• Keep all the Parameters as the Source Display Profile.

• Change the Message Display Element to 0

• Provide a Function Group Name in the Customer Namespace. All the standard screen would be converted and saved in the provided Function Group Name.

• Select the Create Sub-Screen checkbox to convert all the Screens & Sub-Screen as per the New Display Profile.

Step 2: Update the New Display Profile ( Z1 ) in the Presentation Device.

• Goto T-code /SCWM/PRDVC
  •  Update the Presentation Device with the New value of Display Profile (Z1)

• This is the same Presentation Device, which we see when we log in to RFUI.
• Save & Close.

Step 3: Log in to RF Device

• Goto T-code /SCWM/RFUI
• Execute the RF device Transactions.

 

H  LLA

• In case of Error, unlike previous scenario Message is displayed on a separate screen.
• Also the On-Screen Pushbuttons are not overlapped with the Message.

 

Conclusion:

In case of standard display profile the error message overlaps the On-screen Pushbuttons. In such scenarios Warehouse Professionals cannot procced further or go back as the Pushbuttons are no more visible. In case of device with keypad such limitation was not there as Warehouse Professionals could have executed the functionality using the Keypad buttons.

So, in case of Touch Enabled device we can create new Display Profile with Message Display Value as 0  to overcome the Problem.

 

Thanks for reading the blog-post !

Happy Learning …Together.  

 

 

Regards

Vishal Kumar

Source: https://blogs.sap.com/2022/10/31/using-custom-display-profile-for-sap-ewm-rf-screens/