Evaluate
Weigh the pros and cons of technologies, products and projects you are considering.
Handling end-user vendor requests
My business goal is to have an end user submit a request to create a direct (DRUS) vendor. I want the user to complete all the information needed to centrally create a vendor. However, I DO NOT want the vendor to be created until the information is reviewed by central person to determine if a similar vendor already exists.
I think this issue is not specific to vendor creation but to many 'approval' scenarios. The question is: How can you persist a particular object (ie. vendor, SD partner, FI-CA document, etc.) before it has been approved? If it is persisted it will begin to take effect in the system even though it has not yet been approved.
The problem has two possible solutions:
* You could develop various custom tables, screens, etc to persist the data in 'temporary' custom tables and then make the workflow update the 'actual' tables once the object has been approved. In my experience, this solution creates more problems that it solves. The overhead of re-creating the tables and enforcing business rules in your custom screens is a nightmare. This approach is seldom the best way to go.
* What I would do is implement a 'status' based approach. Add a field (if one doesn't exist) called Status or perhaps ApprovalStatus. This would be set to 'Pending' on initial creation via the use of an appropriate Exit or BADI. Again, using various enhancement techniques (ie. Exits), restrict the use of the Vendor to DISPLAY ONLY when the Object is in 'Pending' Status. Once it has been approved, update the status of the Object to 'Approved' and ensure that all restrictions are lifted.
Start the conversation
0 comments