In my last blog on implict enhancements here:
Into the Valley of Depth Rode the Implicit Enhancers
I talked about some issues arising from a client's desire to seriously modify standard SAP MRP (MD01/2/3) via some pretty major and pretty deep implicit enhancements. And in Michelle Crapo's response to this blog, she echoed my feeling that "heavy" implicit enhancements of this type are one of the places where the roles of BPX'ers and developers really diverge: 1) the developer is concerned soley with the technical challenges, whereas 2) the BPXer is concerned with whether the clients is "doing the right thing".
In this blog, I want to show how the same divergence of roles occurs in even relatively minor enhancements that are designed to sidestep oversights in SAP's understanding of its own business logic.
Here's the functional issue in a nutshell.
1) As far back as 4.6c, SAP has allowed the creation of assets without regular depreciation start dates (anlv-afabg) - such assets have special start dates (anlv-safbg) instead.
2) So suppose there's a 4.6c client who's migrating to 6.0 and wants to convert legacy (current year) assets using the SAP-supplied program RAALTD11_UNICODE, including legacy assets that have no regular depreciation dates. (Of course, the client will also have to have someone code a preliminary program to create the "baltd" input file for the RAALTD11_UNICODE program.O
3) In 6.0, the client has set up table ANKV so that a certain asset class - call it AC1 - has a certain vsart (insurance type) - call it IT.
4) The client wants the legacy assets without regular depreciation start dates to wind up in the asset class AC1 in 6.0.
Well guess what!
Deep in RAALTD11_UNICODDE, there's SAP code which basically enforces the following "business rule": if any legacy asset LA is going to be assigned to the asset class AC1 in 6.0 (and therefore associated with the non-null insurance type IT, then LA is going to have to have a regular depreciation start date.
So, basically SAP is saying to the client - "You can't get there from here" - if the client wants legacy assets without regular depreciation start dates to be assigned to an asset class that has an insurance type in ANKV, it ain't gonna happen."
Now let's look at this from the developer's perspective and the BPXer's perspective.
The BPXer is going to try and preserve SAP's business rule and find a functional work around that the client can agree to - maybe using a special asset class in ANKV with an empty insurance type.
The developer, on the other hand, is going to notice the following:
1) RAALTD11_UNICODE calls the form anlv_fuellen
2) ANLV_FUELLEN calls the form anlv_vorschlagswerte_lesen
3) anlv_vorschlagswerte_lesen moves the vsart from ANKV to the ANLV structure of the legacy asset that's being created
4) when control returns to anlv_fuellen, anlv_fuellen tests to see if vsart is initial, and if it isn't, it throws an "E" if regular depreciation start date is initial.
So from the developer's perspective, the problem has an immediate solution:
5) at the end of anlv_vorschlagswerte_lesen form, code an implict enhancement that temporarily clears the value of vsart from the ANLV structure of the legacy asset being created
6) at the end of anlv_fuellen (after SAP's check), code an implicit enhancment that put the value of vsart back into the ANLV structure.
So, what would you do? Try to convince the client to work within SAP's business rules? Or tell your developer to sidestep the SAP vsart/afabg test as in (5-6) above?
My point is - by thinking about seemingly minor cases like this, you can learn a LOT about the real differences between codexpertise and BPXpertise.
And - which is the really the tail and which is really the dog ...
