If you have worked with the Service Management area of NAV/BC then you will have greater insight into the upcoming words and images I’ve thrown together. Within BC service you can log a service contract and assign items to be serviced on a routine basis
Image here shows some key fields which drive that functionality – “Service Period” is a date formula field showing how often we expect a planned service (here it is 1M to indicate once a month). “Next Planned Service Date” and “Contract Expiration Date” then act as the Start and End to the planned services. It is possible to not set an expiration date. For the “Calendar” idea I am about to layout you need that data in place – or you adapt the code/BC data to use defined planning horizon (end date).
All seems fine here I’m sure, but the mild inconvenience behind this post is that only 1 “planned” service order can exist at a time. BC uses the below processing only report – “Create Contract Service Orders” – to create the “planned” service orders. There is another two fields used within this routine called “Last Planned Service Date” and “Last Service Date”. These act as the control to ensure you have just the “required” service order generated by the routine.
*note that this routine does check the service management setup to see how far in the future in can create service orders for.
I’m not bringing this up because I have an issue with standard. Having recently discussed this with prospective users of BC, they want to use a calendar view to aid with resource planning. BC can handle resource allocations when the service order exists only. So what do you do in this case? One possible option is to look at a reporting based solution and just let BC get on with how it automatically creates the required service orders as and when – will certainly stop getting loads of clutter in the tables which hold the data.
The part of BC that has a vague similarity to what I want is Deferral Schedules. Confused? Let me show this:
Before a deferral is posted you can preview what it will produce. In the case of the example it is for 6 months and it was produced data for that – but only in this view. This is in effect what I think would be useful with service contracts so you can plan from that. I’m opting to produce something in Power BI on this occasion so I can display data in a matrix visual. This means a page (api or regular as a web service) is required. For this I’ve taken some inspiration from how the standard BC API handles Sales Order Lines. The table the API is based on is a temporary table and it isn’t even the Sales Order one:For me the page isn’t that straight forward in how it eventually gets populated but it does it with the assistance of a codeunit in the OnFindRecord trigger of the page. For my page I have adopted a similar approach – but kept it simple. A link to the code is at the end of the post.This is the kind of view I was able to generate because I have my API page producing data for future dates based on the “Service Period” defined per service contract line. Note that BC allows for service items to appear on multiple service contracts. So where I have a count of 2 (yellow dots) the service item is scheduled for two different services that month. It’s something standard BC just can’t generate right now and it gives so much more information to a user. I’m sure there are some other use cases for this concept – interested to see what others come up with. You could produce a matrix page in BC with the concept too
33,159
Like
Share
Report
Let me show this:
*This post is locked for comments