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

Comprovante de pagamentoProof of paymentComprobante de pago

A transação de escrita que envia ao backend um comprovante de pagamento — uma foto e/ou um arquivo anexado — vinculado a um item de dívida em aberto de um varejo. Um único builder monta um payload JSON de uma única variante com os dados do débito, da conta, da fatura vinculada e a evidência em base64. Toda a construção do contrato wire vive no builder. The write transaction that sends the backend a proof of payment — a photo and/or an attached file — tied to a retail's open debit item. A single builder assembles a JSON payload of one single variant carrying the debit, account and linked-invoice data plus the evidence in base64. All wire-contract construction lives in the builder. La transacción de escritura que envía al backend un comprobante de pago — una foto y/o un archivo adjunto — vinculado a un ítem de deuda abierta de un punto de venta. Un único builder arma un payload JSON de una única variante con los datos de la deuda, la cuenta, la factura vinculada y la evidencia en base64. 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

Financial management · Payment creation

AtualizadoUpdatedActualizado

18/08/20262026-08-18

Disponível emAvailable inDisponible en BR CL ZA

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

Um varejo tem contas em aberto (dívidas a pagar). Quando o representante de vendas anexa a um desses itens em aberto um comprovante de pagamento — a foto de um recibo ou um arquivo (PDF/imagem) — o app envia essa evidência ao backend por esta transação. É o que registra a prova de que aquela dívida foi paga, junto ao próprio item de dívida. A retail has open items (debts to pay). When the sales rep attaches a proof of payment to one of those open items — a photo of a receipt or a file (PDF/image) — the app sends that evidence to the backend through this transaction. It's what records the proof that the debt was paid, next to the debit item itself. Un punto de venta tiene ítems abiertos (deudas por pagar). Cuando el representante de ventas adjunta a uno de esos ítems abiertos un comprobante de pago — la foto de un recibo o un archivo (PDF/imagen) — la app envía esa evidencia al backend por esta transacción. Es lo que registra la prueba de que la deuda fue pagada, junto al propio ítem de deuda.

A evidência pode ser de três formas, e o app registra qual delas veio:The evidence can come in three forms, and the app records which one it was:La evidencia puede ser de tres formas, y la app registra cuál fue:

FotoPhotoFoto

Uma foto do comprovante, tirada na hora com a câmera.A photo of the receipt, taken on the spot with the camera.Una foto del comprobante, tomada en el momento con la cámara.

ArquivoAttachmentArchivo

Um arquivo anexado do dispositivo (ex.: PDF, imagem). O app guarda o tipo do arquivo.A file attached from the device (e.g. PDF, image). The app keeps the file type.Un archivo adjunto desde el dispositivo (p. ej. PDF, imagen). La app guarda el tipo de archivo.

Foto + arquivoPhoto + fileFoto + archivo

As duas evidências ao mesmo tempo, quando o rep anexa foto e arquivo.Both evidences at once, when the rep attaches a photo and a file.Ambas evidencias a la vez, cuando el rep adjunta foto y archivo.

Onde aconteceWhere it happensDónde ocurre O envio parte do detalhe de um item de dívida em aberto, dentro da Gestão financeira. Também é disparado como parte do fluxo de registro de pagamento, quando um pagamento é criado com comprovante. The send starts from the detail of an open debit item, inside Financial management. It's also fired as part of the payment creation flow, when a payment is registered with a proof. El envío parte del detalle de un ítem de deuda abierta, dentro de Gestión financiera. También se dispara como parte del flujo de registro de pago, cuando un pago se crea con comprobante.

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

O envio é o último passo de anexar um comprovante a uma conta em aberto. As telas do caminho pertencem às features de Gestão financeira e de registro de pagamento; aqui só situamos onde o envio acontece:The send is the last step of attaching a proof to an open item. The screens along the way belong to the Financial management and payment creation features; here we only place where the send happens:El envío es el último paso de adjuntar un comprobante a un ítem abierto. Las pantallas del camino pertenecen a las features de Gestión financiera y de registro de pago; aquí solo situamos dónde ocurre el envío:

Gestão financeiraFinancial managementGestión financieraO rep abre a conta do varejo e vê a lista de itens em aberto (dívidas).The rep opens the retail's account and sees the list of open items (debts).El rep abre la cuenta del punto de venta y ve la lista de ítems abiertos (deudas).
Detalhe do item em abertoOpen item detailDetalle del ítem abiertoEscolhe um item de dívida e abre o seu detalhe.Picks a debit item and opens its detail.Elige un ítem de deuda y abre su detalle.
Anexar comprovanteAttach proofAdjuntar comprobanteTira uma foto e/ou anexa um arquivo do comprovante de pagamento.Takes a photo and/or attaches a file of the payment proof.Toma una foto y/o adjunta un archivo del comprobante de pago.
Enviar → esta transaçãoSend → this transactionEnviar → esta transacciónAo tocar em enviar, o app dispara o Comprovante de pagamento. É este toque que aciona a transação.Tapping send, the app fires Proof of payment. This tap is what triggers the transaction.Al tocar enviar, la app dispara el Comprobante de pago. Este toque es lo que activa la transacción.

Junto com o registro de pagamentoAlongside payment registrationJunto con el registro de pago Quando um pagamento é registrado no fluxo de registro de pagamento com um ou mais comprovantes, cada comprovante é enviado por esta mesma transação — uma vez por evidência. When a payment is registered in the payment creation flow with one or more proofs, each proof is sent through this same transaction — once per evidence. Cuando un pago se registra en el flujo de registro de pago con uno o más comprobantes, cada comprobante se envía por esta misma transacción — una vez por evidencia.

Depois do envioAfter sendingDespués del envío

Confirmação ao repConfirmation to the repConfirmación al rep: Quando o backend aceita, o comprovante fica registrado junto ao item de dívida e o rep recebe a confirmação; a tela limpa a foto e o anexo enviados.When the backend accepts it, the proof is recorded next to the debit item and the rep gets a confirmation; the screen clears the sent photo and attachment.Cuando el backend lo acepta, el comprobante queda registrado junto al ítem de deuda y el rep recibe la confirmación; la pantalla limpia la foto y el adjunto enviados.
Sem internetOfflineSin internet: O envio pode entrar em fila e ser reenviado quando a conexão volta — o comprovante 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 proof 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 — el comprobante 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

Comprovante de pagamento é a transação de saída que anexa a evidência de pagamento de um item de dívida em aberto (DPI) ao backend. É disparada pelo detalhe do item em aberto e pelo fluxo de registro de pagamento. Uma única variante — não há campo de tipo, não há prefixo Promo_ — com destino batchApi. Proof of payment is the outbound transaction that attaches an open debit item's (DPI) payment evidence to the backend. It's fired by the open-item detail and the payment-creation flow. A single variant — no type field, no Promo_ prefix — with batchApi destination. Comprobante de pago es la transacción de salida que adjunta la evidencia de pago de un ítem de deuda abierta (DPI) al backend. Se dispara desde el detalle del ítem abierto y desde el flujo de registro de pago. Una única variante — sin campo de tipo, sin prefijo Promo_ — con destino batchApi.

Payload planoFlat payloadPayload plano

Um único array proofOfPayment com um objeto de 18 campos: débito, conta, fatura vinculada e a evidência em base64.A single proofOfPayment array with one 18-field object: debit, account, linked invoice and the base64 evidence.Un único array proofOfPayment con un objeto de 18 campos: deuda, cuenta, factura vinculada y la evidencia en base64.

Evidência em base64Base64 evidenceEvidencia en base64

O I/O de arquivo (ler foto/anexo) já é resolvido no notifier; o builder só encaminha as strings base64 e deriva evidenceType e fileType.File I/O (reading photo/attachment) is resolved in the notifier; the builder only forwards the base64 strings and derives evidenceType and fileType.El I/O de archivo (leer foto/adjunto) ya se resuelve en el notifier; el builder solo reenvía las strings base64 y deriva evidenceType y fileType.

RPC genéricoGeneric RPCRPC genérico

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

FontesSourcesFuentes BuildFinancialProofPaymentDispatcherPayloadUseCase + FinancialProofPaymentDispatcherPayloadInput + DispatcherType.financialProofOfPayment + DispatcherConectaRep.proto. O input carrega entities cruas de domínio (CLAUDE.md §36); o build() constrói todo o wire. BuildFinancialProofPaymentDispatcherPayloadUseCase + FinancialProofPaymentDispatcherPayloadInput + DispatcherType.financialProofOfPayment + DispatcherConectaRep.proto. The input carries raw domain entities (CLAUDE.md §36); build() constructs the entire wire. BuildFinancialProofPaymentDispatcherPayloadUseCase + FinancialProofPaymentDispatcherPayloadInput + DispatcherType.financialProofOfPayment + 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 — FinancialProofPaymentAPI (sem prefixo Promo_: hasPromotion é sempre false)discriminator — FinancialProofPaymentAPI (no Promo_ prefix: hasPromotion is always false)discriminador — FinancialProofPaymentAPI (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 · debit.invoiceSfid (correlação; "" se ausente)debit.invoiceSfid (correlation; "" if absent)debit.invoiceSfid (correlación; "" si ausente)
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 · literal provisório hoje (ver Pendências)provisional literal today (see Pending)literal provisional 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, account, 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. O account vem de debit.accountSfid / customerSap / accountName. The builder returns a DispatcherEnvelope (type, serviceName, payload, account, 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. The account comes from debit.accountSfid / customerSap / accountName. El builder devuelve un DispatcherEnvelope (type, serviceName, payload, account, 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. El account viene de debit.accountSfid / customerSap / accountName.

O destino é DispatcherDestination.batchApi: o comprovante entra no lote de despachos (batch) e é enviado pelo mesmo sendTransaction, junto de outras transações do lote.The destination is DispatcherDestination.batchApi: the proof joins the dispatch batch and is sent through the same sendTransaction, alongside other batched transactions.El destino es DispatcherDestination.batchApi: el comprobante entra en el lote de despachos (batch) y se envía por el mismo sendTransaction, junto a otras transacciones del lote.

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
`financialProofOfPayment`	`FinancialProofPaymentAPI`	`batchApi`	BR · CL · ZA

Como é disparadoHow it's firedCómo se dispara

A transação é disparada de dois pontos: pelo notifier do detalhe do item em aberto (envio único) e pelo orchestrator de registro de pagamento (um envio por comprovante). Em ambos, o notifier/orchestrator apenas reúne entities cruas e valores injetados; o builder é o dono único de todo join, rename, formatação de data e derivação wire. A cascata:The transaction is fired from two points: the open-item detail notifier (single send) and the payment-submission orchestrator (one send per proof). In both, the notifier/orchestrator only gathers raw entities and injected values; the builder is the sole owner of every join, rename, date formatting and wire derivation. The cascade:La transacción se dispara desde dos puntos: el notifier del detalle del ítem abierto (envío único) y el orchestrator de registro de pago (un envío por comprobante). En ambos, el notifier/orchestrator solo reúne entities crudas y valores inyectados; el builder es el dueño único de todo join, rename, formateo de fecha y derivación wire. La cascada:

Debit open item detailnotifier / orchestrator
- lê foto/anexo como base64 + reúne entities cruasreads photo/attachment as base64 + gathers raw entitieslee foto/adjunto como base64 + reúne entities crudasFinancialProofPaymentDispatcherPayloadInput
  - build()BuildFinancialProofPaymentDispatcherPayloadUseCasemonta o wireassembles the wirearma el wire
    - devolvereturnsdevuelveDispatcherEnvelope
      - SubmitFinancialProofPaymentUseCaseDispatcherRepository
        
        serializa + authserialize + authserializa + authDispatcherGateway
        
        sendTransactionBackendgRPC

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

FinancialProofPaymentDispatcherPayloadInput (Freezed). Carrega o dado como existe no domínio; nada de formato wire. O relógio chega como submittedAt (via DateTimeUtils.now()); o I/O de arquivo já foi resolvido (readAsBase64) antes de montar o input.FinancialProofPaymentDispatcherPayloadInput (Freezed). Carries data as it exists in the domain; no wire shaping. The clock arrives as submittedAt (via DateTimeUtils.now()); file I/O is already resolved (readAsBase64) before building the input.FinancialProofPaymentDispatcherPayloadInput (Freezed). Lleva el dato como existe en el dominio; nada de formato wire. El reloj llega como submittedAt (vía DateTimeUtils.now()); el I/O de archivo ya se resolvió (readAsBase64) antes de armar el input.

CampoFieldCampo	TipoTypeTipo	PapelRoleRol
`debit`	`DebitOpenItemEntity`	item de dívida em aberto (DPI): valor, datas, status, conta, link de faturaopen debit item (DPI): amount, dates, status, account, invoice linkítem de deuda abierta (DPI): monto, fechas, estado, cuenta, enlace de factura
`order`	`OrderEntity?`	pedido vinculado (fatura, nome/SAP da conta) quando resolvível; null se não houverlinked order (invoice, account name/SAP) when resolvable; null otherwisepedido vinculado (factura, nombre/SAP de la cuenta) cuando es resolvible; null si no hay
`visit`	`VisitEntity?`	fallback de nome/SAP da conta a partir da visita da contafallback account name/SAP from the account's visitfallback de nombre/SAP de la cuenta desde la visita de la cuenta
`resource`	`ResourceEntity`	representante de vendas (cru — o builder deriva `resourceSfid` primary/secondary)sales rep (raw — the builder derives `resourceSfid` primary/secondary)representante de ventas (crudo — el builder deriva `resourceSfid` primary/secondary)
`proofImageBase64`	`String?`	foto do comprovante já lida em base64 (I/O feito no notifier)proof photo already read as base64 (I/O done in the notifier)foto del comprobante ya leída en base64 (I/O hecho en el notifier)
`proofAttachmentBase64`	`String?`	arquivo anexado já lido em base64attached file already read as base64archivo adjunto ya leído en base64
`proofAttachmentFileName`	`String?`	nome original do anexo (→ `fileType`)original attachment name (→ `fileType`)nombre original del adjunto (→ `fileType`)
`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`

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 + 18 no objeto = 19). 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 + 18 in the object = 19). 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 + 18 en el objeto = 19). 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
`proofOfPayment`	array	`[proofOfPayment]`	array de um único objeto (o comprovante)single-element array (the proof)array de un solo objeto (el comprobante)

proofOfPayment objeto únicosingle objectobjeto único 18 camposfieldscampos

Campo JSON	TipoTypeTipo	Origem do DadoData sourceOrigen del Dato	RegraRuleRegla
`date`	string	`input.submittedAt`	formato `yyyy-MM-dd HH:mm:ss` (`DateFormatType.isoDateTime`)`yyyy-MM-dd HH:mm:ss` format (`DateFormatType.isoDateTime`)formato `yyyy-MM-dd HH:mm:ss` (`DateFormatType.isoDateTime`)
`invoiceName`	string	`order.invoice.invoiceNumber`	fallback `debit.debitOpenItemSfid` quando não há número de faturafallback `debit.debitOpenItemSfid` when there's no invoice numberfallback `debit.debitOpenItemSfid` cuando no hay número de factura
`invoiceStatus`	string	`order.invoice.invoiceStatus`	fallback `"NO_INVOICE"` quando vaziofallback `"NO_INVOICE"` when emptyfallback `"NO_INVOICE"` cuando vacío
`invoiceId`	string	`debit.invoiceSfid`	fallback `"NO_INVOICE"` quando null/vaziofallback `"NO_INVOICE"` when null/emptyfallback `"NO_INVOICE"` cuando null/vacío
`accountId`	string	`debit.accountSfid`	—
`proofImage`	string	`input.proofImageBase64`	base64 da foto; `""` quando ausentephoto base64; `""` when absentbase64 de la foto; `""` cuando ausente
`proofFile`	string	`input.proofAttachmentBase64`	base64 do anexo; `""` quando ausenteattachment base64; `""` when absentbase64 del adjunto; `""` cuando ausente
`fileType`	string	`Calculado`	extensão de `proofAttachmentFileName` em minúsculas (após o último `.`); `""` se sem pontolowercased extension of `proofAttachmentFileName` (after the last `.`); `""` if no dotextensión de `proofAttachmentFileName` en minúsculas (tras el último `.`); `""` si no hay punto
`resourceSfid`	string	`resource`	`isPrimaryResource ? primaryResourceSfid : secondaryResourceSfidisPrimaryResource ? primaryResourceSfid : secondaryResourceSfidisPrimaryResource ? primaryResourceSfid : secondaryResourceSfid`
`accountName`	string	`order.accountName`	fallback `visit.accountData.name`; `""` se nenhumfallback `visit.accountData.name`; `""` if nonefallback `visit.accountData.name`; `""` si ninguno
`dueDate`	string	`debit.date`	formato `yyyy-MM-dd` (`DateFormatType.isoDate`, default)`yyyy-MM-dd` format (`DateFormatType.isoDate`, default)formato `yyyy-MM-dd` (`DateFormatType.isoDate`, default)
`dpi`	string	`debit.name`	nome do item de dívida (DPI)debit item (DPI) namenombre del ítem de deuda (DPI)
`dpiStatus`	string	`debit.status.value`	`open` · `collected` · `closed` · `unknownopen` · `collected` · `closed` · `unknownopen` · `collected` · `closed` · `unknown`
`inDispute`	bool	`debit.inDispute`	—
`customerSap`	string	`order.accountSapId`	fallback `visit.accountData.customerCode`; `""` se nenhumfallback `visit.accountData.customerCode`; `""` if nonefallback `visit.accountData.customerCode`; `""` si ninguno
`amount`	double	`debit.price`	valor do débito (cru, sem arredondar)debit amount (raw, unrounded)monto de la deuda (crudo, sin redondear)
`OpenDays`	int	`debit.openDays`	dias em aberto (chave em PascalCase, verbatim do contrato)open days (PascalCase key, verbatim from the contract)días abiertos (clave en PascalCase, verbatim del contrato)
`evidenceType`	string	`Calculado`	`"Both"` / `"Photo"` / `"Attachment"` / `"None"` conforme foto e/ou anexo`"Both"` / `"Photo"` / `"Attachment"` / `"None"` per photo and/or attachment`"Both"` / `"Photo"` / `"Attachment"` / `"None"` según foto y/o adjunto

Regras de negócioBusiness rulesReglas de negocio

Tipo de evidênciaEvidence typeTipo de evidencia evidenceType · proofImage · proofFile

evidenceType é derivado da presença das duas evidências: foto + anexo → "Both"; só foto → "Photo"; só anexo → "Attachment"; nenhuma → "None".evidenceType is derived from the presence of both evidences: photo + attachment → "Both"; photo only → "Photo"; attachment only → "Attachment"; none → "None".evidenceType se deriva de la presencia de ambas evidencias: foto + adjunto → "Both"; solo foto → "Photo"; solo adjunto → "Attachment"; ninguna → "None".
proofImage e proofFile caem para "" quando a evidência correspondente é ausente — nunca null no payload.proofImage and proofFile fall back to "" when the matching evidence is absent — never null in the payload.proofImage y proofFile caen a "" cuando la evidencia correspondiente está ausente — nunca null en el payload.
O I/O de arquivo (ler foto/anexo em base64) é feito fora do builder, no notifier (captureService.readAsBase64); o builder só recebe as strings prontas (§36).File I/O (reading photo/attachment to base64) is done outside the builder, in the notifier (captureService.readAsBase64); the builder only receives the ready strings (§36).El I/O de archivo (leer foto/adjunto a base64) se hace fuera del builder, en el notifier (captureService.readAsBase64); el builder solo recibe las strings listas (§36).

Origem da conta e da faturaAccount & invoice sourcingOrigen de la cuenta y la factura order → visit fallback

accountName e customerSap: preferem o pedido vinculado (order.accountName / order.accountSapId); se o pedido não veio ou está vazio, caem para a visita (visit.accountData.name / visit.accountData.customerCode); se nenhum, "".accountName and customerSap: prefer the linked order (order.accountName / order.accountSapId); if the order is missing or empty, fall to the visit (visit.accountData.name / visit.accountData.customerCode); if none, "".accountName y customerSap: prefieren el pedido vinculado (order.accountName / order.accountSapId); si el pedido no vino o está vacío, caen a la visita (visit.accountData.name / visit.accountData.customerCode); si ninguno, "".
invoiceName: usa order.invoice.invoiceNumber; sem fatura, cai para debit.debitOpenItemSfid. invoiceStatus e invoiceId caem ambos para "NO_INVOICE" quando não há fatura vinculada.invoiceName: uses order.invoice.invoiceNumber; without an invoice, falls to debit.debitOpenItemSfid. invoiceStatus and invoiceId both fall to "NO_INVOICE" when there's no linked invoice.invoiceName: usa order.invoice.invoiceNumber; sin factura, cae a debit.debitOpenItemSfid. invoiceStatus e invoiceId caen ambos a "NO_INVOICE" cuando no hay factura vinculada.
transactionReference do envelope = debit.invoiceSfid ?? "" — correlação do despacho.The envelope's transactionReference = debit.invoiceSfid ?? "" — dispatch correlation.El transactionReference del envelope = debit.invoiceSfid ?? "" — correlación del despacho.

Rep e datasRep & datesRep y fechas resourceSfid · date · dueDate

resourceSfid: primary vs secondary decidido por resource.isPrimaryResource — o builder deriva o sfid do rep (nunca pré-resolvido no notifier, §25/§36).resourceSfid: primary vs secondary decided by resource.isPrimaryResource — the builder derives the rep sfid (never pre-resolved in the notifier, §25/§36).resourceSfid: primary vs secondary decidido por resource.isPrimaryResource — el builder deriva el sfid del rep (nunca pre-resuelto en el notifier, §25/§36).
date (envio) usa DateFormatType.isoDateTime (yyyy-MM-dd HH:mm:ss); dueDate (vencimento do débito) usa o default DateFormatType.isoDate (yyyy-MM-dd). Toda formatação de data passa pelo DateTimeUtils (§14).date (submission) uses DateFormatType.isoDateTime (yyyy-MM-dd HH:mm:ss); dueDate (debit due date) uses the default DateFormatType.isoDate (yyyy-MM-dd). All date formatting goes through DateTimeUtils (§14).date (envío) usa DateFormatType.isoDateTime (yyyy-MM-dd HH:mm:ss); dueDate (vencimiento de la deuda) usa el default DateFormatType.isoDate (yyyy-MM-dd). Todo formateo de fecha pasa por DateTimeUtils (§14).
serviceName: fixo FinancialProofPaymentAPI — o builder chama type.resolveServiceName(hasPromotion: false), então nunca há prefixo Promo_.serviceName: fixed FinancialProofPaymentAPI — the builder calls type.resolveServiceName(hasPromotion: false), so there's never a Promo_ prefix.serviceName: fijo FinancialProofPaymentAPI — 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

fileType vem só do anexo (proofAttachmentFileName): uma evidência de foto não carrega fileType (fica ""), mesmo quando evidenceType == "Photo" ou "Both".fileType comes only from the attachment (proofAttachmentFileName): a photo evidence carries no fileType (stays ""), even when evidenceType == "Photo" or "Both".fileType viene solo del adjunto (proofAttachmentFileName): una evidencia de foto no lleva fileType (queda ""), incluso cuando evidenceType == "Photo" o "Both".
amount vai cru (debit.price, sem arredondamento monetário) — diferente do build() de pedido, que arredonda valores.amount ships raw (debit.price, no monetary rounding) — unlike the order build(), which rounds values.amount va crudo (debit.price, sin redondeo monetario) — a diferencia del build() de pedido, que redondea valores.
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().
Transporte: deviceUuid vai como literal provisório no gateway (pendência conhecida do Dispatcher, comum a todas as transações).Transport: deviceUuid ships as a provisional literal in the gateway (known Dispatcher pending item, common to all transactions).Transporte: deviceUuid va como literal provisional en el gateway (pendiente conocido del Dispatcher, común a todas las transacciones).

Feature donaOwning featureFeature dueña O envio parte da Gestão financeira (detalhe do item em aberto) e do registro de pagamento — veja essas features para o contexto de UI. The send comes from Financial management (open-item detail) and payment creation — see those features for the UI context. El envío parte de Gestión financiera (detalle del ítem abierto) y del registro de pago — vea esas features para el contexto de UI.

★

MercadosMarketsMercados

A disponibilidade da transação vem do DispatcherType.financialProofOfPayment.enabledMarkets — BR/CL/ZA. O payload é uniforme: não há divergência de campos por mercado. AR/PY/PE não têm esta transação.Transaction availability comes from DispatcherType.financialProofOfPayment.enabledMarkets — BR/CL/ZA. The payload is uniform: there's no per-market field divergence. AR/PY/PE don't have this transaction.La disponibilidad de la transacción viene de DispatcherType.financialProofOfPayment.enabledMarkets — BR/CL/ZA. El payload es uniforme: no hay divergencia de campos por mercado. 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 é idêntico — os mesmos 18 campos de proofOfPayment, mesmo serviceName e mesmo destino batchApi. A evidência (foto/anexo) e os dados do débito não variam de forma por país. In all three markets the payload is identical — the same 18 proofOfPayment fields, same serviceName and same batchApi destination. The evidence (photo/attachment) and debit data don't vary in shape by country. En los tres mercados el payload es idéntico — los mismos 18 campos de proofOfPayment, mismo serviceName y mismo destino batchApi. La evidencia (foto/adjunto) y los datos de la deuda no varían de forma por país.

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. O envio de comprovante não é disparado nesses mercados. They exist as app markets (minimal PANGEA config), but don't have this transaction — enabledMarkets doesn't list them. Proof-of-payment sending 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. El envío de comprobante no se dispara en estos mercados.