Workflow for MM purchase Requisition steps required

Question

Dear all,
        I am trying to configure purchase requisition Workflow.
        I am working with Work flow, WS 00000038
        I have assigned agents to TS 20000162
        Now how to proceed further, do i need to maintain some more settings
        or i should try to test system.
        Regards,
        Gaurav sood

Answer 1

Under the assumption that things have not changed much since 4.70, here's quick introduction:
The workflow is started only when a relevant release strategy is found, so customizing of release strategies is a very important (first) step here.
In the Implementation Guide you find the customizing in the following path:
Materials Management
-- Purchasing
-- -- Purchase Requisition
-- -- -- Release Procedure
-- -- -- -- Procedure with Classification
Only the procedures with classification are relevant if you want to use workflow to notify about requisitions waiting for release.
First you must set up a classification class if that has not already been done. Derive your characteristics from the structure CEBAN. The online help is not too bad, I had never set up classifications before and managed to get it working.
If you need data that are not available in CEBAN, or you want to modify them for the purpose of determining the release strategy there is an enhancement you can implement, and there are customer fields you can use. The enhancement definition's name is M06B0002.
As an example of what you can do, I have used it to set the company code in one of the customer fields, and to change the account assignment type. However, whether you need this enhancement or not depends strongly on what data you use to determine your release procedures (a step in customizing you will get to later).
When that is done you define release groups and release codes. Release codes are defined within each release group. Whether you should use one group or several groups is often a matter of choice.
I myself prefer using several groups even if I don't have to, so long as it doesn't lead to having to define duplicate release strategies (which you will soon get to). So, if there is some characteristic that clearly separates your release strategies, e.g. the highest amount that does NOT require release etc, you can define one group for each value (group) of this characteristic.
For instance, if some company codes require release for everything worth more than 100EUR while the default is to require release from 10.000EUR you could create to release groups. None of your release strategies will be duplicates since the value from which release is required will be different and you thus need to have that as a characteristic.
You then check that the set-up of release indicators is OK, and then you are ready to start defining the strategies. Release stragies are defined within each release group, and use one or more release codes (two or more release indicators).
It is fairly self-explanatory once you get into the screens. The thing to be observant about is to not define overlapping strategies, as this will prevent the solution from working.
When you are done, and have tested the solution in DEV it is time to transport it to the QA system. That's when I got a rather unpleasant surprise. The classification data are not transported, so both the characteristics and class, as well as the classification data in each release strategy had to be redefined. And in roughly two hours I have to do it again in production.
It is possible to transport classification information, it is described in SAP OSS Notes (different solutions for different versions).