The FurtherDate web service is the negotiation and rescheduling engine within the Booking module. It is invoked by external systems (e.g., Middleware, Customer Portals) when a user needs to view alternative dates, modify an existing appointment, or book a new intervention after a previous one was closed or cancelled.
Upon successful execution, the service returns the Next-Gen FSM Platform Appointment ID along with an array of available time slots (including start/end date and time). The system automatically highlights and reserves the first time slot in the list in a TEMPORARY status.
Input Validation & Routing Logic
When the external system calls FurtherDate, the Booking module executes conditional logic based on the current status of the Work Order's appointment.
System Impact Note: During rescheduling, the system safely holds the customer's original confirmed slot until the new slot is officially confirmed, preventing accidental loss of bookings.
|
Current Appointment Status |
System Logic & Execution Behavior |
|
(e.g., User rejected the FirstDate proposal) |
|
|
(e.g., User wants to change a confirmed booking) |
Checks the Rescheduling Cut-off limit:
|
|
(e.g., Post-confirmation cancellation) |
Generates a new |
|
(e.g., Expired temporary session or direct CancelDate call) |
Aborts execution. Returns error: |
|
(e.g., Follow-up work required) |
Evaluates the request as a new intervention and generates a new date array. |
Pre-requisites & System Constraints
Before the system searches for slots, two strict operational constraints must be met. If either is violated, the service aborts and returns the error: "The required activity cannot be associated with any service".
-
Activity Configuration: The WO Type (
activityTypeCode) must be explicitly flagged as a booking-type activity in the master data. -
Territory Mapping: The WO Type must be successfully associated with a planning grid covering the user's assigned territory.
Time Horizon & Search Logic
The engine searches for new slots based on the temporal parameters passed in the input (searchStartDate, searchEndDate, and daysHorizon). The system applies strict mathematical boundaries to prevent booking violations:
-
Base Search Date Optimization
The search strictly begins from the searchStartDate input. However, if this date is before the date of the appointment already present on the Work Order, the system intelligently overrides the input and starts searching for slots subsequent to the existing appointment date.
-
The "Forced Time Frame" Calculation
The system calculates a hard limit called the Forced Time Frame, which equals System Date + daysHorizon. The system then compares the requested search boundaries against this forced limit:
-
If
searchEndDateis earlier than the Forced Time Frame: The system searches for slots normally up to thesearchEndDate. -
If
searchEndDateexceeds the Forced Time Frame: The system automatically truncates the search, stopping exactly at the Forced Time Frame limit. -
If
searchStartDateis strictly greater than the Forced Time Frame: The system rejects the request completely, returning the error:"An appointment cannot be scheduled due to its high distance from today's date".