terça-feira, 11 de outubro de 2022

Supplier Returns handling in SAP TM, triggered by a QM notification

 

Dear friends of SAP TM,

When setting up the logistics processes for inbound processing, it’s in many cases also important to consider an accurate returns handling. With the enhancement described here, it’s now possible to integrate a supplier returns delivery with SAP TM when it has been triggered out of a QM notification.

Description of the scenario

Assume, you purchase some goods at a supplier and create a respective purchase order. When it now comes to the delivery of the goods, a goods receipt is posted in one of your plants:

But in this scenario now, it’s very important for you as customer that the quality of the delivered goods is exactly as expected (e.g. in case of discrete manufacturing of a high quality product). Therefore, you do not rely on the ‘casual’ check done by the warehouse worker being responsible for the goods receipt. Additionally, you run a quality processing with the SAP QM instance as part of SAP S/4HANA.

So, the goods receipt happens in the stock for quality inspection and the QM processing is triggered, based on a so-called QM Notification.

QM processing is started

Sooner or later it will now happen, that you have complaints about the delivered goods. Depending on what is agreed with the supplier, you could now do a scrapping of the complaint goods. Or you could also return them to the supplier. In both cases you expect another delivery of the goods in the quantity of which the goods have been complaint.

Means for the scenario described here:

  • A returns delivery with reference to the purchase order is created. Either for returning the complaint goods to the supplier. Or in case of a scrapping, this should be charged to the supplier which also requires a returns delivery.
  • The open quantity of the purchase order is increased by the complained quantity to enable the supplier to do another delivery with reference to the original purchase order.

Implemented enhancements

To enable this scenario, the following enhancements have been implemented:

  • Logistics Integration Profile

Basically, when a delivery is created referring to a purchase order, and both documents are TM relevant, the logistics integration profile with the most important settings for the logistics integration (e.g. freight unit building rule) is taken over from the purchase order to the delivery document.

For this scenario, we decoupled the outbound processing from the inbound processing. This means, the logistics integration profile of the returns delivery is not taken over from the purchase order but determined newly from customizing. This reflects the fact that the returns process is started as a separate outbound process.

That enhancement is delivered with note 3221567.

  • Freight unit building at the purchase document

For the underlying purchase document, we identify that another delivery with the complaint goods is expected. Accordingly, freight units are built to enable their transport.

This is enabled with note 3252591.

Document flow in each process step

With those enhancements, the document flow will evolve like in this example:

  1. At first a purchase order is created and TM integration assigns a freight unit.
  2. An inbound delivery has been created for the purchase order and a goods receipt is posted against it.
  3. After the goods receipt, QM processing is started and a respective QM notification is created.
  4. The result of the QM processing is that 2 PCE are complaint which should be returned to the supplier. Therefore, a respective returns delivery is created from the QM notification and TM integration assigns a freight unit of the 2 PCE to be returned. In the same process step, TM integration assigns another freight unit of 2 PCE to the purchase order to enable another delivery of them.

So, this is another important capability of the returns handling with SAP TM, enabling a more powerful integration of affected components.

This functionality is available with SAP S/4HANA oP2022 FPS1 and SAP S/4HANA oP2021 FPS3 or with the mentioned notes.

I appreciate your feedback and comments!

Best regards,

Michael

 Source: https://blogs.sap.com/2022/10/10/supplier-returns-handling-in-sap-tm-triggered-by-a-qm-notification/

Integrate S4 Service Order & FSM appointment offering in Appgyver-SAP Intelligent Service Cloud V2

 

Business Use Case

‘Telporter’ is a Printer company which serves customers across various parts of the world. In this scenario printer had installed in ABC software company in different floors out which one was mal-functioned

Swim lane diagram

Story

Step 1 : Customer will Scan QR Code of the Printer via Appgyver app which inturn create Case

Step 2 : Ticket will received by agent in  SAP Intelligent Service Cloud

Step 3:Agent calls to Customer via Sinch where it opens Agent desktop with Customer Info

Step 4: Agent will create Service Order for malfunction printer via Appgyver app which was embedded as Mashup in Agent desktop

Step 5 :Adding the required services which are required 

Step 6: Create Service order in S4

Step 7: Slot is released to FSM and agent  is booking Appointment slot for Customer based on his availability

Conclusion : Showing the possibility to integrate the S4 Service Order & FSM appointment offering via Appgyver in SAP Intelligent Service Cloud V2

 Source: https://blogs.sap.com/2022/10/09/integrate-s4-service-order-fsm-appointment-offering-in-appgyver-sap-intelligent-service-cloud-v2/

SAP Integration Suite – Availability of a common & coherent User Interface to work with various capabilities

 

Introduction

SAP Integration Suite is an enterprise-grade integration platform as a service (iPaaS) that allows organizations to smoothly integrate on-premise and cloud-based applications and processes with tools and prebuilt content managed by SAP. At the time of writing this blog, it offers various capabilities such as Cloud Integration, API Management, Integration Advisor, Open Connectors, Trading Partner Management, and Integration Assessment.

While each of these capabilities offer rich tools & provide integration & API developers the environments to get their jobs done, they are distributed across different application UIs. For example, if your integration scenario involves building an Integration Flow to work with Employee Data from a SuccessFactor system, you would do so in Cloud Integration Web UI. If you wish to expose this Integration Flow as an API securely with certain rate limiting in place for controlled consumption in a mobile application, you will create such an API in the API Portal UI. So as an integration & API developer you are required to familiarize yourself with multiple application UIs offering different user experiences. SAP Integration Suite addressed this problem to some extent by offering the Launchpad in the past.

The Launchpad loosely wires all the tools of the Integration Suite capabilities and provides easy navigation across them. We now take the Launchpad a step further with our latest release in Oct 2022 – we bring all the capability tools (with few exceptions) natively together into a single application frame. This eliminates the need to navigate in & out of different UIs and provides a smooth single-sign-on experience to work with everything that you need to do with Integration Suite. In this blog, let’s understand what this new coherent user experience has to offer.

Access to Integration Suite UI

The new Integration Suite UI can be launched by administrators by clicking on the link in the cockpit.

The URL of this application remains static and hence can be bookmarked and shared with developers.

Managing capability activation/de-activation

If the application is accessed by an Integration Provisioner, then the Home page offers the tools to manage the capability activations. To begin with, the Capability section shall be empty. Click on ‘Add Capabilities’ to start working.

 

Choose required capabilities & activate.

 

Once activated, the tiles start appearing on the Home page.

 

Further on, perform the necessary capability specific role & set up configurations to make the tenant ready for usage. You can find more information about this here.

Working with the Home page

Once the capabilities are activated and the roles are assigned, if a privileged user accesses the Integration Suite UI, she lands on the Home page. The Home page is divided into several sections.

  1. In the Capabilities section, each of the activated Integration Suite Capability is represented by a tile with prominent quick actions. The actions are enabled based on the user privileges.
  2. The Overview section calls out the salient features of Integration Suite with a short, embedded video and a link to the playlist for additional information.
  3. The Resources section offers various links to learn about the Integration Suite, its latest updates and to interact with the ecosystem around it.

Once a developer starts building artifacts using the Integration Suite UI, the Recent & Monitoring sections start appearing. They help users with easy access to recently managed artifacts and also provide quick overview about the usage & performance of the artifacts.

Common Shell features

The top navigation bar and the left-hand side navigation bar are available always in the application.

  1. The Left-hand side navigation is categorized into Menu and Sub-menu items. It is a completely dynamic section that is created based on the activated capabilities in the tenant and the logged in user’s privileges. Each of the Menu item (except Home & Settings) represents a lifecycle stage and the sub-menu items represent the artifacts belonging to the stage. ‘Settings’ sub-menu item offers a single page to administrators to apply configurations for all activated capabilities
  2. The top navigation bar offers many common actions
    1. News & Announcements action allows users to be informed about the latest updates from Integration Suite
    2. The Product Switcher action allows users to access external applications such as API Business Hub, the BTP Cockpit etc.
    3. The About action opens an aggregated version information dialog for all capabilities deployed on the tenant
    4. The Profile action provides like to documentation & troubleshooting guides along with the logout action

Working with the Capabilities

A developer can interact with each of the capabilities by using the quick links on the Home page tiles or sub-menu items on the left-hand side bar. For example, pre-existing content can be discovered by clicking on ‘Integrations’ or ‘APIs’ under ‘Discover’. New artifacts such as Integration Flows, APIs, MIGs, MAGs etc can be created by visiting the corresponding sub-menu item under ‘Design’. Similarly, the integration artifacts can be monitored by visiting the ‘Integrations’ under ‘Monitor’. APIs can be analyzed by visiting ‘APIs’ under ‘Monitor’.

As stated in the previous paragraph, the availability of these sub-menu items depend on the activated capabilities on the tenant and also the privileges of the logged in user.

You can find the description of each of these Menu items here

 

As of now, Open Connectors and Integration Assessment are still loosely integrated into the Integration Suite UI and hence the user is navigated to an external application when accessed.

Summary

The new Integration Suite UI provides a single web application to work with all the capabilities that Integration Suite has to offer. This is a step forward in providing a coherent user experience to the developer community. You can find a short visual summary by watching the below videos.

Thank you for reading. Do tell us what you think about this new enhancement.

Source: https://blogs.sap.com/2022/10/10/sap-integration-suite-availability-of-a-common-coherent-user-interface-to-work-with-various-capabilities/

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 AdapterReceiver Adapter
  1. AS2.
  2. AS2 MDN.
  3. SOAP 1.x.
  4. IDOC.
  1. AS2.
  2. IDOC.
  3. SOAP 1.x.
  4. 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.

1 Comment
Source: https://blogs.sap.com/2022/10/01/simplify-edi-with-sap-s-4hana-cloud-with-sap-trading-partner-management-and-cloud-integration/