Italian Bollo
Introduction
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.
Key Challenges
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.
Solution
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
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.
Lessons Learnt
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!
Contact JICL Today
Please contact us today to find out more about our services and solutions.