- Expédié
- 8 novembre 2026 à 08:35 UTC
- Auteur
- Kamo
- Commit
- d100d86
Les numéros de bon de travail étaient COUNT(jobs)+1, donc deux jobs soulevés en même temps pouvaient en partager un, et les travaux soulevés à partir d'une commande payée (ServiceFulfillmentPolicy) n'ont pas reçu de numéro du tout. ServiceJobNumbers mints maintenant WO-00001… sous un verrou PESSIMISTIC_WRITE sur l'org commerce_document_counter row (DocumentType.SERVICE_JOB, série année 0 — une série en cours) (série), sélectionné une fois à partir du numéro WO- le plus élevé que l'organisation possède déjà createJob est @RetryOnDbConflict pour le 40001 de Yugabyte sur une base de données contestée ux_service_job_org_number (org_id, job_number) est le backstop, appliqué par main NONCONCURRENTLY après que les nombres nuls ont été remplis. Une tâche ne se déplace plus vers Facturé par un changement de statut: Facturé signifie une facture Il suffit d'en créer un (InvoicingService) pour y placer une tâche. CommerceInvoicePayment (commerce_invoice_payments, appliqué à la main) enregistre chaque Paiement contre une CommerceInvoice, donc ses colonnes AMOUNT_PAID / PAID / PARTIALLY_PAID CommerceInvoiceRepository obtient une lecture verrouillée par ligne et une écriture verrouillée par ligne ServiceJobRepository obtient la valeur claimForInvoicing.