ABAP development and tax customization in SAP: tax scope only, inside Clean Core

What DFSpro builds

Four ABAP development areas, always in the tax scope and inside Clean Core. The scope table shows the extension point and the risk of each one.

When to customize and when not to customize

The decision to customize has the largest consequence in a tax project, because every line of customer code is a line that must be tested, transported, documented and reviewed at each SAP Note and layout update. That is why the criteria below work by exclusion: ABAP comes in only after the cheaper-to-maintain alternatives have been ruled out, in the order they appear.

Two signals help calibrate. The first is how often the rule changes: a rule that changes every time a technical note is released calls for a product or setup, not code. The second is closeness to the core: the closer the code must get to an SAP table or program, the higher the risk, and the stronger the reason to customize must be.

What belongs in the tax scope

Tax scope means the extension exists for a tax reason and is validated against a tax rule. The categories below cover most of what is requested in a Brazilian SAP environment. Each has a typical extension point, a typical risk and a way to test it.

Outside the scope are the overall project architecture, infrastructure interfaces, the platform and generic development with no tax purpose. For the tax integration layer with SAP's integration platform, the page on tax integration with BTP and APIs covers what fits there and what stays with the integrator.

The invoice in SAP and the J_1BNF

1. 01

   First, the layout of electronic invoices evolves through technical notes, and SAP follows it by adding fields to the existing structures.

   Anyone with code that reads or writes these structures needs to know they change this way.

2. 02

   Second, SAP offers extension points specific to the invoice.

   An SAP knowledge base article on filling the AFRMM field (a freight surcharge for merchant marine renewal) in transaction J1B1N mentions two BAdI options: CL_NFE_PRINT and J_1BNF_ADD_DATA (Source: SAP KBA 2730030). The article refers to SAP ERP systems, so in each environment the existence and behavior of the point must be confirmed before design.

3. 03

   Third, reading and writing the invoice directly in the tables is the most fragile path.

   The most stable path is to use the interfaces SAP publishes for the object, and to check that they are released for your SAP edition. The same release logic appears in the section on Clean Core below.

• Complete invoice data. Fill an extra field the layout requires and the standard does not fill, with the rule defined by the tax team and a documented source value.
• Fix a specific behavior. Adjust a case the standard treats in a generic way, such as a specific nature of operation, as long as the extension point is published.
• Read the invoice for checking. Build a report that crosses the invoice, the posting and the tax ledger, reading through a stable interface and not through a copied table.
• Reprocess with a trail. Reopen a rejected document, correct the source data and resubmit, with a record of who did it and why.

Tax calculation and determination: where to be careful

1. 01

   Determining a tax means deciding, for each item of each document, what the tax status is, what the base is, what the rate is and what special treatment applies.

   In SAP this happens in layers: master data, setup, determination rules and, when necessary, code. Each layer above setup raises the cost of maintenance.

2. 02

   The rule of thumb is to push the decision to the lowest and most readable layer.

   A decision table that the tax analyst can read and fix is worth more than a condition hidden in a method. SAP has BRFplus (Business Rule Framework plus) for this, defined in the official documentation as a programming and user interface to specify and process business rules, which lets you model rules in an intuitive way and reuse them in different applications (Source: SAP Help Portal, BRFplus). The same documentation describes functions, expressions, inputs (context) and outputs (result), and features such as simulation, tracing, transport and export.

3. 03

   The consequence for the tax team is concrete.

   With a rule modeled in BRFplus, the auditor's question, why did this item come out with this tax status, can be answered by tracing and simulation instead of reading code. This is an advantage only if the rule is in fact modeled, and if BRFplus is part of the tax solution in your environment, which must be confirmed case by case.

The tax reform strengthens this caution. With new taxes and new document fields arriving, determination rules that are simple today tend to gain new dimensions, and in that setting a badly placed extension becomes a maintenance problem. The page on the tax reform with CBS and IBS explains the calendar and what changes; here the point is that every calculation adjustment in code needs an owner and a review plan for each new act.

Field and data validation: stopping errors early costs less

A document rejection by SEFAZ arrives after issuing, with a technical message and lost time. A field validation done earlier avoids that return. It is one of the healthiest uses of tax ABAP, because the code is short, the rule is objective and the benefit is visible.

• Format. Length, composition and check digit of identifiers such as CNPJ (the Brazilian company tax ID), state registration and NCM, checked before the document is saved.
• Consistency between fields. Combinations that cannot coexist, such as a nature of operation that does not fit the partner type, or a tax status code without the matching base.
• Completeness for the layout. Fields that the current layout requires under a given condition and that the source process tends to leave blank.
• Match with master data. A difference between what the document carries and what the material or partner record states, which points to an error on one side.

1. 01

   First, the message must tell the user what to fix, in clear language, and not repeat the technical code.

2. 02

   Second, the validation must tell an error that blocks from a warning that informs, because blocking too much creates the habit of working around it.

3. 03

   Third, the rule must be written in one sentence that the tax team signs: if the tax team does not recognize the sentence, the code is validating something else.

SPED and DF-e checks: the report the analyst uses

Check programs are the category of tax ABAP closest to the analyst's daily work. They do not issue or book anything: they read what the ERP holds, compare it and show the difference. The page on SPED details each ancillary obligation, and the one on electronic tax documents details the document life cycle. The check sits between the two.

ABAP and Clean Core: what SAP publishes

1. 01

   Key user (in-app)

   For simple needs, such as adding a field, SAP points to the key-user tools. More complex needs should use the ABAP development tools (Source: ABAP Cloud FAQ).

2. 02

   On-stack with ABAP Cloud

   Customer code inside S/4HANA, tied to the process, using only released objects. SAP recommends it for tightly coupled scenarios (Source: ABAP Cloud FAQ).

3. 03

   Side-by-side on BTP

   A separate application that talks to the ERP through an interface. Suited to cases where the extension's life cycle should not depend on the core's cycle (Source: SAP News Center).

4. 04

   Classic ABAP with governance

   In the Private Edition and on-premise editions, it is also possible to build Clean Core compatible extensions using classic ABAP, within the level rules and ATC checks (Source: ABAP Cloud FAQ).

Levels A to D applied to tax

SAP evolved its three-layer model into a concept of Clean Core levels, with four levels (A, B, C and D) based on architectural integrity, stability across updates and alignment with Clean Core principles (Source: SAP News Center). The cards below summarize SAP's definition and add DFSpro's tax reading.

The use of this classification for the tax team is vocabulary. Instead of arguing whether an extension is good or bad, the team says which level it is at and what it would take to move up. An inventory of the tax extensions in the environment, each with a level, an owner and a review date, is a simple and very useful governance document, and it can start from an SAP Tax Diagnostic.

ATC and tests: what prevents regression

Transport and traceability

A tax extension can be trusted only if you can say, for any date, which version of the code was active in production and who approved it. SAP's transport flow allows this when used with discipline.

• One transport order per change with tax meaning, complete, with a description that cites the rule and the source ticket, and never a generic order that mixes subjects.
• Transport released only after ATC with no open messages and a test approval by the tax team.
• A record in the ticket of who requested, who defined the rule, who developed, who tested and who approved, with dates.
• Test evidence attached to the ticket: cases, results and screenshots of what was checked.
• Production transport window aligned with the tax calendar, avoiding a rule change in the middle of a close.
• A rollback plan described before the change: how to revert and what to do with the documents generated in between.

Traceability serves a purpose beyond the technical audit. When an assessment or a discrepancy asks why a tax was calculated a certain way in a certain month, the answer must appear in minutes, with the rule, the version and the approval. This is what turns a customization into a defensible asset, and not a hidden risk.

Documentation that outlives the team

The documentation of a tax extension has three readers: the tax person who needs to understand the rule, the technical person who needs to maintain it and the auditor who needs to trust it. One short document, with fixed sections, serves all three.

• Rule in one sentence. What the extension does, in tax language, signed by the rule owner.
• Legal basis. The act, the article or the technical note that supports the rule, with a link and the date of the last check.
• Extension point and level. Where the code is plugged in, which Clean Core level it fits and why.
• Inputs, outputs and exceptions. What data it reads, what it returns, what happens when the data is missing.
• Test cases. The list of cases approved by the tax team, with the expected result of each.
• Owner and review. Who answers for the tax side, who answers for the technical side and when the rule is reviewed again.

Maintenance for SAP Notes and layout changes

A tax extension is not a project that ends. The environment it lives in changes in at least three ways, and each needs a routine.

A continuous operating model helps keep this routine from being left for the eve of the problem. The page on AMS Fiscal describes how this advisory follow-up can be organized, and the page on S/4HANA migration covers the moment when the inventory of extensions is decisive.

Illustrative example of code and test

The snippets below are short, fictional examples, written only to show the format of a small validation and the test case that goes with it. They do not represent any customer's code, are not meant for production use and do not replace the analysis of the extension point in your environment.

METHOD validar_ncm.
  " ILLUSTRATIVE EXAMPLE (EXEMPLO ILUSTRATIVO E FICTÍCIO). Do not use in production.
  rejeitado = abap_false.
  IF strlen( ncm ) <> 8 OR ncm CN '0123456789'.
    rejeitado = abap_true.
    mensagem  = |NCM { ncm } is not in the 8-digit format|.
  ENDIF.
ENDMETHOD.

Note what the example does and what it avoids. It does one thing, with clear input and output. It does not read an SAP table, does not write anything and does not depend on a global variable. The message says what is wrong. The method fits on one screen and can be covered by an automated test, and the extension point where it would be called is a separate decision, which depends on the environment.

Item: material with NCM 12345678, nature of operation X
Rule signed by the tax team: "for nature X, the NCM must exist in table Z"
Expected: accepts
Item: material with NCM 1234
Expected: rejects with the message "NCM 1234 is not in the 8-digit format"

The test case above came from the rule, written in plain language by the tax team, and not from the code. This is the format we want: the tax team's sentence becomes the test, and the test becomes the criterion for accepting the code.

Roadmap of a tax extension

The roadmap below summarizes how a tax extension should be run, from request to operation. It serves whoever hires and whoever delivers, and it is the reference DFSpro uses in the tax scope.

1. 01

   Request and rule

   The request is described in tax terms, with the scenario, the document and the expected result. The tax team writes the rule in one sentence and points to the legal basis.

2. 02

   Alternatives

   The team goes through the criteria for when not to customize: master data, setup, product, published extension point. The result is recorded.

3. 03

   Design

   The extension point, the target Clean Core level and the interface design are chosen. The tax owner and the technical owner are defined.

4. 04

   Test cases

   The cases are written before the code, with the tax team, including edge cases and cases where the rule must not act.

5. 05

   Development

   The code is written at the smallest possible size, with ATC and unit tests running during the work.

6. 06

   Acceptance testing

   The tax team tests in a test system with representative documents, and the acceptance is recorded.

7. 07

   Transport and operation

   The transport order is released with the evidence attached, in a window that fits the tax calendar.

8. 08

   Periodic review

   The extension enters the inventory, with a level, an owner and a review date, and is reviewed at each new act or each update.

Mistakes that cost a lot in tax ABAP

Most of these mistakes share the same root: treating customization as a technical decision when it is, first of all, a tax decision. When the tax team is at the table from the request, most of them disappear.

How DFSpro works

DFSpro is a SAP tax governance consultancy based in Curitiba, founded in 2018, and works in the tax layer of the project.

For what belongs to setup and standardized determination, DFSpro is also an Authorized Channel for GUEPARDO Tax, a product of NTT DATA, and the choice between product and code is part of the criteria for when to customize. If the question is the current state of your extensions, the SAP Tax Diagnostic is the starting point.

Official sources with links

The statements about the extension model, ABAP Cloud, ATC, BRFplus and the invoice extension points come from material published by SAP, listed below. The decision criteria and the roadmap are DFSpro's guidance.

Start with the rule in one sentence

If you have a tax extension requested, or a set of old extensions that nobody dares to touch, the starting point is the same: write, in one sentence, the tax rule the code runs. A conversation through our contact page is the channel to do this together with DFSpro.