- Enviado
- 8 de novembro de 2026 às 08:35 UTC
- Autor
- Kamo
- Confirmação
- d100d86
Os números de ordem de trabalho eram COUNT(jobs)+1, então dois trabalhos levantados de uma só vez poderiam compartilhar um, e os trabalhos gerados a partir de uma ordem paga (ServiceFulfillmentPolicy) não receberam nenhum número. ServiceJobNumbers agora mints WO-00001... sob um bloqueio PESSIMISTIC_WRITE na organização commerce_document_counter row (DocumentType.SERVICE_JOB, série ano 0 — uma linha em execução) série), semeado uma vez a partir do maior número WO- que a organização já tem use-o; createJob é @RetryOnDbConflict para o 40001 da Yugabyte em um conteúdo contencioso contador. ux_service_job_org_number (org_id, job_number) é o backstop, aplicado por mão NONCONCURRENTLY depois que os números nulos foram preenchidos. Uma tarefa não é mais movida para Faturado por uma alteração de status: Faturado significa uma fatura existe, e somente a criação de um (InvoicingService) coloca um trabalho lá. CommerceInvoicePayment (commerce_invoice_payments, aplicado manualmente) registra cada pagamento contra uma CommerceInvoice, então suas colunas AMOUNT_PAID / PAID / PARTIALLY_PAID CommerceInvoiceRepository ganha uma leitura com bloqueio de linha e uma by-customer finder; ServiceJobRepository ganha claimForInvoicing.