Breaking news from around the world
Get the Bing + MSN extension
Now Available in Community - MBAS 2019 Presentation Videos
Catch the most popular sessions on demand and learn how Dynamics 365, Power BI, Power Apps, Power Automate, and Excel are powering major transformations around the globe. | View Gallery
2019 release wave 2 Discover the latest updates and new features to Dynamics 365 planned through March 2020
Release overview guides and videos Release Plan | View virtual launch event
Ace your Dynamics 365 deployment with packaged services delivered by expert consultants. | Explore service offerings
Connect with the ISV success team on the latest roadmap, developer tool for AppSource certification, and ISV community engagements | ISV self-service portal
The FastTrack program is designed to help you accelerate your Dynamics 365 deployment with confidence.
FastTrack Program | Finance TechTalks | Customer Engagement TechTalks | Talent TechTalks | Upcoming TechTalks
Has anyone come up with a simple way of completing a booking retrospectively so that Booking Journals would be created for manually entered times?
So, I have a Booking that was scheduled for yesterday morning but the Engineer (for whatever reason) has not completed the booking. I would like to update the Booking Manually entering the Start, Arrival and Completion Times then Changing the Status to Complete and have Journals created for the times entered.
Currently as soon as you set to the Status Complete the End Time Defaults to Current Date and Time and if the Booking was already in progress then the Duration is also calculated from Start until now.
You can give the user the ability to create Booking Timestamps manually? You can specifiy the timestamp time.
Hi Thomas - I have given that a go, creating a Manual Timestamp record of 'Complete' for a Booking that was Travelling but hat didn't update the Booking record - Status or End Time
Any other ideas?
You might have to run a workflow off a manual creation of a timestamp to change the Booking Status and End Time?
I have had to create a Workflow that on Completion of the Booking, creates a Timestamp to get the End Time, (the system then sets the end time as now()) then update the end time back to the time entered by the user and manually calculate what the Labour charge should be.
Convoluted way of performing an action that must happen regularly for any business with Field Engineers but at least it works :)
Hi John, I just wondered how you have got on with this workflow - has it solved your issue? We are experiencing the same thing. Our users will often need to retrospectively complete a booking, but we want the time/duration to remain as the time/duration entered by the user.
Hi Melissa - I did manage to sort this out. I created an option set for the Workflow to run off and then in the workflow the steps are
Create a Completion Timestamp Record using the manually entered values for the End Time
Update the Booking Status (this will update the End Time to now() )
Reset the End Time from the Timestamp created within the Workflow
Create a Journal (if you need to ) based on the new Start Time/End Time
Hope that helps
Thanks John - will give it a try!
Sounds good, however the solution would not completely replace/restore standard system behavior when it comes to the creation of the Booking Journal record.
I think it is hard to emulate the standard behavior for the creation of a Booking Journal record when it comes to the decision about which Pay Type should be used for the Booking Journal record.
Usually the system checks the Resource's Work Hours calendar, whether the Resource was working outside of his regular availability (Overtime) or during Business Closure times... and it even splits work time spans into two (or more) Booking Journal entries if there is a period ending/beginning during the work time span. Maybe one could rebuild that mechanism by using Flow but is looks really tricky to me to query the calendar Work Hours. Maybe it would be better to engage a Pro Dev for this to become a solution closer to 100%.
If Pay Types doesn't matter to you than it sounds like a doable way.
Maybe you can tell us if your solution has been accepted by the end users and has withstood the test of time.
Business Applications communities