As a support engineer, now and then I get incidents that are caused by a SORT PXXXX BY BEGDA DESCENDING ABAP command (Could be also SORT by ENDDA). Normally this kind of sentences are placed in customer includes.
e.g.
SORT P00001 BY BEGDA DESCENDING
On the other hand, a very popular way to read the information contained in infotypes in the HCM / Payroll modules is the provide statement:
Read more about the provide statement:
http://help.sap.com/abapdocu_70/en/ABAPPROVIDE.htm
Well, the provide statement is powerful but may be also a little tricky and what is more:
PROVIDE ONLY WORKS WITH INFOTYPE TABLES THAT ARE SORTED BY DATES
got it?.
One of the most popular places where the sentence "provide" is used is function WPBP:
PROVIDE massn massg stat1 stat2 stat3 FROM p0000
persg persk bukrs werks btrtl kostl plans gsber
vdsk1 ansvh orgeh stell
fistl geber fkber grant_nbr sgmnt
budget_pd
dysch wkwdy arbst
schkz empct zterf FROM p0007
subty
trfar trfgb trfgr trfst
bsgrd divgv waers FROM p0008
BETWEEN pn-begda AND pn-endda
How hasn't ever debugged this beautiful piece of code?.
So if the following sentence is executed before FUWPBP in a payroll run (Typically in retrocalculations):
SORT P00001 BY BEGDA DESCENDING
No wonder you'd get a rejection like this in the next WPBP execution:
Of course, the above example is one of the most typical but not the only one: Basically there are as many forbidden SORT DESCENDINGs in your payroll as different PROVIDE sentences there are.
So if PROVIDE P0456 is in your code, never put a SORT P0456.
What to do?.
Use something like:
AUX_P0456[] = P0456
SORT AUX_P0456[]
Being AUX_P0456 your own local variable.
Remember that PXXXX are global variables in your payroll driver and any manipulation may cause side-effects.
Take care and enjoy your vacation!