It’s Friday… so we found a new decoupled infotype bug
Oh man, it’s Friday afternoon and it will happen: something bad will happen.
This time: modifying IT11 through the Standard SAP_PA in a hcm pf form or PTUI_IT will clash with the computed indicator from IT3 if overlapping, even though I’m only reducing the end date from hidate to a lower one, that is after the Computer indicator from IT3. Which of course doesn’t happen in PA30. Again have to fix this in the Close_luw instead of using pure Standard, again SAP message. This will make the 5th OSS message this week, yay!
Oh ! I can totally relate to that... 15 OSS message last year (11 for the same infotype) and I am using it in a very limited way.... It just feels like decoupled infotype framework was rushed into release to customer... love the concept and the new technology but hate the crappy bugs.
It's becoming hard when the issue at hand is complicated to explain and your OSS handler does not understand it. Still OSS message after OSS message always about the same thing they start to know you. 😉
However if you are in a rush it is always very easy to make a quick fix and transport it to live without modification keys (since its very easy to copy the whole class to your customer name space).
The annoying thing is when legal change affecting the old the framework only get replicated from a certain level of EHP (say 7)... the whole decoupled framework is since first released backward compatible since EHP4.... you know there will be an awkward moment with your local SAP product manager when you client is on EHP6 !
we have reached number 27, but about 8 of them were either stuff that we did not do quite properly. Since about 1,5years.
But the concept is a bit flawed yes, for instance you have the possibility to call commands (I.e. Buttons in pa30) to conversion classes but they are not integrated in the HCM P&F at all. The laughable part was when SAP was proposing to put us in contact with their consulting branch for obvious concept flaws or bugs. The customer I'm with dislikes modifications so I can't move my way around as easily. Fortunately we need no updated (legally) classes typically.
But one of the most annoying things that sap generally does, is not acknowledge the consultants implementing the solution. E.g. What on Earth is the deal with private methods and private variables in the sap form feeder class instead of protected - the one that is meant for inheritance? There is no way to interfere with many things there having to duplicate, overwrite, etc. There is always the possibility to mark an attribute as non writable if they are so afraid. Blatant ignorance of implementation processes at the customer. While we are basically the missionaries outside the sap Vatican...