Skip to main content

General

In the 'Dime.Scheduler Setup' page, two features are available that the FastTrack wizard doesn't expose:

  • Check appointments on delete
  • Notify appointment errors
tip

You can find the wizard by looking for Dime.Scheduler Setup in the search bar.

Connector Setup

Check appointments on delete​

One of the most common errors is when people remove orders from Business Central that have a planning in Dime.Scheduler. Here's a typical message that's shown in Business Central when a user deletes an order from Dime.Scheduler:

The specified job JOB12345 cannot be deleted because it is associated with existing appointments. Please remove the appointments first, or retry this command with CheckAppointments set to 0.

The error message already suggests the solution. In the endpoint of Dime.Scheduler's API on both the job and task level, you can specify whether to check if it is safe to remove the job and not lose any additional planning data in the process using the CheckAppointments flag:

  • When set to true, the above message will be thrown and the job won't be removed from Dime.Scheduler.
  • When it is switched off, it will remove the job, as well as all underlying tasks and planned appointments.

The global Check appointments on delete setting is read by the extension for Dime.Scheduler in BC and passed along with every request to remove tasks and jobs. It is a global setting, but it can easily be overridden with custom extensions on top of Dime.Scheduler's extension in Business Central.

Notify appointment errors​

Dime.Scheduler keeps a trail of all the interactions it initiates with the connected backoffice systems like Business Central, Exchange, and webhook connections. The audit trail is available inside Dime.Scheduler itself.

When Dime.Scheduler successfully posts the data into the connected system, it marks that transaction as successful. In Business Central, a successful transaction means that all data is written in the Dime.Scheduler Appointments table. This is the staging table that Dime.Scheduler writes to, and through a routing table (the Dime.Scheduler Source Types list), a code unit gets invoked when a new item is added to the list (this can be an insert, update, or removal of an appointment in Dime.Scheduler), and processes the new planning information provided by Dime.Scheduler.

However, even though the item is available in the staging table, doesn't necessarily mean that the connected system has successfully processed the appointment itself. There are many reasons why that might be. For example, in the image below, the assigned resource is missing a 'Unit of Measure':

DS Appointments

As a result, the status of this appointment in BC is Error. Planners may wonder why the appointment isn't showing up in the desired tables. The staging table is available for diagnostics, but it may be more user-friendly to enable the 'Notify appointment errors' switch in the Dime.Scheduler setup.

When this flag is set to true, any errors produced in BC will be sent back to Dime.Scheduler as a 'Notification':

DS Appointments

So even when Dime.Scheduler considers the item to be sent successfully to Business Central, the appointment may not have processed exactly right in the backoffice system. This may be confusing to some, which is why it might be a good choice to turn on this switch.

To summarize, here is how the transaction system is designed in Dime.Scheduler in tandem with Business Central: