Reagendamento de entregaDelivery rescheduleReprogramación de entrega
A transação de escrita que informa ao backend a nova data de entrega de um pedido, quando o representante de vendas reagenda uma entrega do dia. Envia uma folha de viagem (trip sheet) mínima — o pedido, o rep, a nova data e um marcador de que nenhuma visita foi criada. Toda a construção do contrato wire vive no builder. The write transaction that tells the backend the new delivery date of an order, when the sales rep reschedules one of the day's deliveries. It sends a minimal trip sheet — the order, the rep, the new date and a flag that no visit was created. All wire-contract construction lives in the builder. La transacción de escritura que informa al backend la nueva fecha de entrega de un pedido, cuando el representante de ventas reprograma una entrega del día. Envía una hoja de viaje (trip sheet) mínima — el pedido, el rep, la nueva fecha y una marca de que no se creó ninguna visita. Toda la construcción del contrato wire vive en el builder.
O que é e quando aconteceWhat it is and when it happensQué es y cuándo ocurre
Quando uma entrega do dia não vai acontecer na data prevista, o representante de vendas pode escolher uma nova data para ela. Ao confirmar a nova data, o app avisa o backend por esta transação: a entrega passa a valer para o novo dia. É o que registra o reagendamento no sistema — o pedido em si não muda, muda só quando a entrega deve ocorrer. When one of the day's deliveries won't happen on its planned date, the sales rep can pick a new date for it. On confirming the new date, the app notifies the backend through this transaction: the delivery now applies to the new day. It's what records the reschedule in the system — the order itself doesn't change, only when the delivery should happen. Cuando una entrega del día no va a ocurrir en su fecha prevista, el representante de ventas puede elegir una nueva fecha para ella. Al confirmar la nueva fecha, la app avisa al backend por esta transacción: la entrega pasa a valer para el nuevo día. Es lo que registra la reprogramación en el sistema — el pedido en sí no cambia, solo cambia cuándo debe ocurrir la entrega.
Dois envios num só gestoTwo sends in one gestureDos envíos en un solo gesto Reagendar dispara, na prática, duas transações em sequência: primeiro a atualização de status (marca a entrega como Rescheduled) e depois este reagendamento (carrega a nova data). Para o rep é um único toque de confirmação. Rescheduling actually fires two transactions in sequence: first the status update (marks the delivery as Rescheduled) and then this reschedule (carries the new date). For the rep it's a single confirmation tap. Reprogramar dispara, en la práctica, dos transacciones en secuencia: primero la actualización de estado (marca la entrega como Rescheduled) y luego esta reprogramación (lleva la nueva fecha). Para el rep es un único toque de confirmación.
Fluxo de telas que disparaScreen flow that fires itFlujo de pantallas que lo dispara
O reagendamento parte do cartão de uma entrega na tela de Entregas do dia. As telas do caminho pertencem a essa feature; aqui só situamos onde o envio acontece:Rescheduling starts from a delivery card in the Deliveries of the day screen. The screens along the way belong to that feature; here we only place where the send happens:La reprogramación parte de la tarjeta de una entrega en la pantalla de Entregas del día. Las pantallas del camino pertenecen a esa feature; aquí solo situamos dónde ocurre el envío:
- Entregas do diaDeliveries of the dayEntregas del díaO rep vê a lista de entregas previstas e encontra a que precisa mudar de data.The rep sees the list of planned deliveries and finds the one whose date needs changing.El rep ve la lista de entregas previstas y encuentra la que necesita cambiar de fecha.
- Deslizar para reagendarSwipe to rescheduleDeslizar para reprogramarNo cartão de uma entrega pendente, o rep desliza para revelar a ação de reagendar.On a pending delivery's card, the rep swipes to reveal the reschedule action.En la tarjeta de una entrega pendiente, el rep desliza para revelar la acción de reprogramar.
- Escolher a nova dataPick the new dateElegir la nueva fechaUm calendário abre: o rep escolhe um dia útil dentro de uma janela de 60 dias (fins de semana bloqueados, a partir do próximo dia útil).A calendar opens: the rep picks a business day within a 60-day window (weekends blocked, starting the next business day).Se abre un calendario: el rep elige un día hábil dentro de una ventana de 60 días (fines de semana bloqueados, a partir del próximo día hábil).
- Confirmar → esta transaçãoConfirm → this transactionConfirmar → esta transacciónAo confirmar a data, o app dispara a atualização de status e, em seguida, este reagendamento. É este toque que aciona a transação.On confirming the date, the app fires the status update and then this reschedule. This tap is what triggers the transaction.Al confirmar la fecha, la app dispara la actualización de estado y luego esta reprogramación. Este toque es lo que activa la transacción.
Depois do envioAfter sendingDespués del envío
- Confirmação ao repConfirmation to the repConfirmación al rep
- Quando o backend aceita os dois envios, o app mostra um aviso verde de sucesso e a entrega passa a aparecer como Rescheduled, agora com a nova data.When the backend accepts both sends, the app shows a green success notice and the delivery now appears as Rescheduled, with the new date.Cuando el backend acepta ambos envíos, la app muestra un aviso verde de éxito y la entrega pasa a aparecer como Rescheduled, ahora con la nueva fecha.
- Se um envio falhaIf a send failsSi un envío falla
- Como são dois envios em sequência, se qualquer um falhar o reagendamento não se completa e o rep vê uma mensagem de erro — a entrega continua na data original.Since these are two sequential sends, if either fails the reschedule doesn't complete and the rep sees an error message — the delivery stays on its original date.Como son dos envíos en secuencia, si cualquiera falla la reprogramación no se completa y el rep ve un mensaje de error — la entrega permanece en su fecha original.
- Acompanhar o envioTracking the sendSeguir el envío
- O status técnico do despacho (enviado, em fila, com erro) pode ser acompanhado na central de dados / tracking de despachos do app — útil para suporte investigar um envio.The dispatch's technical status (sent, queued, errored) can be followed in the app's data center / dispatch tracking — useful for support to investigate a send.El estado técnico del despacho (enviado, en cola, con error) puede seguirse en el centro de datos / tracking de despachos de la app — útil para que soporte investigue un envío.
Visão técnicaTechnical overviewVisión técnica
Reagendamento de entrega é a transação de saída que envia uma trip sheet (folha de viagem) com a nova data de entrega de um pedido. É a segunda perna do reagendamento: o DeliveryOrchestrator envia primeiro a atualização de status (marca Rescheduled) e só depois esta. Origem: um pedido já entregue/pendente da tela de Entregas do dia.
Delivery reschedule is the outbound transaction that sends a trip sheet carrying an order's new delivery date. It's the second leg of the reschedule: the DeliveryOrchestrator first sends the status update (marks Rescheduled) and only then this one. Source: a pending delivery from the Deliveries of the day screen.
Reprogramación de entrega es la transacción de salida que envía una trip sheet (hoja de viaje) con la nueva fecha de entrega de un pedido. Es la segunda pierna de la reprogramación: el DeliveryOrchestrator envía primero la actualización de estado (marca Rescheduled) y solo después esta. Origen: una entrega pendiente de la pantalla de Entregas del día.
Payload mínimoMinimal payloadPayload mínimo
Uma única estrutura tripSheet com 6 campos: PO, rep, a nova data em dois formatos e um visitCreated fixo em false.A single tripSheet structure with 6 fields: PO, rep, the new date in two formats and a visitCreated fixed to false.Una única estructura tripSheet con 6 campos: PO, rep, la nueva fecha en dos formatos y un visitCreated fijo en false.
RPC genéricoGeneric RPCRPC genérico
Não há RPC próprio: passa pelo mesmo sendTransaction, com o JSON serializado em message e serviceName = TripsheetUploadAPI como discriminador.There's no dedicated RPC: it goes through the same sendTransaction, with the JSON serialized into message and serviceName = TripsheetUploadAPI as the discriminator.No hay RPC propio: pasa por el mismo sendTransaction, con el JSON serializado en message y serviceName = TripsheetUploadAPI como discriminador.
Input de entities cruasRaw-entity inputInput de entities crudas
O input carrega order e resource inteiros + duas datas; o build() deriva PO, ResID, conta e formata as datas (CLAUDE.md §36).The input carries the whole order and resource + two dates; build() derives PO, ResID, account and formats the dates (CLAUDE.md §36).El input lleva order y resource enteros + dos fechas; el build() deriva PO, ResID, cuenta y formatea las fechas (CLAUDE.md §36).
FontesSourcesFuentes
BuildDeliveryTripSheetDispatcherPayloadUseCase + DeliveryTripSheetDispatcherPayloadInput + DispatcherType.deliveryReschedule + DispatcherConectaRep.proto. Orquestrado por DeliveryOrchestrator e enviado por SubmitDeliveryUseCase.
BuildDeliveryTripSheetDispatcherPayloadUseCase + DeliveryTripSheetDispatcherPayloadInput + DispatcherType.deliveryReschedule + DispatcherConectaRep.proto. Orchestrated by DeliveryOrchestrator and sent by SubmitDeliveryUseCase.
BuildDeliveryTripSheetDispatcherPayloadUseCase + DeliveryTripSheetDispatcherPayloadInput + DispatcherType.deliveryReschedule + DispatcherConectaRep.proto. Orquestado por DeliveryOrchestrator y enviado por SubmitDeliveryUseCase.
Transporte gRPCgRPC transportTransporte gRPC
DispatcherConectaRep.proto · proto3 · package mn.bat.conectarep.dispatcher. O serviço expõe um único RPC genérico — não existe mensagem por transação. TODA transação de escrita do app usa este mesmo sendTransaction; o que muda é o serviceName (discriminador) e o JSON dentro de message.The service exposes a single generic RPC — there's no per-transaction message. EVERY write transaction in the app uses this same sendTransaction; what changes is the serviceName (discriminator) and the JSON inside message.El servicio expone un único RPC genérico — no existe mensaje por transacción. TODA transacción de escritura de la app usa este mismo sendTransaction; lo que cambia es el serviceName (discriminador) y el JSON dentro de message.
sendTransactionunaryrpc sendTransaction(InboxTransactionRequest) returns (InboxTransactionReply)
path /mn.bat.conectarep.dispatcher.DispatcherConectaRepService/sendTransaction
InboxTransactionRequestendpointstring· #1 · endpoint alvo (config de ambiente)target endpoint (environment config)endpoint destino (config de ambiente)serviceNamestring· #2 · discriminador — sempreTripsheetUploadAPI(sem prefixoPromo_; reagendamento não tem promoção)discriminator — alwaysTripsheetUploadAPI(noPromo_prefix; reschedule has no promotion)discriminador — siempreTripsheetUploadAPI(sin prefijoPromo_; la reprogramación no tiene promoción)dateReferencestring· #3 ·AAAA-MM-DDdo envio (submittedAt, formatoisoDate)YYYY-MM-DDof the submission (submittedAt,isoDateformat)AAAA-MM-DDdel envío (submittedAt, formatoisoDate)transactionReferencestring· #4 · opurchaseOrderNumberdo pedido (correlação)the order'spurchaseOrderNumber(correlation)elpurchaseOrderNumberdel pedido (correlación)usernamestring· #5 · oresource.usernamedo rep logado (preenchido pelo gateway)the logged-in rep'sresource.username(filled by the gateway)elresource.usernamedel rep conectado (rellenado por el gateway)messagestring· #6 · o payload JSON serializado (a tabela da seção 08)the JSON payload serialized (the table in section 08)el payload JSON serializado (la tabla de la sección 08)manufacturer/model/deviceUuid/deviceVersionstring· #7–#10 · dados do dispositivo (preenchidos pelo gateway)device data (filled by the gateway)datos del dispositivo (completados por el gateway)tidint64· #11 · id de transação para idempotência/replaytransaction id for idempotency/replayid de transacción para idempotencia/replay
InboxTransactionReplystatusint32· #1 · status do ack (0ou5= sucesso;1= duplicado)ack status (0or5= success;1= duplicate)status del ack (0o5= éxito;1= duplicado)messagestring· #2 · mensagem do backendbackend messagemensaje del backendtransactionIdint32· #3 · id atribuído pelo backend (correlação)backend-assigned id (correlation)id asignado por el backend (correlación)
Envelope → Request
O build() devolve um DispatcherEnvelope com type = deliveryReschedule, serviceName = TripsheetUploadAPI, payload (o tripSheet), account = DispatchAccountEntity(sfid: order.accountSfid, sapCode: order.accountSapId, name: order.accountName), transactionReference = order.purchaseOrderNumber e dateReference = submittedAt em isoDate. O DispatcherGateway serializa payload em JSON para message, copia os demais campos, preenche dispositivo + auth e chama o RPC.
build() returns a DispatcherEnvelope with type = deliveryReschedule, serviceName = TripsheetUploadAPI, payload (the tripSheet), account = DispatchAccountEntity(sfid: order.accountSfid, sapCode: order.accountSapId, name: order.accountName), transactionReference = order.purchaseOrderNumber and dateReference = submittedAt as isoDate. The DispatcherGateway serializes payload to JSON into message, copies the rest, fills device + auth and calls the RPC.
build() devuelve un DispatcherEnvelope con type = deliveryReschedule, serviceName = TripsheetUploadAPI, payload (el tripSheet), account = DispatchAccountEntity(sfid: order.accountSfid, sapCode: order.accountSapId, name: order.accountName), transactionReference = order.purchaseOrderNumber y dateReference = submittedAt en isoDate. El DispatcherGateway serializa payload a JSON en message, copia el resto, completa dispositivo + auth y llama al RPC.
resendMayDuplicate == true: o reagendamento não está no conjunto lightweight (notificationRead, answerTask, priceCheck), então um reenvio pode duplicar no backend; a idempotência via tid é o que mitiga isso.resendMayDuplicate == true: reschedule is not in the lightweight set (notificationRead, answerTask, priceCheck), so a resend may duplicate on the backend; idempotency via tid is what mitigates it.resendMayDuplicate == true: la reprogramación no está en el conjunto lightweight (notificationRead, answerTask, priceCheck), así que un reenvío puede duplicar en el backend; la idempotencia vía tid es lo que lo mitiga.
Correspondência de nomesName correspondenceCorrespondencia de nombres
Esta transação carrega três nomes que não coincidem — vale fixar a correspondência para não confundir busca no código:This transaction carries three names that don't match — worth pinning the correspondence to avoid code-search confusion:Esta transacción lleva tres nombres que no coinciden — conviene fijar la correspondencia para no confundir la búsqueda en el código:
| PapelRoleRol | Nome no códigoName in codeNombre en el código | ObservaçãoNoteObservación |
|---|---|---|
| Tipo (enum)Type (enum)Tipo (enum) | DispatcherType.deliveryReschedule | a intenção de negócio — reagendar entregathe business intent — reschedule deliveryla intención de negocio — reprogramar entrega |
| serviceName (wire)serviceName (wire)serviceName (wire) | TripsheetUploadAPI | o discriminador que o backend lê — nomeado pela trip sheet, não por "reschedule"the discriminator the backend reads — named after the trip sheet, not "reschedule"el discriminador que lee el backend — nombrado por la trip sheet, no por "reschedule" |
| Builder / InputBuilder / InputBuilder / Input | BuildDeliveryTripSheet… · DeliveryTripSheet…Input | nomeados pela estrutura tripSheet do payload, alinhados ao serviceNamenamed after the payload's tripSheet structure, aligned to serviceNamenombrados por la estructura tripSheet del payload, alineados al serviceName |
Não confundirDon't confuseNo confundir
Buscar por "reschedule" no wire não acha nada: o backend só conhece TripsheetUploadAPI. E buscar por "reschedule" no código traz também reschedulingCallTask (call task, transação 27) e o buyback — nada a ver com entrega.
Searching the wire for "reschedule" finds nothing: the backend only knows TripsheetUploadAPI. And searching the code for "reschedule" also brings up reschedulingCallTask (call task, transaction 27) and buyback — unrelated to delivery.
Buscar "reschedule" en el wire no encuentra nada: el backend solo conoce TripsheetUploadAPI. Y buscar "reschedule" en el código trae también reschedulingCallTask (call task, transacción 27) y el buyback — sin relación con la entrega.
Como é disparadoHow it's firedCómo se dispara
A transação é orquestrada pelo DeliveryOrchestrator (remote-first, §36). O notifier apenas reúne entities cruas; o builder é o dono único de derivar PO/ResID/conta e formatar as datas. Reagendar dispara duas pernas — status update, depois trip sheet — em sequência; se a primeira falha, a segunda nem é montada. A cascata:The transaction is orchestrated by DeliveryOrchestrator (remote-first, §36). The notifier only gathers raw entities; the builder is the sole owner of deriving PO/ResID/account and formatting dates. Rescheduling fires two legs — status update, then trip sheet — in sequence; if the first fails, the second isn't even built. The cascade:La transacción se orquesta desde el DeliveryOrchestrator (remote-first, §36). El notifier solo reúne entities crudas; el builder es el dueño único de derivar PO/ResID/cuenta y formatear las fechas. Reprogramar dispara dos piernas — status update, luego trip sheet — en secuencia; si la primera falla, la segunda ni se arma. La cascada:
- DeliveryCardWidgetswipe + calendárioswipe + calendarswipe + calendario
- rescheduleDelivery(order, date)DeliveriesOfTheDayNotifier
- updateDelivery(...)DeliveryOrchestratorinjeta submittedAt = now()injects submittedAt = now()inyecta submittedAt = now()
- 1ª perna1st leg1ª pierna02 · DeliveryStatusUpdateRescheduled
- 2ª perna · build()2nd leg · build()2ª pierna · build()BuildDeliveryTripSheet…UseCase
- devolvereturnsdevuelveDispatcherEnvelope
- SubmitDeliveryUseCaseDispatcherGateway
serializa + authserialize + authserializa + auth
- sendTransactionBackendgRPC
- SubmitDeliveryUseCaseDispatcherGateway
serializa + authserialize + authserializa + auth
- devolvereturnsdevuelveDispatcherEnvelope
- updateDelivery(...)DeliveryOrchestratorinjeta submittedAt = now()injects submittedAt = now()inyecta submittedAt = now()
- rescheduleDelivery(order, date)DeliveriesOfTheDayNotifier
O input (entities cruas)The input (raw entities)El input (entities crudas)
DeliveryTripSheetDispatcherPayloadInput (Freezed). Carrega o dado como existe no domínio; nada de formato wire. O relógio chega como submittedAt (via DateTimeUtils.now() no orchestrator); a data escolhida chega como rescheduleDate (já normalizada em dateOnly).DeliveryTripSheetDispatcherPayloadInput (Freezed). Carries data as it exists in the domain; no wire shaping. The clock arrives as submittedAt (via DateTimeUtils.now() in the orchestrator); the picked date arrives as rescheduleDate (already normalized via dateOnly).DeliveryTripSheetDispatcherPayloadInput (Freezed). Lleva el dato como existe en el dominio; nada de formato wire. El reloj llega como submittedAt (vía DateTimeUtils.now() en el orchestrator); la fecha elegida llega como rescheduleDate (ya normalizada con dateOnly).
| CampoFieldCampo | TipoTypeTipo | PapelRoleRol |
|---|---|---|
order | OrderEntity | pedido cru — o builder deriva orderPONum, account e transactionReferenceraw order — the builder derives orderPONum, account and transactionReferencepedido crudo — el builder deriva orderPONum, account y transactionReference |
resource | ResourceEntity | representante de vendas cru — o builder deriva ResID de resource.sfidraw sales rep — the builder derives ResID from resource.sfidrepresentante de ventas crudo — el builder deriva ResID de resource.sfid |
rescheduleDate | DateTime | nova data escolhida → deliveryDate, tripStartDate, tripEndDatepicked new date → deliveryDate, tripStartDate, tripEndDatenueva fecha elegida → deliveryDate, tripStartDate, tripEndDate |
submittedAt | DateTime | relógio do envio → dateReference do envelopesubmission clock → envelope dateReferencereloj del envío → dateReference del envelope |
Payload (message)
O JSON serializado no campo message do request. A tabela tem 4 colunas — Campo JSON · Tipo · Origem do Dado · Regra — e lista toda chave que o build() emite (6 no total, dentro de tripSheet[0]). Campo, Tipo e Origem são código cru; só a Regra é prosa. Um exemplo completo (BR) está em transaction_example.json, ao lado deste doc.The JSON serialized into the request's message field. The table has 4 columns — JSON field · Type · Data source · Rule — and lists every key that build() emits (6 in total, inside tripSheet[0]). Field, Type and Source are raw code; only Rule is prose. A full example (BR) sits in transaction_example.json, next to this doc.El JSON serializado en el campo message del request. La tabla tiene 4 columnas — Campo JSON · Tipo · Origen del Dato · Regla — y lista toda clave que build() emite (6 en total, dentro de tripSheet[0]). Campo, Tipo y Origen son código crudo; solo la Regla es prosa. Un ejemplo completo (BR) está en transaction_example.json, junto a este doc.
| Campo JSON | TipoTypeTipo | Origem do DadoData sourceOrigen del Dato | RegraRuleRegla |
|---|---|---|---|
tripSheet | array | estruturalstructuralestructural | wrapper; o builder emite exatamente 1 entrada (a entrega reagendada)wrapper; the builder emits exactly 1 entry (the rescheduled delivery)wrapper; el builder emite exactamente 1 entrada (la entrega reprogramada) |
tripSheet[].orderPONum | string | order.purchaseOrderNumber | PO do pedido cuja entrega está sendo reagendadaPO of the order whose delivery is being rescheduledPO del pedido cuya entrega se está reprogramando |
tripSheet[].ResID | string | resource.sfid | sfid do representante de vendas (§25 — em escrita, sfid identifica o rep)sales rep's sfid (§25 — on writes, sfid identifies the rep)sfid del representante de ventas (§25 — en escritura, sfid identifica al rep) |
tripSheet[].deliveryDate | string | formatDate(rescheduleDate, slashYearMonthDay) | nova data em yyyy/MM/dd (barras)new date as yyyy/MM/dd (slashes)nueva fecha en yyyy/MM/dd (barras) |
tripSheet[].tripEndDate | string | formatDate(rescheduleDate, isoDate) | a mesma data em AAAA-MM-DD (ISO)the same date as YYYY-MM-DD (ISO)la misma fecha en AAAA-MM-DD (ISO) |
tripSheet[].tripStartDate | string | formatDate(rescheduleDate, isoDate) | a mesma data em AAAA-MM-DD — início = fim (janela de 1 dia)the same date as YYYY-MM-DD — start = end (single-day window)la misma fecha en AAAA-MM-DD — inicio = fin (ventana de 1 día) |
tripSheet[].visitCreated | bool | Fixo: falseFixed: falseFijo: false | sempre false — reagendar não cria visitaalways false — reschedule creates no visitsiempre false — reprogramar no crea visita |
ExemploExampleEjemplo
Um payload completo (BR, 1 entrega) está em docs/public/dispatcher/03_delivery_reschedule/transaction_example.json — a forma exata serializada em message (sem wrapper gRPC).
A complete payload (BR, 1 delivery) is in docs/public/dispatcher/03_delivery_reschedule/transaction_example.json — the exact shape serialized into message (no gRPC wrapper).
Un payload completo (BR, 1 entrega) está en docs/public/dispatcher/03_delivery_reschedule/transaction_example.json — la forma exacta serializada en message (sin wrapper gRPC).
Regras de negócioBusiness rulesReglas de negocio
Dois formatos para a mesma dataTwo formats for the same dateDos formatos para la misma fecha deliveryDate vs trip*Date
deliveryDate:rescheduleDateemyyyy/MM/dd(slashYearMonthDay).deliveryDate:rescheduleDateasyyyy/MM/dd(slashYearMonthDay).deliveryDate:rescheduleDateenyyyy/MM/dd(slashYearMonthDay).tripStartDateetripEndDate: a mesmarescheduleDateemAAAA-MM-DD(isoDate) — formato diferente dodeliveryDate, e as duas iguais entre si.tripStartDateandtripEndDate: the samerescheduleDateasYYYY-MM-DD(isoDate) — different format fromdeliveryDate, and both equal to each other.tripStartDateytripEndDate: la mismarescheduleDateenAAAA-MM-DD(isoDate) — formato distinto dedeliveryDate, y ambas iguales entre sí.dateReferencedo envelope:submittedAt(o relógio do envio, não a nova data) emisoDate.envelopedateReference:submittedAt(the submission clock, not the new date) asisoDate.dateReferencedel envelope:submittedAt(el reloj del envío, no la nueva fecha) enisoDate.
Conta e correlaçãoAccount & correlationCuenta y correlación account · transactionReference
accountdo envelope =DispatchAccountEntitycomsfid = order.accountSfid,sapCode = order.accountSapId,name = order.accountName— todos derivados do próprio pedido.envelopeaccount=DispatchAccountEntitywithsfid = order.accountSfid,sapCode = order.accountSapId,name = order.accountName— all derived from the order itself.envelopeaccount=DispatchAccountEntityconsfid = order.accountSfid,sapCode = order.accountSapId,name = order.accountName— todos derivados del propio pedido.transactionReference = order.purchaseOrderNumber— o mesmo PO que vai emorderPONum, usado para correlação do despacho.transactionReference = order.purchaseOrderNumber— the same PO carried inorderPONum, used for dispatch correlation.transactionReference = order.purchaseOrderNumber— el mismo PO que va enorderPONum, usado para correlación del despacho.
Janela de datas escolhíveisSelectable date windowVentana de fechas elegibles próximo dia útil · 60 dias · sem fim de semana
- O calendário (
DeliveryCardWidget._openReschedule) começa no próximo dia útil (DateTimeUtils.nextBusinessDay()) e vai até +60 dias; sábados e domingos ficam bloqueados (blockedWeekdays: [0, 6]).The calendar (DeliveryCardWidget._openReschedule) starts on the next business day (DateTimeUtils.nextBusinessDay()) and runs to +60 days; Saturdays and Sundays are blocked (blockedWeekdays: [0, 6]).El calendario (DeliveryCardWidget._openReschedule) empieza en el próximo día hábil (DateTimeUtils.nextBusinessDay()) y llega a +60 días; sábados y domingos quedan bloqueados (blockedWeekdays: [0, 6]). - A data escolhida é normalizada com
DateTimeUtils.dateOnly(sem hora) antes de virarrescheduleDate.The picked date is normalized viaDateTimeUtils.dateOnly(no time) before becomingrescheduleDate.La fecha elegida se normaliza conDateTimeUtils.dateOnly(sin hora) antes de convertirse enrescheduleDate.
Sequência de duas pernasTwo-leg sequenceSecuencia de dos piernas status update → trip sheet
No DeliveryOrchestrator.updateDelivery, com action == reschedule e rescheduleDate != null:In DeliveryOrchestrator.updateDelivery, with action == reschedule and rescheduleDate != null:En DeliveryOrchestrator.updateDelivery, con action == reschedule y rescheduleDate != null:
- 1Envia a atualização de status (status
Rescheduled). Se falhar, retorna erro e não monta a trip sheet.Sends the status update (statusRescheduled). If it fails, returns an error and does not build the trip sheet.Envía la actualización de estado (estadoRescheduled). Si falla, devuelve error y no arma la trip sheet. - 2Envia esta trip sheet (a nova data). Se falhar, retorna erro.Sends this trip sheet (the new date). If it fails, returns an error.Envía esta trip sheet (la nueva fecha). Si falla, devuelve error.
- 3Só após ambos: atualização otimista do cache (status
rescheduled,deliveryDate= nova data em ISO).Only after both: optimistic cache update (statusrescheduled,deliveryDate= new date in ISO).Solo tras ambos: actualización optimista del cache (estadorescheduled,deliveryDate= nueva fecha en ISO).
As duas pernas compartilham o mesmo submittedAt (um único DateTimeUtils.now() por reagendamento).Both legs share the same submittedAt (a single DateTimeUtils.now() per reschedule).Ambas piernas comparten el mismo submittedAt (un único DateTimeUtils.now() por reprogramación).
Pendências / roadmapPending / roadmapPendientes / roadmap
O que o builder envia inerte ou acoplado, documentado fiel ao estado atual do código (nunca descrito como se fosse configurável):What the builder ships inert or coupled, documented faithfully to the current code state (never described as if it were configurable):Lo que el builder envía inerte o acoplado, documentado fiel al estado actual del código (nunca descrito como si fuera configurable):
Estado atual / pendenteCurrent state / pendingEstado actual / pendiente
visitCreated: semprefalse, literal fixo — reagendar nunca gera uma visita; não há caminho no app que envietrue.visitCreated: alwaysfalse, a fixed literal — rescheduling never spawns a visit; no app path sendstrue.visitCreated: siemprefalse, literal fijo — reprogramar nunca genera una visita; no hay camino en la app que envíetrue.tripStartDateetripEndDatesão idênticos (a nova data): a trip sheet só modela uma janela de um único dia — não há data de início/fim distintas.tripStartDateandtripEndDateare identical (the new date): the trip sheet only models a single-day window — there are no distinct start/end dates.tripStartDateytripEndDateson idénticos (la nueva fecha): la trip sheet solo modela una ventana de un único día — no hay fechas de inicio/fin distintas.- Acoplamento com a 1ª perna: se a atualização de status falhar, a trip sheet não é enviada — não há reenvio isolado só da trip sheet a partir da UI.Coupling with the 1st leg: if the status update fails, the trip sheet isn't sent — there's no isolated retry of the trip sheet alone from the UI.Acoplamiento con la 1ª pierna: si la actualización de estado falla, la trip sheet no se envía — no hay reenvío aislado solo de la trip sheet desde la UI.
- Transporte:
deviceUuidvai como literal provisório no gateway (pendência conhecida do Dispatcher, comum a todas as transações).Transport:deviceUuidships as a provisional literal in the gateway (known Dispatcher pending item, shared by all transactions).Transporte:deviceUuidva como literal provisional en el gateway (pendiente conocido del Dispatcher, común a todas las transacciones).
Transações irmãsSister transactionsTransacciones hermanas As três ações de entrega (confirmar, rejeitar, reagendar) passam pela 02 · Delivery status update. Só o reagendar dispara, além dela, esta trip sheet. All three delivery actions (confirm, reject, reschedule) go through 02 · Delivery status update. Only reschedule fires, on top of it, this trip sheet. Las tres acciones de entrega (confirmar, rechazar, reprogramar) pasan por 02 · Delivery status update. Solo reprogramar dispara, además de ella, esta trip sheet.
MercadosMarketsMercados
A disponibilidade vem do DispatcherType.deliveryReschedule.enabledMarkets = BR e CL apenas. Diferente da maioria das transações de entrega, a ZA não está incluída. AR/PY/PE não têm dispatcher de entrega.Availability comes from DispatcherType.deliveryReschedule.enabledMarkets = BR and CL only. Unlike most delivery transactions, ZA is not included. AR/PY/PE have no delivery dispatcher.La disponibilidad viene de DispatcherType.deliveryReschedule.enabledMarkets = solo BR y CL. A diferencia de la mayoría de las transacciones de entrega, ZA no está incluida. AR/PY/PE no tienen dispatcher de entrega.
Brasil e ChileBrazil and ChileBrasil y Chile
O reagendamento (TripsheetUploadAPI) existe só em BR e CL. O payload e as regras são idênticos nos dois mercados — não há campo específico por país nesta trip sheet.
Reschedule (TripsheetUploadAPI) exists only in BR and CL. The payload and rules are identical in both markets — there's no country-specific field in this trip sheet.
La reprogramación (TripsheetUploadAPI) existe solo en BR y CL. El payload y las reglas son idénticos en ambos mercados — no hay campo específico por país en esta trip sheet.
África do Sul — ausenteSouth Africa — absentSudáfrica — ausente
A ZA não está em enabledMarkets desta transação (embora tenha entregas). Atenção: a 1ª perna (status update) vale BR/CL/ZA, mas a trip sheet de reagendamento só BR/CL.
ZA is not in this transaction's enabledMarkets (even though it has deliveries). Note: the 1st leg (status update) applies to BR/CL/ZA, but the reschedule trip sheet is BR/CL only.
ZA no está en los enabledMarkets de esta transacción (aunque tenga entregas). Atención: la 1ª pierna (status update) aplica a BR/CL/ZA, pero la trip sheet de reprogramación solo BR/CL.
AR · PY · PE
Existem como mercados do app (config PANGEA mínima), mas não têm dispatcher de entrega — não estão em enabledMarkets. O reagendamento não é disparado nesses mercados.
They exist as app markets (minimal PANGEA config), but have no delivery dispatcher — not in enabledMarkets. Reschedule is not fired in these markets.
Existen como mercados de la app (config PANGEA mínima), pero no tienen dispatcher de entrega — no están en enabledMarkets. La reprogramación no se dispara en estos mercados.