‎2005 May 07 1:03 PM
Hi,
I would like to create a time dependent communication data in the standard Business Partner transaction ( Tcode - BP ).
Scenario : A customer might call in to inform that for the coming 2 months he'll be away and wants all the communications be sent to a differnet address for this two months.
Standard SAP documentation says that the the Business Address Service which currently handles the address managemnt does not support time dependent data.
http://help.sap.com/saphelp_470/helpdata/en/12/ad797a5c5811d3b4ea006094192fe3/frameset.htm
Any workarounds to this problem? Anyone who has ever faced such a requirement? Appreciate any ideas on this.
Thanks, Debasish
‎2005 May 08 10:16 AM
Hi Debasish,
Workarounds, 2 spring to mind both with pros and cons:
1. Maintain the customer in another client (an exact copy of the customer), and then use ALE to time the change. This would allow you to store up to 1 time dependent change in the future. So, when you knew a change was coming you could change the customer in the other client, and then schedule the ALE job to process the idoc on the date that the change was due to take place. The pro of this work around is there is no development to do, the cons are that it means keeping your customer data in another client, and that you can only store one change into the future and its not so user friendly.
2. Build your own time dependent function for communication data. Build a dynpro which called the standard address handling screens and then store the data in the standard address tables linked to your own custom tables for date/time of change etc. Then schedule a batch job every day (or hour, or as required) to look through your scheduled changes and then call a bapi or idoc or function to update the customer with the stored addresses. This should be great from the user friendliness point of view and will allow any number of future changes of address for each customer, but will require some development effort (although not a huge amount as you will be using standard functions a lot).
Hope that helps.
Brad
‎2005 May 08 10:16 AM
Hi Debasish,
Workarounds, 2 spring to mind both with pros and cons:
1. Maintain the customer in another client (an exact copy of the customer), and then use ALE to time the change. This would allow you to store up to 1 time dependent change in the future. So, when you knew a change was coming you could change the customer in the other client, and then schedule the ALE job to process the idoc on the date that the change was due to take place. The pro of this work around is there is no development to do, the cons are that it means keeping your customer data in another client, and that you can only store one change into the future and its not so user friendly.
2. Build your own time dependent function for communication data. Build a dynpro which called the standard address handling screens and then store the data in the standard address tables linked to your own custom tables for date/time of change etc. Then schedule a batch job every day (or hour, or as required) to look through your scheduled changes and then call a bapi or idoc or function to update the customer with the stored addresses. This should be great from the user friendliness point of view and will allow any number of future changes of address for each customer, but will require some development effort (although not a huge amount as you will be using standard functions a lot).
Hope that helps.
Brad
‎2005 May 09 11:53 AM
Thanks Brad,
Guess the second options is a much viable option.
But i was wondering if we have some method using BDTs which might provide a more online solution rather than having a batch job run in the background?
Any thoughts?
‎2005 May 09 12:15 PM
Hi Debasish,
Forgive my ignorance, but whats a BDT?
In my explanation, I was suggesting you build an online solution (with lots of help from the standard function modules for maintaining address data). This online solution would let the user select a customer, create a changed address, and then specify the date/time of the change.
The background job would merely be for the application of changes. Thus, if you had scheduled a change for 11th of May, then the background job would run each night at say 00:10 am and then look for all scheduled changes. If it found one (by looking at your Z tables which record the date/time of the change), then it would select the address data and update the customer (using BAPI/IDoc/etc.).
I hope that is clearer now.
Brad
Message was edited by: Brad Williams
‎2005 May 09 1:29 PM
Hi Debasish,
I may have not understood the problem correctly, but there seems to be another link in the documentation which says something about this. Could you please check this one out ?
http://help.sap.com/saphelp_erp2004/helpdata/en/72/35209026b5204bab95ddf8ab01aad2/frameset.htm
Regards,
Anand Mandalika.
‎2005 May 09 1:35 PM
Nice spot Anand,
but its version 5.0...
Debasish is looking at the help on 4.7, so I guess he is on 4.7 (doesn't talk about it in this version).
Brad
‎2005 May 09 1:51 PM
Yes Brad. You're right.
But I have observed that most of us have a shortcut to the latest version of SAP Online Documentation on our desktops.
And we do not necessarily consult the help for the same version that we work on. So I was just wondering if Debasish is actually on 5.0 :-).
Regards,
Anand Mandalika.
‎2005 May 09 1:57 PM
Sorry guys,
Should have told you about the version earlier.
Its actually 4.7 that i'm working on.