This post was originally written in Portuguese, and can be read in original language here
If there was a burial for TAXBRA, my first question would be: do I go in a black suit or colored shorts? I surely would be there, but I wouldn’t even cry or talk about the wonders it did in life. I enjoy working with processes, and spending months on projects to find out a new crazy way of calculating taxes, honestly, it never caught my attention. Electronic Invoices then ... well, that is my opinion. I have good friends who love working with taxes, but I'm not happy to meet the expectations of fiscal games of creative governments.
Thing is that TAXBRA already has a great replacement solution with a ton of benefits for customers. SAP Tax Service is the name and is already available in Brazil in the version S/4HANA 1805 (in cloud).
Now, let's face it, the fact is that SAP Tax Service is an obvious and natural way, already available to many countries with equally complicated taxes, and has in the cloud strategy dependence on consumption of APIs to keep moving forward. When evaluating the whole context of S/4HANA, the new forms of expansion, consumption of APIs and rationalization of the developments, as well as the elastic and fast way of solutions in Cloud, it is crystal clear that we cannot move forward with TAXBRA and the 320 formula (and many of its’ hardcodes). That is the reason why the change makes all sense.
Before you email me with the phrase "I doubt TAXBRA will die," please notice that and I also doubt it. As I doubt that after 2025 there will be no more SAP 4.6c running TAXBRJ. Now, I strongly believe that balance leans towards the new solution more than the old one,
Entering the detail of the new tax calculation formula, basically the operation passes through the consumption of a service in which the information of the transaction is given, either of purchase or sale, and the API (of SAP and/or partners) will return all the data relevant to the tax calculation.
Architecture design, SAP source. (see original document)
Call
It is sent to service the data unit cost, source, destination, business partners, material and other relevant informations for determination of taxes and aliquots. And here is an important point, in this context J1BTAX will no longer be the primary source of tax and aliquot data.
Return
The return is much larger than the example below, I just separated some tags to show how the return happens.
quote {
total (Nota Fiscal total amount)
subtotal (Sum of the goods price)
country (Country)
…
}
taxLine {
id (Nota Fiscal Item)
totalTax (Total Amount of material, with ICMS + ICMS-FCP + PIS + COFINS)
taxcode (CFOP)
…
}
taxValue {
taxTypeCode (IPI, ICMS, ICMS-ST, ICMS-FCP, ICMS-ST-FCP, PIS, COFINS, ISS, IR, CSLL)
name (Tax description)
taxable (base)
exemptedBaseAmount (lowered base)
otherBaseAmount (other bases)
…
withholdingRelevant (WHT)
…
}
taxAttributes {
attributeType (Values for CST, CENQ,...)
attributeValue (Value for attribute)
The truth is that tax is not at the top of the priority to follow a virtuous path of digital transformation, and separating the core's location from the application seems to make perfect sense to me.
In addition to that, machine learning and blockchain tools may in the near future be used in complement to the API tax, to automate parameterizations, assist in tax operations or even to write in a segment of tax information blocks for later audit. This means infinite possibilities, for an infinitely complex theme.
Want to know more? See the links below:
PS: an information. In this calculation formula, that little button in pricing of “calculation analysis” … It won’t be available anymore, ok?
Innovation for thought!
FM
If there was a burial for TAXBRA, my first question would be: do I go in a black suit or colored shorts? I surely would be there, but I wouldn’t even cry or talk about the wonders it did in life. I enjoy working with processes, and spending months on projects to find out a new crazy way of calculating taxes, honestly, it never caught my attention. Electronic Invoices then ... well, that is my opinion. I have good friends who love working with taxes, but I'm not happy to meet the expectations of fiscal games of creative governments.
Thing is that TAXBRA already has a great replacement solution with a ton of benefits for customers. SAP Tax Service is the name and is already available in Brazil in the version S/4HANA 1805 (in cloud).
Now, let's face it, the fact is that SAP Tax Service is an obvious and natural way, already available to many countries with equally complicated taxes, and has in the cloud strategy dependence on consumption of APIs to keep moving forward. When evaluating the whole context of S/4HANA, the new forms of expansion, consumption of APIs and rationalization of the developments, as well as the elastic and fast way of solutions in Cloud, it is crystal clear that we cannot move forward with TAXBRA and the 320 formula (and many of its’ hardcodes). That is the reason why the change makes all sense.
Before you email me with the phrase "I doubt TAXBRA will die," please notice that and I also doubt it. As I doubt that after 2025 there will be no more SAP 4.6c running TAXBRJ. Now, I strongly believe that balance leans towards the new solution more than the old one,
Entering the detail of the new tax calculation formula, basically the operation passes through the consumption of a service in which the information of the transaction is given, either of purchase or sale, and the API (of SAP and/or partners) will return all the data relevant to the tax calculation.
Architecture design, SAP source. (see original document)
Call
It is sent to service the data unit cost, source, destination, business partners, material and other relevant informations for determination of taxes and aliquots. And here is an important point, in this context J1BTAX will no longer be the primary source of tax and aliquot data.
Return
The return is much larger than the example below, I just separated some tags to show how the return happens.
quote {
total (Nota Fiscal total amount)
subtotal (Sum of the goods price)
country (Country)
…
}
taxLine {
id (Nota Fiscal Item)
totalTax (Total Amount of material, with ICMS + ICMS-FCP + PIS + COFINS)
taxcode (CFOP)
…
}
taxValue {
taxTypeCode (IPI, ICMS, ICMS-ST, ICMS-FCP, ICMS-ST-FCP, PIS, COFINS, ISS, IR, CSLL)
name (Tax description)
taxable (base)
exemptedBaseAmount (lowered base)
otherBaseAmount (other bases)
…
withholdingRelevant (WHT)
…
}
taxAttributes {
attributeType (Values for CST, CENQ,...)
attributeValue (Value for attribute)
The truth is that tax is not at the top of the priority to follow a virtuous path of digital transformation, and separating the core's location from the application seems to make perfect sense to me.
In addition to that, machine learning and blockchain tools may in the near future be used in complement to the API tax, to automate parameterizations, assist in tax operations or even to write in a segment of tax information blocks for later audit. This means infinite possibilities, for an infinitely complex theme.
Want to know more? See the links below:
- https://api.sap.com/api/taxservice/resource
- Specific Brazil Informations in version 1805 (link) - Country Specifics > Brazil
PS: an information. In this calculation formula, that little button in pricing of “calculation analysis” … It won’t be available anymore, ok?
Innovation for thought!
FM
- SAP Managed Tags:
