Cadastro de novo varejoNew retail registrationRegistro de nuevo punto de venta

Clean Architecture + Riverpod + Freezed + gRPC + ObjectBox. O fluxo tem três caminhos de dados independentes: (a) leitura de apoio — as listas de opções (ReferenceData) e a configuração do mercado (EndMarketConfiguration), que hidratam o State no build(); (b) checagens sob demanda — taxNumberCheck e emailCheck, disparadas por botão, sem cache e sem Model; (c) escrita — um envelope do Dispatcher com o cadastro inteiro.Clean Architecture + Riverpod + Freezed + gRPC + ObjectBox. The flow has three independent data paths: (a) supporting reads — the option lists (ReferenceData) and market configuration (EndMarketConfiguration), which hydrate the State in build(); (b) on-demand checks — taxNumberCheck and emailCheck, fired by a button, with no cache and no Model; (c) write — one Dispatcher envelope with the whole registration.Clean Architecture + Riverpod + Freezed + gRPC + ObjectBox. El flujo tiene tres caminos de datos independientes: (a) lecturas de apoyo — las listas de opciones (ReferenceData) y la configuración del mercado (EndMarketConfiguration), que hidratan el State en el build(); (b) verificaciones a demanda — taxNumberCheck y emailCheck, disparadas por botón, sin caché y sin Model; (c) escritura — un envelope del Dispatcher con el registro completo.

(a) Leitura — listas de apoio e configuração(a) Read — supporting lists and configuration(a) Lectura — listas de apoyo y configuración

• ReferenceDataReplygRPC proto
  • toDTOReferenceDataDTODTO · Freezed
    • toDomainReferenceDataEntitydomain · enums tipados
      • toModelReferenceDataModelObjectBox
        • toDomainReferenceDataEntitydomain · cache
          • GetReferenceDataUseCaseNewRetailFlowNotifier._load()+ marketConfigurationProvider
            • → StateNewRetailFlowState
              • → UI9 pages do assistente

O build() pede source: local (cache primeiro); o pull-to-refresh da primeira tela repete com source: remote. Em paralelo, marketConfigurationProvider entrega o NewRetailConfig (JSON do EMC → DTO → Entity, sem proto e sem ObjectBox), que define tipos, campos, obrigatoriedade, edição e as quatro flags de comportamento.build() asks for source: local (cache first); the first screen's pull-to-refresh repeats with source: remote. In parallel, marketConfigurationProvider delivers NewRetailConfig (EMC JSON → DTO → Entity, no proto and no ObjectBox), which defines types, fields, requiredness, editability and the four behavior flags.El build() pide source: local (caché primero); el pull-to-refresh de la primera pantalla repite con source: remote. En paralelo, marketConfigurationProvider entrega el NewRetailConfig (JSON del EMC → DTO → Entity, sin proto y sin ObjectBox), que define tipos, campos, obligatoriedad, edición y las cuatro flags de comportamiento.

(b) Checagens sob demanda — documento e e-mail(b) On-demand checks — document and e-mail(b) Verificaciones a demanda — documento y correo

• Botão do repValidar · Continuar · Registrar
  • CheckTaxNumberUseCase / CheckEmailUseCaseReferenceDataRepositoryImploffline → NetworkFailure
    • gRPCtaxNumberCheck / emailCheckRemote · sem cache
      • toDTOTaxNumberCheckResultDTO
        EmailCheckResultDTO
        • toDomain…ResultEntitycanProceed
          • → outcomebloqueia ou libera o avanço

Nenhuma das duas checagens tem Model, cache ou fromMap de JSON real — o mock resolve por listas dentro do próprio asset de reference_data. Offline, o repository devolve NetworkFailure antes de tocar a rede.Neither check has a Model, a cache or a real JSON fromMap — the mock resolves them from lists inside the reference_data asset itself. Offline, the repository returns NetworkFailure before touching the network.Ninguna de las dos verificaciones tiene Model, caché ni fromMap de JSON real — el mock las resuelve con listas dentro del propio asset de reference_data. Offline, el repository devuelve NetworkFailure antes de tocar la red.

(c) Escrita — a transação do cadastro(c) Write — the registration transaction(c) Escritura — la transacción del registro

• NewRetailFlowStatetudo em memória + fotos
  • submitNewRetail()NewRetailUploadDispatcherPayloadInputdado cru de domínio
    • BuildNewRetailUploadDispatcherPayloadUseCase.build()DispatcherEnvelopeserviceName AccountContactUploadAPI
      • SubmitNewRetailUploadUseCase.submit()DispatcherOrchestratorretailNew não entra em fila offline
        • send()DispatcherRepositoryImpl → DispatcherGatewayjsonEncode(payload)
          • gRPCsendTransaction(InboxTransactionRequest)
            • → ackDispatcherAckstatus 0|5 = sucesso

Regra travada do projeto: o Input carrega dado cru de domínio (entities, nomes de domínio) e toda a construção wire — rename, concatenação, formatação de data, digitsOnly, campos fixos, derivação do sfid do representante — mora só no build() do builder. O que o notifier injeta é o que o builder puro não obtém: relógio (submittedAt), ResourceEntity, GPS, customerCode gerado e as fotos já em base64.Locked project rule: the Input carries raw domain data (entities, domain names) and all wire construction — rename, concatenation, date formatting, digitsOnly, fixed fields, deriving the rep sfid — lives only inside the builder's build(). What the notifier injects is what a pure builder cannot obtain: the clock (submittedAt), ResourceEntity, GPS, the generated customerCode and the photos already base64-encoded.Regla fija del proyecto: el Input lleva dato crudo de dominio (entities, nombres de dominio) y toda la construcción wire — rename, concatenación, formato de fecha, digitsOnly, campos fijos, derivación del sfid del representante — vive solo en el build() del builder. Lo que el notifier inyecta es lo que un builder puro no puede obtener: el reloj (submittedAt), ResourceEntity, GPS, el customerCode generado y las fotos ya en base64.

O dado de leitura deste fluxo (as listas de opções) existe em quatro representações ao longo das camadas — Proto (wire gRPC) → DTO (Freezed) → Model (ObjectBox) → Entity (domínio) — e cada fronteira é atravessada por um mapper. O fetch é write-through: todo retorno remoto é gravado no ObjectBox (registro único, regravado por inteiro) e a UI passa a ler do cache. Os nomes dos campos se mantêm em todas as camadas; muda pouco (enums tipados na Entity, relações ToMany/ToOne no Model).This flow's read data (the option lists) exists in four representations across the layers — Proto (gRPC wire) → DTO (Freezed) → Model (ObjectBox) → Entity (domain) — and each boundary is crossed by a mapper. Fetch is write-through: every remote response is written to ObjectBox (single row, fully rewritten) and the UI then reads from cache. Field names stay the same across layers; little changes (enums typed in the Entity, ToMany/ToOne relations in the Model).El dato de lectura de este flujo (las listas de opciones) existe en cuatro representaciones a lo largo de las capas — Proto (wire gRPC) → DTO (Freezed) → Model (ObjectBox) → Entity (dominio) — y cada frontera se cruza con un mapper. El fetch es write-through: toda respuesta remota se graba en ObjectBox (registro único, regrabado completo) y la UI lee del caché. Los nombres se mantienen en todas las capas; cambia poco (enums tipados en la Entity, relaciones ToMany/ToOne en el Model).

Nem tudo aqui percorre as quatro camadas. As duas checagens (EmailCheckResult, TaxNumberCheckResult) param na Entity — não têm Model nem cache. A configuração do mercado (NewRetailConfig e filhos) nasce de JSON e vai a DTO → Entity, sem proto e sem ObjectBox. E o rascunho do cadastro (NewRetailContact, PostalCodeAddress, NewRetailUploadDispatcherPayloadInput) é só domínio: existe em memória e morre no envio. Nas tabelas abaixo, camada inexistente aparece como —. A seguir, na ordem: o proto, as estruturas de dados campo-a-campo, o payload da transação, os mappers e os deltas.Not everything here crosses the four layers. The two checks (EmailCheckResult, TaxNumberCheckResult) stop at the Entity — no Model, no cache. The market configuration (NewRetailConfig and children) is born from JSON and goes to DTO → Entity, with no proto and no ObjectBox. And the registration draft (NewRetailContact, PostalCodeAddress, NewRetailUploadDispatcherPayloadInput) is domain only: it lives in memory and dies on submit. In the tables below, a non-existent layer shows as —. Next, in order: the proto, the field-by-field data structures, the transaction payload, the mappers and the deltas.No todo aquí recorre las cuatro capas. Las dos verificaciones (EmailCheckResult, TaxNumberCheckResult) paran en la Entity — sin Model ni caché. La configuración del mercado (NewRetailConfig e hijos) nace de JSON y va a DTO → Entity, sin proto y sin ObjectBox. Y el borrador del registro (NewRetailContact, PostalCodeAddress, NewRetailUploadDispatcherPayloadInput) es solo dominio: vive en memoria y muere en el envío. En las tablas de abajo, una capa inexistente aparece como —. A continuación, en orden: el proto, las estructuras de datos campo a campo, el payload de la transacción, los mappers y los deltas.

Proto

ReferenceDataConectaRep.proto · proto3 · package mn.bat.conectarep.streambridge · importaimportsimporta CommonConectaRep.proto. Um serviço (ReferenceDataConectaRepService) com três métodos unários — o fluxo usa os três.One service (ReferenceDataConectaRepService) with three unary methods — the flow uses all three.Un servicio (ReferenceDataConectaRepService) con tres métodos unarios — el flujo usa los tres.

Estruturas de dadosData structuresEstructuras de datos

Um dropdown por estrutura, aninhados pela hierarquia. Cada tabela tem uma coluna por camada — Proto · DTO · Model · Entity; o texto em destaque marca onde o tipo primeiro muda (relação no Model, enum na Entity). — = a camada não existe para aquela estrutura. ¹ = optional no proto.One dropdown per structure, nested by hierarchy. Each table has one column per layer — Proto · DTO · Model · Entity; accent text marks where the type first changes (relation in the Model, enum in the Entity). — = that layer does not exist for the structure. ¹ = optional in the proto.Un dropdown por estructura, anidados por jerarquía. Cada tabla tiene una columna por capa — Proto · DTO · Model · Entity; el texto destacado marca dónde primero cambia el tipo (relación en el Model, enum en la Entity). — = la capa no existe para esa estructura. ¹ = optional en el proto.

• ReferenceData raiz · listas de apoioroot · supporting listsraíz · listas de apoyo 20 campos

  Campo	Proto	DTO	Model	Entity
  lastSyncAt	—	DateTime	DateTime	DateTime
  deliveryCancelReasons	repeated DeliveryCancelReason	List<…DTO>	ToMany<…Model>	List<…Entity>
  geographicalHierarchy	GeographicalHierarchy	…DTO	ToOne<…Model>	…Entity
  outletSubtypes	repeated SfidNamePair	List<…DTO>	ToMany<…Model>	List<…Entity>
  categoriesForSale	repeated string	List<String>	List<String>	List<CategoryForSale>
  banners	repeated SfidNamePair	List<…DTO>	ToMany<…Model>	List<…Entity>
  propertyTypes	repeated string	List<String>	List<String>	List<String>
  keyAccountTypes	repeated string	List<String>	List<String>	List<String>
  giroOptions	repeated SfidNamePair	List<…DTO>	ToMany<…Model>	List<…Entity>
  canalOptions	repeated SfidNamePair	List<…DTO>	ToMany<…Model>	List<…Entity>
  localClassificationDefinitions	repeated LocalClassificationDefinition	List<…DTO>	ToMany<…Model>	List<…Entity>
  contactRoles	repeated string	List<String>	List<String>	List<ContactRole>
  languagePreferences	repeated string	List<String>	List<String>	List<LanguagePreference>
  buybackReasons	repeated BuybackReason	List<…DTO>	ToMany<…Model>	List<…Entity>
  moduleMaster	ModuleMaster	…DTO	ToOne<…Model>	…Entity
  accountInactiveReasons	repeated string	List<String>	List<String>	List<AccountInactiveReason>
  pdvTypes	repeated PdvType	List<…DTO>	ToMany<…Model>	List<…Entity>
  holidays	repeated Holiday	List<…DTO>	ToMany<…Model>	List<…Entity>
  visitCancelReasons	repeated VisitReason	List<…DTO>	ToMany<VisitCancelReasonModel>	List<VisitReasonEntity>
  visitNoBuyReasons	repeated VisitReason	List<…DTO>	ToMany<VisitNoBuyReasonModel>	List<VisitReasonEntity>

  O cadastro de varejo consome 11 campos: geographicalHierarchy, outletSubtypes, categoriesForSale, banners, propertyTypes, keyAccountTypes, giroOptions, canalOptions, localClassificationDefinitions, contactRoles, languagePreferences (+ lastSyncAt para o DataLoadInfo). Os demais pertencem a outras features. pdvTypes existe fim-a-fim mas nenhum código o lê hoje.New retail consumes 11 fields: geographicalHierarchy, outletSubtypes, categoriesForSale, banners, propertyTypes, keyAccountTypes, giroOptions, canalOptions, localClassificationDefinitions, contactRoles, languagePreferences (+ lastSyncAt for DataLoadInfo). The rest belong to other features. pdvTypes exists end-to-end but no code reads it today.El registro de PDV consume 11 campos: geographicalHierarchy, outletSubtypes, categoriesForSale, banners, propertyTypes, keyAccountTypes, giroOptions, canalOptions, localClassificationDefinitions, contactRoles, languagePreferences (+ lastSyncAt para el DataLoadInfo). Los demás pertenecen a otras features. pdvTypes existe de punta a punta pero ningún código lo lee hoy.

  • GeographicalHierarchy ReferenceData.geographicalHierarchy 2 campos

    Campo	Proto	DTO	Model	Entity
    countrySfid	string	String	String	String
    states	repeated State	List<GeoStateDTO>	ToMany<GeoStateModel>	List<GeoStateEntity>

    • GeoState GeographicalHierarchy.states[] · protoprotoproto State 4 campos

      Campo	Proto	DTO	Model	Entity
      sfid	string	String	String	String
      name	string	String	String	String
      code	string	String	String	String
      cities	repeated City	List<GeoCityDTO>	ToMany<GeoCityModel>	List<GeoCityEntity>

      • GeoCity GeoState.cities[] · City 2 campos

        Campo	Proto	DTO	Model	Entity
        sfid	string	String	String	String
        name	string	String	String	String

  • LocalClassificationDefinition ReferenceData.localClassificationDefinitions[] 4 campos

    Campo	Proto	DTO	Model	Entity
    sfid	string	String	String	String
    name	string	String	String	String
    type	string	String	String	LocalClassificationType
    options	repeated SfidNamePair	List<SfidNamePairDTO>	ToMany<SfidNamePairModel>	List<SfidNamePairEntity>

    • SfidNamePair compartilhado ·shared ·compartido · CommonConectaRep.proto 2 campos

      Campo	Proto	DTO	Model	Entity
      sfid	string	String	String	String
      name	string	String	String	String

      Alimenta outletSubtypes, banners, giroOptions, canalOptions e as opções de classificação local.Feeds outletSubtypes, banners, giroOptions, canalOptions and the local-classification options.Alimenta outletSubtypes, banners, giroOptions, canalOptions y las opciones de clasificación local.

• EmailCheckResult raiz · sem Model, sem cacheroot · no Model, no cacheraíz · sin Model, sin caché 2 campos

  Campo	Proto	DTO	Model	Entity
  hasEmail	bool	bool	—	bool
  message	string	String	—	String

  Getter da Entity: bool get canProceed => !hasEmail;. O message é o motivo do backend, exibido no modal abaixo da mensagem traduzida.Entity getter: bool get canProceed => !hasEmail;. message is the backend reason, shown in the modal below the translated message.Getter de la Entity: bool get canProceed => !hasEmail;. message es el motivo del backend, mostrado en el modal debajo del mensaje traducido.

• TaxNumberCheckResult raiz · sem Model, sem cacheroot · no Model, no cacheraíz · sin Model, sin caché 3 campos

  Campo	Proto	DTO	Model	Entity
  hasTaxNumber	bool	bool	—	bool
  isBlackListed	bool	bool	—	bool
  blackListMessage	string	String	—	String

  Getter da Entity: bool get canProceed => !hasTaxNumber && !isBlackListed; — o notifier da tela reimplementa a mesma regra em dois passos para escolher a mensagem certa.Entity getter: bool get canProceed => !hasTaxNumber && !isBlackListed; — the screen's notifier reimplements the same rule in two steps to pick the right message.Getter de la Entity: bool get canProceed => !hasTaxNumber && !isBlackListed; — el notifier de la pantalla reimplementa la misma regla en dos pasos para elegir el mensaje correcto.

• PostalCodeAddress raiz · serviço de CEP (só domínio)root · postal-code service (domain only)raíz · servicio de código postal (solo dominio) 4 campos

  Campo	Proto	DTO	Model	Entity
  street	—	—	—	String
  neighborhood	—	—	—	String
  city	—	—	—	String
  stateCode	—	—	—	String

• NewRetailContact raiz · rascunho em memóriaroot · in-memory draftraíz · borrador en memoria 9 campos

  Campo	Proto	DTO	Model	Entity
  firstName	—	—	—	String
  lastName	—	—	—	String
  pronoun	—	—	—	Pronoun
  preferredLanguage	—	—	—	LanguagePreference
  role	—	—	—	ContactRole
  cellPhone	—	—	—	String
  email	—	—	—	String
  dateOfBirth	—	—	—	DateTime?
  isMainContact	—	—	—	bool

  Getter: String get fullName => "$firstName $lastName".trim();. No Brasil o formulário coleta o nome completo e o notifier o divide em primeiro/último ao salvar.Getter: String get fullName => "$firstName $lastName".trim();. In Brazil the form collects the full name and the notifier splits it into first/last on save.Getter: String get fullName => "$firstName $lastName".trim();. En Brasil el formulario recoge el nombre completo y el notifier lo divide en primero/último al guardar.

• NewRetailConfig raiz · EMC (JSON → DTO → Entity)root · EMC (JSON → DTO → Entity)raíz · EMC (JSON → DTO → Entity) 14 campos

  Campo	Proto	DTO	Model	Entity
  documentRequirementsByType	—	Map<String, List<…DTO>>	—	Map<NewRetailType, List<…>>
  startOfActivityDocumentsByType	—	Map<String, List<…DTO>>	—	Map<NewRetailType, List<…>>
  legalEntityFieldsByType	—	Map<String, List<…DTO>>	—	Map<NewRetailType, List<…>>
  addressFieldsByType	—	Map<String, List<…DTO>>	—	Map<NewRetailType, List<…>>
  operationalDataFieldsByType	—	Map<String, List<…DTO>>	—	Map<NewRetailType, List<…>>
  contactFieldsByType	—	Map<String, List<…DTO>>	—	Map<NewRetailType, List<…>>
  postalCodeAutoComplete	—	bool	—	bool
  wireConfig	—	NewRetailWireConfigDTO	—	NewRetailWireConfig
  requiresDocumentValidation	—	bool	—	bool
  retailTypes	—	List<String>	—	List<NewRetailType>
  checksAccountEmailUniqueness	—	bool	—	bool
  checksContactEmailUniqueness	—	bool	—	bool
  requiresB2bCustomerForContacts	—	bool	—	bool
  allowsStateRegistrationExemption	—	bool	—	bool

  As chaves do JSON são idênticas aos nomes dos campos. As chaves de tipo ("individual"/"business"/"generic") viram NewRetailType por fromKey, com fallback silencioso para generic. Métodos: documentRequirementsFor, startOfActivityDocumentsFor, legalEntityFieldsFor, addressFieldsFor, operationalDataFieldsFor, contactFieldsFor — todos com lista vazia como padrão.The JSON keys are identical to the field names. Type keys ("individual"/"business"/"generic") become NewRetailType via fromKey, with a silent fallback to generic. Methods: documentRequirementsFor, startOfActivityDocumentsFor, legalEntityFieldsFor, addressFieldsFor, operationalDataFieldsFor, contactFieldsFor — all defaulting to an empty list.Las claves del JSON son idénticas a los nombres de los campos. Las claves de tipo ("individual"/"business"/"generic") pasan a NewRetailType vía fromKey, con fallback silencioso a generic. Métodos: documentRequirementsFor, startOfActivityDocumentsFor, legalEntityFieldsFor, addressFieldsFor, operationalDataFieldsFor, contactFieldsFor — todos con lista vacía por defecto.

  • NewRetailWireConfig NewRetailConfig.wireConfig 20 campos

    Campo	Proto	DTO	Model	Entity
    accountRecordTypeId	—	String	—	String
    contactRecordTypeId	—	String	—	String
    locationHierarchyId	—	String	—	String
    paymentMethod	—	String	—	String
    defaultPaymentMethod	—	String	—	String
    currencyIsoCode	—	String	—	String
    language	—	String	—	String
    mailingCountry	—	String	—	String
    contactPreferredLanguage	—	String	—	String
    sendsVatRegistrationNo	—	bool	—	bool
    sendsTaxId	—	bool	—	bool
    sendsDocumentData	—	bool	—	bool
    collectsDirectSales	—	bool	—	bool
    userQuotas	—	String	—	String
    ownerShipType	—	String	—	String
    totalSellInValPerAnnum	—	String	—	String
    isTaxRequired	—	String	—	String
    contactB2bStatus	—	String	—	String
    restrictedOrderEdit	—	String	—	String
    isPartialDelivery	—	String	—	String

    Note os bools textuais: isTaxRequired, restrictedOrderEdit e isPartialDelivery são String no Dart e "true"/"false" no JSON, porque vão crus para o payload. Defaults do mapper: sendsTaxId: true, sendsDocumentData: true, userQuotas: "50", totalSellInValPerAnnum: "1", isTaxRequired: "false", contactB2bStatus: "Inactive".Note the stringly-typed bools: isTaxRequired, restrictedOrderEdit and isPartialDelivery are String in Dart and "true"/"false" in JSON, because they go raw into the payload. Mapper defaults: sendsTaxId: true, sendsDocumentData: true, userQuotas: "50", totalSellInValPerAnnum: "1", isTaxRequired: "false", contactB2bStatus: "Inactive".Note los bools textuales: isTaxRequired, restrictedOrderEdit e isPartialDelivery son String en Dart y "true"/"false" en JSON, porque van crudos al payload. Defaults del mapper: sendsTaxId: true, sendsDocumentData: true, userQuotas: "50", totalSellInValPerAnnum: "1", isTaxRequired: "false", contactB2bStatus: "Inactive".

  • NewRetailDocumentRequirement documentRequirementsByType[type][] 4 campos

    Campo	Proto	DTO	Model	Entity
    id	—	String	—	String
    titleKey	—	String	—	String
    subtitleKey	—	String?	—	String?
    documentKeys	—	List<String>	—	List<String>

    É o acordeão "os documentos necessários são:" — puramente informativo, sem relação com os espaços de foto. subtitleKey só existe hoje no perfil individual_rsa_resident (África do Sul).This is the "the required documents are:" accordion — purely informative, unrelated to photo slots. subtitleKey today exists only on the individual_rsa_resident profile (South Africa).Es el acordeón "los documentos requeridos son:" — puramente informativo, sin relación con los espacios de foto. subtitleKey hoy solo existe en el perfil individual_rsa_resident (Sudáfrica).

  • NewRetailStartOfActivityDocument startOfActivityDocumentsByType[type][] 3 campos

    Campo	Proto	DTO	Model	Entity
    id	—	String	—	String
    labelKey	—	String	—	String
    isMandatory	—	bool	—	bool

    Tamanho da lista = máximo de fotos; quantidade de isMandatory: true = mínimo exigido. A ordem da lista casa com a ordem de captura e, no builder, com as posições do payload.List length = max photos; count of isMandatory: true = required minimum. The list order matches the capture order and, in the builder, the payload positions.Longitud de la lista = máximo de fotos; cantidad de isMandatory: true = mínimo exigido. El orden de la lista coincide con el orden de captura y, en el builder, con las posiciones del payload.

  • NewRetailLegalEntityFieldConfig legalEntityFieldsByType[type][] 4 campos

    Campo	Proto	DTO	Model	Entity
    fieldName → field	—	String?	—	NewRetailLegalEntityField
    isVisible	—	bool	—	bool
    isRequired	—	bool	—	bool
    isEditable	—	bool	—	bool

  • NewRetailAddressFieldConfig addressFieldsByType[type][] 5 campos

    Campo	Proto	DTO	Model	Entity
    fieldName → field	—	String?	—	NewRetailAddressField
    isVisible	—	bool	—	bool
    isRequired	—	bool	—	bool
    isFreeText	—	bool	—	bool
    isEditable	—	bool	—	bool

    isFreeText troca lista por campo de texto (é o que o Chile usa em região e comuna) e muda o que vai no payload: nome em vez de sfid. isEditable é lido pelo mapper mas nenhum mercado o declara hoje na lista de endereço.isFreeText swaps the dropdown for a text field (what Chile uses for region and comuna) and changes what goes on the wire: name instead of sfid. isEditable is parsed by the mapper but no market declares it in the address list today.isFreeText cambia la lista por un campo de texto (lo que Chile usa en región y comuna) y cambia lo que va en el payload: nombre en vez de sfid. isEditable lo lee el mapper pero ningún mercado lo declara hoy en la lista de dirección.

  • NewRetailOperationalDataFieldConfig operationalDataFieldsByType[type][] 3 campos

    Campo	Proto	DTO	Model	Entity
    fieldName → field	—	String?	—	NewRetailOperationalDataField
    isVisible	—	bool	—	bool
    isRequired	—	bool	—	bool

    A obrigatoriedade efetiva é isVisible && isRequired — é assim que a Classificação Local só é exigida na África do Sul, onde está visível e obrigatória.Effective requiredness is isVisible && isRequired — that is how Local classification is only enforced in South Africa, where it is both visible and required.La obligatoriedad efectiva es isVisible && isRequired — así la Clasificación Local solo se exige en Sudáfrica, donde está visible y obligatoria.

  • NewRetailContactFieldConfig contactFieldsByType[type][] 3 campos

    Campo	Proto	DTO	Model	Entity
    fieldName → field	—	String?	—	NewRetailContactField
    isVisible	—	bool	—	bool
    isRequired	—	bool	—	bool

• NewRetailUploadDispatcherPayloadInput raiz · entrada do builder (só domínio)root · builder input (domain only)raíz · entrada del builder (solo dominio) 46 campos

  Campo	Proto	DTO	Model	Entity
  retailType	—	—	—	NewRetailType
  vatNumber	—	—	—	String
  stateRegistration	—	—	—	String
  outletName	—	—	—	String
  commercialName	—	—	—	String
  countrySfid	—	—	—	String
  stateCode	—	—	—	String
  city	—	—	—	String
  district	—	—	—	String
  addressLine	—	—	—	String
  number	—	—	—	String
  addressContinue	—	—	—	String
  postalCode	—	—	—	String
  cellPhone	—	—	—	String
  phone	—	—	—	String
  email	—	—	—	String
  outletSubtypeSfid	—	—	—	String
  categoriesSold	—	—	—	List<CategoryForSale>
  operatingDays	—	—	—	List<String>
  openingTime	—	—	—	String
  closingTime	—	—	—	String
  breakStart	—	—	—	String
  breakEnd	—	—	—	String
  banner	—	—	—	String
  propertyType	—	—	—	String
  keyAccountType	—	—	—	String
  giro	—	—	—	String
  channel	—	—	—	String
  isB2BCustomer	—	—	—	bool
  isDirectSales	—	—	—	bool
  isNetworkParent	—	—	—	bool
  localClassificationName	—	—	—	String
  localClassificationOptionSfid	—	—	—	String
  localClassificationDefinitionSfid	—	—	—	String
  localClassificationDefinitionType	—	—	—	String
  contacts	—	—	—	List<NewRetailContactEntity>
  wireConfig	—	—	—	NewRetailWireConfig
  resource	—	—	—	ResourceEntity
  market	—	—	—	EndMarket
  customerCode	—	—	—	String
  imagesBase64	—	—	—	List<String>
  latitude	—	—	—	double
  longitude	—	—	—	double
  submittedAt	—	—	—	DateTime
  deliveryDay	—	—	—	WeekDay?
  salesmanVisitDay	—	—	—	WeekDay?

  Freezed, nomes de domínio (giro, channel, vatNumber) — o rename para o wire acontece no builder. stateCode e city carregam sfid ou nome, conforme isFreeText; localClassificationOptionSfid carrega o sfid da opção (picklist) ou o valor digitado (número/texto).Freezed, domain names (giro, channel, vatNumber) — the wire rename happens in the builder. stateCode and city carry sfid or name, per isFreeText; localClassificationOptionSfid carries the option sfid (picklist) or the typed value (number/text).Freezed, nombres de dominio (giro, channel, vatNumber) — el rename al wire ocurre en el builder. stateCode y city llevan sfid o nombre, según isFreeText; localClassificationOptionSfid lleva el sfid de la opción (picklist) o el valor escrito (número/texto).

Payload da transaçãoTransaction payloadPayload de la transacción

O BuildNewRetailUploadDispatcherPayloadUseCase monta um Map com 7 chaves de topo (a última condicional), serializado com jsonEncode no campo message do InboxTransactionRequest. Um dropdown por seção; colunas Campo JSON · Tipo · Origem do dado · Regra.BuildNewRetailUploadDispatcherPayloadUseCase assembles a Map with 7 top-level keys (the last one conditional), serialized with jsonEncode into the message field of InboxTransactionRequest. One dropdown per section; columns JSON field · Type · Data source · Rule.El BuildNewRetailUploadDispatcherPayloadUseCase arma un Map con 7 claves de nivel superior (la última condicional), serializado con jsonEncode en el campo message del InboxTransactionRequest. Un dropdown por sección; columnas Campo JSON · Tipo · Origen del dato · Regla.

Mappers

Todas as conversões são extension. O fluxo usa cinco direções, mas nenhuma estrutura usa as cinco:All conversions are extensions. The flow uses five directions, but no single structure uses all five:Todas las conversiones son extension. El flujo usa cinco direcciones, pero ninguna estructura usa las cinco:

O fluxo fala com dois repositories. O ReferenceDataRepositoryImpl (implementa ReferenceDataRepositoryInterface) injeta os 3 datasources + ConnectivityService + a flag useMockData + Ref, e responde por leitura e pelas duas checagens. O DispatcherRepositoryImpl responde pela escrita. Um dropdown por método — assinatura, retorno e comportamento; quem tem árvore de decisão a carrega dentro do próprio detalhe.The flow talks to two repositories. ReferenceDataRepositoryImpl (implements ReferenceDataRepositoryInterface) injects the 3 datasources + ConnectivityService + the useMockData flag + Ref, and answers for reads and the two checks. DispatcherRepositoryImpl answers for the write. One dropdown per method — signature, return and behavior; whoever has a decision tree carries it inside its own detail.El flujo habla con dos repositories. El ReferenceDataRepositoryImpl (implementa ReferenceDataRepositoryInterface) inyecta los 3 datasources + ConnectivityService + la flag useMockData + Ref, y responde por la lectura y las dos verificaciones. El DispatcherRepositoryImpl responde por la escritura. Un dropdown por método — firma, retorno y comportamiento; quien tiene árbol de decisión lo lleva dentro de su propio detalle.

ReferenceDataRepositoryImpl

DispatcherRepositoryImpl

Um card por datasource (dropdown), com dropdown aninhado por método. No corpo: método, envio, retorno, fluxo de uso e tratamento de erro.One card per datasource (dropdown), with a nested dropdown per method. In the body: method, what it sends, return, usage flow and error handling.Un card por datasource (dropdown), con dropdown anidado por método. En el cuerpo: método, envío, retorno, flujo de uso y manejo de errores.

Um dropdown por enum, com todos os valores. Os enums de campo (NewRetail*Field) são o vocabulário fechado que a configuração do mercado pode usar — chave desconhecida cai em unknown e o campo simplesmente não é renderizado.One dropdown per enum, with every value. The field enums (NewRetail*Field) are the closed vocabulary market configuration may use — an unknown key falls to unknown and the field is simply not rendered.Un dropdown por enum, con todos los valores. Los enums de campo (NewRetail*Field) son el vocabulario cerrado que la configuración del mercado puede usar — una clave desconocida cae en unknown y el campo simplemente no se renderiza.

Cinco UseCases servem o fluxo — dois de leitura/checagem, um de leitura das listas e dois de escrita. Um dropdown por UseCase, com Método · Retorna · Uso.Five UseCases serve the flow — two checks, one list read and two writes. One dropdown per UseCase, with Method · Returns · Use.Cinco UseCases sirven al flujo — dos verificaciones, uno de lectura de listas y dos de escritura. Un dropdown por UseCase, con Método · Devuelve · Uso.

O fluxo tem dois notifiers. O NewRetailFlowNotifier (@riverpod, with AsyncGuard<NewRetailFlowState>) é o cérebro das 9 telas: o build() cria a sessão de arquivos, registra a limpeza no ref.onDispose e devolve _load(source: local); o State (NewRetailFlowState, Freezed, 74 campos) é a fonte única de verdade de todo o assistente — configuração do mercado, listas de apoio, valores digitados, fotos, rascunho de contato e status do envio. O NewRetailDocumentValidationNotifier é um notifier síncrono e local da tela de validação de documento (Brasil). Toda validação de formulário acontece nos métodos privados _updateLegalEntity, _updateAddress, _updateOperationalData e _updateContactDraft, que recalculam erro e validade a cada tecla.The flow has two notifiers. NewRetailFlowNotifier (@riverpod, with AsyncGuard<NewRetailFlowState>) is the brain of the 9 screens: build() creates the file session, registers cleanup on ref.onDispose and returns _load(source: local); the State (NewRetailFlowState, Freezed, 74 fields) is the wizard's single source of truth — market configuration, supporting lists, typed values, photos, contact draft and submission status. NewRetailDocumentValidationNotifier is a synchronous, local notifier for the document-validation screen (Brazil). All form validation happens in the private methods _updateLegalEntity, _updateAddress, _updateOperationalData and _updateContactDraft, which recompute error and validity on every keystroke.El flujo tiene dos notifiers. El NewRetailFlowNotifier (@riverpod, with AsyncGuard<NewRetailFlowState>) es el cerebro de las 9 pantallas: el build() crea la sesión de archivos, registra la limpieza en ref.onDispose y devuelve _load(source: local); el State (NewRetailFlowState, Freezed, 74 campos) es la fuente única de verdad de todo el asistente — configuración del mercado, listas de apoyo, valores escritos, fotos, borrador de contacto y estado del envío. El NewRetailDocumentValidationNotifier es un notifier sincrónico y local de la pantalla de validación de documento (Brasil). Toda validación de formulario ocurre en los métodos privados _updateLegalEntity, _updateAddress, _updateOperationalData y _updateContactDraft, que recalculan error y validez en cada tecla.

Métodos — NewRetailFlowNotifierMethods — NewRetailFlowNotifierMétodos — NewRetailFlowNotifier