Date: Sep/27/2019 Intended Audience: SAP FI-AP, MM-LIV consultants, SAP super users and SAP support users. Keywords: OpenText VIM, Unplanned Costs, MIRO GL tab. Notes: Screenshots and system specific details are from S/4HANA 1610 and OpenText VIM7.5.
Costs such as Freight, Customs duty, Packaging etc are common in a purchasing business process. However it is not always possible to estimate and plan for such costs on the Purchase Order. Some of these costs that cannot be planned need to be handled as unplanned costs when posting a vendor invoice for those purchase orders.
Standard SAP allows handling of planned costs on Purchase Order through header or line-level conditions and unplanned costs through account determination (see screenshot below).
SAP allows either distributing the unplanned costs to invoice line items or to post them to one specific G/L account and can be controlled through MM-LIV configuration.
What if the business needs a portion of those unplanned additional costs to be posted directly to a separate G/L account? For example, say the vendor invoice shows freight, packaging and customs duty – all of which are unplanned costs. However, business ask is to treat packaging and customs duty as ‘Unplanned cost’ that need to post to the account determined through configuration. And freight should be posted to a separate G/L account – one that is NOT configured in the ‘UPF’ key. This nuance in the requirement to handle a portion of unplanned costs differently introduces challenges to this process and turns this requirement from simple configuration change to high complexity change.
This is easy if the users were manually posting the invoice through MIRO transaction because they can manually decide how the unplanned costs can be split posted. But what if such a requirement needs to be met through automatic invoice postings and especially when these invoices are flowing through OpenText VIM process? Now that poses a challenge.
Our first thought could be go build custom enhancement to solve this requirement. But there appears to be a way to achieve this using standard configuration.
For those who worked with OpenText VIM understand that data flow through VIM is complex. In addition to typically involving 3rd party service providers, middle-ware and custom ABAP code, it also involves processing invoice information through various inbound channels (IDOC, Mail, Upload etc) which then create DP documents in VIM, which then triggers workflow and uses the BAPI for posting the invoice to accounting. Of course security is embedded in every step of this process.
Standard OpenText VIM provides configuration options for handling such unplanned costs as part of the inbound data processing. In this config VIM provides means to categorize such costs and means to identify such costs to automatically post to a G/L account. This configuration detail can be understood with the help of VIM configuration documentation. However, the OpenText documentation does not clarify how such additional costs needs to be passed in the IDOC. This part is left to the consultants to figure out and this is where this blog post aims to shed some light and show how standard configuration can be used for posting part of the unplanned cost to a separate G/L account through IDOC processing.
Using INVOIC02 IDOC type for invoice posting is typical and it is well understood that E1EDP01 segment and its sub-segments are used for passing line item details pertaining to a given PO-line. In combination with the E1EDK01 segment, these line item segments provide the complete picture for posting a given PO-invoice. But which segment should be used for the unplanned costs? That was the unknown.
For the sake of easy understanding let’s stick with the earlier example of freight, customs duty and packaging:
- freight portion of the unplanned costs need to post to a separate G/L account (i.e. G/L tab)
- packaging and customs duty need to post to unplanned cost account identified through ‘UPF’ account determination key
Let us also make an assumption that these are header-level unplanned costs and not pertaining to a any specific PO-line item. Given that example, we know that the packaging and customs duty costs can be mapped to the unplanned cost field.
This makes the combined value of these amounts show on the in the Unplanned Delivery Costs field on the PO-Invoice. However, if we want additional costs that need to go to the G/L Account tab, then the following 5-steps need to be done:
- Add additional E1EDP01 segment with following fields and sub-segments. Note that this new segment should be the first E1EDP01 segment in the IDOC for this setup to work.
E1EDP01-POSEX *First line-item number of the PO-invoice E1EDP01-MENEE *UoM from first line-item of the PO-invoice E1EDP02-BELNR (001) *PO Number E1EDP05-ALCKZ * '+' symbol E1EDP05-KOTXT *Cost qualifier matching with VIM configuration E1EDP05-BETRG *Amount of the additional unplanned cost E1EDP04-KTEXT *Tax code to be used for this additional cost E1EDP04-TXJCD *Tax jurisdiction if applicable
2. Map the following IDOC fields in VIM IDOC mapping
3. Update automated field enhancement configuration in VIM for the following fields. Note that the values ‘A5’ is a standard VIM value for configuring unplanned cost posting. And ‘FREIGHT’ is an example cost qualifier.
4. Update IDOC field mapping for ALTERNATIVE and QUALIFIER fields as field type ‘I – Item’.
5. Update Cost Determination configuration for the ALTERNATIVE and QUALIFIER (company code, GL account and Profit Center values shown are examples – these need to be modified per user requirement)
In addition to the above configuration, there might be need to update OKB9 configuration if Profitability Segment needs to be used instead of a cost center.
I did implement the above single cost qualifier scenario and it works as expected. In theory the above setup should handle multiple cost qualifiers to be passed through the IDOC data-flow and post to various G/L accounts and account assignment combinations. However, the placement of the E1EDP01 segments in the IDOC for unplanned costs need to be looked into and could pose a challenge. I have not tested this myself.
There are couple of key dependencies for the setup detailed above:
- The input invoice data file that feeds into IDOC process. If the additional costs are NOT clearly identified in that file then they cannot be populated on the IDOC.
- VIM upgrades. Since this setup using IDOC is not formally documented by VIM, it is possible that future VIM upgrades might impact this process and so this scenario needs to be accounted for regression testing as part of the VIM upgrade.
It is important to understand the above dependencies and clarify the same to the business users to avoid false expectations.
This change will make business accountants and cost controllers happy because it reduces the clutter in the auto-determined unplanned delivery costs G/L account and makes their business reconciliation easier. Good luck !!