Relationships before row counts
Three client records and three project records define the parent keys. Six incoming time entries must pass the same identity, relationship and numeric rules before a batch can be committed.
Incoming rows6
Ready / held2 / 4
Accepted value · USD320.00
Committed rows0
A small model with explicit keys
ClientPK client_iddisplay_nameC10 / C20 / C30
ProjectPK project_idFK client_id → Clienthourly_rate_cents
Time entryUNIQUE external_idFK project_id → Projecthours_hundredths
Client → Project → Time entry. A missing project cannot become a valid reference merely because its text appears in an imported cell.
| Project | Client key | Rate USD/h |
|---|---|---|
| P10 · Portal | C10 | 80.00 |
| P11 · Catalogue | C10 | 100.00 |
| P20 · Scheduling | C20 | 90.00 |
What the acceptance review checks
IdentityOne external ID per entry
RelationshipKnown project and client
PrecisionPositive hours, max 2 decimals
BoundaryProject belongs to selected client
CommitCurrent preview + owner approval
ImportBatch, validation decisions and an audit event retain the revision, held-row reasons and committed row identifiers.
Staged entries · input set DB06
Input revision 1| Row | External ID | Project | Hours | USD value | Validation decision |
|---|
Repair an incoming row
A correction changes the input revision and clears any earlier commit preview. R03 repeats T101; try T103 to make that row eligible.
Commit the reviewed subset
Create a preview from Import review before committing.
| Batch | Revision | Rows | USD | State |
|---|
Parent deletion check
Try deleting P10 after committing its time entry. The relationship check keeps a referenced parent in place. Reverse the batch to remove its dependent entries, then try again.
Decision log
No mutations recorded.