Executing the Advanced Intercompany Sales and Stock Transfer Process

Objectives

After completing this lesson, you will be able to:

  • Understand the features of an advanced intercompany sales process
  • Understand the features of an advanced intercompany stock transfer process

Advanced Intercompany Sales Processing

Introduction

SAP S/4HANA release 2022 introduced advanced versions of the intercompany sales and stock transfer processes in the system.

Note
See what Michael has to say about advanced intercompany sales processing in SAP S/4HANA:

Best practices solution process Advanced Intercompany Sales (5D2) describes this process for the on premise version of SAP S/4HANA and SAP S/4HANA Cloud Private Edition.

Note
See the SAP Signavio Process Navigator (URL: https://me.sap.com/processnavigator) for more details. Search for solution process 5D2.

This lesson first discusses some characteristics and shortcomings of classical intercompany sales processing. After this, advanced intercompany sales is introduced, followed by the advanced version of the intercompany stock transfer process. The framework used to control and orchestrate these processes is also briefly discussed.

Classical Intercompany Sales Processing

The classical intercompany sales process, which has been available for many years, can be described in the following way:

An example is presented of a classical intercompany sales process.
Note
The process depicted here is a single level process executed in a single SAP S/4HANA system.

A selling company in one country (company Germany in this example) sells materials to a customer in that country. These materials are picked, packed and delivered directly to the customer out of a delivering company (US in this example). This delivering company code is located in another country (or at least: it is another legal and financial entity).

No intercompany purchase order from the selling towards the delivering company is created and/or no intercompany sales order in the delivering company is created, making it hard to perform any meaningful reporting in the delivering company code based on sales order-related KPIs.

An invoice for the customer is created (out of the selling company) and an intercompany invoice is sent from the delivering to the selling company. This intercompany invoice can be posted automatically in the selling company based on an IDOC, which is outdated technology. No supplier invoice can be posted in the selling company, since there is no purchase order to relate it to.

Another drawback here in this classical intercompany sales process, is that there is no valuated stock in transit available for the selling company. So goods leaving the US towards the German customer might be owned by the German company, but these are not visible as valuated stock in transit in this company.

Advanced Intercompany Sales Processing

SAP S/4HANA 2022 introduced an advanced version of this intercompany sales process, to alleviate the shortcoming of the classical intercompany sales process as discussed above.

The advanced version of the process can be described in the following way:

An example is presented of an advanced intercomapny sales process.
Note
The process shown above is a single level process executed in a single SAP S/4HANA system.

The process starts again with a sales order for a customer in the selling company. After this, a second sales order is automatically created in the delivering company, based on a purchase order which is sent from the selling towards the delivering company. This purchase order is also automatically created. The purchase order is in fact created first and then the second sales order is created based on this purchase order.

The sales order in the selling company is referred to as sales order 2 (SO2). The purchase order from the selling towards to delivering company is referred to as purchase order 3 (PO3). The sales order in the delivering company is referred to as sales order 4 (SO4).

SO2 is the leading object, in which a US plant (in this example) is determined as the delivering plant. SO2 is also visible in the MRP run in the selling company and for its items, an (advanced) ATP check can be executed (and so on).

Note

Both classic and advanced intercompany sales items can be combined in one sales order. Currently the activation of the advanced process is done for sales order types and item categories. Additionally, SAP plans to offer a BAdI, where a customer can activate advanced intercompany sales for certain sales order items according to their own logic.

For the customer sales order (SO2), a normal document type is used (like OR). The purchase order in the selling company (PO3) is using a new purchase order type. The sales order in the delivering company (SO4) is using a new sales order type, item category and schedule line category that are customized in such a manner, that there is no relevance for ATP, MRP, product compliance, trade compliance, transportation management, and so on. Only the sales order in the selling company (SO2) is relevant for MRP and (advanced) ATP. The intercompany purchase order (PO3) and the intercompany sales order (SO4) are not visible in MRP.

Sales order 2 contains an additional field on item level called Transit Plant, which is used to be able to record valuated stock in transit (belonging to the German company in our example) once transfer of control/ownership from the US to the German company takes place.

Note
No new movement types have been introduced for the goods movement postings related to this valuated stock in transit.

An outbound delivery is created in the delivering company (US in our example) referencing the sales order in the selling company (SO2), which is always considered as the logistically leading object in this process.

Note
The outbound delivery 'sees' the financial data stored in the sales order for the delivering company code (SO4), which is represented on the figure as a dotted line.

After picking and packing, the goods issue is posted out of the delivering company towards a valuated stock in transit, belonging to the delivering company (US in our example: see step 6 in the figure).

When control of the goods/ownership is transferred from the US to the German company, a goods movement is posted from valuated stock in transit belonging to the US company to valuated stock in transit belonging to the German company (see steps 7, 7a and 7b in the figure).

Once the customer takes control/ownership, a goods issue out of this valuated stock in transit (belonging to the German company) is posted.

As soon as a goods issue for the outbound delivery has been posted, an intercompany customer invoice can be created (A in the figure). This can in turn trigger the creation of an intercompany supplier invoice (B in the figure), referencing purchase order 3 (PO3).

A new billing type is also used for the intercompany customer invoice (A in the figure). Therefore, it is not possible to combine intercompany customer invoice items for a classical intercompany sales process with intercompany customer invoice items for an advanced intercompany sales process into one intercompany customer invoice document.

The additional steps PO3, SO4 and also the goods movements related to the valuated stock in transit (7, 7a/b and 8) are all automatically created/posted by the system. The goods movements are posted automatically based on specific field data maintained in the outbound delivery (the so-called transfer of control dates in the outbound delivery header).

Some key characteristics of this advanced version of the process include:

  • Seamless end-to-end process that is highly automated and embedded into the following areas:
    • Product compliance
    • Trade compliance
    • SAP Transport Management (including freight costs)
    • Revenue recognition
    • Profitability reporting
    • Product costing
    • Group reporting/consolidation
  • Changes in a customer-facing sales order are consistently applied by the system throughout the end-to-end document flow.
  • Valuated stock in transit in the selling company allowing for a seamless change of control between the affiliates and also later on the customer
  • A purchase order in the selling company enabling landed costs in product costing
  • End-to-end monitoring and issue detection (and posting services)

Current features that this process supports are:

  • Sell-from-stock items (Item category TAN)
  • Free-of-charge items with invoice relevance (Item category CBXN)
  • Batches with batch splits
  • Serial numbers
Note

Advanced intercompany sales can be used for sales processes only. Customer returns are not included (yet). This means that if you create a customer return with reference to an advanced intercompany sales item, the return process is executed as a classical intercompany process.

A multi level process using a single SAP S/4HANA system is also planned to be delivered in the future.

Note
Multi system scenarios are planned, but no details are known for this as of yet.

This multi level process can be described in the following way:

An example is presented of a multi-level advanced intercompany sales process.

The above process differs from the single level process described earlier in the sense that now one or more additional companies are involved in the intercompany sales process as intermediate parties.

The German company still sells to the customer and the US company delivers (i.e. the US plant is still the delivering plant in SO2), but the German company does this by buying the goods from the French company. This company in turns buys the goods from the US company: a purchase order towards the French company is automatically created when SO2 is saved, leading to a sales order in France (SO4') and an additional purchase order from the French company towards the US (PO3'), which created SO4.

The following SAP notes provide more details regarding some aspects of the advanced intercompany sales process:

  • Note 3192584: SAP S/4HANA Cloud: Restrictions and General Information for Advanced Intercompany Sales
  • Note 3226683: SAP S/4HANA 2022: Restrictions and General Information for Advanced Intercompany Sales
Note
Advanced intercompany sales doesn't require any specific additional licenses.

Advanced Intercompany Stock Transfer Processing

Intercompany stock transfer processes

One example of a classical intercompany stock transfer process can be described in the following way:

An example is presented of a classical intercompany stock transfer process.
Note
The process depicted here is a single level process executed in a single SAP S/4HANA system.

The purchase order (/stock transport order) from the German company towards the US company is the basis for the outbound delivery (and its processing) in the delivering company code (US in this example). Stock in transit is again available.

After the creation of an inbound delivery in the receiving company (Germany in this example), the goods receipt in the receiving company is posted.

One issue here is that there is no sales order present in the US company for this process. This means that all sales order KPI-based reporting in the US is very difficult, when these kinds of processes are in place.

Another issue here is the proof of delivery (POD) (that can be seen in the figure), that is used to trigger the stock transfer from valuated stock in transit in the delivering company to valuated stock in transit in the receiving company.

An advanced intercompany stock transfer process can be described in the following way:

An example is presented of an advanced intercompany stock transfer process.
Note
The process shown above is a single level process executed in a single SAP S/4HANA system.

Although the process seen in the figure above is quite similar to the classical version of this process, the way that the orchestration of the process works (and the architecture used in the background) is very different: the so-called Value Chain Monitoring Framework (VCM) is used. More on that later.

A purchase order (/stock transport order), using an (advanced) ATP check, triggers the automatic creation of a sales order in the delivering company, also referred to as sales order 4 (SO4).

The logistically leading document in this process is purchase order 3 (PO3). SO4 is there much more for commercial reasons, for audit reasons and for the integration with SAP S/4HANA Finance.

Triggering the goods movements related to the valuated stock in transit is now again done based on the transfer of control date fields in the outbound delivery header. This is similar to what was discussed before for the advanced intercompany sales process. There is no need anymore to trigger these kinds of postings based on a proof of delivery document (POD).

Advanced intercompany stock transfers are now very much aligned with advanced intercompany sales processes in the way they work and also in the way that they are orchestrated and monitored (using the VCM framework).

An example is presented of a multi-level advanced intercompany stock transfer process.

A multi level process using a single SAP S/4HANA system is also planned to be available. One or more intermediate companies can be included in the process, where for example the German company still determines the US plant as the delivering plant but where the ordering is done via the French company (PO3 leading to SO4' in the figure), that in turn orders the goods from the delivering company in the US (PO3' and SO4).

Note
Multi-system scenarios are also planned.

The following SAP notes provide more details regarding some aspects of the advanced intercompany stock transfer process:

  • Note 3192546: SAP S/4HANA Cloud: Restrictions and General Information for Advanced Intercompany Stock Transfer
  • Note 3226677: SAP S/4HANA 2022: Restrictions and General Information for Advanced Intercompany Stock Transfer

The Value Chain Monitoring Framework (VCM)

Both the intercompany sales and the intercompany stock transfer process are orchestrated and monitored using the so-called Value Chain Monitoring Framework (VCM).

The VCM framework is a generic framework that is able to run and monitor very specific business processes in SAP S/4HANA (that have been enabled for it by SAP). It currently supports 3 pre-configured SAP standard end-to-end processes in SAP S/4HANA. This framework is what is used here to orchestrate and monitor both the advanced intercompany sales and the advanced intercompany stock transfer process.

Note
In the current version of VCM it’s not possible that customers can add additional process steps or that customers can define their own end-to-end processes.

VCM can be used for issue detection and it provides posting services. An example: a purchase order has not been created due to a missing material master view. With the Monitor Value Chain app a user can detect this issue. After creation of the missing material master view, the user can re-trigger the creation of the purchase order (using again the Monitor Value Chain app).

Value Chain Monitoring is introduced.

VCM takes care of the orchestration and execution of the advanced intercompany processes discussed here. With the Monitor Value Chain app, the user can monitor this process. The figure above tries to visualize this.

VCM contains its own definition of each process it orchestrates. When a sales order containing an item relevant for advanced intercompany sales processing is saved, the runtime environment of the framework is triggered (by the processing of this sales order). From here, the next step in the process is triggered based on the relevant process definition. In this example that would be the step to automatically create the purchase order (PO3). PO3 goes back to the runtime and the runtime then triggers the creation of SO4.

Note
VCM is purely there for orchestration and monitoring reasons: it doesn't contain or handle any business data. Only document IDs are used.

An example of VCM in action: in advanced intercompany sales, changes in the sales order in the selling company are automatically managed by the system (VCM – Value Chain Monitoring Framework), e.g. in case some confirmed quantities are changed, the new confirmed quantities are distributed to the purchase order of step 3 (PO3) and the sales order of step 4 (SO4).

Another example: in advanced intercompany sales, in case the delivering plant is changed from the US to Canada the item in the existing purchase order of step 3 (PO3) will be flagged for deletion, the item of the sales order of step 4 (SO4) will be rejected and a new purchase order (PO3) towards Canada and a new sales order (SO4) in Canada will be created. This is all arranged by VCM.

Note
Creation of the outbound delivery in the example presented here is something that is done by the business application (for example transaction VL10A or a similar report) and not by the VCM framework. The VCM framework will wait until the outbound delivery is created, before it checks what the possible next steps are. It might then automatically triggers these steps based on the relevant process definition.

Since the VCM framework contains all relevant document IDs for a certain process, it is relatively easy to visualize these in the form of a document flow. The SAP Fiori app called Monitor Value Chains can be used for this.

Note

VCM is not based on IDOCs. Integration to the business applications is done via function module calls. Again: VCM doesn’t contain any business data (e.g. material number or quantities), only the document IDs generated in a process are included in VCM.

Log in to track your progress & complete quizzes