Timesheet Posting and Adjustment Workflow in DATABASICS
Initial Posting:
When a timesheet is posted, it is flagged as Posted in the system and assigned a unique Batch ID or Document Number for tracking purposes.
Example:
Project ABC: 20 hours (Posted in Batch #12345)
Handling Changes:
If a user modifies a previously posted timesheet (e.g., changes the project or updates the hours), the system:
Creates a new Adjustment Document linked to the original posting.
Calculates the difference (delta) between the original record and the updated entry.
Adjustment Posting:
In the next extract posting, the system ensures that adjustments are accurately reflected:
The original record is reversed to negate its effect.
The updated record is posted with the new details.
Example:
Original Post: Project ABC – 20 hours (Batch #12345)
User Change: Updates Project ABC from 20 hours to Project XYZ with 40 hours.
Adjustment Posting:
Project ABC: -20 hours (Reversal)
Project XYZ: 40 hours (New entry)
This workflow ensures that all changes are tracked and posted accurately, providing a clear audit trail for every adjustment made to a timesheet.
In scenarios where customers receive unposted timesheet data (e.g., timesheets that are not fully approved), it becomes the customer’s responsibility to manage the potential dirty data they receive from DATABASICS.
This includes handling discrepancies between:
Unposted Data:
Timesheets that are still under review or awaiting full approval.
These records may change before they are included in an official posting batch.
Posted Batch Data:
Timesheets that have been fully approved, finalized, and posted as part of an official batch with a Batch ID or Document Number.
Customer Responsibility:
Customers must ensure that they properly segregate and manage unposted data from posted data in their systems.
Any reporting or processing of unposted data should account for its temporary and potentially mutable nature, as it may differ from the final data included in a posted batch.
This approach ensures that customers have the flexibility to review unposted data while maintaining accountability for how they use it in reporting or integration workflows.