GMDERIVE - Best Practices

[Former Member]

Hello experts,

Do you have any best practices to share for the setup of GM DERIVE? Although I know this is company-specific, I would appreciate if you could give some advice.

I am currently analyzing 2 possibilities for the derivation of sponsored objects, but neither of them satisfies me completely:

1st option:

Set up derivation rules, and maintain correspondance table (i.e. sponsor + GL account = Sponsored class).

The main disadvantage here is that every time a user creates a new sponsor or sponsored object, the correspondance table will have to be maintained manually. I am afraid this will create additional workload and risk of errors.

2nd option:

Use a function module to derive sponsored objects from the master data.

This is a little complex, specially for the derivation of sponsored programs, because it means the program has to:

• Select combination of funded program and fund center

• Check in which funded program groups/ funds center groups they are used

• In grant and/ or sponsor master data, select each sponsored class and check if the combination of funded program group/ fund center group is found in view tab "Allowed Budget and postings".

This seems sooo complex! I am sure there is a simpler way to do it, the advantage being that the user would only maintain the master data and no parallel tables on top of it.

Is it possible to use tab "Budget transfer"instead of "Allowed budget and postings" for the derivation?

I was not able to find the real use of tab "allowed budget and postings" in the SAP help, and I am wondering why we have both:

• "allowed BUDGET and postings"

• and "BUDGET transfer"

Does this mean there is a double check for budget entries?

Thanks for taking the time reading this, I hope it is clear. And thanks in advance for your answers and for sharing your experience on this matter.

Regards,

Nafissa Diop.

Edited by: Nafissa DIOP on Mar 5, 2009 11:44 AM

[paul_abrahamson_sap]

We went down the route of having our own master data table to match GL accounts to sponsored classes, but with a set of defaults for each Business Partner.

The advantages for us are:

1. Control of the mapping is in the hands of the end-users who set up the grants

2. The derivation rule is static and simply has code to lookup the mapping table

3. The maintenance of the data is grant-specific / grant-focused.

4. The inheritance of defaults for a Business Partner simplifies the need to do the mapping for all grants, and just allows specific grants which differ from the BP defaults to be defined independently.

We've been running with GM live now since that start of 2007 and have not needed to change our FMDERIVE or GMDERIVE rules since.

Regards,

Paul

[Former Member]

Hello Paul,

Thanks a lot for your feedback, which is very helpful.