- Enviado
- 8 de noviembre de 2026 a las 8:35 UTC
- Autor
- Kamo
- Commit
- d100d86
Los números de las órdenes de trabajo eran COUNT(jobs)+1, por lo que dos trabajos generados a la vez podían compartir uno, y los trabajos generados a partir de un pedido pagado (ServiceFulfillmentPolicy) no recibieron ningún número. ServiceJobNumbers ahora mints WO-00001… bajo un bloqueo PESSIMISTIC_WRITE en la organización commerce_document_counter row (DocumentType.SERVICE_JOB, serie año 0 — una fila en ejecución) (serie), sembrado una vez desde el número WO- más alto que la organización ya tiene createJob es @RetryOnDbConflict para el 40001 de Yugabyte en una ruta contenida ux_service_job_org_number (org_id, job_number) es el backstop, aplicado por el contador NONCONCURRENTLY después de que los números nulos fueron rellenados. Un trabajo ya no se mueve a Facturado por un cambio de estado: Facturado significa una factura Existe, y solo crear uno (InvoicingService) pone un trabajo allí. CommerceInvoicePayment (commerce_invoice_payments, aplicado a mano) registra cada Pago contra una CommerceInvoice, por lo que sus columnas AMOUNT_PAID / PAID / PARTIALLY_PAID CommerceInvoiceRepository gana una lectura bloqueada en fila y una lectura bloqueada en fila ServiceJobRepository obtiene claimForInvoicing.