GATP & PPDS for capability to promise in Steel Industry

[Former Member]

Dear all, the way steel industry products are bought, manufactured and sold it is clear that to map them into SAP , one would need Variant Configuration with immense amounts of Macro authoring for rules. The trouble is in promising the date of delivery, or rather honoring it once you have promised. This can only be done by utilizing a combination of GATP and PPDS. Basically using CTP.

My request to Gurus here is, if anyone has been in similar circumstances, can she / he guide me with some information, material ...or just continuing this discussion. We are about to enter a large scale SAP implementation with above scenario as a focus area.

regards

[alfred_becker]

Dear Siddharth,

You are absolutely right when you say that all, Variant Configuration, gATP, PP/DS and CTP will be required to reflect steel business in a modern and flexible way. I'm afraid your questions is too generic and answers may need to have the size of an encyclopedia.

It all starts with the right master data modelling, and already in ERP-LO-VC you need to make sure that it'll allow to integrate with APO lateron. Some recommendations like for example using class nodes for a certain structure of master data might turn into huge problems as APO doesn't know class nodes at all. Most objects of variant configuration (VC) will be send to APO. Some objects like variant tables, class nodes are not known in APO at all. Other objects like object dependencies (between characteristics) must be remodeled in APO and cannot be send from ERP to APO automatically – but unfortunately those will be necessary in both systems.

The material master can carry partial or full configuration. In case of KMAT (partial configuration) you shouldn’t re-classify the material master after it has been sent to APO or this new information must be send to APO in a master data load. You should use classes 023 and 300 which reflect in APO as class type 400. You have to set-up super-BOM and super-routing in ERP, and from these objects during variant configuration it can choose the correct entries for BOM & routing for a certain sales order item. The routing can affect many operations, so all necessary operations (or activities) can be determined in one step -> for one production level. If additional levels of production are required then the system needs to perform the same steps for the lower level materials. Of course, variant configuration can be configured to determine BOM and a component of the BOM is a configurable material again and with this you can process all steps in one run. In this way the complex structure of steel products can be reflected in the system. You may want to consider Business Rules Framework BRF+ to reflect all the complexities and dependencies in metals business.APO can take over super-BOM and super-routing and it can create different lines in one PDS for different entries of BOM and routing. But all the dependencies between characteristics you have created in ERP need to be remodeled in APO. They can’t be copied as the format is totally different. They need to be reflected in a BAdI and they get executed when the PDS is used in APO. In this way you can modify the values of a PDS in APO based on current configuration of an individual sales order item in ERP. Unfortunately there is no real documentation how you do that, I have listed some documentation below explaining how to reflect characteristic requirements at dependent demands of a planned order in PP/DS and this can give an idea how to. There are a number of implementations already completed successfully, and in consequence there is a number of people available with the right knowledge. This includes implementation partners specialized on metals (Accenture, GESIS) or Mill Products (SAP Consulting). All of those could be of great help but their services will be liable to costs.

A good starting point may be this collection of information (But all topics of this list cannot explain how to implement rather than how to avoid traps):

• SAP notes 1306779, 1430993, 459694, 528189, and related notes are a good source to start with  

• SAP may recommend certain modeling approaches in LO-VC which are not to be used in case APO is being used, too. (example: use class nodes in R/3, if there are many possible values / value combinations for a characteristic. But APO doesn't know class nodes, so you will end up with many many lines in a PDS) 

• Some objects in VC are not available in APO at all (class nodes, variant tables, variant functions, etc.). This stuff needs to be re-modeled in APO completely. 

• For Mill customers, we recommend to set APO configuration scheme to CDP and not to VC (We mean it! Use CDP although a customer sees himself in MTO business...), see note 1284461. CDP and VC cannot be used together in one client anymore, see note 1236319. For internal systems only you can still use both settings in one client, switched per material, see note 882692.  

• Setting the scheme to CDP may lead to restrictions, for example in gATP - you can use rules-based ATP, but no multi-level ATP anymore.  

• Use ERP class types 023 and 300, which get condensed to APO class 400.  

• Use identical names of batch class 023 & variant class 300 

• APO does not support multiple classes of variant class type 300 containing APO relevant characteristics 

• Do not use class type 200 or similar which would allow using class nodes. Integration to APO is possible partly, but it's not fully tested nor is it approved. 

• Dependencies between characteristics can be reflected in a variant table. This is not available in APO, so it must use object dependencies there. The maintenance of such data is much more complex than maintaining the variant table and the question remains if business people who usually have the need to change such data can still maintain it. 

• Avoid using multi-value characteristics  

• Avoid alternate sequences of R/3 routing 

• Avoid unspecified characteristics (e.g. define also a characteristic value for “not selected/not specified), See notes 526883 and 528189.  

• Avoid restrictable characteristics because they cannot be transferred to Product Data Structures PDS. (However there is a workaround for that) 

• The fields that could be used as reference characteristics in a dependence in ECC do not necessarily exist in APO. Although you can actually add fields to the PDS structure, you can not make those fields available for the object dependencies on SCM (only custom solutions exist, ask GESIS, Salzgitter AG) 

• In ERP object dependencies can be connected like a chain; the first one writes characteristics values which are read in the second or in the third one and so on. In ERP all dependencies belong to the same group and they can be sequenced in any order. If you move them to SCM, you have to choose which group each dependency belongs to. You have 'Activity' groups, 'Mode' groups and 'Operation' groups. During the explosion of an order in APO the system first executes all dependencies of Activity, them all of Mode and them Operation. 

• To determine which group each dependency should belong to is made based on the reference characteristic in the dependency. Reference characteristics of a dependency can only write and read values which belong to the data structure of that specific group. Mode data like “resource” and “operation time” can only be read or written on a dependency of the group 'Mode'. The same rule applies for the other groups. In ERP you do not have this limited scope, all dependencies belong to the same group, so a characteristic can be read or written in all dependencies of a router if necessary

ATP configuration is not much different in steel business than in other businesses. And as CTP is nothing else than ATP calling into PP/DS, the PP/DS application is where the complexity will be found afterwards.

A few words to CTP: first of all this is very preformance critical and SAP recommends to include only bottle-neck resources into a CTP check. Second the same resource can be planned in different modes depending on the calling application. And for steel processes you may want to use "block planning" which constraints any capacity offering with additional characteristics like grade or coating (->classifed resource). So if a block for a certain grade is planned on a certain day, you may want to reflect the block as a bucket within CTP check, but lateron during any PP/DS run the same block is scheduled time-continuously for sequencing.

There would be so much more to say, but I guess this forum cannot replace training, classes or assistance by experienced consultants.

Regards,
Alfred

[former_member225637]

Dear Alfred,

your detail explanation about CDP is very nice

I have one question in this

"Dependencies between characteristics can be reflected in a variant table. This is not available in APO, so it must use object dependencies there. The maintenance of such data is much more complex than maintaining the variant table and the question remains if business people who usually have the need to change such data can still maintain it "

My understanding from above APO does  not support variant table and it is recommended to used object dependency correct me if I am not wrong

if Variant table can be used in ECC DMIP is it possible to CIF to APO ?

if you are not clear about what I am asking please let me know

Thanks

Regards

Raj

[alfred_becker]

Hello Raj,

No, it is not possible to CIF variant tables to APO. There is no integration model available for variant tables and APO wouldn't be able to interpret this kind of data.

Best regards,

Alfred

[former_member225637]

Dear Alfred,

which mean we are not advised to use Variant tables in ECC (IS-DIMP) if we want to use characteristic based planning in APO

IS it possible to transfer object dependency from ECC to APO ?

if have more than 400 variant to be used how to map in APO for Characteristic based planning

Regards

Raj

[alfred_becker]

Dear Raj,

Indeed it is not advised to use variant tables in ECC for those characteristics which are meant to be sent to APO. For others it is possible (e.g. pricing relevant stuff which is unlikely to be planning relevant).

Regarding transfer of object dependencies I couldn't add anything to the (comprehensive) posting of Rajesh Jagadeeswaran you have linked above already.

Regards,
Alfred

[former_member225637]

Dear Alfred,

Many thanks for your clear reply

Here we are using IS Mill- DIMP and SCM 7

we are into textile industry , basically we have quite number for variants like day 400

was thinking either use Variant table or Object dependencies

do you think we can use Object dependencies in ECC and push to apo and plan

or do some development to use variant table

Thanks in advance

Regards

Raj

[alfred_becker]

Well, I'm not an implementation consultant so there may be more qualified opinions than mine available....

From my experience with a number of APO implementation projects in Mill Products industries no one mananged to integrate variant tables into APO but many did use object dependencies even if this meant to re-work some object dependencies in APO.

Additionally I would like to provide a totally different approach: variant config and object dependencies can be seen as rules which define how a certain business process needs to run. Lately SAP offers Business Rules Framework BRFplus which can reflect exactly this.

See also http://scn.sap.com/docs/DOC-8824

This tool can then create function modules out of the rules defined which can be consumed in various systems. In consequence you would have to do the modeling only once. I don't believe this can fully replace variant config due to the deep integration of VC into many applications. But it may be able to save some work for some object dependencies and it could be worth a look.

Regards,
Alfred

[former_member225637]

Many thanks Alfred

it really helps

Hello Alfred,

Just a quick update

i found a OSS note 614280 have a look when you are free

Thanks

Regards

Raj

[former_member495491]

Hi Raj,

it is not unusual to use variant tables in APO. The important thing is, to create the table, before you send the PDS with the relevant object dependencies to APO.

As mentioned before, there is no CIF integration for the table itself. So we transformed the variant table into a DB table and did a setting, that whenever something was changed in that table an RFC call changed also the table on APO side.

If you still use the variant table, you have to maintain it twice or only on APO side.

Regards,

Oliver