Transação gRPC · DispatchergRPC transaction · DispatcherTransacción gRPC · Dispatcher

Reagendamento de call taskReschedule call taskReprogramación de call task

A transação de escrita que reagenda uma call task para uma nova data. Quando o representante de vendas, no detalhe de uma call task, escolhe outra data para executá-la, o app envia esse reagendamento ao backend por esta transação. É um envio simples — um único objeto com a call task, a visita, o representante e a nova data. The write transaction that reschedules a call task to a new date. When the sales rep, on a call task's detail, picks another date to carry it out, the app sends that reschedule to the backend through this transaction. It's a simple send — a single object with the call task, the visit, the sales rep and the new date. La transacción de escritura que reprograma una call task a una nueva fecha. Cuando el representante de ventas, en el detalle de una call task, elige otra fecha para ejecutarla, la app envía esa reprogramación al backend por esta transacción. Es un envío simple — un único objeto con la call task, la visita, el representante y la nueva fecha.

PúblicoAudiencePúblico

QA · Suporte · Produto · DevQA · Support · Product · DevQA · Soporte · Producto · Dev

CamadaLayerCapa

Escrita · DispatcherWrite · DispatcherEscritura · Dispatcher

RelacionadoRelatedRelacionado

Call Task · Answer call task

AtualizadoUpdatedActualizado

17/08/20262026-08-17

Disponível emAvailable inDisponible en BR CL ZA

O que é e quando aconteceWhat it is and when it happensQué es y cuándo ocurre

Uma call task é uma tarefa de execução ligada a uma visita — algo que o representante de vendas precisa fazer no ponto de venda (checar ruptura de produto, uma orientação, um alerta). Quando o rep não vai conseguir executar a tarefa na data prevista, ele pode reagendá-la para outro dia. Esta transação é o momento em que essa nova data sai do dispositivo e passa a valer no sistema. A call task is an execution task tied to a visit — something the sales rep needs to do at the point of sale (check a product stockout, a guideline, an alert). When the rep can't carry the task out on the planned date, they can reschedule it to another day. This transaction is the moment that new date leaves the device and takes effect in the system. Una call task es una tarea de ejecución ligada a una visita — algo que el representante de ventas necesita hacer en el punto de venta (verificar quiebre de producto, una orientación, una alerta). Cuando el rep no va a poder ejecutar la tarea en la fecha prevista, puede reprogramarla para otro día. Esta transacción es el momento en que esa nueva fecha sale del dispositivo y pasa a valer en el sistema.

Reagendar ≠ concluirReschedule ≠ completeReprogramar ≠ completar Reagendar só move a data da call task; a tarefa continua pendente. Marcá-la como concluída (incluindo a resposta de ruptura por produto) é outra transação — a Resposta de call task. Rescheduling only moves the date of the call task; the task stays pending. Marking it complete (including the per-product stockout answer) is a different transaction — the Answer call task. Reprogramar solo mueve la fecha de la call task; la tarea sigue pendiente. Marcarla como completada (incluyendo la respuesta de quiebre por producto) es otra transacción — la Respuesta de call task.

Fluxo de telas que disparaScreen flow that fires itFlujo de pantallas que lo dispara

A transação é o último passo do reagendamento. As telas do caminho pertencem à feature de Call Task; aqui só situamos onde o envio acontece:The transaction is the last step of the reschedule. The screens along the way belong to the Call Task feature; here we only place where the send happens:La transacción es el último paso de la reprogramación. Las pantallas del camino pertenecen a la feature de Call Task; aquí solo situamos dónde ocurre el envío:

Detalhe da visitaVisit detailDetalle de la visitaO rep abre uma visita e vê a lista de call tasks daquela visita.The rep opens a visit and sees that visit's list of call tasks.El rep abre una visita y ve la lista de call tasks de esa visita.
Detalhe da call taskCall task detailDetalle de la call taskToca em uma call task para abrir seu detalhe, onde ficam as ações de concluir e reagendar.Taps a call task to open its detail, where the complete and reschedule actions live.Toca una call task para abrir su detalle, donde están las acciones de completar y reprogramar.
Escolher nova dataPick new dateElegir nueva fechaToca em reagendar; um seletor de data abre para escolher o novo dia.Taps reschedule; a date picker opens to choose the new day.Toca reprogramar; un selector de fecha se abre para elegir el nuevo día.
Confirmar → esta transaçãoConfirm → this transactionConfirmar → esta transacciónAo confirmar a nova data, o app dispara o Reagendamento de call task. É este toque que aciona a transação.On confirming the new date, the app fires the Reschedule call task. This tap is what triggers the transaction.Al confirmar la nueva fecha, la app dispara la Reprogramación de call task. 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, o app confirma o reagendamento e a call task passa a mostrar a nova data. A tarefa continua pendente — só a data mudou.When the backend accepts it, the app confirms the reschedule and the call task now shows the new date. The task stays pending — only the date changed.Cuando el backend lo acepta, la app confirma la reprogramación y la call task pasa a mostrar la nueva fecha. La tarea sigue pendiente — solo cambió la fecha.
Sem internetOfflineSin internet: O envio pode entrar em fila e ser reenviado quando a conexão volta — o rep não perde o reagendamento. O sistema usa um identificador de transação para evitar duplicidade em um reenvio.The send may be queued and retried when the connection returns — the rep doesn't lose the reschedule. The system uses a transaction id to avoid duplicates on a retry.El envío puede quedar en cola y reintentarse cuando vuelve la conexión — el rep no pierde la reprogramación. El sistema usa un identificador de transacción para evitar duplicados en un reenvío.
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 o 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 call task é a transação de saída que persiste a nova data de uma call task no backend. É disparada pelo notifier da page call_task_detail quando o representante de vendas confirma uma nova data no seletor. É uma das transações mais simples do Dispatcher: um único objeto com cinco campos. Reschedule call task is the outbound transaction that persists a call task's new date on the backend. It's fired by the call_task_detail page notifier when the sales rep confirms a new date in the picker. It's one of the simplest Dispatcher transactions: a single object with five fields. Reprogramación de call task es la transacción de salida que persiste la nueva fecha de una call task en el backend. Se dispara desde el notifier de la page call_task_detail cuando el representante de ventas confirma una nueva fecha en el selector. Es una de las transacciones más simples del Dispatcher: un único objeto con cinco campos.

Só a dataDate onlySolo la fecha

O payload não carrega os produtos nem o status da tarefa — só a call task, a visita, o rep e a nova data. Concluir é outra transação.The payload carries neither the products nor the task status — only the call task, the visit, the rep and the new date. Completing is a separate transaction.El payload no lleva los productos ni el estado de la tarea — solo la call task, la visita, el rep y la nueva fecha. Completar es otra transacción.

Sem variantesNo variantsSin variantes

Um único DispatcherType.reschedulingCallTask, um único serviceName. Não há prefixo Promo_ (o builder passa hasPromotion: false).A single DispatcherType.reschedulingCallTask, a single serviceName. There's no Promo_ prefix (the builder passes hasPromotion: false).Un único DispatcherType.reschedulingCallTask, un único serviceName. No hay prefijo Promo_ (el builder pasa hasPromotion: false).

RPC genéricoGeneric RPCRPC genérico

Como toda transação, passa pelo mesmo sendTransaction, com o JSON no campo message e o serviceName como discriminador. Destino sfbatchapi.Like every transaction, it goes through the same sendTransaction, with the JSON in the message field and serviceName as the discriminator. Destination sfbatchapi.Como toda transacción, pasa por el mismo sendTransaction, con el JSON en el campo message y el serviceName como discriminador. Destino sfbatchapi.

FontesSourcesFuentes BuildRescheduleCallTaskDispatcherPayloadUseCase + RescheduleCallTaskDispatcherPayloadInput + DispatcherType + DispatcherConectaRep.proto. O input carrega entities cruas de domínio (CLAUDE.md §36); o build() constrói todo o wire. BuildRescheduleCallTaskDispatcherPayloadUseCase + RescheduleCallTaskDispatcherPayloadInput + DispatcherType + DispatcherConectaRep.proto. The input carries raw domain entities (CLAUDE.md §36); build() constructs the entire wire. BuildRescheduleCallTaskDispatcherPayloadUseCase + RescheduleCallTaskDispatcherPayloadInput + DispatcherType + DispatcherConectaRep.proto. El input lleva entities crudas de dominio (CLAUDE.md §36); build() construye todo el wire.

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.

sendTransactionunary

MétodoMethodMétodo

rpc sendTransaction(InboxTransactionRequest) returns (InboxTransactionReply)

path /mn.bat.conectarep.dispatcher.DispatcherConectaRepService/sendTransaction

Request · InboxTransactionRequest

endpoint: string · #1 · endpoint alvo (config de ambiente)target endpoint (environment config)endpoint destino (config de ambiente)
serviceName: string · #2 · discriminador — ReschedulingCallTaskAPI (sem prefixo Promo_)discriminator — ReschedulingCallTaskAPI (no Promo_ prefix)discriminador — ReschedulingCallTaskAPI (sin prefijo Promo_)
dateReference: string · #3 · AAAA-MM-DD da nova data (input.newDate)YYYY-MM-DD of the new date (input.newDate)AAAA-MM-DD de la nueva fecha (input.newDate)
transactionReference: string · #4 · o id da call task (correlação)the call task id (correlation)el id de la call task (correlación)
username: string · #5
message: string · #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: string · #7 · dado do dispositivodevice datadato del dispositivo
model: string · #8 · dado do dispositivodevice datadato del dispositivo
deviceUuid: string · #9
deviceVersion: string · #10
tid: int64 · #11 · id de transação para idempotência/replaytransaction id for idempotency/replayid de transacción para idempotencia/replay

Reply · InboxTransactionReply

status: int32 · #1 · status do ack (0 = sucesso)ack status (0 = success)status del ack (0 = éxito)
message: string · #2 · mensagem do backendbackend messagemensaje del backend
transactionId: int32 · #3 · id atribuído pelo backend (correlação)backend-assigned id (correlation)id asignado por el backend (correlación)

Envelope → Request O builder devolve um DispatcherEnvelope (type, serviceName, payload, transactionReference, dateReference). O DispatcherGateway serializa payload em JSON para message, copia serviceName/dateReference/transactionReference, preenche os campos de dispositivo e o bearer token de auth, e chama o RPC. The builder returns a DispatcherEnvelope (type, serviceName, payload, transactionReference, dateReference). The DispatcherGateway serializes payload to JSON into message, copies serviceName/dateReference/transactionReference, fills in the device fields and the auth bearer token, and calls the RPC. El builder devuelve un DispatcherEnvelope (type, serviceName, payload, transactionReference, dateReference). El DispatcherGateway serializa payload a JSON en message, copia serviceName/dateReference/transactionReference, completa los campos del dispositivo y el bearer token de auth, y llama al RPC.

serviceName e destinoserviceName & destinationserviceName y destino

Um único DispatcherType, sem variantes. O serviceName vem de type.resolveServiceName(hasPromotion: false) — o builder passa false fixo, então o prefixo Promo_ nunca é aplicado. O destino batchApi (sfbatchapi) roteia o envio para o endpoint de lote, não o Salesforce direto.A single DispatcherType, no variants. The serviceName comes from type.resolveServiceName(hasPromotion: false) — the builder passes a fixed false, so the Promo_ prefix is never applied. The batchApi destination (sfbatchapi) routes the send to the batch endpoint, not straight to Salesforce.Un único DispatcherType, sin variantes. El serviceName viene de type.resolveServiceName(hasPromotion: false) — el builder pasa un false fijo, así que el prefijo Promo_ nunca se aplica. El destino batchApi (sfbatchapi) rutea el envío al endpoint de lote, no a Salesforce directo.

`DispatcherType`	`serviceName`	DestinoDestinationDestino	MercadosMarketsMercados
`reschedulingCallTask`	`ReschedulingCallTaskAPI`	`batchApi` · `sfbatchapi`	BR · CL · ZA

Como é disparadoHow it's firedCómo se dispara

A transação é orquestrada pelo notifier de call_task_detail (remote-first, §36). O notifier apenas reúne entities cruas e a nova data; o builder é o dono único de todo rename e formatação de data wire. A cascata:The transaction is orchestrated by the call_task_detail notifier (remote-first, §36). The notifier only gathers raw entities and the new date; the builder is the sole owner of every rename and wire date formatting. The cascade:La transacción se orquesta desde el notifier de call_task_detail (remote-first, §36). El notifier solo reúne entities crudas y la nueva fecha; el builder es el dueño único de todo rename y formateo de fecha wire. La cascada:

CallTaskDetailNotifierreschedule()
- reúne entities cruas + nova datagathers raw entities + new datereúne entities crudas + nueva fechaRescheduleCallTaskDispatcherPayloadInput
  - build()BuildRescheduleCallTaskDispatcherPayloadUseCasemonta o wireassembles the wirearma el wire
    - devolvereturnsdevuelveDispatcherEnvelope
      - SubmitRescheduleCallTaskUseCaseDispatcherRepository
        
        serializa + authserialize + authserializa + authDispatcherGateway
        
        sendTransactionBackendgRPC

Após o ack de sucesso, o notifier chama RescheduleCallTaskUseCase.execute(...) para atualizar o cache local (a call task passa a mostrar a nova data) — write remote-first, cache depois.After the success ack, the notifier calls RescheduleCallTaskUseCase.execute(...) to update the local cache (the call task now shows the new date) — remote-first write, cache after.Tras el ack de éxito, el notifier llama a RescheduleCallTaskUseCase.execute(...) para actualizar el cache local (la call task pasa a mostrar la nueva fecha) — write remote-first, cache después.

O input (entities cruas)The input (raw entities)El input (entities crudas)

RescheduleCallTaskDispatcherPayloadInput (Freezed). Carrega o dado como existe no domínio; nada de formato wire. O relógio chega como submittedAt (via DateTimeUtils.now()).RescheduleCallTaskDispatcherPayloadInput (Freezed). Carries data as it exists in the domain; no wire shaping. The clock arrives as submittedAt (via DateTimeUtils.now()).RescheduleCallTaskDispatcherPayloadInput (Freezed). Lleva el dato como existe en el dominio; nada de formato wire. El reloj llega como submittedAt (vía DateTimeUtils.now()).

CampoFieldCampo	TipoTypeTipo	PapelRoleRol
`callTask`	`CallTaskEntity`	call task crua — o builder deriva `id_call_task_visit` e `call_task_visit_original_date`raw call task — the builder derives `id_call_task_visit` and `call_task_visit_original_date`call task cruda — el builder deriva `id_call_task_visit` y `call_task_visit_original_date`
`visitSfid`	`String`	→ `sfid_visit_current`
`newDate`	`DateTime`	→ `rescheduling_visit_date` e `dateReference`; a data escolhida no seletor→ `rescheduling_visit_date` and `dateReference`; the date chosen in the picker→ `rescheduling_visit_date` y `dateReference`; la fecha elegida en el selector
`resource`	`ResourceEntity`	representante de vendas (cru — o builder deriva `sfid_rep`)sales rep (raw — the builder derives `sfid_rep`)representante de ventas (crudo — el builder deriva `sfid_rep`)
`submittedAt`	`DateTime`	relógio injetado (`DateTimeUtils.now()`); não usado pelo `build()` atual — ver Pendênciasinjected clock (`DateTimeUtils.now()`); not used by the current `build()` — see Pendingreloj inyectado (`DateTimeUtils.now()`); no usado por el `build()` actual — ver Pendientes

Payload (`message`)

O JSON serializado no campo message do request. Cada tabela abaixo tem 4 colunas — Campo JSON · Tipo · Origem do Dado · Regra — e lista toda chave que o build() emite (5 no total). 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. Each table below has 4 columns — JSON field · Type · Data source · Rule — and lists every key that build() emits (5 in total). 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. Cada tabla abajo tiene 4 columnas — Campo JSON · Tipo · Origen del Dato · Regla — y lista toda clave que build() emite (5 en total). 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.

Raiz do payloadPayload rootRaíz del payload

Campo JSON	TipoTypeTipo	Origem do DadoData sourceOrigen del Dato	RegraRuleRegla
`ReschedulingCallTask`	array	`Calculado`	array de um único objeto (o reagendamento)single-element array (the reschedule)array de un solo objeto (la reprogramación)

ReschedulingCallTask objeto únicosingle objectobjeto único 5 camposfieldscampos

Campo JSON	TipoTypeTipo	Origem do DadoData sourceOrigen del Dato	RegraRuleRegla
`sfid_visit_current`	string	`input.visitSfid`	SFID da visita à qual a call task pertenceSFID of the visit the call task belongs toSFID de la visita a la que pertenece la call task
`rescheduling_visit_date`	string	`input.newDate`	nova data, formato `yyyy-MM-dd HH:mm:ss` (`DateFormatType.isoDateTime`)new date, `yyyy-MM-dd HH:mm:ss` format (`DateFormatType.isoDateTime`)nueva fecha, formato `yyyy-MM-dd HH:mm:ss` (`DateFormatType.isoDateTime`)
`sfid_rep`	string	`input.resource.sfid`	SFID do representante de vendassales rep SFIDSFID del representante de ventas
`id_call_task_visit`	string	`callTask.id`	id da call task sendo reagendadaid of the call task being rescheduledid de la call task siendo reprogramada
`call_task_visit_original_date`	string	`callTask.originalDate`	`originalDate == null ? "" : formatDate(yyyy-MM-dd)` — data original antes do reagendamento; string vazia quando ausente`originalDate == null ? "" : formatDate(yyyy-MM-dd)` — original date before the reschedule; empty string when absent`originalDate == null ? "" : formatDate(yyyy-MM-dd)` — fecha original antes de la reprogramación; string vacía cuando ausente

Dois formatos de dataTwo date formatsDos formatos de fecha A nova data vai em dois lugares com formatos diferentes: rescheduling_visit_date no payload usa isoDateTime (yyyy-MM-dd HH:mm:ss), enquanto o dateReference do envelope usa isoDate (yyyy-MM-dd). A call_task_visit_original_date também usa isoDate. The new date goes into two places with different formats: rescheduling_visit_date in the payload uses isoDateTime (yyyy-MM-dd HH:mm:ss), while the envelope's dateReference uses isoDate (yyyy-MM-dd). call_task_visit_original_date also uses isoDate. La nueva fecha va a dos lugares con formatos diferentes: rescheduling_visit_date en el payload usa isoDateTime (yyyy-MM-dd HH:mm:ss), mientras el dateReference del envelope usa isoDate (yyyy-MM-dd). call_task_visit_original_date también usa isoDate.

Regras de negócioBusiness rulesReglas de negocio

transactionReference = callTask.id: O envelope correlaciona o envio pelo id da call task, não pela visita.The envelope correlates the send by the call task id, not by the visit.El envelope correlaciona el envío por el id de la call task, no por la visita.
Sem prefixo Promo_No Promo_ prefixSin prefijo Promo_: O builder chama resolveServiceName(hasPromotion: false) fixo — reagendamento nunca carrega promoção.The builder calls a fixed resolveServiceName(hasPromotion: false) — a reschedule never carries a promotion.El builder llama a un resolveServiceName(hasPromotion: false) fijo — una reprogramación nunca lleva promoción.
call_task_visit_original_date tolera nullcall_task_visit_original_date tolerates nullcall_task_visit_original_date tolera null: Quando a call task não tem originalDate, o campo é emitido como string vazia (""), nunca ausente.When the call task has no originalDate, the field is emitted as an empty string (""), never absent.Cuando la call task no tiene originalDate, el campo se emite como string vacía (""), nunca ausente.
Guardas do notifierNotifier guardsGuardas del notifier: O envio só ocorre se state.canReschedule (não está submetendo) e se o currentResourceProvider resolveu um representante — sem representante, o notifier marca falha e não dispara.The send only happens if state.canReschedule (not already submitting) and if currentResourceProvider resolved a rep — without a rep, the notifier flags failure and doesn't fire.El envío solo ocurre si state.canReschedule (no está enviando) y si currentResourceProvider resolvió un representante — sin representante, el notifier marca falla y no dispara.
Cache após sucessoCache after successCache tras éxito: Só depois do ack de sucesso o cache local é atualizado (originalDate ← newDate); a call task segue pendente, só a data muda.Only after the success ack is the local cache updated (originalDate ← newDate); the call task stays pending, only the date changes.Solo tras el ack de éxito se actualiza el cache local (originalDate ← newDate); la call task sigue pendiente, solo cambia la fecha.

Pendências / roadmapPending / roadmapPendientes / roadmap

A alinhar com o backendTo align with backendA alinear con backend O payload envia uma data livre escolhida no seletor: não há um sfid de visita de destino do reagendamento — o backend recebe apenas a data e a visita atual. O contrato de para onde a call task é efetivamente movida ainda precisa ser alinhado com o StreamBridge / backend (ver memória project_call_task_feature). The payload sends a free date picked in the selector: there's no target visit sfid for the reschedule — the backend only gets the date and the current visit. The contract for where the call task is actually moved to still needs to be aligned with StreamBridge / backend (see memory project_call_task_feature). El payload envía una fecha libre elegida en el selector: no hay un sfid de visita destino de la reprogramación — el backend solo recibe la fecha y la visita actual. El contrato de a dónde se mueve efectivamente la call task aún debe alinearse con StreamBridge / backend (ver memoria project_call_task_feature).

submittedAt inerteinertinerte O input carrega submittedAt (relógio injetado pelo notifier via DateTimeUtils.now()), mas o build() atual não o consome — todas as datas do payload derivam de newDate e originalDate. O campo segue o padrão §36 (relógio injetado como DateTime) e fica disponível caso o contrato passe a exigir a data de submissão. The input carries submittedAt (a clock injected by the notifier via DateTimeUtils.now()), but the current build() doesn't consume it — all payload dates derive from newDate and originalDate. The field follows the §36 pattern (clock injected as a DateTime) and stays available in case the contract starts requiring the submission date. El input lleva submittedAt (reloj inyectado por el notifier vía DateTimeUtils.now()), pero el build() actual no lo consume — todas las fechas del payload derivan de newDate y originalDate. El campo sigue el patrón §36 (reloj inyectado como DateTime) y queda disponible por si el contrato pasa a exigir la fecha de envío.

★

MercadosMarketsMercados

A disponibilidade da transação vem do DispatcherType.reschedulingCallTask.enabledMarkets = [BR, CL, ZA]. A feature Call Task está ativa (ModuleType.visitDetailCallTask) nesses três mercados. AR/PY/PE não têm dispatcher de call task (config PANGEA mínima).Transaction availability comes from DispatcherType.reschedulingCallTask.enabledMarkets = [BR, CL, ZA]. The Call Task feature is active (ModuleType.visitDetailCallTask) in those three markets. AR/PY/PE have no call task dispatcher (minimal PANGEA config).La disponibilidad de la transacción viene de DispatcherType.reschedulingCallTask.enabledMarkets = [BR, CL, ZA]. La feature Call Task está activa (ModuleType.visitDetailCallTask) en esos tres mercados. AR/PY/PE no tienen dispatcher de call task (config PANGEA mínima).

BRx CLx ZAx AR— PY— PE—

disponívelavailabledisponible presente, desligadopresent, offpresente, apagado ausenteabsentausente

BRCLZA

Comportamento idênticoIdentical behaviorComportamiento idéntico O payload não tem nenhum ramo por mercado — os cinco campos são iguais em BR, CL e ZA. A diferença entre mercados está só na disponibilidade da feature, não no conteúdo do envio. The payload has no per-market branch — the five fields are the same in BR, CL and ZA. The difference between markets is only in feature availability, not in the send's content. El payload no tiene ninguna rama por mercado — los cinco campos son iguales en BR, CL y ZA. La diferencia entre mercados está solo en la disponibilidad de la feature, no en el contenido del envío.

AR · PY · PE Existem como mercados do app (config PANGEA mínima), mas não têm dispatcher de call task — reschedulingCallTask.enabledMarkets não os lista. O reagendamento não é disparado nesses mercados. They exist as app markets (minimal PANGEA config), but have no call task dispatcher — reschedulingCallTask.enabledMarkets doesn't list them. The reschedule is not fired in these markets. Existen como mercados de la app (config PANGEA mínima), pero no tienen dispatcher de call task — reschedulingCallTask.enabledMarkets no los lista. La reprogramación no se dispara en estos mercados.