on 06-30-2010 9:15 AM
Hello Experts
We are currently creating TOs for multiple deliveries and are facing user locking issue.
I would like your expert guidance on the use of option 3 - Delayed update at each confirmation of a TO item found in Shipping control per Warehouse.
I have the following question :
1. Is using this option the solution for locking issue that we are facing when confirming TOs for multiple deliveries?
2. Is the delayed update of the delivery done automatically by the system?
2. How much time after which the system tries to update the delivery?
3. In case of failure to update the delivery at the first instance, how many more times will the system try to update the delivery?
4. Are there any other configuration changes that we need to do, other than choosing option 3 - Delayed update at each confirmation of a TO item, for this solution to work?
5. Are there any complication that may arise due to using of this functionality?
6. Any other information that you feel will help us in using this option.
Thank you in advance for your advice.
Regards
C. A. Pillai
>
> Hello Experts
>
> We are currently creating TOs for multiple deliveries and are facing user locking issue.
>
> I would like your expert guidance on the use of option 3 - Delayed update at each confirmation of a TO item found in Shipping control per Warehouse.
>
> I have the following question :
> 1. Is using this option the solution for locking issue that we are facing when confirming TOs for multiple deliveries?
> 2. Is the delayed update of the delivery done automatically by the system?
> 2. How much time after which the system tries to update the delivery?
> 3. In case of failure to update the delivery at the first instance, how many more times will the system try to update the delivery?
> 4. Are there any other configuration changes that we need to do, other than choosing option 3 - Delayed update at each confirmation of a TO item, for this solution to work?
> 5. Are there any complication that may arise due to using of this functionality?
> 6. Any other information that you feel will help us in using this option.
>
> Thank you in advance for your advice.
>
> Regards
> C. A. Pillai
1. mostly yes, you may still see locking issues but the updates will happen when the locking issue is removed and LX47 runs again
2. this should be run via scheduled batch job
2B. changes/updates to the delivery will trigger an update that will be attempted when the job is run
3. a delivery that will not update will get stuck in LX47 and remain there (batch job running LX47 will continue to attempt updates until it is sucseful)
4. I am sure there are but without knowing your system I can't say what exactly
5. YES, when deliveries get stuck they often require manual changes to update. There are around 7 reason (at our warehouse) for a delivery to get stuck in the update tables.
for example: if a delivery level carton is packed to a shipment level pallet before the transfer order(s) associated with the carton are 100% complete the delivery will get stuck (requires unpacking the cartons and manual trigger LX47 to clear/repack)
(Co09) item availablity will cause all updates for deliveries with that item to fail if you are over promised on an item.
I am sure your challanges will be unique and choosing that option may require some small procedure changes to make it work (to fix any timing issues you might find)
In my opinion it works fine but you should be aware some one will need to check it periodicaly to make sure delvieries aren't getting stuck and clear as needed.
Hope that helps
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hello again,
Sorry but when I need to schedule a job I coordinate with our batch job scheduling team and I do not have access or knowledge of the transactions they use.
Note* we did create a custom transaction to help detail the reasons for locked deliveries in LX47
(Z delayed delivery analysis tool)
Some thing you may want to consider as well.
best of luck with your project
Perhaps another user on this site can help from here?
Hey...
I haven't used option 2 but if Sap recommends 3 then you could go for it.
I generally interface with Jco and have my code called from the Java end and then use threads to allow for delays using the sleep concept of threads for multiple deliveries so as to go give time to SAP to update.
Thanks,
Arup
User | Count |
---|---|
85 | |
7 | |
6 | |
4 | |
3 | |
3 | |
3 | |
3 | |
3 | |
2 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.