- Ya
- 27 Agosti 2026, 16:26 UTC
- Mwandishi
- Kamo
- Ahadi ya
- 253295a
The one verb the service-job surface was missing. Until now the only thing on the platform that could produce a ServiceJob row was **************** off a paid order — which is why every service-work table holds zero rows. CreateJobInput carries no column the server owns: no status, no jobNumber, no totals, no signedOff/signoffAt. SW6b took exactly those five off JobInput after finding PUT /{uid} accepted them verbatim; a create path that took them would be the same door with a different name on it. sourceCommitment stays null, deliberately. processOrderPaid opens with `if (order.getCommitment() != null) return;`, so a commitment invented here to fill a nullable column would disable the whole paid-order downstream if this job later joined an order. One ServiceVisit, sequenceNo 1, SCHEDULED, no calendar event and no assignee — the same four facts createFromCommitment writes, so a job looks the same however it was raised. The market and the customer are resolved WITH the org predicate in the query (findByIdAndOrganizationId / findByUidAndOrganization), the pair SW4 used on QuoteService.create. The market cannot be stored — there is no market column on ServiceJob and none on Engagement — so its one durable effect is the engagement type, through **************** exactly as a quote's is.