CLIENTE (LojaCliente) (STATUS: PARCIAL)
DocumentaçãDocumentação TéTécnica
| Nome do cliente | TO-DO |
| Nome do projeto | TO-DO |
| Biblioteca | wosk_loja_cliente |
| Token da Biblioteca |
1be199d8-98e8-4de7-a92c-e59c2f08edd6
|
|
URL de
|
https://isnapp.illimitar.pro/bibliotecas/1be199d8-98e8-4de7-a92c-e59c2f08edd6/wosk_loja_cliente |
| URL de |
https://hmg-isnapp.illimitar.pro/bibliotecas/1be199d8-98e8-4de7-a92c-e59c2f08edd6/wosk_loja_cliente |
| Data | ? |
SumáSumário
DocumentaçãDocumentaçãoTéTécnicaSumáSumárioHistóHistórico deVersõVersõesDescriçãDescrição Geral dos Processos- Fluxo do Processo
CritéCritérios deAceitaçãAceitação
HistóHistórico de VersõVersões
| Data | Modificado por | ||
| ? | 1.0 | Maykon | Estrutura inicial da |
DescriçãDescrição Geral dos Processos
O processo de integraçãintegração de Cliente Varejo éé composto por trêtrês componentes principais: WebService, Monitor e Queue, que atuam de forma encadeada e assíassíncrona para garantir consistêconsistência, escalabilidade e rastreabilidade das informaçõinformações.
O WebService éé acionado por meio de um Endpoint e representa o ponto de entrada da integraçãintegração. Ele recebe os dados cadastrais do cliente, executa validaçõvalidações estruturais e regras de negónegócio, aplica reestruturaçõreestruturações necessánecessárias (normalizaçõnormalizações, definiçõdefinições automáautomáticas e ajustes de campos) e persiste as informaçõinformações na base CLIENTES_VAREJO. ApóApós a confirmaçãconfirmação da transaçãtransação, os dados tornam-se elegíelegíveis para o fluxo de captura incremental.
O Monitor éé acionado periodicamente por um agendador (cron) e tem como responsabilidade identificar registros novos ou alterados a partir da DATA_PARA_TRANSFERENCIA. O componente mantémantém controle de estado (offset, chave de posiçãposição, filtros e situaçãsituação), permitindo continuidade segura entre execuçõexecuções. Durante o processamento, os registros sãsão consultados de forma paginada, sanitizados e enviados para a Queue, onde aguardam processamento assíassíncrono. Esse mecanismo evita sobrecarga, duplicidade de captura e perda de posiçãposição.
A Queue tambétambém éé acionada por cron e executa o processamento assíassíncrono das mensagens pendentes. Para cada item da fila, o sistema atualiza o status para "Enviando", realiza as transformaçõtransformações finais (normalizaçãnormalização de telefones, composiçãcomposição de endereçendereço, validaçõvalidações obrigatóobrigatórias e definiçãdefinição do tipo de pessoa), monta o payload de integraçãintegração e efetua a chamada ao endpoint externo. Conforme o retorno recebido, o registro éé marcado como processado com sucesso ou erro, sendo armazenadas informaçõinformações de auditoria, tempo de execuçãexecução e mensagens de diagnódiagnóstico.
De forma resumida, o fluxo operacional ocorre da seguinte maneira:
1) Endpoint →→ aciona WebService →→ valida e persiste CLIENTES_VAREJO
2) Cron →→ aciona Monitor →→ captura incremental →→ envia para Queue
3) Cron →→ aciona Queue →→ transforma →→ integra com sistema externo
Essa arquitetura separa claramente as responsabilidades de entrada, captura e envio, proporcionando maior robustez, controle transacional e tolerâtolerância a falhas.
Monitor
1. DESCRIÇÃDESCRIÇÃO DO FLUXO
O processo Monitor éé responsáresponsável por habilitar e executar a captura incremental de registros de CLIENTES_VAREJO, preparando-os para integraçãintegração assíassíncrona via Queue.
Ao ser acionado, o mémétodo run() recupera o estado anterior do monitor (offset, chave de posiçãposição, datas e filtros). Com base na situaçãsituação armazenada:
- Se CONCLUÍCONCLUÍDO (2) →→ o estado éé redefinido para PARADO (0).
- Se PARADO (0) ou EM EXECUÇÃEXECUÇÃO (1) →→ o processamento éé iniciado ou continuado.
Quando iniciado do estado PARADO:
- A data de posiçãposição e a data de iníinício sãsão redefinidas.
- O offset retorna a 0.
- A chave de posiçãposição éé limpa.
Em seguida:
- Os filtros sãsão normalizados.
- Define-se a DATA_PARA_TRANSFERENCIA mímínima caso nãnão informada.
O processo entra em loop de paginaçãpaginação utilizando OFFSET/FETCH:
1) Atualiza o monitor para situaçãsituação EXECUTANDO (1).
2) Executa a consulta paginada ordenada por DATA_PARA_TRANSFERENCIA.
3) Para cada registro retornado:
- Os valores sãsão tratados (trim).
- Atualiza-se o novo filtro de posiçãposição.
- O registro éé enviado para a Queue.
- Offset e posiçãposição sãsão persistidos.
O loop encerra quando nãnão háhá mais registros.
Ao final:
- O monitor éé marcado como CONCLUÍCONCLUÍDO (2).
Em caso de erro:
- O monitor éé marcado como PROBLEMA (4).
- A mensagem de erro éé armazenada no filtro.
2. DADOS NECESSÁNECESSÁRIOS PARA O ENDPOINT
Os dados capturados sãsão provenientes da viewQuery aplicada sobre CLIENTES_VAREJO.
Campos utilizados:
- CODIGO_CLIENTE
- CLIENTE_VAREJO
- CPF_CGC
- RG_IE
- ANIVERSARIO
- TIPO_LOGRADOURO
- ENDERECO
- NUMERO
- COMPLEMENTO
- BAIRRO
- CIDADE
- UF
- CEP
- PAIS
- IBGE
- PAIS_BC
- DDD
- TELEFONE
- DDD_CELULAR
- CELULAR
- EMAIL
- CODIGO_CONTATO
- FILIAL
- ESTRANGEIRO
- TIPO_VAREJO
- TIPO_BLOQUEIO
- CADASTRAMENTO
- OBS
- SEXO
- STATUS
- DATA_PARA_TRANSFERENCIA
ObservaçãObservação:
IBGE e PAIS_BC dependem de joins auxiliares (municímunicípio e paípaís).
3. REESTRUTURAÇÃREESTRUTURAÇÃO DOS DADOS
3.1 RecuperaçãRecuperação do estado do monitor
Momento: IníInício do run()
- offset ←← valor persistido
- chavePosicao ←← valor persistido
- dataPosicao ←← valor persistido
- filtro ←← valor persistido
- situacao ←← valor persistido
Regra:
- Se situacao = 2 →→ redefinir para 0
3.2 Reset ao iniciar execuçãexecução
Momento: Quando situacao ≠≠ 1
- dataPosicao ←← Data/hora atual
- dataIniciado ←← Data/hora atual
- offset ←← 0
- chavePosicao ←← ''
3.3 NormalizaçãNormalização dos filtros
Momento: Antes da query
- CODIGO_CLIENTE ←← '' se vazio
- DATA_PARA_TRANSFERENCIA ←←
•• valor informado →→ convertido para datetime
•• vazio →→ '2023-06-01 00:00:00'
3.4 AtualizaçãAtualização do estado para EXECUTANDO
Momento: Antes da consulta
- situacao ←← 1
3.5 PaginaçãPaginação dos registros
Momento: ExecuçãExecução da query
Regra:
- ORDER BY DATA_PARA_TRANSFERENCIA ASC
- OFFSET offset
- FETCH NEXT limiteConfigurado
3.6 SanitizaçãSanitização dos dados
Momento: Ao ler cada registro
TransformaçãTransformação:
- trim() em todos os campos
3.7 AtualizaçãAtualização do filtro de posiçãposição
Momento: ApóApós fetch()
- novoFiltro['CODIGO_CLIENTE'] ←← registro atual
- novoFiltro['DATA_PARA_TRANSFERENCIA'] ←← data do registro
3.8 Enfileiramento
Momento: Dentro do loop
OperaçãOperação:
- Queue::set()
ParâParâmetros:
- chave ←← CODIGO_CLIENTE
- payload ←← registro completo
- status ←← 'Aguardando IntegraçãIntegração'
- situacao ←← 0
3.9 AtualizaçãAtualização incremental da posiçãposição
Momento: ApóApós inserir na fila
- offset ←← offset + 1
- chavePosicao ←← CODIGO_CLIENTE
- dataPosicao ←← DATA_PARA_TRANSFERENCIA
3.10 FinalizaçãFinalização
Momento: Fim do loop
- situacao ←← 2 (ConcluíConcluído)
3.11 Tratamento de erro
Momento: catch(Exception)
- situacao ←← 4 (Problema)
- filtro['ERRORS'][] ←← mensagem + timestamp
4. PERSISTÊPERSISTÊNCIA DOS DADOS (BANCO DE DADOS)
4.1 Controle do monitorMéMétodo: _set("LojaCliente")
Dados persistidos:
- offset
- chavePosicao
- dataPosicao
- filtro
- situacao
- dataIniciado
- token
SituaçõSituações:
- 0 →→ Parado
- 1 →→ Executando
- 2 →→ ConcluíConcluído
- 4 →→ Problema
4.2 Fila de integraçãintegração
Classe: Queue
OperaçãOperação:
- INSERT / UPDATE em wosk_queue
Dados gravados:
- chave
- conteudo (payload)
- status
- situacao
- data_referencia
- token (quando reaproveitado)
5. RESULTADO DO PROCESSAMENTO
ExecuçãExecução normal:
- Monitor atualizado como CONCLUÍCONCLUÍDO (2)
- Registros enviados para Queue
ExecuçãExecução com erro:
- Monitor marcado como PROBLEMA (4)
- Mensagem registrada no filtro
6. OPERAÇÃOPERAÇÃO MANUAL –– capturar()
Permite capturar clientes especíespecíficos.
Fluxo:
- Recebe chave(s) (CODIGO_CLIENTE)
- Executa consulta direta
- Sanitiza os dados
- Reenvia para Queue
Regra adicional:
- Se jájá existir na fila →→ reaproveita token existente
Queue
1. DESCRIÇÃDESCRIÇÃO DO FLUXO
O componente Queue éé responsáresponsável pelo processamento assíassíncrono das mensagens de integraçãintegração relacionadas ao contexto "LojaCliente". O mémétodo run() éé acionado com um token identificador da mensagem a ser processada.
Inicialmente, o sistema recupera um item da fila utilizando o token informado. Caso exista conteúconteúdo pendente, o registro éé imediatamente atualizado para o status "Enviando", garantindo rastreabilidade e evitando reprocessamentos simultâsimultâneos.
Em seguida, o sistema inicia o processamento do payload (conteudo), realizando:
- Montagem dos dados de contato (telefone, celular, e-mail)
- NormalizaçãNormalização dos núnúmeros telefôtelefônicos
- ComposiçãComposição do logradouro completo
- ValidaçãValidação de cócódigos obrigatóobrigatórios (IBGE / BACEN)
- ConstruçãConstrução da estrutura final de integraçãintegração
- IdentificaçãIdentificação do tipo de pessoa (FíFísica / JuríJurídica)
ApóApós a montagem do objeto final, éé realizada a chamada ao endpoint externo de integraçãintegração (setIlli).
Dependendo do retorno:
- Sucesso →→ registro atualizado com situacao = 2
- Erro →→ registro atualizado com situacao = 4
Ao final, o tempo de execuçãexecução éé calculado e persistido junto ao resultado do processamento.
2. DADOS NECESSÁNECESSÁRIOS PARA O ENDPOINT
O processamento da fila pressupõpressupõe que o conteúconteúdo jájá tenha sido previamente estruturado. Os seguintes campos sãsão esperados:
Campos relevantes:
- CODIGO_CLIENTE
- CLIENTE_VAREJO
- CPF_CGC
- RG_IE
- ENDERECO
- TIPO_LOGRADOURO
- NUMERO
- COMPLEMENTO
- BAIRRO
- CIDADE
- UF
- CEP
- PAIS
- PAIS_BC
- IBGE
- TELEFONE
- DDD
- CELULAR
- DDD_CELULAR
- EMAIL
- SEXO
- STATUS
- ANIVERSARIO
- CADASTRAMENTO
- DATA_PARA_TRANSFERENCIA
- FILIAL
- TIPO_VAREJO
- ESTRANGEIRO
ObservaçãObservação:
Campos como IBGE e PAIS_BC devem estar previamente resolvidos. A ausêausência desses dados pode interromper o processamento.
3. REESTRUTURAÇÃREESTRUTURAÇÃO DOS DADOS
3.1 AtualizaçãAtualização de status inicial da fila
Momento: Imediatamente apóapós recuperar o item
Regra:
- situacao ←← 1 (Enviando)
3.2 Montagem dos contatos
Momento: IníInício do processamento do payload
TransformaçõTransformações:
- Remove caracteres nãnão numénuméricos de:
•• DDD
•• TELEFONE
•• DDD_CELULAR
•• CELULAR
- ConcatenaçãConcatenação:
•• TELEFONE →→ DDD + TELEFONE
•• CELULAR →→ DDD_CELULAR + CELULAR
- InclusãInclusão condicional:
•• Apenas se houver valor informado
3.3 ComposiçãComposição do logradouro
Momento: Antes da montagem do endereçendereço
Regra:
- logradouro ←← TIPO_LOGRADOURO + ENDERECO
3.4 NormalizaçãNormalização do CEP
Momento: Montagem da estrutura final
Regra:
- CEP →→ somente núnúmeros
- CEP →→ preenchido àà esquerda atéaté 8 dídígitos
3.5 NormalizaçãNormalização de campos numénuméricos
Momento: Montagem do endereçendereço
TransformaçõTransformações:
- NUMERO →→ somente núnúmeros
- RG_IE →→ somente núnúmeros
3.6 ValidaçãValidação de cócódigo IBGE
Momento: PréPré-integraçãintegração
Regra:
- ObrigatóObrigatório para clientes nacionais
- Se ausente →→ exceçãexceção
3.7 ValidaçãValidação de cócódigo BACEN
Momento: PréPré-integraçãintegração
Regra:
- PAIS_BC obrigatóobrigatório
- Se ausente →→ exceçãexceção
3.8 NormalizaçãNormalização da UF
Momento: Montagem do endereçendereço
Regra:
- Se UF inváinválida ou vazia:
•• Estrangeiro →→ "EX"
•• Nacional →→ vazio
3.9 DefiniçãDefinição do cócódigo IBGE
Momento: Montagem do endereçendereço
Regra:
- Nacional →→ usa IBGE informado
- Estrangeiro →→ "9999999"
3.10 ConversãConversão do STATUS
Momento: Montagem do objeto final
Regra:
- STATUS ≠≠ '1' →→ situacao ←← '0'
- STATUS = '1' →→ situacao ←← '1'
3.11 IdentificaçãIdentificação do tipo de pessoa
Momento: Montagem final
Regra:
- CPF_CGC > 11 dídígitos →→
tipo ←← JURIDICA
cnpj ←← normalizado (14 dídígitos)
ie ←← RG_IE normalizado
- CPF_CGC ≤≤ 11 dídígitos →→
tipo ←← FISICA
cpf ←← normalizado (11 dídígitos)
identidade ←← RG_IE normalizado
3.12 Controle de truncamento
Momento: Montagem do endereçendereço
Regra:
- logradouro →→ mámáx. 250 caracteres
- COMPLEMENTO →→ mámáx. 250 caracteres
4. PERSISTÊPERSISTÊNCIA DOS DADOS (BANCO DE DADOS)
Tabela de controle da fila:→→ wosk_queue
OperaçõOperações realizadas:
- AtualizaçãAtualização ao iniciar processamento
MéMétodo: set(..., 'Enviando', situacao = 1)
- AtualizaçãAtualização ao finalizar processamento
MéMétodo: set(..., retorno, mensagem, tempo, situacao)
SituaçõSituações possípossíveis:
- 2 →→ Processado com sucesso
- 4 →→ Erro no processamento
Dados registrados:
- ConteúConteúdo original
- Retorno do endpoint externo
- Mensagem de erro/sucesso
- Dump da requisiçãrequisição (CURL)
- Tempo de execuçãexecução
5. RESULTADO DO PROCESSAMENTO
Sucesso:
- situacao = 2
- Mensagem retornada pelo serviçserviço externo
Erro:
- situacao = 4
- Mensagem detalhada do erro
- Retorno estruturado indicando falha
6. ROTINAS AUXILIARES
prepare():
- Prepara o contexto da fila "LojaCliente"
notificar():
- Consulta registros com erro (situacao = 4)
- Envia notificaçãnotificação por e-mail
get():
- Recupera itens pendentes ou especíespecíficos
set():
- Persiste atualizaçõatualizações da fila
getConteudo():
- Extrai conteúconteúdo normalizado do payload
WebService
1. DESCRIÇÃDESCRIÇÃO DO FLUXO
O WebService recebe uma requisiçãrequisição contendo os dados cadastrais de um cliente varejo. Ao ser acionado, o mémétodo run() executa inicialmente o processo de validaçãvalidação dos parâparâmetros recebidos. Caso exista qualquer inconsistêinconsistência (campo obrigatóobrigatório ausente, tipo inváinválido ou tamanho excedido), a execuçãexecução éé interrompida e uma exceçãexceção éé retornada.
ApóApós validaçãvalidação bem-sucedida, os dados sãsão encaminhados ao mémétodo setClientesVarejo(), onde o processamento principal ocorre dentro de uma transaçãtransação de banco de dados. Nesse estáestágio, o sistema:
- Define automaticamente as datas de CADASTRAMENTO e DATA_PARA_TRANSFERENCIA.
- Ajusta o TIPO_VAREJO caso o valor informado nãnão exista na tabela de tipos váválidos.
- Determina o status de ESTRANGEIRO com base na UF.
- Remove o campo SEXO se estiver vazio.
- Normaliza o CEP quando necessánecessário.
- Determina o CODIGO_CLIENTE conforme regras de prioridade.
Em seguida, o sistema verifica se jájá existe um cliente cadastrado:
- Se NÃNÃO existir: realiza INSERT na tabela CLIENTES_VAREJO.
- Se EXISTIR: realiza UPDATE conforme regras de atualizaçãatualização.
Ao final, a transaçãtransação éé confirmada (commit). Em caso de erro, ocorre rollback.
O retorno do WebService inclui o CODIGO_CLIENTE definido e mensagens de status ("OK" / "Registrado com sucesso.").
2. DADOS PARA O ENDPOINT
| CAMPO | TIPO | TAMANHO | ||
|
CLIENTE_VAREJO
|
STRING | 40 |
Nome do cliente
|
sim |
|
FILIAL
|
STRING |
25 |
Nome ou
|
sim |
|
PF_PJ
|
INT | 1 |
Pessoa
Pessoa
|
sim |
|
ESTRANGEIRO
|
INT | 1 |
Estrangeiro /
Nacional
|
sim |
|
ENDERECO
|
STRING |
90
|
Nome da via/logradouro sem o tipo. | |
|
UF
|
STRING |
2
|
Sigla da unidade federativa ou indicador de estrangeiro. | |
|
RG_IE
|
STRING |
19
|
Documento de |
|
|
CPF_CGC
|
STRING |
19
|
Documento fiscal (CPF ou CNPJ). | |
|
CIDADE
|
STRING |
35
|
Nome da cidade do cliente. | |
|
COMPLEMENTO
|
STRING |
20
|
||
|
CEP
|
STRING |
9
|
||
|
TELEFONE
|
STRING |
10
|
||
|
ANIVERSARIO
|
DATETIME | DATETIME | Data de nascimento ou |
|
|
DDD
|
STRING |
4
|
||
|
SEXO
|
STRING |
1
|
||
|
OBS
|
STRING |
200
|
||
|
EMAIL
|
STRING |
100
|
||
|
BAIRRO
|
STRING |
35
|
Nome do bairro do |
|
|
STATUS
|
INT |
1
|
||
|
PAIS
|
STRING |
40
|
Nome do |
|
|
TIPO_LOGRADOURO
|
STRING |
10
|
Tipo do logradouro. | |
|
NUMERO
|
STRING |
10
|
||
|
DDD_CELULAR
|
STRING |
4
|
||
|
CELULAR
|
STRING |
10
|
ObservaçãObservação importante:
Mesmo nãnão sendo informado diretamente, o campo CODIGO_CLIENTE torna-se obrigatóobrigatório apóapós a fase de reestruturaçãreestruturação.
3. REESTRUTURAÇÃREESTRUTURAÇÃO DOS DADOS
3.1 Datas automáautomáticas
Momento: IníInício do processamento em setClientesVarejo()
- CADASTRAMENTO = Data/hora atual
- DATA_PARA_TRANSFERENCIA = Data/hora atual
3.2 ValidaçãValidação e ajuste do TIPO_VAREJO
Momento: Antes de persistir os dados
Regra:
- Se TIPO_VAREJO nãnão existir em CLIENTE_VAR_TIPOS:
TIPO_VAREJO = "CLIENTE VAREJO"
3.3 DeterminaçãDeterminação de ESTRANGEIRO
Momento: Antes da validaçãvalidação final
Regra:
- Se ESTRANGEIRO vazio:
ESTRANGEIRO = '0'
- Se UF = 'EX':
ESTRANGEIRO = '1'
3.4 RemoçãRemoção do campo SEXO
Momento: PréPré-validaçãvalidação
Regra:
- Se SEXO vazio:
Campo removido do payload
3.5 NormalizaçãNormalização do CEP
Momento: PréPré-validaçãvalidação
Regra:
- Se CEP informado e valor numénumérico = 0:
CEP = 'NULL()'
3.6 DefiniçãDefinição do CODIGO_CLIENTE
Momento: PréPré-validaçãvalidação obrigatóobrigatória
Regra de prioridade:
1) CODIGO_CLIENTE informado: utilizado apóapós trim()
2) Se vazio:
CODIGO_CLIENTE = CPF_CGC
3) Se ESTRANGEIRO = 1:
CODIGO_CLIENTE = RG_IE
3.7 ValidaçãValidação obrigatóobrigatória do CODIGO_CLIENTE
Momento: ApóApós reestruturaçãreestruturação
Regra:
- Deve existir
- Tipo string
- MáMáx. 14 caracteres
3.8 Filtro de busca (identificaçãidentificação do registro)
Momento: Antes de INSERT/UPDATE
Regra:
- Nacional:
filtro = CPF_CGC
- Estrangeiro:
filtro = CODIGO_CLIENTE
3.9 VerificaçãVerificação de existêexistência e controle de duplicidade
Momento: ApóApós definiçãdefinição do filtro e antes e durante o processo que decide entre INSERT ou UPDATE
Durante o processamento em setClientesVarejo(), apóapós a definiçãdefinição e normalizaçãnormalização dos campos obrigatóobrigatórios, o sistema executa uma consulta na tabela CLIENTES_VAREJO com o objetivo de identificar se o cliente jájá possui cadastro.
A busca éé realizada utilizando um filtro dinâdinâmico:
- Cliente nacional: filtro por CPF_CGC
- Cliente estrangeiro: filtro por CODIGO_CLIENTE
O registro mais recente éé recuperado com ordenaçãordenação decrescente por CADASTRAMENTO e limite de 1 resultado.
Caso NÃNÃO seja encontrado um CODIGO_CLIENTE váválido:
1) ValidaçãValidação de duplicidade (somente para clientes nacionais)
O sistema realiza uma segunda consulta verificando se jájá existe algum registro com o mesmo CODIGO_CLIENTE informado.
Essa validaçãvalidação evita inconsistêinconsistências onde um CODIGO_CLIENTE esteja associado a um CPF_CGC diferente.
Se encontrado: A execuçãexecução éé interrompida com exceçãexceção indicando conflito de identidade.
2) NormalizaçãNormalização do campo FILIAL
Se o valor de FILIAL for numénumérico: O sistema converte o cócódigo para o nome correspondente na tabela FILIAIS.
3) Complemento automáautomático do campo OBS
O sistema prefixa o texto: "Cadastrado Pelo PDV ILLIMITAR."
4) PersistêPersistência dos dadosÉdadosÉ executado um INSERT na tabela CLIENTES_VAREJO utilizando sqlPrepareInsert().
Caso SEJA encontrado um registro existente: O fluxo segue para a lólógica de atualizaçãatualização (UPDATE), preservando dados crícríticos conforme regras definidas.
3.10 ConversãConversão de FILIAL numénumérica
Momento: Apenas em INSERT
Regra:
- Se FILIAL numénumérica: FILIAL = Nome correspondente na tabela FILIAIS
3.11 Complemento automáautomático de OBS
Momento: INSERT
Regra:
- OBS = "Cadastrado Pelo PDV ILLIMITAR. {OBS}"
4. PERSISTÊPERSISTÊNCIA DOS DADOS (BANCO DE DADOS)
Tabela principal: CLIENTES_VAREJO
OperaçõOperações possípossíveis:
- INSERT
Quando: Cliente nãnão localizado
MéMétodo: sqlPrepareInsert()
- UPDATE
Quando: Cliente jájá existente
MéMétodo: sqlPrepareUpdate()
Campos controlados automaticamente:
- CODIGO_CLIENTE
- CADASTRAMENTO
- DATA_PARA_TRANSFERENCIA
- FILIAL (em update preserva valor original)
- TIPO_VAREJO (em update preserva valor original)
5. RESULTADO DO PROCESSAMENTO
Retorno padrãpadrão (sucesso):
- Mensagem: OK
- Mensagem Detalhada: Registrado com sucesso.
- CODIGO_CLIENTE
- CADASTRAMENTO
- DATA_PARA_TRANSFERENCIA
Em caso de erro:
- TransaçãTransação revertida (rollback)
- ExceçãExceção com prefixo:
"CLIENTES_VAREJO: {detalhes do erro}"
Exemplos de Request:
{
"UF": "MG",
"CEP": "06845330",
"DDD": "21",
"OBS": "",
"OMS": "0",
"key": "609d9139-3439-45ae-ad00-a3e5a9f835f1",
"PAIS": "BRASIL",
"SEXO": "M",
"EMAIL": "T.TESTE@GMAIL.COM",
"PF_PJ": "1",
"RG_IE": "94987713999",
"BAIRRO": "PADRE EUSTÁEUSTÁQUIO",
"CIDADE": "BELO HORIZONTE",
"FILIAL": "ESTOQUE CENTRAL",
"NUMERO": "370",
"STATUS": "1",
"CELULAR": "",
"CPF_CGC": "99999999999",
"eventId": "d061d60d-d2bc-4181-a224-881ebf4ded07",
"ENDERECO": "CESÁCESÁRIO ALVIM",
"TELEFONE": "999999999",
"ANIVERSARIO": "1993-07-04 00:00:00",
"COMPLEMENTO": "",
"DDD_CELULAR": "",
"ESTRANGEIRO": "0",
"TIPO_VAREJO": "VENDEDOR (C)",
"CLIENTE_VAREJO": "LOREM IPSUM",
"CODIGO_CLIENTE": "94987713999",
"TIPO_LOGRADOURO": "RUA"
}Exemplos de Response:
{
"UF": "MG",
"CEP": "06845330",
"DDD": "21",
"OBS": "",
"OMS": "0",
"key": "609d9139-3439-45ae-ad00-a3e5a9f835f1",
"PAIS": "BRASIL",
"SEXO": "M",
"EMAIL": "T.TESTE@GMAIL.COM",
"PF_PJ": "1",
"RG_IE": "94987713999",
"BAIRRO": "PADRE EUSTÁEUSTÁQUIO",
"CIDADE": "BELO HORIZONTE",
"FILIAL": "ESTOQUE CENTRAL",
"NUMERO": "999",
"STATUS": "1",
"CELULAR": "",
"CPF_CGC": "99999999999",
"eventId": "d061d60d-d2bc-4181-a224-881ebf4ded07",
"ENDERECO": "CESÁCESÁRIO ALVIM",
"Mensagem": "OK",
"TELEFONE": "999999999",
"ANIVERSARIO": "1993-07-04 00:00:00",
"COMPLEMENTO": "",
"DDD_CELULAR": "",
"ESTRANGEIRO": "0",
"TIPO_VAREJO": "VENDEDOR (C)",
"CADASTRAMENTO": "2025-09-25 15:58:07.000",
"CLIENTE_VAREJO": "LOREM IPSUM",
"CODIGO_CLIENTE": "94987713999",
"TIPO_LOGRADOURO": "RUA",
"Mensagem Detalhada": "Registrado com sucesso.",
"DATA_PARA_TRANSFERENCIA": "2026-02-03 11:41:39"
}Fluxo do Processo
CritéCritérios de AceitaçãAceitação
| Processo | Subprocesso | ||