cancel
Showing results for 
Search instead for 
Did you mean: 

Script Logic or BADI for Allocation?

fermin_iduate1
Explorer
0 Kudos

I understand from latest online help for PC10.0NW that when using RUNALLOCATION Logic, the use of *APP in the WHAT, WHERE, USING definition is no longer supported (not available?) in 10.0.

What we want to do is run an allocation based upon driver values that are stored within another model than the one we want to write to.  This would allow us to keep the driver values (which could have a significant volume) outside of the reporting Model (i.e. Profitability) which will already be very large.

Does anyone have any recommendations?

Accepted Solutions (0)

Answers (4)

Answers (4)

former_member200327
Active Contributor
0 Kudos

Hi Fermin,

You started a very interesting discussion.

Unfortunately *APP i only in MS version, never was in NW.

Almost everything you can do with RUNALOCATION you can do with WHEN/REC, not so efficient though in most cases.

So, to keep drivers at proper level you can use LOOKUP and WHEN/REC.

Regards,

Gersh

GFV
Active Contributor
0 Kudos

In my experience the best solution is the BAdI implementations.
Pros and Cons evaluation is up to the project/customer, but the most important reason is indicated in OSS Note 1413180 - BPC NW RUNALLOCATION functions work differently than BPC MS.

At the end it says "For complex Driver based Budget scenarios, you can write ABAP BADI implementation."

Gianfranco

Former Member
0 Kudos

Hi Fermin,

I agree with Vadim. However, would also like to indicate that if you need to do so many data transfers from one model to another, you will end up having duplicate records in different models.

Keeping your requirement in mind, the best fit would be to go with BADI. This will be able to handle the requirement easily, and will be performance effective also.

Hope this helps.

former_member186338
Active Contributor
0 Kudos

Hi Nilanjan,

Everything can be done using BADI, but at the end of the day you will have a system having all calculations coded in ABAP. And when you need to upgrade it a lot of code will require revision and corrections (like with 7.5 -> 10). The script logic functionality will not require such changes and easier to maintain. To my mind, writing BADI is required when:

1. The functionality can't be implemented using script logic.

2. The performance of optimized script logic doesn't suite business requirements.

In all other cases script logic is better. And I hope that sometimes in future the internal logic processing code will be significantly improved At least the developers replaced calculation engine from Java Script to ABAP in some SP for BPC 10.

Additional comment about possible data duplication: It's very easy to avoid it using proper script logic code with RUNLOGIC BADI - always clear target scope before writing data to target.

B.R. Vadim

Former Member
0 Kudos

Hi Vadim,

You are absolutely correct from the development point of view.

However, based on my experience, I have seen, from maintenance point of view, BADI has been better. When we talk about BPC NW, the customer already has SAP BI. And in most of the cases, the customer will have a good asset of ABAP developers. From this context, the maintenance of the system is much easier by the customer. Otherwise, they need to have an additional team who will have a good understanding of BPC's script logic.

There is no right or wrong approach in this. It all depends on the comfort level of the customer (those who need to maintain the system), after we deploy the solution.

former_member186338
Active Contributor
0 Kudos

Hi

I have seen the process of transferring the BADI code support from one developer to another. Even with some documentation it takes a long time for the new person to be able to make changes in this code. And absolutely no issues with script logic (it's so simple!).

B.R. Vadim

former_member186338
Active Contributor
0 Kudos

Hi Fermin,

You always has an option to write a BADI, but first you have to try with script and switch to BADI only in case of unacceptable performance.

If you insist on storing driver values in a separate model in the script file you can copy the required driver values to the reporting model, run allocation logic and then delete driver values from reporting model.

As an example in our case we use 3 models and do all calculations in script logic:

1. Model to calculate driver figures (using complex matrix). The result of calculation is copied in model 2.

2. Model with values to allocate. The allocation is done in this model. The results of allocation are copied to model 3.

3. Reporting model. Some values from reporting model are copied to model 1 to be used in driver calculation. The resulting allocated values are presented in this model 3.

B.R. Vadim