During July 2009, Wartsila Finland's Corporate Tax department were informed that as of 01.01.2010, the place of supply (when determining and reporting VAT) for service related materials would no longer be where the work physically took place, but from the customers fixed place of establishment. This was refering to the EU Directive, (article 44) and was targeted at the Business to Business (B2B) scenarios. There were also notes relating to Business to Customer (B2C) where a distinction had to be made between the two scenarios. These details were provided via SAP note 1371729. However, the B2C section was not applicable, as Wartsila at the time did not supply to consumers.
As with standard SAP solutions, the 'ship to party partner's country key' was always the key field used to determine the tax destination country. This of course meant that for service materials, the tax destination country would now need to be determined from the sold to party partner, (customer address).
Secondly, service related billing documents also needed to be reported separately on the EC Sales List. There were other OSS notes recommended to be implemented by the FI module for the report to make this possible, including new entries to the tax code configuration.
To summarise, a distinction between spare part and service materials would be required, and invoiced dependent on the tax destination country for the particular material type.
Wartsila was the first customer of SAP to realise that a solution for cases where spare part and service materials were invoiced on the same billing document (in effect, two tax destination countries) would be needed if all business transactions were to continue as normal . At the time, there was no available solution from SAP for mixed cases, and after raising a message via the on line portal, it suddenly became apparent to SAP that Wartsila would be the first of many customers that would require some answers for mixed cases, and quickly!
I was subsequently asked to attend The Grosvenor Hotel in London to explain how Wartsila overcame this problem, and the experiences / lessons learnt from that complicated phase in the project. Unfortunately I had to decline, due to other commitments at the time.
During the kick off meetings with multiple Business Controllers accross Europe, it was also clear that there would be many country specific requirements throughout the project, namely Greece and Cyprus.
To begin with, we first looked at the original OSS note and how SAP recommended the split of spare parts and service materials. However, Wartsila's SAP system already had an existing solution in place to do this via the MWST condition record, where material tax classification was a field previously selected from the field catalogue and applied to most tables (where required) on the MWST access sequence.
The MWST condition records would be maintained with material tax classification 1 or 0 (taxable and non taxable spare parts) and 6 or 5 (non taxable and taxable service materials). However, both material types (1 and 6 or 0 and 5) on the condition record within nearly all MWST tables shared the same tax code, making it impossible to split the material types when running the EC Sales List. This meant that for every EU company within Wartsila, (fifteen) there would need to be new tax codes created and applied to new MWST condition records, valid from 01.01.2010. After checking with SAP if this solution would be acceptable (and more importantly - supported after any further OSS notes or upgrades) Wartsila agreed to continue with this solution.
Regarding the resetting of tax destination country, USEREXIT_PRICING_PREPARE_TKOMK was updated with the Include ZSD_EU_VAT_SERVICES_MV within MV45AFZZ (Sales Document) and RV60AFZZ (Billing Document) meaning for service items, the system would set the destination country according to the Sold-to country (whereas for goods the destination country would remain the Ship-to country). This would lead to the correct VAT (condition type MWST) determination and the corresponding VAT codes.
There were many other unexpected issues that also needed to be resolved before 01.01.2010. One of them relating to the correct VAT number being determined, (also issues affecting the EC Sales List incorrectly showing domestic VAT numbers when clearly only non domestic VAT numbers should be reported).The Wartsila rule to determine the VAT Registration number followed the logic that the number should always be determined from the Sold-to party partner. So In cases where there was a mixed scenario (goods and services on one Sales Document) and either the Sold-to or the Ship-to were in a non-EU country, but the other partner was in a EU-country, the system would determine a VAT number for the EU items, but none for the items going to the non-EU member.
As the customer VAT number is a header field, the system needed to split such cases into two separate Billing Documents. In order to achieve this, the relevant Copy Routines also had to be adapted to meet this requirement. SAP were again contacted over this matter, and they confirmed that our solution was the correct way to proceed.
Finally, (not related to the SAP Note or directly related to the VAT Package), another important requirement related to tax determination was also to be implemented. If the customers (Sold-to party) VAT number was from the same country as the selling Sales Organization, domestic taxes should apply (as if the VAT number field on table KNA1 was blank). This however, should only be active, if no further EU VAT numbers were maintained for the EU customer on table KNAS.
For this, the standard SAP Requirement 007 (as assigned to the Access Sequence MWST) was to be enhanced, in order to check the format of the number, (first two characters). A new requirement, (607) was created and assigned to the MWST access sequence. It was also required that for Greece, whose VAT number began with 'EL' but country code was GR required some additional ABAP code in order to recognise the VAT number.
As you can read from the solution section, the whole logic of VAT determination within SAP for EU companies was changed for Wartsila. A basic appreciation of VAT determination should have been mandatory, prior to asking any of the End Users to participate in the project. However, as more and more legal requirements were added to the project scope, nobody could have anticipated the complexity of forthcoming changes. After the project was closed, I was asked to document the technical changes that had been implemented. The document was thirty seven pages long.
The requirements and design from a system side were clear, but business was never fully aware of what was expected from them, even during the validation phases. Many countries did not have the resources or experience to contribute to the UVT, meaning that I had to do many (unanticipated) hours of training, testing (on behalf of business) and documentation, explaining what would happen from 2010, and how any problems could be prevented when the new logic was implemented, namely the relationship between differing services rendered date (sales document type dependent) and validity dates for MWST condition records.
The project expected to be close February 2010, but did not until June, as not only were the training issues delaying us, but many other requirements were added to the project as mentioned above. Many were known issues from the original SAP roll out, which included VAT number determination, master data clean ups, plants abroad and ICB / drop shipment scenarios etc - which we also fully resolved for Wartsila by the end of the project. The project was a great success, and all members of the development team gained a large amount of cross modular experience.
When Italian businesses invoice their domestic customers an amount greater than 77.47, and no VAT is applied, they are required to apply an additional 1.81 to the final amount, (Bollo). This is a legal requirement and has been the law in Italy since 1863, (although the amounts differ on a yearly basis).
SAP has a standard condition type (BOLL) in its relevant pricing procedures to cover these types of scenarios. When pricing takes place, the condition record is triggered if the above criteria are met, and the 1.81 is applied to the total sum. The condition record itself is of course set at item level, but BOLLO will only be applied once for all items. It is also worth noting that the amount does not show on the sales document, only when the billing document has been created.
With the introduction of the EU VAT Package, Wartsila Italy required two new tax codes creating, to cover domestic sales to seagoing vessels.
These were as follows:
L0 (EXEMPT- ART. 7 C.1. DPR 633/72)
ME (Exempt-art. 7-DPR 633/72)
The tax codes would be used for EU and non EU (export) payers. However, the condition type BOLL would now also need to be applied, if these tax codes were determined on the billing document.
Italy also required an English text declaration to be displayed on the billing document outputs, where SmartForm Z_SD_BOLLO would be adapted to meet their needs.
The first concern was that the standard SAP solution used a table for BOLL records that did not contain the tax code as an available field, (held in KOMK-MWSKZ). Since BOLL is always behind MWST, we discussed a variable that could be used that temporarily stores the value of the tax code (KOMV-MWSK1) and could be used the moment the condition BOLL is performed.
Routine 026 which is assigned to BOLL could be enhanced, I.e. copied and replaced with a 926 to only assign Z (flagging the data as active) to xkomv-kinak when KOMP-MWSBP not equalled 0 or when the tax code contained LO or ME. However, this was not feasible. Whatever changes we would carry out, we confirmed that no changes would be required to the access sequence Z110 (Bollo in Fattura), or to MV45AFZZ - as the sales order was not to be affected. There was also some confusion over whether or not BOLL should have only been active if condition type LCIT was determined during the pricing. LCIT is only active in the sales order if an LCIT condition record exists for the customer, but after confirmation from end users in Italy, it was agreed that LCIT (and any associated condition records) would not affect the applying of BOLLO to their invoices.
After much time spent re-analysing the requirements, and discussing possible solutions with external ABAP developers, it was agreed that a new formula would be created (as originally thought) and replace the standard one provided by SAP (026) on the pricing procedure at step 917. The formula would include the following
if komp-mwsbp NE 0 or komp-zzagarea = 'C' or komp-zzagarea ='E'. xkomv-kinak = 'Z'. endif. if v_tax16 eq 'L0' or v_tax16 eq 'ME'. CLEAR xkomv-kinak
Thus, if the net value is not equal to 0 or payer is equal to C or E, (I.e. not domestic) mark the condition as inactive. If the tax code equals L0 or ME, then clear the inactive field. This provided the necessary solution, and the changes were UVT approved by business and moved to the Production System during the originally assigned release. All deadlines were met and the originator from Italy was extremely pleased with the extra effort that was required and applied from me during the requirements stage, so all the deadlines could be met. I subsequently wrote the release notes and clearly communicated the changes to the business via a PowerPoint presentation.
When I was asked to provide a solution to this legal issue, it initially seemed quite a simple requirement. Determining a condition record depending on a specific tax code fetched to the billing document at first glance did not seem to involve too much analysis, but when it became apparent that the tax code could not be directly related to the BOLL condition record, it was clear that additional ABAP resource would be required. Transferring the requirements to my developer also had its problems, and many live sessions were needed in order to communicate these effectively, in the hope that any unit testing would be approved first time around. This turned out not to be the case, and at one point it was feared that the solution would not be approved in time for the release schedules deadlines. However, we did manage to get the confirmation approval to Release Management -but with only hours to spare! From this, I learnt never to underestimate a business requirement, as the simplest ones can sometimes be the most difficult!
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).
When a payable purchase order is created from a normal (delivery related) sales order in SAP, the costs to the seller (sales organization) are determined from the vendor's invoice, (and must be equal) when applying the VPRS values on the sales invoice.
There are also cases where a purchase order will be created where no vendor invoice will be receipted, (i.e. purchasing free items). The standard way is to flag the item as free of charge directly in the purchase order. When this takes place, (as it is not possible to receipt an MM Invoice for 0.00) no costs to the seller are determined. Therefore, when the sales invoice is created, the condition value for VPRS is fetched from the moving average price of the material master record instead. This is standard SAP functionality.
This is incorrect when the PO is FOC, as there are no costs to the seller - as the real costs should have been equal to the external vendor's invoice, (0.00). This error lead to discrepancies between PCA and COPA costs. Therefore the requirement of this CIP is to prevent the costs appearing from the material master record when the PO has a net value of 0.00.
I created a new item category ZTBV (W IndPO FOC, FOC PO) A copy of ZTBF in table TVAP.On the Business Data settings of the new item category, I unchecked the "Determine Cost" indicator. After saving the new item category, I made the assignments to the sales document type and existing item category groups in table T184.
Once the above steps had taken place, the new item category ZTBV (W IndPO FOC, FOC PO) became available for use on sales document type ZTFR (WT Free of Charge). By manually assigning this under the free of charge PO scenario, the item category was then uniquely configured to NOT determine costs on the order / invoice. Hence, VPRS would always be 0.00. This way of working was only to be used in the FOC PO scenario, and by doing so prevented the MAP from material master being fetched to COPA.
This was a very quick and simple solution that was migrated to Production on time and with very satisfactory UVT results. The most difficult part of the change was instructing the Key users about this new functionality, and ensuring the item categort was used correctly. However, with clear .ppt slides it was communicated at the correct level and no issues arose after the Go Live.
Client X invoice their services to customers via one of two different billing mechanisms, based on the contract between them.
Firstly through a Resource Related Billing process, where again this splits into two processes. Internally delivered work is where costs are posted to a works order via confirmed time. The second is when the work is sub-contracted to an external vendor, and costs are again posted to the works order but via service entry sheets.
The costs from both scenarios are copied through to the subsequent Debit Memo Request (DMR) and populated on condition type EK01. However, EK01 is not the reference condition for populating the sales price (ZPR2), but a “fixed rate” sales price for the material determined (via the DIP Profile’s material determination) based on a quantity of time (measured in EA). Note that due to the requirement to use serial number profiles (in order to activate technical objects for using Functional Locations) on the DMR, the minute unit of measure could not be adopted – you cannot assign a serial number to a measurement of time.
The second method was a bespoke DP90 transaction (ZPD90) that was created to “copy” activity numbers / service masters from the confirmation and add to the DMR, when a different Billing form was maintained on the works order. The requirement being that dependent on the customer, and whether the work was performed internally or externally, then the billing form and DIP profile in the works order should be auto populated and thus, providing the correct billing mechanism – I.e. fixed price materials (copied from services) or use standard DP90 with Resource Related Billing.
Each of the two billing methods both had separate rules as to how “minimum cost to the customer” should be calculated. These were as follows:
Fixed price Services (i.e. actual materials) – “Minimum order” value
RRB with fixed price per quantity transferred (I.e. the labour) – “Minimum item” value
Finally, during the second scenario, there was a requirement to “round up” the price of the Labour into 15 minute intervals, and this should only be effective after the first full hour had been invoiced.
Quantities of minutes could not be adjusted, else the business would lose sight of the actual number of minutes that were confirmed, (initial sales price) which would then lead to losing visibility of the any revenue made from “rolling up” their number of minutes, (I.e. final ZPR2 minus initial ZPR2).
The second challenge was to ensure that the billing methods never overlapped, I.e. do not charge a minimum order value of the item(s) have a minimum amount themselves. Also, there were the following scenarios to consider:
- Recalled works (Free of charge) where KBM1 was utilised
- Out of hours (Fixed price with and without a profit surcharge dependent on customer)
In summary, the billing requirements were quite complex and needed to be fully automated based on one key factor… who the customer was and when the work took place. Apart from these facts, it was expected that the system would fully automate the remainder of the pricing calculations.
Minimum order value:
To achieve this, the standard minimum order condition types (AMIZ and AMIW) were copied and assigned to the pricing procedure – ZMIW and ZMIZ. The tables as standard included the “Pricing group” and a record was created against the Sales Organisation, Distribution Channel, Division and Price Group (Z1) – with a value of £50.00.
By maintaining only certain customers with a Z1 on their master data record, it guaranteed that if the vendor invoiced this customer, then a minimum order value of £50.00 would be applied regardless of the items being invoiced. We now needed to prevent the minimum order from being triggered if the scenario dictated minimum item value. The one control that would not change would be the billing method for the customer, so by NOT maintaining a Z1 on specific customers meant that they would never be invoiced a minimum order value – I.e. those customers that preferred to be invoiced based on a time calculated rate (and chose to pay a minimum item amount for Labour).
Minimum item value:
This condition type was a little more difficult, as standard SAP does not provide a condition type to support this process. I investigated several options, including the use of minimum order quantity on the material master, (not appropriate as this is “Order quantity” based, not “Target quantity” as in a DMR). Also, material determination - even Sales BoM’s etc. None of these were a suitable solution. I finally created a copy of the minimum order value, but requested a calculation (913) to be created that checked the previous condition type (the reference) and applied an uplift to the item, as in the header. Naturally, there would only be condition records created for the material “Labour”.
As a precaution, I also created some condition exclusions that deactivated the minimum order value if minimum item was active, and vice versa. The rules would be as follows:
- Minimum order is initially active (as it is document type specific only)
- Minimum order will be set to inactive if minimum item is active - Controlled via condition exclusions
- Minimum item will only be active if there is a valid condition record - Controlled via condition records created for material “Labour”
- Minimum order will be included when invoicing option 1
- Minimum order will be excluded when NOT invoicing option 1
- Minimum item will be included when NOT invoicing option 1
- Minimum item will be excluded (not determined) when invoicing option 1
The first thing to do was to create a material called “Labour”. This would be the material used during option two when RRB was the billing method. Once this had been created and configured in ODP1, I then created a typical sales condition record (ZPR2) that was maintained with 15 minutes at £12.50.
Finally, add the formula to the conditon type on the pricing procedure.
Finally, the requirement to start “rounding” the minutes that were transferred from the DIP profile was achieved by creating a custom table (ZROUND_2544) and would be handled through pricing (and not quantities). Firstly, the requirement should not be fulfilled if the minimum order condition type was active (as this was a separate billing method and only Labour should be rounded). If the minimum order was not active, the next check would be to make sure that the material existed on table ZROUND and was flagged as active (so it could be controlled via a maintenace based master data table). This would store all the service materials that (when determined through RRB) would then round up to a value based on a piece of master data.
The calculation (formula) would then as follows:
Check the item being invoiced on the DMR exists on the custom table ZROUND_2544 (and is flagged as active)
Read Pricing Communications-Condition Record for condition type ZMIV
If condition record is found
And condition record is active on the DMR (I.e. minimum item value has been activated)
And has a positive rate (so it avoids "divide by zero" in any calculations)
Read Pricing Communications-Condition Record for condition type ZPR2
Only continue if record found
Condition pricing unit must have a value (so it avoids "divide by zero" in calculations)
Divide Item quantity(I.e. minutes confirmed) by the pricing unit and round up to one decimal.
63 minutes divided by £12.50 = 5.04, therefore becomes 6
Multiply the resultant value (6) by the Pricing Communications-Condition Record rate (6 x £12.50)
Round resultant calculation to 2 decimal places to determine condition value
Pass condition value back into standard SAP and populate ZPR2.
Finally, add the formula to the conditon type on the pricing procedure.
During the initial pricing workshops, there was a clear misunderstanding as to what “Actual costs” referred to. Whether correctly or not, I interpreted this phrase to mean the actual costs posted against the works order, whereas the client mean that it was “Actual time”, and time had a fixed sales price – not related to the costs whatsoever. It was quite far in the project when this was realised, and after some development had already been done to check activity rates, cost centres etc. to determine a “cost per minute” that should be added to the DMR.
The lesson I learnt from this was to “play back” the solution as early as possible, perhaps in a simulated environment or pilot the solution with the client before any development and configuration is carried out. What may seem obvious to the Functional Consultant may mean something completely different to a client - if they are not familiar with SAP terminology and the strict guidelines that it it follows.