Reply from Typewriter on Jan 25 at 4:50 AM Dear Dave,
Your posts - in this thread - are value-adding! Thinking about an issue from functional and technical side and sharing those thoughts with the group is learning for many members. Furthermore, this techno-functional approach encourages me to (and may be others) to think from both perspectives (i.e. technical and functional - when ever possible).
I would still go ahead and do some tests and come back with my findings. For me partner procedure is configured in document types along the entire OTC process (e.g. partner procedure determination to sales document type, item category, delivery type, billing type, billing item category). So to set up ship-to party or any partner function in the entire process is a matter of configuration and (should not) be a matter of hard coded programing.
In the future, if SAP decides to change WE to WS then would they have to go and change the program every where WE is hard coded?
This for me is difficult to accept. Anyway I shall do my testing and come back.
Thank you once again for your input!
PS - I have marked your post as helpful.
| | | ---------------Original Message---------------
From: Dave Thornburgh
Sent: Tuesday, January 24, 2012 5:44 PM
Subject: Partner Function SH Already Exists
TW -
For point 1, I don't really need to go much further than SAPMV45A, form KUWEV_SELECT_POSITION. There are a great many spots in order processing that require the structure KUWEV to be filled with details from the shipto partner. The very first statement in this form (which fills KUWEV) is "perform xvbpa_lesen(sapfv45k) using 'WE'". In other words, SAP has exactly one idea of what a shipto is, and you cannot extend that concept because they hard-coded it in the logic.
On point 2, I meant a custom partner function, not type. In other words, I was referring to what you had already proposed.
For 3, talk to your ABAP resource about finding user exits in the programs that maintain customers - like XD01. In the user exit, if the account group is allowed only one SH according to your business rules, then throw an error if the user violates the rule. In document maintenance, the impact depends on what you code. Obviously, SH will need to be marked not-unique so that some account groups can have multiples. Your user exits will need to enforce uniqueness for the limited account groups.
Dave |
| Reply to this email to post your response. __.____._ | In the Spotlight Become a blogger at Toolbox.com and share your expertise with the community. Start today.  _.____.__ |
