Dogboy- How to manage new products in a running Prod allocation case

[Former Member]

Hi Dogboy

I want to know what should be the standard process for Product allocation implementation w.r.t. any new product coming in.

I mean to say if my Allocations are up and running, but if the business decide to do product allocation for some other existing products, then what should be the approach to bring those products in. I understand that we need to follow the below steps ( correct me if I am wrong) :

1. Assign Allocation group in the Product master.

2. Create CVCs in the Planning area, //MC62

3. Copy CVCs to Allocation Group //ATPQ_PAREA_K

4. Create Collective Characteristics //ATPQ_COLLECT

5. Copy the resultant CVCs from the Allocation Group back into the Planning Area //ATPQ_PAREA_C

6.Transfer data to planning area //ATPQ_PAREA_W

7. Open book, maintain Allocation quantities //SDP94

8. Close book. Copy Values into Allocation Group //ATPQ_PAREA_R

Since all the above steps are technical for any end user to go and they cannot carry out these steps on their own.

Initially I had thought to create the CVC from Infocube and the load data into the infocube via a csv file, but that doesn't seem to be a viable option because of the technicalities and non reliability of loading data through a csv file.

Now I am thinking of creating an interface which will load the data directly into the planning area/book from an excel sheet. It will be similar to the data load for safety days of supply in SNP planning area/book. This data load through interface can replace step 7 above and we will not need any Infocube.

Now my question is how should i automate the process? through Program/ custom development/ batch jobs/process chains/ any other ? And what are your inputs for handling such a situation? How are these situations handled in other projects?

ARYANG

[Former Member · Accepted solution]

Aryang,

???? Technical? Are you joking? If your end users are incapable of performing these simple steps, I would question whether they are capable of managing allocation in general. This is not rocket science. Several discreet steps are required, each of which is fairly straightforward. The steps themselves only take a few minutes.

The frequency at which allocations must be managed is typically monthly; or sometimes weekly. The volume of maintenance work is typically low (a subset of allocated products). The number of allocated materials is typically relatively low (compared to the entire sales backlog) I have never seen a situation when there would be any payback in automating this process, if one measures the cost to develop and maintain the custom code, compared to the expected labor savings.

It is a moot point, since I never give detailed advice on creating enhancements in these forums. My personal opinion is that most enhancements are a result of trying to support illogical business processes. I will admit that many disagree with my position..

If you choose to use custom programming to automate this process, I unfortunately have no advice for you.

Best Regards & Good luck,

DB49

[Former Member · Accepted solution]

Hi Dogboy

I agree with your point on enhancement/customs that they usually support illogical business processes. I personally never prefer to do that.

But here the business users are very reluctant and don''t want to go inside too many APO transactions. They just want to manage everything form the sales order screen in ECC. So automating might be required to fulfill their requirements.

Besides this, there is an additional benefit which we get when loading data into the planning area through custom development - and that is avoiding the locking logic of planning area. If a business person is maintaining allocation in a planning book and at the same time some user tries to create a sales order , then the system does not allows the confirmation - It gives an error message that the planning book is locked by user xxxxx. So through this custom development of Interface all the data maintained in an spreadsheet will be loaded in the planning area in milliseconds!! No sales order will be affected.

On the question of automating the mentioned steps - I wanted an advise (on the technical feasibility) from you on automating all those 6-7 steps through process chain, if i decide to go for it.

Is it possible to design such a process chain? ..or it can be only handled through custom programming?

ARYANG

[Former Member · Accepted solution]

Aryang,

But here the business users are very reluctant and don't want to go inside too many APO transactions. They just want to manage everything form the sales order screen in ECC. So automating might be required to fulfill their requirements.

There is no standard way you are going to be able to maintain allocations in R/3. If the users who are responsible for maintaining allocation cannot be bothered to log into APO, you have a serious problem with your users. It would be a huge undertaking to create enough programming to perform these transactions from within R/3. Maybe they should be thinking about those unemployment lines that are so prevalent. at least here in the US.

If a business person is maintaining allocation in a planning book and at the same time some user tries to create a sales order , then the system does not allows the confirmation - It gives an error message that the planning book is locked by user xxxxx. 

???? I thought you were performing Sales order allocations in the Allocation group? If you are allowing the Sales orders to perform ATP directly in the Planning area (this is an uncommon setting) then you don't need to copy data and CVCs back and forth between the Allocation Group and the Allocation area.

In configuration, if you want to avoid the 'locking' problem:

IMG > APO > GATP > Product Allocation > Maintain Product allocation group. Under the detail of the group, you UNcheck 'check planning area'. All of the instructions I have up until now given you, and the ones you have quoted from my previous posts, assume that you are ATP'ing your sales orders in the Allocation Group, not the Planning area. Performing Sales Order ATPs directly in the planning area is only suitable for companies that can afford to shut down their Sales order entry system for extended periods of time. Most companies nowadays perform ATPs 24/7/365, which is why they normally use the Allocation Group.

Best Regards,

DB49

[Former Member · Accepted solution]

Hi DB49

thanks for your immense help.

I clearly understand now the difference b/w 'ATPing directly against planning area' and 'ATPing against Prod allocation group' and how we can choose b/w the two by the 'check planning area checkbox'.

As you advised that most companies does not choose to check directly against planning area but in the allocation group and the reason is that they will need to shut down there slaes order entry system for extended period of time.

If I develop a simple interface to load the allocation data directly in the planning area from a spreadsheet like we have done for loading the "Safety days supply" from excel sheet into SNP planning area, then loading the allocation data will just happen in milliseconds and it will avoid any locking logic.

Also, checking directly against the planning area will be easy since we will not be required to copy the CVC and data to and fro b/w planning area and allocation group (and hence business user will also be happy).

What do you think about this solution? Does it sound good?

ARYANG

[Former Member · Accepted solution]

Aryang,

Well, it will certainly work, it is a standard SAP solution. In the solutions I have worked with, the business either immediately, or eventually, found it necessary to move away from performing ATP in the planning area. However, I can conceive of situations where this might not be necessary. Evidently, you have decided that this tradeoff (occasionally locking of ATP) is acceptable.

I don't know how much analysis you have designed into your planning book (this is usually a substantial part of the DP design for allocation). If you intend to minimize lock duration of the Planning area, then you won't have much time available with the Planning book(s) open to perform analysis (e.g. statistical forecasting, consensus forecasting, etc). You are pretty much resigned to performing your analysis externally.

It is a standard solution to upload/download Planning book data using CSV files, with no programming or additional configuration. This solution is commonly used in DP solutions. CSV import is fussy about details, but once the users learn the idiosyncrasies, it is pretty transparent. If you are talking about a custom interface, I can't comment. Remember that opening the Planning book will create a lock. Updating PA with a program will create a lock. Performing ATP will create a lock. All these locks will compete against each other. As long as you are willing to live with this competition, your solution will be workable.

Best Regards, & Good luck,

DB49

[Former Member · Accepted solution]

Hi Dogboy

On your below point :

I don't know how much analysis you have designed into your planning book (this is usually a substantial part of the DP design for allocation). If you intend to minimize lock duration of the Planning area, then you won't have much time available with the Planning book(s) open to perform analysis (e.g. statistical forecasting, consensus forecasting, etc). You are pretty much resigned to performing your analysis externally.

We have a different planning area for DP and GATP, so I don't understand how will the analysis of statistical forecasting etc will be effected since that will happen in a different planning area? And we have very few products ( only 15- 20) for which we'll be carrying out allocations. So loading data through interface will not lock the planning area for more than a second.

For analysis into designing of planning books, I read in SAP help that it's advisable to backup the data into some other version except the active version - 000. Kindly advise on what other analysis are you referring to.

ARYANG

[Former Member · Accepted solution]

Aryang,

The analyses to which I refer are required to support the allocation decision-making processes. For instance: How does the client decide which customers/products will go on to, or be removed from, product allocation? Of each product that is placed on allocation, how does the client decide the quantities that each customer will be allowed to buy? How does a client decide what to do if a customer fails to buy the quantity allocated to him? How does the allocation situation for this quarter compare to the allocation situation for last quarter? What to do if Sales department wants to submit one set of allocation numbers, Marketing wants to submit another set of allocation numbers, and manufacturing wants to submit a third set of allocation numbers? etc etc etc. These are standard business requirements that can easily be managed in a DP environment. This is one of the major advantages in using DP with allocation.

With only 15-20 products, I suppose these activities could probably be better done offline....

Best Regards,

DB49

[Former Member · Accepted solution]

Hi Dogboy

Thanks for the valuable inputs.

One more thing I want to ask is that is there any way the unutilized allocation quantity be carried forward to the next period i.e. rolling over for the unutilized allocation qty? Is there any setting through which this can be controlled?

ARYANG

[former_member209769 · Accepted solution]

Hi Aryan,

You can consider the settings under "consumption period" for product allocation group.

Maintain a backward consumption period, which will tell the system how many days in the past from the allocation check date should be considered.

Also, if you want that allocations that lie in the past (any day day earlier than today, if you are running allocations today) should also be considered, then UNcheck the option of "w/o past period" under consumption period of the product allocation group.

PS: Hope you and Dogboy don't mind my intrusion in your private consulting thread.

Thanks - Pawan

[Former Member · Accepted solution]

Aryan,

I believe expert Pawan has outlined the standard way to manage the issue of allowing un-used allocations to be bought by an allocated customers in subsequent periods. Although, really, I don't find this business requirement all that often. Clients who are on allocation don't usually want to roll forward, they want to award the unused allocation to another customer.

Note to Pawan:

I encourage other forum members to participate. There is a much better probability of getting good answers if many people submit ideas. You should 'intrude' anytime you want!

Best Regards,

DB49

[Former Member · Accepted solution]

Hi Dogboy & Pawan

Thanks for your help.

ARYANG

[Former Member · Accepted solution]

Aryang,

I think I will not need to transfer CVC from Plng area to alloc group, generate collective CVC and transfer it back to Plng area ?

You should continue copying. CVCs between PA and ProdAlloc Group must be consistent. Copying is the sensible method to accomplish this task.

With respect to collective characteristics, it depends upon your business requirements. The only time you need to generate collective characteristics is if you intend to use wild cards (this is common). Even if you only specifically assign one wild card to one characteristic, //ATPQ__COLLECT is the most reliable way to ensure that all the remaining required CVCs containing 'wild cards' are properly created. The logic is fairly straightforward, and I suppose you could create all of the CVCs containing wild cards manually, in //MC62, but this is a tedious task and prone to errors.

The thing that you don't have to do with direct checking is to transfer data back and forth. //ATPQ_PAREA_W & //ATPQ_PAREA_R

With respect to question 2, there are several issues that could be causing your problem. I suggest you study the online help at http://help.sap.com/saphelp_scm50/helpdata/en/02/77073c61563259e10000000a114084/frameset.htm Carefully go through the checklists there.

Best Regards,

DB49

[Former Member · Accepted solution]

Thanks for the clarification Dogboy. But while generating collective characteristics //ATPQ_COLLECT , there are 3 checkboxes:

1. No status adjustmment for characteristics

2. List of new characteristic combination

3. Test

Should I tick the first checkbox while executing the transaction?

Also, Does the 2nd checkbox just displays the CVC

Please advise.

ARYANG

[Former Member · Accepted solution]

Aryang,

This thread has devolved to the point where it is getting really basic. Now you have asked questions that can easily be answered by pressing F1 help, and through online searches within the forum and within standard SAP documentation..

You have displayed quite a desire to learn the basics about product allocation, which unfortunately is not the purpose of this forum. I suggest that you consider registering for one of SAP's classes. I attended

https://training.sap.com/us/en/course/scm670-global-available-to-promise-classroom-095-us-en/

a few years back and it gave me a great start in learning the basics of APO ATP. It was money well spent.

Best Regards & good Luck,

DB49

[Former Member · Accepted solution]

I was not fully satisfied with the F1 help which SAP provided. It was not getting clear whether the 1st checkbox should be ticked or not. I am only interested in adding a new CVC combination and generating the collective CVC for the same.

Thanks for the training link provided but I think such kind of basic doubts arise owing to the unclear language which SAP help uses and one tends to get them at any level, no matter whatever training you attend. Trainings can never match an actual project experiance.

ARYANG.