- Shipped
- 8 noiembrie 2026 la 08:35 UTC
- Author
- Kamo
- Commit
- d100d86
Numerele comenzilor de lucru erau COUNT(jobs)+1, deci două locuri de muncă ridicate simultan puteau împărți unul, Și locurile de muncă ridicate dintr-o comandă plătită (ServiceFulfillmentPolicy) nu au primit niciun număr. ServiceJobNumbers acum mints WO-00001... sub un blocaj PESSIMISTIC_WRITE pe org commerce_document_counter row (DocumentType.SERVICE_JOB, seria anul 0 — un rând curent) Serii), semănate o singură dată din cel mai mare număr WO- pe care îl are deja organizația createJob este @RetryOnDbConflict pentru 40001 al lui Yugabyte pe o cale contestată ux_service_job_org_number (org_id, job_number) este backstop-ul, aplicat de ux_service_job_org_number NONCONCURENȚI după ce numerele nule au fost completate. O lucrare nu se mai mută la Facturat prin schimbarea stării: Facturat înseamnă o factură Există, și numai crearea unuia (InvoicingService) pune un loc de muncă acolo. CommerceInvoicePayment (commerce_invoice_payments, aplicat manual) înregistrează fiecare Plata contra unei facturi CommerceInvoice, deci coloanele sale AMOUNT_PAID / PAID / PARTIALLY_PAID CommerceInvoiceRepository câștigă o citire blocată pe rând și o citire blocată pe rând by-client finder; ServiceJobRepository câștigă claimForInvoicing.