Skip to main content

Time Registration

Status: Preview

Time registration is currently in preview on both sides. The Business Central objects described here ship in a preview build of the extension, and the API shape may change between releases. Not recommended for production-critical workflows yet.

This is the actual-hours route

This page covers time a resource actually worked and submitted. If you want the hours as scheduled, with nobody registering anything, that is the Time Sheets module. Both fill the same Business Central time sheetTime sheet (Business Central)The Business Central record that registers hours per employee. Dime.Scheduler can fill it from the plan (planned time) or from released time entries (time registration); running both for the same work registers the hours twice. table; see the overview for how to choose.

How time arrives​

Registered time reaches Business Central as a staged row plus an explicit process call, the same two-step pattern the appointment integration uses. Dime.Scheduler:

  1. POSTs the time entryTime entryA claim of a resource's time on one task for one calendar day. This is the record that is submitted to the back office, where it becomes a time sheet line. to the timeEntries API page, which stages it in the Dime DS Time Entry table.
  2. Reads the Location header from that response and POSTs to {location}/Microsoft.NAV.process, invoking the page's bound Process action.

The second call is where the work happens, and its HTTP response is the answer. If processing succeeds, Dime.Scheduler marks the resourceResourceAn entity that can carry out work - a person, vehicle, tool, or room - that you schedule on the planning board.'s entry as In back office (status Accepted in the API), where it waits for approval on the Business Central side. If it raises an error, the error text comes back in the OData error body, Dime.Scheduler marks the entry Failed, and shows that text to the resource verbatim.

This is worth internalizing before customizing anything: whatever your code raises is what the resource reads. An error like Time sheet for week 36 is already submitted is actionable. Nothing to process is not.

Staging rows are kept with their outcome: Status becomes Processed or Error, and Error Message holds the reason. That table is the first place to look when investigating a rejected entry, because it holds BC's side of the same story the resource sees.

The API page​

PropertyValue
PageDime DS Time Entry Api (2087649)
Publisher / group / versiondimeSoftware / dimeScheduler / v1.0
Entity settimeEntries
Source tableDime DS Time Entry

Which makes the endpoint:

https://api.businesscentral.dynamics.com/v2.0/{tenantId}/{environment}/api/dimeSoftware/dimeScheduler/v1.0/companies({companyId})/timeEntries

That URL is what goes into the connectorConnectorAn integration that links Dime.Scheduler to a back-office system, routing data in and scheduling decisions back out.'s Web service URI in Dime.Scheduler. See setting up time registration for the rest of the connector configuration.

tip

Check {environment} character by character. A wrong environment name returns an error that reads like an authorization or availability problem rather than a wrong address, and it is an easy way to lose an afternoon.

Fields​

FieldMeaning
entryIdThe Dime.Scheduler time entry identifier. Your handle back to the record that was submitted.
sourceApp, sourceTypeWhere the work came from. sourceType selects the routing codeunit.
databaseActionCreate, update or delete.
resourceNo, resourceNameThe resource whose time it is. Time sheets are keyed by resource number.
jobNo, taskNoThe work the time is against.
dateThe calendar day. Registered time is always day-grained.
durationSec, quantityHow much time.
descriptionThe resource's own note.
chargeableThe billable flag as the resource set it. BC remains free to apply its own rules.
status, errorMessageRead-only. Written by processing, not by the caller.

Deletes are not allowed through the page; a retraction arrives as a databaseAction instead.

Configuration in Business Central​

Two things must be set, and a missing either one produces a clear error rather than silence.

Enable the module. On the Dime.Scheduler SetupDS SetupThe connector’s setup page in the back office (DS Setup in NAV, DS Connector Setup in Business Central). It holds the same settings as the FastTrack wizard, plus actions to send data manually. page, switch on Resource - Enable Time Sheets. Processing refuses with Dime.Scheduler time sheet integration is disabled when it is off.

Register a routing codeunit per source type. On the Dime.Scheduler Source Type page, each source typeSource typeAn identifier that, together with the source app, tells Dime.Scheduler which back-office table a record belongs to. that carries time needs a Time Entry Codeunit No. The extension ships handlers for jobs, service and absence. Processing refuses with Dime.Scheduler time sheet routing for source type X is missing when a source type has none.

That second one is the most common setup mistake, because it is per source type: a tenant that registers time on both projects and service orders needs both rows configured, and getting one working does not mean the other is.

Extending it​

Two events wrap the routing, so you can add your own behavior without touching the shipped codeunits:

EventWhen
OnBeforeProcessDsTimeEntryBefore the module and routing checks. Validate or enrich the staged row.
OnAfterProcessDsTimeEntryAfter the routing codeunit has run.

To support a source type of your own, write a codeunit that takes the Dime DS Time Entry record and register it on the source type. Raise a descriptive Error for anything you reject: that text is the message the resource sees, and it is the only thing they have to act on.

See extend the extension for the general pattern.

Answering every submission​

The submitted entry waits in Dime.Scheduler until BC answers, and Dime.Scheduler will not invent an outcome on BC's behalf. A submission that is never answered leaves the resource's entry sitting in Submitting, which is truthful but of no use to them.

In the normal flow the Process action answers synchronously, so this is handled for you. It only becomes your concern if you extend the flow with something asynchronous, in which case you own the acknowledgement and should send it through the time API.