Question Re: APO - extreme growth of EBAN table in Supply Chain Management Q&A

APO - extreme growth of EBAN table

former_member192550 — Mon, 14 Mar 2016 06:20:53 GMT

Hi All

We do planning in APO using SNP-CTM. We run net change planning daily and regenerative planning weekly.

The solution is live for little more than a year. We are currently experiencing a state where the EBAN table in ECC (PRs) has around 45 million records. This is creating a problem in system performance. This growth is because of the PRs created from APO.

Kindly let us know the best practices to handle this issue. We know archiving can be a potential solution but we are looking for some other solution to contain the table growth/ PR creation.

Thanks,

Anand Solomon

Re: APO - extreme growth of EBAN table

alok_jaiswal — Mon, 14 Mar 2016 14:15:48 GMT

Hi Anand,

Just checking, are you also noticing any performance issues while accessing standard transaction in ECC like ME21N etc.

You can check below SAP note related to it -

1942976 - Performance issues in transactions.

Hope it helps.

Regards,

Alok

Re: APO - extreme growth of EBAN table

former_member192550 — Mon, 14 Mar 2016 14:19:08 GMT

Yes. We are facing performance issues in standard transactions.

Re: APO - extreme growth of EBAN table

Former Member — Mon, 14 Mar 2016 14:24:51 GMT

Anand,

Archiving is the logical solution for large EBAN tables. Now that your EBAN is so big, you have no other alternative. Once you implement regular archiving, other solutions become less important.

Some options to reduce the number of new purchase reqs being created:

1. Net change planning in CTM

2. Reduce CTM planning horizon

3. Use lot sizing that reduces number of PurReqs required.

Each of these options can have side effects, testing required!

Best Regards,

DB49

Re: APO - extreme growth of EBAN table

Damean — Mon, 14 Mar 2016 15:06:23 GMT

My 2 cents is to take a look at why is there such a high volume of PReq. I know of several companies that generates more than 18 months worth of PReq in APO and send all of them to ERP. Most of them has now redesign their process .... The original reason they want to do so is because some vendors required 18 months worth of forecast for collaboration purposes; these could have been easier to achieve via an SNP reporting cube.