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

Solicitação de ajuda/suporteHelp & support requestSolicitud de ayuda/soporte

A transação de escrita que envia ao backend uma solicitação de ajuda/suporte aberta pelo representante de vendas — um assunto escolhido e uma descrição em texto livre. Um único builder monta um payload JSON de uma única variante com o assunto, a descrição, o sfid do rep e, em alguns mercados, o nome de usuário. Toda a construção do contrato wire vive no builder. The write transaction that sends the backend a help/support request opened by the sales rep — a chosen subject and a free-text description. A single builder assembles a JSON payload of one single variant carrying the subject, description, the rep's sfid and, in some markets, the username. All wire-contract construction lives in the builder. La transacción de escritura que envía al backend una solicitud de ayuda/soporte abierta por el representante de ventas — un asunto elegido y una descripción en texto libre. Un único builder arma un payload JSON de una única variante con el asunto, la descripción, el sfid del rep y, en algunos mercados, el nombre de usuario. Toda la construcción del contrato wire vive en el builder.

PúblicoAudiencePúblico

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

CamadaLayerCapa

Escrita · DispatcherWrite · DispatcherEscritura · Dispatcher

RelacionadoRelatedRelacionado

FAQ

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

Quando o representante de vendas precisa de ajuda ou suporte — reportar um problema no app, tirar uma dúvida, pedir apoio — ele abre uma solicitação de suporte a partir da tela de FAQ / Ajuda. Ele escolhe um assunto na lista, escreve uma descrição do que precisa e envia. É este envio que registra a solicitação no backend, para que a equipe de suporte a receba. When the sales rep needs help or support — to report an app issue, ask a question, request assistance — they open a support request from the FAQ / Help screen. They pick a subject from the list, write a description of what they need and send it. This send is what records the request in the backend, so the support team receives it. Cuando el representante de ventas necesita ayuda o soporte — reportar un problema en la app, hacer una consulta, pedir apoyo — abre una solicitud de soporte desde la pantalla de FAQ / Ayuda. Elige un asunto de la lista, escribe una descripción de lo que necesita y la envía. Este envío es lo que registra la solicitud en el backend, para que el equipo de soporte la reciba.

Uma solicitação é feita de três partes:A request is made of three parts:Una solicitud está hecha de tres partes:

AssuntoSubjectAsunto

O rep escolhe um assunto pré-definido para a solicitação (ex.: pedido, pagamento, app).The rep picks a predefined subject for the request (e.g. orders, payment, app).El rep elige un asunto predefinido para la solicitud (p. ej. pedidos, pago, app).

DescriçãoDescriptionDescripción

Um texto livre onde o rep descreve o problema ou o pedido de ajuda.A free-text field where the rep describes the problem or the help request.Un texto libre donde el rep describe el problema o el pedido de ayuda.

IdentificaçãoIdentificationIdentificación

O rep é sempre identificado pelo seu sfid; em alguns mercados o nome de usuário também é anexado.The rep is always identified by their sfid; in some markets the username is also attached.El rep siempre se identifica por su sfid; en algunos mercados el nombre de usuario también se adjunta.

Onde aconteceWhere it happensDónde ocurre A solicitação parte da tela de FAQ / Ajuda, na área de contato/suporte. Não há anexo nem arquivo: a solicitação é só texto (assunto + descrição). The request starts from the FAQ / Help screen, in the contact/support area. There's no attachment or file: the request is text only (subject + description). La solicitud parte de la pantalla de FAQ / Ayuda, en el área de contacto/soporte. No hay adjunto ni archivo: la solicitud es solo texto (asunto + descripción).

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

O envio é o último passo de abrir uma solicitação de suporte. As telas do caminho pertencem à feature de FAQ / Ajuda; aqui só situamos onde o envio acontece:The send is the last step of opening a support request. The screens along the way belong to the FAQ / Help feature; here we only place where the send happens:El envío es el último paso de abrir una solicitud de soporte. Las pantallas del camino pertenecen a la feature de FAQ / Ayuda; aquí solo situamos dónde ocurre el envío:

FAQ / AjudaFAQ / HelpFAQ / AyudaO rep abre a tela de FAQ / Ajuda e vai até a área de contato/suporte.The rep opens the FAQ / Help screen and goes to the contact/support area.El rep abre la pantalla de FAQ / Ayuda y va al área de contacto/soporte.
Escolher o assuntoPick the subjectElegir el asuntoAbre o seletor de assuntos e escolhe um da lista.Opens the subject picker and chooses one from the list.Abre el selector de asuntos y elige uno de la lista.
Escrever a descriçãoWrite the descriptionEscribir la descripciónDescreve o problema ou o pedido de ajuda no campo de texto.Describes the problem or help request in the text field.Describe el problema o el pedido de ayuda en el campo de texto.
Enviar → esta transaçãoSend → this transactionEnviar → esta transacciónAo tocar em enviar, o app dispara a Solicitação de ajuda/suporte. É este toque que aciona a transação.Tapping send, the app fires the Help & support request. This tap is what triggers the transaction.Al tocar enviar, la app dispara la Solicitud de ayuda/soporte. Este toque es lo que activa la transacción.

Botão de envio ativa por validaçãoSend enabled by validationEnvío habilitado por validación O envio só é permitido quando há um assunto escolhido e a descrição não está vazia. Enquanto faltar um dos dois, o botão de enviar fica indisponível. The send is only allowed when a subject is chosen and the description isn't empty. While either is missing, the send button stays disabled. El envío solo se permite cuando hay un asunto elegido y la descripción no está vacía. Mientras falte uno de los dos, el botón de enviar queda deshabilitado.

Depois do envioAfter sendingDespués del envío

Confirmação ao repConfirmation to the repConfirmación al rep: Quando o backend aceita, o rep recebe a confirmação de que a solicitação foi enviada; depois de um breve instante a tela limpa o assunto e a descrição, pronta para uma nova solicitação.When the backend accepts it, the rep gets a confirmation that the request was sent; after a brief moment the screen clears the subject and description, ready for a new request.Cuando el backend lo acepta, el rep recibe la confirmación de que la solicitud fue enviada; tras un breve instante la pantalla limpia el asunto y la descripción, lista para una nueva solicitud.
Sem internetOfflineSin internet: O envio pode entrar em fila e ser reenviado quando a conexão volta — a solicitação não se perde. O sistema usa um identificador de transação para evitar duplicidade em reenvios.The send may be queued and retried when the connection returns — the request isn't lost. The system uses a transaction id to avoid duplicates on retries.El envío puede quedar en cola y reintentarse cuando vuelve la conexión — la solicitud no se pierde. El sistema usa un identificador de transacción para evitar duplicados en los reenvíos.
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

Solicitação de ajuda/suporte é a transação de saída que envia ao backend uma solicitação de suporte aberta pelo rep. É disparada pelo notifier de FAQ. Uma única variante — não há campo de tipo, não há prefixo Promo_ — com destino batchApi. Help & support request is the outbound transaction that sends the backend a support request opened by the rep. It's fired by the FAQ notifier. A single variant — no type field, no Promo_ prefix — with batchApi destination. Solicitud de ayuda/soporte es la transacción de salida que envía al backend una solicitud de soporte abierta por el rep. Se dispara desde el notifier de FAQ. Una única variante — sin campo de tipo, sin prefijo Promo_ — con destino batchApi.

Payload enxutoLean payloadPayload reducido

Um único objeto support com até 5 campos: data, assunto, descrição, sfid do rep e (condicional) nome de usuário.A single support object with up to 5 fields: date, subject, description, rep sfid and (conditional) username.Un único objeto support con hasta 5 campos: fecha, asunto, descripción, sfid del rep y (condicional) nombre de usuario.

Só texto, sem anexoText only, no attachmentSolo texto, sin adjunto

Não há foto, arquivo nem base64: o builder só encaminha o texto do assunto e da descrição, mais a identificação do rep.No photo, file or base64: the builder only forwards the subject and description text, plus the rep identification.No hay foto, archivo ni base64: el builder solo reenvía el texto del asunto y la descripción, más la identificación del rep.

RPC genéricoGeneric RPCRPC genérico

Não há RPC por solicitação: tudo passa pelo mesmo sendTransaction, com o JSON serializado em message e serviceName = SupportRequestAPI.There's no per-request RPC: everything goes through the same sendTransaction, with the JSON serialized into message and serviceName = SupportRequestAPI.No hay RPC por solicitud: todo pasa por el mismo sendTransaction, con el JSON serializado en message y serviceName = SupportRequestAPI.

FontesSourcesFuentes BuildHelpSupportDispatcherPayloadUseCase + HelpSupportDispatcherPayloadInput + DispatcherType.helpSupport + DispatcherConectaRep.proto. O input carrega entities cruas de domínio (CLAUDE.md §36); o build() constrói todo o wire. BuildHelpSupportDispatcherPayloadUseCase + HelpSupportDispatcherPayloadInput + DispatcherType.helpSupport + DispatcherConectaRep.proto. The input carries raw domain entities (CLAUDE.md §36); build() constructs the entire wire. BuildHelpSupportDispatcherPayloadUseCase + HelpSupportDispatcherPayloadInput + DispatcherType.helpSupport + 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), o endpoint (destino) 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), the endpoint (destination) 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), el endpoint (destino) 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 · destino "sfbatchapi" (type.destination.value = batchApi)destination "sfbatchapi" (type.destination.value = batchApi)destino "sfbatchapi" (type.destination.value = batchApi)
serviceName: string · #2 · discriminador — SupportRequestAPI (sem prefixo Promo_: hasPromotion é sempre false)discriminator — SupportRequestAPI (no Promo_ prefix: hasPromotion is always false)discriminador — SupportRequestAPI (sin prefijo Promo_: hasPromotion siempre es false)
dateReference: string · #3 · AAAA-MM-DD do envio (input.submittedAt)YYYY-MM-DD of the submission (input.submittedAt)AAAA-MM-DD del envío (input.submittedAt)
transactionReference: string · #4 · input.transactionReference (correlação; gerado por DispatcherUtils.generateTransactionReference())input.transactionReference (correlation; generated by DispatcherUtils.generateTransactionReference())input.transactionReference (correlación; generado por DispatcherUtils.generateTransactionReference())
username: string · #5 · do resource.username no gateway (campo do transporte; independe da chave userName do payload)from resource.username in the gateway (transport field; independent of the payload's userName key)de resource.username en el gateway (campo del transporte; independiente de la clave userName del payload)
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 · literal provisório "REP" hoje (ver Pendências)provisional literal "REP" today (see Pending)literal provisional "REP" hoy (ver Pendientes)
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, resolve endpoint de type.destination.value, copia serviceName/dateReference/transactionReference, preenche os campos de dispositivo e o bearer token de auth, e chama o RPC. Para esta transação account e visitDispatchKind do envelope ficam null. The builder returns a DispatcherEnvelope (type, serviceName, payload, transactionReference, dateReference). The DispatcherGateway serializes payload to JSON into message, resolves endpoint from type.destination.value, copies serviceName/dateReference/transactionReference, fills in the device fields and the auth bearer token, and calls the RPC. For this transaction the envelope's account and visitDispatchKind stay null. El builder devuelve un DispatcherEnvelope (type, serviceName, payload, transactionReference, dateReference). El DispatcherGateway serializa payload a JSON en message, resuelve endpoint de type.destination.value, copia serviceName/dateReference/transactionReference, completa los campos del dispositivo y el bearer token de auth, y llama al RPC. Para esta transacción el account y el visitDispatchKind del envelope quedan null.

O destino é DispatcherDestination.batchApi (endpoint = "sfbatchapi"): a solicitação entra no lote de despachos (batch) e é enviada pelo mesmo sendTransaction, junto de outras transações do lote. Como helpSupport não está no conjunto lightweight, resendMayDuplicate == true: um reenvio pode, em tese, duplicar; a idempotência via tid é o que mitiga isso.The destination is DispatcherDestination.batchApi (endpoint = "sfbatchapi"): the request joins the dispatch batch and is sent through the same sendTransaction, alongside other batched transactions. Since helpSupport isn't in the lightweight set, resendMayDuplicate == true: a resend could, in theory, duplicate; idempotency via tid is what mitigates it.El destino es DispatcherDestination.batchApi (endpoint = "sfbatchapi"): la solicitud entra en el lote de despachos (batch) y se envía por el mismo sendTransaction, junto a otras transacciones del lote. Como helpSupport no está en el conjunto lightweight, resendMayDuplicate == true: un reenvío podría, en teoría, duplicar; la idempotencia vía tid es lo que lo mitiga.

serviceName

Uma única variante — um só DispatcherType, um só serviceName. Não há campo de tipo no input e não há prefixo Promo_ (o builder chama type.resolveServiceName(hasPromotion: false) fixo).A single variant — one DispatcherType, one serviceName. There's no type field on the input and no Promo_ prefix (the builder calls type.resolveServiceName(hasPromotion: false) fixed).Una única variante — un solo DispatcherType, un solo serviceName. No hay campo de tipo en el input y no hay prefijo Promo_ (el builder llama type.resolveServiceName(hasPromotion: false) fijo).

`DispatcherType`	`serviceName`	DestinoDestinationDestino	MercadosMarketsMercados
`helpSupport`	`SupportRequestAPI`	`batchApi` (`"sfbatchapi"`)	BR · CL · ZA

Como é disparadoHow it's firedCómo se dispara

A transação é disparada pelo notifier de FAQ (FaqNotifier.submitSupportMessage()), acionado pelo botão de enviar da tela de FAQ / Ajuda. O notifier apenas reúne entities cruas e valores injetados; o builder é o dono único de todo rename, formatação de data e derivação wire. A cascata:The transaction is fired by the FAQ notifier (FaqNotifier.submitSupportMessage()), triggered by the send button on the FAQ / Help screen. The notifier only gathers raw entities and injected values; the builder is the sole owner of every rename, date formatting and wire derivation. The cascade:La transacción se dispara desde el notifier de FAQ (FaqNotifier.submitSupportMessage()), accionado por el botón de enviar de la pantalla de FAQ / Ayuda. El notifier solo reúne entities crudas y valores inyectados; el builder es el dueño único de todo rename, formateo de fecha y derivación wire. La cascada:

FaqNotifiersubmitSupportMessage()
- reúne resource + subject + description + sendsUserNamegathers resource + subject + description + sendsUserNamereúne resource + subject + description + sendsUserNameHelpSupportDispatcherPayloadInput
  - build()BuildHelpSupportDispatcherPayloadUseCasemonta o wireassembles the wirearma el wire
    - devolvereturnsdevuelveDispatcherEnvelope
      - SubmitHelpSupportUseCaseDispatcherOrchestrator
        
        serializa + authserialize + authserializa + authDispatcherGateway
        
        sendTransactionBackendgRPC

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

HelpSupportDispatcherPayloadInput (Freezed). Carrega o dado como existe no domínio; nada de formato wire. O relógio chega como submittedAt (via DateTimeUtils.now()); o transactionReference é gerado no notifier (DispatcherUtils.generateTransactionReference()); sendsUserName vem do EMC (marketConfig.faqConfig.sendsUserName).HelpSupportDispatcherPayloadInput (Freezed). Carries data as it exists in the domain; no wire shaping. The clock arrives as submittedAt (via DateTimeUtils.now()); transactionReference is generated in the notifier (DispatcherUtils.generateTransactionReference()); sendsUserName comes from the EMC (marketConfig.faqConfig.sendsUserName).HelpSupportDispatcherPayloadInput (Freezed). Lleva el dato como existe en el dominio; nada de formato wire. El reloj llega como submittedAt (vía DateTimeUtils.now()); el transactionReference se genera en el notifier (DispatcherUtils.generateTransactionReference()); sendsUserName viene del EMC (marketConfig.faqConfig.sendsUserName).

CampoFieldCampo	TipoTypeTipo	PapelRoleRol
`resource`	`ResourceEntity`	representante de vendas (cru — o builder deriva `resourceSfid` primary/secondary e o `userName`)sales rep (raw — the builder derives `resourceSfid` primary/secondary and `userName`)representante de ventas (crudo — el builder deriva `resourceSfid` primary/secondary y el `userName`)
`subject`	`SupportSubjectEntity`	assunto escolhido (`id` + `subject`); o payload usa o texto `subject.subject`)chosen subject (`id` + `subject`); the payload uses the text `subject.subject`)asunto elegido (`id` + `subject`); el payload usa el texto `subject.subject`)
`description`	`String`	descrição livre do rep (o builder aplica `.trim()`)rep's free-text description (the builder applies `.trim()`)descripción libre del rep (el builder aplica `.trim()`)
`sendsUserName`	`bool`	de `marketConfig.faqConfig.sendsUserName` — decide se a chave `userName` entra no payloadfrom `marketConfig.faqConfig.sendsUserName` — decides whether the `userName` key enters the payloadde `marketConfig.faqConfig.sendsUserName` — decide si la clave `userName` entra en el payload
`submittedAt`	`DateTime`	relógio injetado (`DateTimeUtils.now()`) — vira `date` e `dateReference`injected clock (`DateTimeUtils.now()`) — becomes `date` and `dateReference`reloj inyectado (`DateTimeUtils.now()`) — se vuelve `date` y `dateReference`
`transactionReference`	`String`	correlação do despacho (`DispatcherUtils.generateTransactionReference()`)dispatch correlation (`DispatcherUtils.generateTransactionReference()`)correlación del despacho (`DispatcherUtils.generateTransactionReference()`)

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 (1 na raiz + 5 no objeto support, sendo 4 sempre + 1 condicional = 6). 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 (1 at the root + 5 in the support object, being 4 always + 1 conditional = 6). 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 (1 en la raíz + 5 en el objeto support, siendo 4 siempre + 1 condicional = 6). 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
`support`	object	`{support}`	objeto único com os dados da solicitaçãosingle object with the request dataobjeto único con los datos de la solicitud

support objeto únicosingle objectobjeto único 5 camposfieldscampos

Campo JSON	TipoTypeTipo	Origem do DadoData sourceOrigen del Dato	RegraRuleRegla
`date`	string	`input.submittedAt`	formato `yyyy-MM-dd HH:mm:ss` (`DateFormatType.isoDateTime`) — sempre`yyyy-MM-dd HH:mm:ss` format (`DateFormatType.isoDateTime`) — alwaysformato `yyyy-MM-dd HH:mm:ss` (`DateFormatType.isoDateTime`) — siempre
`subject`	string	`input.subject.subject`	o texto do assunto escolhido (não o `id`) — semprethe chosen subject's text (not the `id`) — alwaysel texto del asunto elegido (no el `id`) — siempre
`description`	string	`input.description`	`.trim()` aplicado (remove espaços nas pontas) — sempre`.trim()` applied (strips edge whitespace) — always`.trim()` aplicado (quita espacios en los bordes) — siempre
`resourceSfid`	string	`resource`	`isPrimaryResource ? primaryResourceSfid : secondaryResourceSfid` — sempre`isPrimaryResource ? primaryResourceSfid : secondaryResourceSfid` — always`isPrimaryResource ? primaryResourceSfid : secondaryResourceSfid` — siempre
`userName`	string	`resource.username`	condicional — a chave só existe quando `input.sendsUserName` é `true` (de `marketConfig.faqConfig.sendsUserName`)conditional — the key exists only when `input.sendsUserName` is `true` (from `marketConfig.faqConfig.sendsUserName`)condicional — la clave solo existe cuando `input.sendsUserName` es `true` (de `marketConfig.faqConfig.sendsUserName`)

Regras de negócioBusiness rulesReglas de negocio

Assunto e descriçãoSubject & descriptionAsunto y descripción subject.subject · description.trim()

subject no payload é o texto do assunto (SupportSubjectEntity.subject), não o id. O rep escolhe da lista de assuntos; o notifier resolve a SupportSubjectEntity pelo id selecionado.The payload's subject is the subject text (SupportSubjectEntity.subject), not the id. The rep picks from the subject list; the notifier resolves the SupportSubjectEntity by the selected id.El subject del payload es el texto del asunto (SupportSubjectEntity.subject), no el id. El rep elige de la lista de asuntos; el notifier resuelve la SupportSubjectEntity por el id seleccionado.
description passa por .trim() no builder — os espaços nas pontas são removidos. A validação do formulário (assunto escolhido + descrição não vazia após trim) acontece no notifier/state (isSubmissionFormValid) antes do envio.description goes through .trim() in the builder — edge whitespace is stripped. Form validation (subject chosen + non-empty trimmed description) happens in the notifier/state (isSubmissionFormValid) before sending.description pasa por .trim() en el builder — los espacios en los bordes se quitan. La validación del formulario (asunto elegido + descripción no vacía tras trim) ocurre en el notifier/state (isSubmissionFormValid) antes del envío.

Identificação condicionalConditional identificationIdentificación condicional userName · sendsUserName · EMC

resourceSfid é sempre emitido: primary vs secondary decidido por resource.isPrimaryResource — o builder deriva o sfid do rep (nunca pré-resolvido no notifier, §25/§36).resourceSfid is always emitted: primary vs secondary decided by resource.isPrimaryResource — the builder derives the rep sfid (never pre-resolved in the notifier, §25/§36).resourceSfid se emite siempre: primary vs secondary decidido por resource.isPrimaryResource — el builder deriva el sfid del rep (nunca pre-resuelto en el notifier, §25/§36).
A chave userName é condicional: só aparece quando input.sendsUserName é true. Esse flag vem do End Market Configuration (marketConfig.faqConfig.sendsUserName) — é o único ponto que decide se o nome de usuário do rep acompanha a solicitação.The userName key is conditional: it only appears when input.sendsUserName is true. That flag comes from the End Market Configuration (marketConfig.faqConfig.sendsUserName) — it's the single point that decides whether the rep's username accompanies the request.La clave userName es condicional: solo aparece cuando input.sendsUserName es true. Ese flag viene del End Market Configuration (marketConfig.faqConfig.sendsUserName) — es el único punto que decide si el nombre de usuario del rep acompaña la solicitud.
O campo username do transporte (request do gateway) é independente: vem sempre de resource.username no gateway, mesmo quando a chave userName do payload está ausente.The transport's username field (gateway request) is independent: it always comes from resource.username in the gateway, even when the payload's userName key is absent.El campo username del transporte (request del gateway) es independiente: viene siempre de resource.username en el gateway, incluso cuando la clave userName del payload está ausente.

Datas e serviceNameDates & serviceNameFechas y serviceName date · dateReference · SupportRequestAPI

date (dentro de support) usa DateFormatType.isoDateTime (yyyy-MM-dd HH:mm:ss); o dateReference do envelope/transporte usa o default DateFormatType.isoDate (yyyy-MM-dd). Ambos vêm do mesmo input.submittedAt. Toda formatação de data passa pelo DateTimeUtils (§14).date (inside support) uses DateFormatType.isoDateTime (yyyy-MM-dd HH:mm:ss); the envelope/transport dateReference uses the default DateFormatType.isoDate (yyyy-MM-dd). Both come from the same input.submittedAt. All date formatting goes through DateTimeUtils (§14).date (dentro de support) usa DateFormatType.isoDateTime (yyyy-MM-dd HH:mm:ss); el dateReference del envelope/transporte usa el default DateFormatType.isoDate (yyyy-MM-dd). Ambos vienen del mismo input.submittedAt. Todo formateo de fecha pasa por DateTimeUtils (§14).
serviceName: fixo SupportRequestAPI — o builder chama type.resolveServiceName(hasPromotion: false), então nunca há prefixo Promo_.serviceName: fixed SupportRequestAPI — the builder calls type.resolveServiceName(hasPromotion: false), so there's never a Promo_ prefix.serviceName: fijo SupportRequestAPI — el builder llama type.resolveServiceName(hasPromotion: false), así que nunca hay prefijo Promo_.

Pendências / roadmapPending / roadmapPendientes / roadmap

O que o builder ainda não preenche ou envia inerte, documentado fiel ao estado atual do código (nunca descrito como se já existisse):What the builder does not yet fill, or ships inert, documented faithfully to the current code state (never described as already existing):Lo que el builder aún no completa, o envía inerte, documentado fiel al estado actual del código (nunca descrito como si ya existiera):

Não portado / pendenteNot ported / pendingNo portado / pendiente

Sem anexos: a solicitação é só texto (assunto + descrição). Não há foto, arquivo nem base64 no payload — diferente de outras transações de suporte/evidência.No attachments: the request is text only (subject + description). There's no photo, file or base64 in the payload — unlike other support/evidence transactions.Sin adjuntos: la solicitud es solo texto (asunto + descripción). No hay foto, archivo ni base64 en el payload — a diferencia de otras transacciones de soporte/evidencia.
Sem campo de tipo/variante e sem suporte a Promo_: hasPromotion é sempre false no build().No type/variant field and no Promo_ support: hasPromotion is always false in build().Sin campo de tipo/variante y sin soporte a Promo_: hasPromotion siempre es false en build().
account e visitDispatchKind do DispatcherEnvelope ficam null: a solicitação não é vinculada a uma conta nem a uma visita.account and visitDispatchKind on the DispatcherEnvelope stay null: the request is not tied to an account or a visit.account y visitDispatchKind del DispatcherEnvelope quedan null: la solicitud no se vincula a una cuenta ni a una visita.
Transporte: deviceUuid vai como literal provisório "REP" no gateway (pendência conhecida do Dispatcher, comum a todas as transações).Transport: deviceUuid ships as the provisional literal "REP" in the gateway (known Dispatcher pending item, common to all transactions).Transporte: deviceUuid va como literal provisional "REP" en el gateway (pendiente conocido del Dispatcher, común a todas las transacciones).

Feature donaOwning featureFeature dueña O envio parte da FAQ / Ajuda (área de contato/suporte) — veja essa feature para o contexto de UI. The send comes from FAQ / Help (contact/support area) — see that feature for the UI context. El envío parte de FAQ / Ayuda (área de contacto/soporte) — vea esa feature para el contexto de UI.

★

MercadosMarketsMercados

A disponibilidade da transação vem do DispatcherType.helpSupport.enabledMarkets — BR/CL/ZA. A estrutura do payload é uniforme; a única variação por mercado é a presença da chave userName, dirigida pelo EMC (faqConfig.sendsUserName). AR/PY/PE não têm esta transação.Transaction availability comes from DispatcherType.helpSupport.enabledMarkets — BR/CL/ZA. The payload structure is uniform; the only per-market variation is the presence of the userName key, driven by the EMC (faqConfig.sendsUserName). AR/PY/PE don't have this transaction.La disponibilidad de la transacción viene de DispatcherType.helpSupport.enabledMarkets — BR/CL/ZA. La estructura del payload es uniforme; la única variación por mercado es la presencia de la clave userName, dirigida por el EMC (faqConfig.sendsUserName). AR/PY/PE no tienen esta transacción.

BRx CLx ZAx AR— PY— PE—

disponívelavailabledisponible presente, desligadopresent, offpresente, apagado ausenteabsentausente

BRCLZA

Mesmo contratoSame contractMismo contrato Nos três mercados o payload tem a mesma forma — o objeto support, o mesmo serviceName e o mesmo destino batchApi. A única diferença possível é a chave userName, presente só onde faqConfig.sendsUserName é true no EMC daquele mercado. In all three markets the payload has the same shape — the support object, the same serviceName and the same batchApi destination. The only possible difference is the userName key, present only where faqConfig.sendsUserName is true in that market's EMC. En los tres mercados el payload tiene la misma forma — el objeto support, el mismo serviceName y el mismo destino batchApi. La única diferencia posible es la clave userName, presente solo donde faqConfig.sendsUserName es true en el EMC de ese mercado.

AR · PY · PE Existem como mercados do app (config PANGEA mínima), mas não têm esta transação — enabledMarkets não os lista. A solicitação de ajuda/suporte não é disparada nesses mercados. They exist as app markets (minimal PANGEA config), but don't have this transaction — enabledMarkets doesn't list them. The help/support request is not fired in these markets. Existen como mercados de la app (config PANGEA mínima), pero no tienen esta transacción — enabledMarkets no los lista. La solicitud de ayuda/soporte no se dispara en estos mercados.