Reservation engine: Competitors advantage or unmanageable beast? 

In my previous post I have mentioned sweat and sleepless nights. There was hidden element in Go lives with NAV/BC which always multiplied the complexity of the project and not always been working out of the Microsoft box in great shape: Reservation engine. 

In my 11 years of experience with NAV/BC I heard many times my consultant colleagues saying: “I do not recommend using reservations module” “Handle these requests manually off system” “Lets change reservation engine” It was always meant in a way to avoid using this part of the system. I think reason why these people saying it is due to lack of understanding of Reservation engine and the experience of those who have tried (we all are choosing easy paths when we can right? or not?) I do always the opposite as others! 

I have implemented Reservation Engine nearly in every implementation I did. If you do it well, you are giving the customer competitors advantage. The end user process can be that slick and automated that majority of my customers where I implemented Reservation Engine they love the system, they do not realise that it’s all sticks together through something called: Reservation Entries. 

Why the experience who tried went wrong? I think the breaking change in 2015 Assembly-to-order functionality which pushed NAV/BC level above allowing kitting process (MS humbly thank you for it very much) It has brought to the system enormous amounts of bugs, that it was not enjoyable for us who deliver NAV/BC solutions to implement them around that time (2015-2020). I’m sure Microsoft are aware, and we have not seen such a big influx of issues again thanks to automated test process which didn’t really exist 8-10 years ago. I remember picks with negative quantities on the take line, hundreds of shipments stuck in posting routine due to standard bugs (I said already I heard people screaming and shouting right) Could you imagine not just my sweat, but the end user sweat too! That’s where a lot of negative emotions from the implementations been brought (described in previous blog post). Could I do more to change it? Hardly. Can I do anything about it now? Read below. 

Through my career I have helped Microsoft to patch about 10 different scenarios in various NAV/BC versions where my customer had hit bug related to Reservation Engine (Often causing non-native speaking lorries drivers to shout at NAV/BC users! We are all innocent nobody’s fault, right???). Very often this was linked to scenarios which I guess are not mainstream, but when you use Lot Numbers or Serial Numbers why would the system have so many bugs? I think the reason is the design structure of Reservation entry table/engine where all related records are saved in one table 337 (each experienced consultant will know the number even if you wake them up or ask after a night out!) Guess why - we need batch report/cu to delete or amend data from there. We are literally mixing apples and bananas in one basket. Why would you save information in one table about MRP thought process – read “Tracking” Entries with “Surplus” Lot Number record entry on Item Journal (one off record which exist only before you Post in average for 30 seconds?) I don’t think there is anybody on this planet, who would fully understand all logic behind everything in Reservation Engine. I do a bit, more than average (I would like to think!) Reservation engine has grown throughout the time to size where now it’s too big to be reground. I’m sure there is backlog entry on Microsoft Internal DevOps to completely reground the engine by new modern design, but this, as we all know, is not going to be simple and quick task. 

Where are we nowadays? Goods news, I feel we are over with the times where you should be saying “don’t go reservations” and thanks to SaaS Systems we don’t need to worry about going through ‘Release Notes’ and try to match your customers scenario with very vague description of the Microsofts bugfix (I went so many times though 50 different CUs release notes to try to match what customer is facing) Quite often I have been successful and we applied or merged required patches. I have seen recently post from a Microsoft senior saying, “how we can make the service better for you partners” I think this is what we BC CSP partners would really appreciate. When you vaguely describe bugs, give us please test scripts in human readable language, let we non developers can translate it very quickly to the customer why we need to get them on latest version (oh I forgotten we don’t need to do it anymore; we are now on platform which does it for us; but don’t forget there are still customer on premise, and there will be for a while at least). 

Where I think Microsoft could do more (and again I think it’s on backlog already) is bulk reservation of the whole Sales document. What is the average document size nowadays? I’d think 10 Sales Order lines (well Cronus surely will be 2-3). 

From software design perspective, your foundation must be “Keep it simple” “Do not overcomplicate around exceptions” But how would you describe an exception? Well get 10 people to big wooden board and you will see that we have 8 different opinions what exception is.  

Very often you get to complexities which prevents simple generic solution. Unless you decide for customer what the assumption is (which you need to do anyway; you will hear from consultants “you need to decide yourself”; very often, in ideal paradise planet, nowadays you asked to give customer solution before they asked for the options) 

We at MB365 raise the bar higher than other partners. We think following scenarios is what Microsoft should consider as a very frequent user story: 

Do I as an end user really have to click Function > Reserve for every line of the document? (I know customers where 50+ lines is their core business): 

When you show standard Microsoft Functions>Reserve process to customer nowadays, first question is: “Really? Can we have Header > Reserve from Stock for all lines?”. Yes, we have an app for this at MB365!

Key ‘MB365 Stock Allocation’ functionality: 

1) Sales document bulk reservation (we call this process Allocation): 

The fuctionality creates non-lot/sn specific reservation (Binding None; I will elaborate on separate blog post what Binding field on reservation entry does and how it can be used to leverage customers processes). 

We use latest technologies which Microsoft allow us to use. Emojis, embedded JavaScript etc let us do what you think is worthy value. 

2) Total Available quantity added on document lines (including intercompany sparing location availability) 

Where do I see what is available on the Item or Sales Order line? I have heard this from users so many times. Reservation engine provide the answer you need, but you need to drill it down to see ‘Total Available Quantity’. This means non reserved elsewhere and available. 

As a part of allocation app this field is available on all Sales Line subforms (Quote, Sales Order, Blanket Order) to provide end user required efficiency. 

On top of that, if you use multi company environments, you will typically hold stock only in some of them, so you need to see this value in other company. It’s part of the Mb365 out of the box solution (Total Sparing Location Availability). 

3) Assembly Component allocation:  

Do you use Assembly to Order Items? It’s no longer than Sales order lines you need to reserve, but all Assembly components. Microsoft out of the box functionality here is poor as it will pick only half of the Assembly BOM if other components are not on stock (Can you ship a bicycle without wheels in real life?) I guess we all been delivered partials at least once, so this literally could have been the case! We at MB365 have this covered too.  

When Sales Order is Allocated, ATO items are looped through ATO Components and Component accordingly reserved: 

We made design assumption that we reserve everything if you have everything, and nothing if one or more of components is missing. The other app we have for warehouse, then allows you to configure only fully reserved ATO components to be picked. I will share more details about our warehouse enhancements in future. 

4) Allocate as recurring process on Job Queue 

To ease manual process of allocation after system activities like customer order cancellation, new stock booked in, you can set how often to allocate on the Job Queue Entry. We made design assumption that the documents with oldest Shipment Dates are the most important ones. Design is extensible to cater for any potential requirements. 

5) Assembly to Stock automation 

Should it have been assembled on stock but it hasn’t for any reason? Do you need to create Assembly Orders Assembly to Stock as an output of an allocation? If you partially have stock, for Assembly to Stock Items, our Allocation function will make partial reservation from stock and calculate what to assemble and create Assembly to stock Assembly order.

6) Auto allocate as part of the Release Process 

When I mentioned slickness for the end user, in the end of the day, he can just Release sales order, and all above will happen automatically. Quite cool right? 

How much does it cost? We are new startup company, currently we are not close to be able to release the apps on the BC Extension marketplace, but MB365 can ship you an app as PTE “tomorrow”. The app cost £1.500 excl. VAT (UK VAT companies applied only). Ask us for more information. If you would need to expand on what we already have to cater for your specific business requirement, our development team can deliver. Get in touch on Slack Publick channel to get 10% off. I’d recommend having a quick chat first, but I'm sure this app can save you loads of the money. Potentially replace already existing solution to cater with the reservation engine. 

We at MB365 think it should be a standard functionality and mindset of people who implement these systems (although you will probably find that most people at traditional partners still in 2023 saying “do not go reservation way” I’m here to help educate and learn together with everybody. You would be surprised how many failed implementation and ruined systems I have seen! I think there is nothing unique on your knowledge if you don't share it. Once you shared, you can explore more for everybody and let's push the bar further for the end user benefit.  

Do you like the content? Please add a feedback on the linkedin.

Previous
Previous

Continuation of Confession from 20 NAV/BC Implementations. Part 2

Next
Next

Confession of an experienced consultant from 20 NAV/BC implementations