Planning Primary Costs through Separate Program Execution

PLANPRIMCOST_PRG

* from Allevo version 2.9.18 for annual values
* from Allevo version 3.2.3 also for period valuese

High integration level in Allevo sometimes results in wrong output caused by sequentially performed planning steps during the Allevo planning process. This happens because the sequentially performed BAPIs are not designed for this direct sequence. The reason might be the internal caches that are not updated in a correct way. The current constant allows running the BAPI of the primary cost posting in a separate program context (the so called “roll area”) each time the program is called. Thus, the BAPI is forced to attend to new values instead of relying on the previous BAPI’s caches. (We are not talking of a database cache here but of a cache in a function group which is used by the BAPI. The database cache - if available – remains in use in future). 

The following application scenarios are known to date:

· In activity type dependent cost element planning, the distribution key (VS) is transferred from Allevo (VS11, analog to LSTR) and is also displayed in KP06; still, the distribution itself is not triggered that way. If the key is then manually reset in KP06 to a different value and then again to the initial one, the distribution will be performed as well. A program error in SAP-BAPI for the primary cost planning actually takes place here.  

· If a project is started via BAPI (e.g. in a BAdI in Allevo) and planned with values within the same Allevo step, the planning BAPI can find the wrong project structure in the cache. This leads to an error when rolling up the planned values (e.g. a run-time error if the WBS element from the higher layer is not found; the resulting exception is not intercepted by SAP so that it cannot intercept Allevo otherwise as well).

To avoid this error, Allevo provides a special workaround. This workaround can be activated via the constant PLANPRIMCOST_PRG by entering X in column Value from.

Note:

The constant relocates the call parameters of the BAPI to a separate environment in order to reset the internal variables of the BAPI. Otherwise, no limitations are triggered by the workaround.