During the Drop Shipment scenario, (Intercompany Billing) it is the Product Companies (PC) that deliver the goods on behalf of the Network Company, (NC). As the NC is not aware of the amount to be invoiced by the freight forwarder (received by PC) when creating their sales order, these costs are applied directly to the F2 by the PC after the post goods issue takes place.
It is imperative that these costs are not applied to the sales order, as the PCs invoice (IV) is created with reference to the sales order (Standard SAP functionality). Freight and packing is not invoiced on the IV, and a separate report is run at the end of each month to separate these costs in COPA.
To guarantee that these costs are not applied to the IV invoice, Wartsila created condition exclusions, whereby if the NC incorrectly added them; the condition values would not be copied to the IV (excluded). The IV invoice in most cases uses the pricing procedure ZCA005, (ZCA006 for Japan) and the sales order (in most cases) uses ZCA001.
The condition exclusions are created against the document procedure (IV being assigned to procedure I). The document procedure I was used for both IV and ZF9 billing document types at the time.
Wartsila Japan raised an issue via the Helpdesk where their Freight and packing charges were not being displayed on the Proforma invoice outputs correctly. These additional costs are manually applied to the invoice via condition types at header level, and divided equally across all existing line items.
After investigating the issue further, I realised that the existing condition exclusions which had been created for the IV invoice (as explained above) were also triggering the exclusions for the ZF9 (globally). I analysed the current situation and realised that this would not be a simple solution, as the ZF9 is used by all Wartsila Product companies. As the condition exclusions are not created against sales area data, it would be impossible to make the change without affecting all other sales areas in the system.
I contacted the other Product companies, briefly explaining the situation. However, (apart from Japan) they all claimed that the additional costs of freight and packing should still be excluded from the ZF9 billing document. This meant that the solution continued to be sales area specific, where the key elements did not allow the change to be made at such a level.
After spending further time looking at various options, (mainly changes to outputs) it was clear that the best solution would be standard SAP configuration. A key had to be identified where Japan would have the condition exclusions excluded from their ZF9, without affecting the same billing document for other Product Companies.
I finally decided to create a new pricing procedure (ZCA007 – a copy of ZCA006). I also created a new document procedure (J) and assigned it to the billing document type ZF9. From here, I looked at the pricing procedure determination and extracted all sales areas that were currently assigned to the ZF9.
Using standard SAP, I copied the entries (except for Japan) and created new ones – but with the document procedure J instead. I assigned the same pricing procedure as before to the PC sales area entries and left the original settings in place (as these would be needed for their IV invoice which remained as I).
For Japan, I created a completely new entry in their sales area, assigning document procedure J but now with pricing procedure ZCA007. I then created the new condition exclusions, carefully removing the condition types used for freight and packing. This would result in these values being considered when the ZF9 billing document was created, but still excluded for the IV.
COPA values would not be affected as the proforma does not post to any GL accounts in SAP.
The solution was a great success, and to guarantee positive regression testing, I was lucky enough to have End users from other Product companies across the world (introduced from previous solutions that I provided) willingly volunteer to assist in the UVT. No issues were reported and Japan were very pleased with the solution provided, speed in which it was analysed and the communication they received during the design, build and test phases.
The changes were migrated to the Production system in the dedicated release and no further issues were found. From what initially seemed a rather complex requirement (due to the way in which condition exclusions are non sales area specific) it was very nice to use existing standard SAP solutions. No ABAP programming was required and the build only took around 4 hours to complete (including unit testing in the development client).