Sales Order Events and Sales Order Hold

Sales order events and sales order hold

There are two interesting functionalities in R3 that have flown in under the radar because they are officially part of Retail and the Call Center functionality. This certainly should not stop us from using them for manufacturing companies. Let’s first check the license configuration.

The two features discussed in this paper do not have their own license key, they are part of the “feature set”, so make sure the Retail – Full feature set is checked. The rest of retail features, including the call center, can be switched off without losing Order events and Order holds.

1.     Sales Order events

In an ERP system, few transactions are as scrutinized as sales orders, which makes the requirement of a sales order change history rather unsurprising. Throughout the past years we heard this requirement regularly and we could only answer “use database logging”. But we all know that the access to the data in database logging is not exactly user friendly. More importantly, we were always cautious to show much enthusiasm for database logging, mindful of the serious warnings we received from our developers that the server “could be brought to its knees” if we use database logging too abundantly.

Now our R3 release brought a beautiful new feature that allows a set up of sales order logging parameters per user.

This certainly sounds like a winner by reading the description alone. Is it indeed a winner? We think yes.

Sales and Marketing/setup/Order events/Order event set up

This interesting screen allows the familiar feature “Table/Group/All” with regards to the user. Is the event parameter set up for one user, for a user group or for all users? Once we know WHO should be tracking order events, we have a most sophisticated set of checkboxes to our disposal that we can check for order event tracking.

Below we see the closed fast tabs.

NOTE: Start and end dates don’t hurt, yet I don’t see anybody ever putting an end date on tracking sales order events.

Sales order, sales line, Returns and Sales quotation checkboxes speak for themselves.

Rather intriguing are the boxes for Direct Delivery and Automatic Notification:

Direct Delivery

• Create order – this is the created Purchase order, one would think, but I could not see this one being recorded as an event.
• Delivery order – this should mean the receiving of that DD Purchase order and it is indeed. It also results in a “modify sales order” event because the sales order line is shipped automatically after receiving the DD Purchase order.
• Somewhat unexpectedly, this shows up as an event after we confirm the direct delivery PO.
• Cancel order – this is the event of the cancellation of the DD purchase order

Automatic notification and cancellation

• Exempt: this is a surprising reverse checkbox. This relates to RETAIL functionality regarding automatic notifications. Call center parameters shows the following:

https://technet.microsoft.com/en-us/library/dn497861.aspx

For manufacturing companies, this seems irrelevant functionality to me.

INQUIRY OF THE ORDER EVENTS

One can click the icon ‘order events’ in the action bar of an individual sales order but there is also a general inquiry in Sales and Marketing/Inquiry/Order status/Order eventsOnce on a sales order, clicking the “Sales inquiry” gives access to a special summary screen that allows the user to see the details of a sales order.

2.     Sales order Holds

This functionality is in addition to credit hold functionality. This functionality has nothing to do with credit hold.

There was always a requirement for a different type of hold then the credit hold. Especially in the Make-to-Order and certainly in the Engineer-to-Order business, the sales order hold is very common. With this functionality we can put a sales order on hold for any reason and we do it manually. In MTO, the most common hold may be “engineering hold”.

It is interesting to note that the use of sales configurators is supposed to avoid these “engineering holds”.

Often a sales order is on hold right at the start while more information is being gathered from the customer and discussed. In ETO environments, a long back and forth can go on between the company and its customer. During this time that sales order should be on hold.

Sales and Marketing/Common/order holds

As opposed to the Order events, the Order holds have a menu choice in Sales and Marketing/Common.

A list of features:

1. Hold codes are user-defined and can get a color
2. On Hold orders can be “checked out” to a user, similar to checking out a document in Share -point, indicating a user is working on solving the problem of the hold.
3. Checked out orders can be “stolen” by other users by using the check out override (Share -point does not have that!)
4. Hold functionality has date/time stamping for every change in the hold status.
5. Days on hold is showing
6. A handy menu choice “ Holds” and “Order” is available Sales and marketing/Setup/Sales orders/Hold codes

Remarkable is that one can associate a hold code with a certain role, which ties into security.

• Only certain people should be allowed to put sales orders on hold and more importantly, take them off hold.
• One can declare a hold code to be a default (not so interesting)
• One can remove reservations. This is okay of course and it certainly depends on the type of hold, which is exactly what the system allows you to do.

On our wish list: Sales order Hold on lines / Sales order Hold and Production orders

After having voiced our general enthusiasm for this new feature, are there some criticisms? Yes there are.

1. The hold functionality is for the entire sales order. We would like to have it for the lines. For the lines we always had the checkbox ‘stopped’ that would prevent picking and packing. We would think this new hold functionality should somehow link to this checkbox.
2. What we are still missing is a sales order hold that trickles upstream to production and purchasing. We have heard this requirement at every manufacturing customer (MTO, ETO)

• In MTO environments, for new sales order lines that are on hold, MRP should not generate a planned order and if it would, it should not allow firming of it
• For existing sales order lines that already have a production order, the sales order line hold should cause the production order to go on hold (with proper communication mechanism to the floor). This “production hold” should also be visible in Manufacturing Execution screens. (Edit Jobs list, Registration screen). Honestly, we need a production order “on hold” functionality in general, not just one that is triggered by sales.

Conclusion

The functionalities of “Order Events” and “Order holds” seem pretty solid and work “as designed”. They are very useful functionalities for MTO/ETO manufacturing companies, although we are missing a production order hold. This is even more urgent given the fact that “Cases” cannot be used for Production orders, so we are facing a guaranteed customization in that area.