Auto-allocate received stock to non-intersite sales orders first

SUGGESTED

Hello,

We are wondering if, when stock is received and automatically allocated, to allocate it to NON-intersite flagged orders first, even if they are older than the regular orders.

The scenario:

I am transferring stock physically and digitally from one stock site (retail store) to another (warehouse) in order to fill a customer order which needs to be picked from the warehouse stock site. However, if an intersite sales order (we call it a restock) is present for that retail store stock site for that item where the order is older than the customer order, upon receiving the transfer into the warehouse stock, it will automatically allocate onto the retail store restock order and not the customer order, because the retail restock order is older. We are wondering if it is possible to give allocation priority to non-intersite sales orders (ie. regular customer orders) when automatic allocation happens upon the point of receipt.

The intersite sales orders are marked with the field BETFCY in the SOH screen, where a check mark has a value of two and unchecked has a value of one.

  or 

We want sales orders without the check mark to allocate first even if they are newer than orders with the checkmark. Is this possible?

Thank you,

Zoey

Parents
  • 0
    SUGGESTED

    Hi Zoey,

    Personally, I don't like the auto processing of shortages unless absolutely necessary. If you use the automatic allocations function and automate on the batch server then there is an option to add criteria, you could then run it first for non intersite then run a separate task to allocate the intersite. Depending on timings you could run the first task every 5 minutes and the intersite allocations less frequently taking care to ensure they don't run at the same time.

    This method also allows for other considerations in the filtering.

    Cheers

    Steve

  • 0 in reply to Steve Higgins

    Thanks for your reply! Unfortunately, we run a very tight picking schedule (print pick tickets every 10-15 minutes from 10AM-5PM, Monday to Friday), and auto allocation function (FUNAUTALL) takes 45 minutes to process just for our warehouse sales site where we do the picking. Since we are constantly receiving and putting stock away for picking throughout the entire day (8AM-4:30PM, Monday to Friday) we need the stock to automatically allocate as soon as the stock becomes available (A status) so it can get picked and shipped the same day. We process about 5000-10000 pick ticket lines per month, so unfortunately the FUNAUTALL function running in batch process is not fast enough for this use case. (It also slows down the system considerably). I really wish it could take 5 minutes but unfortunately it takes much much longer :( do you know any reason why FUNAUTALL takes so long?

Reply
  • 0 in reply to Steve Higgins

    Thanks for your reply! Unfortunately, we run a very tight picking schedule (print pick tickets every 10-15 minutes from 10AM-5PM, Monday to Friday), and auto allocation function (FUNAUTALL) takes 45 minutes to process just for our warehouse sales site where we do the picking. Since we are constantly receiving and putting stock away for picking throughout the entire day (8AM-4:30PM, Monday to Friday) we need the stock to automatically allocate as soon as the stock becomes available (A status) so it can get picked and shipped the same day. We process about 5000-10000 pick ticket lines per month, so unfortunately the FUNAUTALL function running in batch process is not fast enough for this use case. (It also slows down the system considerably). I really wish it could take 5 minutes but unfortunately it takes much much longer :( do you know any reason why FUNAUTALL takes so long?

Children
  • 0 in reply to Zoey Mattison

    Hi Zoey,

    It shouldn't be taking anywhwere near this long for your volumes - I'd suggest you log a case with your Sage partner as this shouldn't be the case.  You could run the various stock resyncs as a first pass but it does sound like a support case.  The one thing I can absolutely say is that it should be much faster and shouldn't be an issue to manage your required timings.

    Cheers

    Steve