Secret Way to Tweak SAP Standard Processing Logic in S/4HANA Finance (Part 1)

If you’ve worked with SAP long enough, you understand how configuration works and the various options within a given module. You know that configuration is used to specify various parameters or objects to support the basic processing throughout the ECC or S/4HANA system. But the logic that SAP uses to process, for instance, a purchase order, to create a journal entry, to settle a project, etc. is largely un-touchable. The code SAP has delivered to handle these processes is frequently not changeable without using enhancements (either SAP published or implicitly created).  Said another way, you can’t influence how standard SAP processes function outside of the options available within standard configuration or via enhancements.

However, SAP does recognize that customers have legitimate requirements where they need this processing logic changed.  For instance, there are customers with such large datasets that they need to tweak how settlement is technically processed to avoid locks or short dumps.  Other customers don’t have this problem and are fine to use the delivered processing logic as-is.

The good news is that SAP has quietly delivered two similar tools that let you specifically influence how some of these programs work! In this new blog series, I’ll introduce the first tool and give you some examples of how it can tweak SAP’s standard processing.

 

Copy Project Plan Data

First, let’s start at the end and go through an example of what kind of tweaks I’m talking about.

Below is transaction [CJ9B] which is used to copy plan data between versions and years for a group of projects.  I’ve highlighted the Fiscal Year fields between the source and target versions.  As you can see it’s only possible to copy a single year to another single year.  No range is possible. 

 

Note 1281578  documents how I can tweak this process if I insert a particular code into the T811FLAGS table.  There are a few ways to do this.  You can create an entry at SE16 (IYKYK) or write a program to do it directly.  The note provides a basic update utility though the screenshots below are from my own version of that program so it will look different.

On the selection screen I’ll specify the table, field, and parameter values as specified by the note.

 

The update was succesful.

 

Just to double-check, I’ll go to [SE16N] and confirm that the entry was created correctly.

 

When I re-launch [CJ9B] there are new fields for the ‘to year’ on both sides of the copy process.  It also will intelligently figure out the target ‘to year’ based on what I populate on the template/sender side. 

 

I’ll be the first to admit that this example isn’t a huge leap forward in … well, much of anything.  Not everyone maintains plan data on a project and copying it over to the new year is usually just a quick one-time event.  But when you’re working in test or QA environments and have to get things up and running quickly, or if you are working in a new system that hasn’t been maintained well for several years, then having little tools like this let you work faster.  Low hanging fruit is still worth grabbing.

 

Background

This specific solution of adding parameters to T811FLAGS is entirely in the CO domain.  The T811* tables are all for managing CO allocations so the CO development team in Germany created this solution for their own way to deliver tweaks to how their standard processes work.  I’m not expecting to find anything in here regarding document splitting or payment method supplements.

You might be asking yourself, why did SAP do it this way?  After all, couldn’t they have just made a direct change to the program behind [CJ9B]?  Couldn’t they add a new IMG activity with a similar flag that would activate this functionality?  Couldn’t they have re-coded the program completely since it’s likely that they have other issues with this old process that could collectively be upgraded? 

The answer to all of those is obvious but they all take more time.  Time is money, money is budget, and no one has all the development budget that they want.  Taking the IMG example… If they added a flag to the IMG they would have to create/edit an IMG activity accordingly, make data dictionary changes, screen changes, possibly edit the IMG structure, develop documentation for it, get it translated to multiple languages (that’s another department at SAP AG), possibly update the official documentation (help.sap.com), etc.  Or they could publish a quick OSS note with the code necessary to deliver this functionality and then only mention it to those customers that show symptoms of the problem that this addresses.  And because it’s a flag based system, it’s easy for customers to implement the code change (if it’s not already in everyone’s system), and then activate it via this tweak.  If it doesn’t provide benefit, then can turn it back off. 

On the one hand, I really like stuff like this.  And while it’s not a polished solution, isn’t the enterprise IT industry constantly pushing SAP to be more responsive?  Develop bigger solutions and deliver them faster?  This one example isn’t that big of a deal but there’s no reason to criticize it either.

 

More Information

I searched in OSS for ‘T811FLAGS’ and got 256 notes!  That’s way too many switches for me to document (!!!) so I’ll let you do your own searching to discover the ones that are most applicable (or interesting) to you.

Here’s a few that I’ve saved over the years:

  • 853601 – Sometimes it’s not possible to maintain CO allocation cycles because of the client/system settings, CTS, etc.  Activating this flag will allow cycle maintenance regardless of any client/system settings.
  • 925346 – This has a flag that assists in identifying why and where certain allocation cycles have long runtimes.
  • 1074098 – The CO-PC period-end transactions for WIP, OH calculation, revaluation, and settlement can be run with parallel processing.  By default, it will use the maximum number of available processes which is not always optimal for other related functions.  Using the flags in this note (CO_WIP_PARA, CO_REVAL_PARA, CO_SURCHARGE_PARA, CO_SETTLE_PARA), you can limit the number of processes that these programs will run on.
  • 2609125 – This is similar to 1074098 but for regular orders that settle to a material.
  • 2204236 – This is an interesting one.  If you are settling a project to an AuC or final asset, you might get error F5727 “Maximum number of items reached in FI” which means you’ve exceeded the 999 line item limitation.  There is a workaround by activating the flag int his note.  After that it will automatically stop processing the settlement after 950 records.  You then repeat the settlement again until the WBS is fully settled.
  • 2750967 – This allows parallel processing of settlement to assets and materials.

 

Next I’ll discuss the broader successor to T811FLAGS.