The "How" and the "Why" of rounding-off Tax wage types.

[former_member140346]

I've recently come across a lot of cases where rounding-off of income-tax related wage types has caused a lot of confusion among people who work on PY-IN solution.  Now, the main problem doesn't arise from any bugs or errors in the system, but due to the wide variety of rounding-off behaviour supported by PY-IN payroll driver.  But, before we get into the specifics, I need to address the meat and potatoes first, which is to say that the main component responsible for rounding-off needs to be addressed first before we can move on to the technical aspects of the same.

So, without further ado, I must introduce you all to a rather inconspicuous cog (so to speak) in the giant wheel that is Payroll-India payroll driver processing, namely, the constant called TAXRO.  This constant, whose value can currently be set to either 0, 1, 2, 3 or 4, as of right now, was introduced in the Payroll-India solution via either the Note 2094638 or Note 2094637, based upon your SAP-HR release.  Since then, its behaviour has only grown to become more complex and varied and that is what causes the problems in understanding why and how certain wage types are rounded-off in the system.

Now, I've recently written a wiki to explain the behaviour of this constant w.r.t. the tax wage types generated in the payroll driver.  Now, even though it's a bit of a shameless self-plug, I'm requesting that anyone still reading, hold off on brickbats for a bit, as I'm about to get to the really interesting part soon(ish) and the information given in the wiki will be helpful in understanding it.  The wiki in question can be checked by clicking here.

It's interesting to note that I've only provided an explanation for one of the values of TAXRO, which is "2".  There's a reason for that, which is that even in the latest note released for TAXRO, which is 2314048, SAP still recommends to use TAXRO with this value, so it was apropos to follow their lead.  It is pertinent to note that SAP does not stop you from maintaing a value other than "2" and you can use any value among 0, 1, 2, 3 and 4, as per the advice of your legal counsel.

Now, I promised to get to the interesting part, so before I lose any good will I've earned till now, I'll get down to the practical aspects of the information that's presented on the wiki I referenced earlier, because, honestly speaking, things don't become interesting till we understand the real-world implications of a bunch of mathematical operations on a load of numbers representing employee salary.  So, always remember the following when dealing with this constant:

1. Always keep the value of this constant the same (or in other words, constant.  I couldn't help it, the wordplay was just sitting there waiting to happen) throughout the financial year.
2. Just changing the value of this constant will NOT magically change the values of the tax wage types linked to it because TAXRO comes into play only during payroll processing, so you have to first change the value of TAXRO and then run the payroll and not the other way around.
3. TAXRO will affect the value of wage types displayed on Form 16 and Form 24Q as both of these programs pick up values from payroll cluster.
4. TAXRO doe NOT affect any monthly wage types like /4MT, /4ME, /4MH etc. as NSDL has been noticeably silent about rounding them off.

Point number 3 is of special importance to us as all the rambling I've done till now has basically been a set up for it.  So, to cap off this meandering online discourse, I'll leave behind a few screenshots of how TAXRO affects Form 16.

This first screenshot shows the effect of TAXRO on the Point 3 "Balance" of Form 16, Part-B:

To see the effect of TAXRO on Points 11, 12, 13 and 14 of Form 16, Part-B, please check the screenshot below:

Now, hold on, I know I said, these screenshots were meant to cap off this blog, but I can hear one last burning question, that's bound to come up after seeing these screenshots... "What about Form 24Q?"

Well, to be honest, I would have created more examples for Form 24Q as well, but since Form 24Q is basically using the values generated for tax wage types per month each quarter, I'm sure the correlation for the same can be inferred.  Or, I might come back later with another blog for Form 24Q (if there's demand for it) as this one's already getting a bit too long, due in part to my circuitous style of writing.

Cue, bouquets and brickbats.