Saturday, 25 November 2006

Order stock allocation mechanism

Dynamics Ax could really benefit from the introduction of some basic SCM functionality that allows orders to be treated as a unit and to be allocated as such.

I have many clients in the wholesale business who desire the ability to work with complete orders, typically mail order catalogue businesses are an example, but really any business that delivers multiple parts in an order will desire this possibility if nothing else.

Today in Ax it is possible at line level on the order to denote that the line is either to be delivered in total or not at all.

Most of the big ERP systems on the market today have the above mechanisms built in, not all perform well ;-), from the echos I get.

Having built three times several variants on the algorithm of de-allocate everything (bar specials) then allocate in time windows with matching to future purchases the items, and flag all the orders with new dates if applicable, I think it is about time that Ax has one built in as a standard.

We already have a field with a type of order and it would be nice to expand this field with some attributes that govern what is done by the order matching process, as well as denoting how the orders are treated. We can choose to use either the Sales Pool, or the Sales Origin, or create our own categorisation. As the two flags / tables in question today are not overly used any action will do.

Then build a process which based on certain categories of orders can re-do the inventory reservations, also against future orders where of course we are not really speaking of reserving but rather allocating.

The above would definitely benefit from doing a reservation as discussed in another of my blogs, that is one that is not fully developped.

The alogorithms for doing the allocation are basically largest orders first, in time slots (f'ex weeks), priority of orders (notion of red flag orders), priority of customers. After the process a certain number are passed in "good to go" status and these are then the orders which are the pool to process the next day.

Most of the time a secondary lot is also designated where more than XX% of the order in value or qty is deliverable, and these can be delivered based on a manual decision the following day.

Some additional functions to pick the orders to allocate are added in to the mix above with some criteria allowing people to colour code or segment the orders, could be to create truck loads / containers by region etc etc.

But that again in and of itself is part of a larger question which it would also be nice to see added to the product, a proper shipping solution.

Of course Circon have a solution but it is very much transport oriented and it does not interfere through the whole cycle. I have built for some customers variants on the Masterplanning where the master planning did the load planning as well, that is organised in container loads the shipments to be done.


/Sven

2 comments:

Anonymous said...

Hello,
There is a bit of reallocating when using the WMS II module (V3+V4), that you may or may not have seen.
At reservation time on a Shipment the system undoes reservations and "redoes" them according to the WMS rules that are set up.
From here it was pretty easy to add an Expiry-date control into the select statement to introduce perishable goods (FEFO) management.
I totally agree with you that there should be the same thing triggered by item arrivals (or simple non-WMS goods receipts).
Cheers
Nick

Sven Jochimsen said...

Yes and the WMS module code can easily be "stolen" or lifted out to be more generally used. It f.ex. requires the use of Pallets which is not active everywhere etc.

However the main problem remains I do not want to pick a batch or serial number when I reserve, and the above fails if I rob peter to pay paul in a fully reserved stock situation.

I go to the warehouse and want to deliver an item with serial number I pick the "wrong" one and now I have to unreserve the order taking this one put it on my number and reserve mine with this one basically very complicated coding as opposed to having reservation functionality at a higher level.

/Sven