on 11-29-2006 2:25 PM
Hi,
Can anyone please suggest about the idea of creating shopping cart using dummy account assignment category "U" and then using workflow to route it to the appropriate agent to input the actual accounting information as in my scenario the requisitioner is not aware of the funds and accounting information. I would really appreciate some input on it.
Thanks,
Prathima
Hi Yann/Prathima,
Are we looking at BADIs: BBP_DETERMINE_ACCT or BBP_ACCCAT_MAP_IMP.
Let me know if those help.
BR
Rakesh
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
You don't need to create account assignment category.
If the user (all users i guess) do not know what allocation is required , you can just activate a one step workflow to route to the appropriate agent.
kind regards,
Yann
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi,
You are correct : in standard, you have to fill a correct allocation +G/L in the shopping cart.
My answer was that if for every SC saved, a workflow is required to change the account assignment by another agent, then you just need to activate a one step WF.
If not all SC have to be routed via WF to an agent, then , you have to find a criteria to filter SC to be routed to agent.
In which scenario are you ?
Kind regards,
Yann
Hi Yann,
The scenario is as follows:
1.I have worked on the workflow design and we are planning to use N-Step BADI Approval workflow because there are 3 levels of approvals along with commodity based and dollar value based approvals for certain departments.So,My idea of the design steps were to:
1.Create an Shopping Cart with some dummy G/L Account (Bcoz the requisitioner is not aware of the accounts and funds,they want to just say that I need set of office supplies)
2.After,the required approvals are obtained the final step is to send it to agent responsible for putting in accounting info.
3.Then,before the PR gets created in the backend I thought of using BADI (BBP_DOC_CHANGE_BADI) AND BBP_DOC_CHECK_BADI to validate if the dummy account assignment has been changed to the actual account and if not raise error messages.
The major concern I had was about the consequences of using an dummy G/L Account or to get any better ideas for this.
Thanks,
Prathima
Hi,
I see two options :
1- create dummy code in ECC in order to use it as you have described it.
-> hum....
2- deactivate the account check if the dummy code is defaulted in the SC.
As soon as a value different from the dummy code is set, standard check occurs.
i think you can do it in a badi but not sure which one ...
Kind regards,
Yann
Message was edited by:
Yann Bouillut
Hi Yann,
Thank you very much for your response but can you explain me more in detail about the second option.
I don't know much about SRM configuration and so can you please tell me the steps to deactivate the check and also I didn't understand the point that you have mentioned that if a value other than dummy code is entered standard checks will happen but if we are deactivating the check how can the system validate it.Please let me know about it.
Thanks,
Prathima.
Hi,
As you know, SRM is checking the accounting value against ECC in your scenario.
Thus, badi should be implemented to deactivate this check only when dummy value is present.
As soon as the agent has change the dummy value to a correct value, the standard accounting check works again.
Let me check which badi you have to use...
Kind regards,
Yann
Hi Yann,
I'm sorry but I was just waiting to contact our SRM consultant to verify if we are validating G/L Account assignment with ECC but I wasn't able to find him.When I went in to PPOSA_BBP and looked at the attribute KNT value the backend log.system is not defined and there is only value like "CC".So,from my understanding it looks like there is no validation with back end.Thanks.
Regards,
Prathima
User | Count |
---|---|
1 | |
1 | |
1 | |
1 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.