Problema na identificação e seleção da UF

[otachies]

Olá. Estou testando o checkout em minha loja e está quase 100%. Percebi 2 comportamentos que não condizem com o real funcionamento.

1) Quando o usuário não está logado e vai para finalizar a compra. Etapa de identificação está ativada e compra como anônimo também. Ao chegar no checkout, já pula para a etapa de frete. Sem identificação nenhuma. Todas as etapas aparecem ao mesmo tempo na tela. Segue screenshot.

Se clicarmos em uma outra etapa, como identificação, aparece normalmente e podemos prosseguir com o checkout

2) O Estado não é automaticamente selecionado. Ao preencher o endereço, ele não seleciona e nem salva o UF. Acontece com alguns endereços já cadastrados, em que o cliente tem que voltar para a edição do endereço e selecionar novamente.

www.inusual.com.br O checkout está ativo e pode ser visto esse comportamento.

[redati]

A questão do endereço, o estado não ter sido preenchido automaticamente, eu também acompanhei alguns casos, mas não tive tempo de checar o que esta acontecendo.

[elisei]

Olá @otachies

De fato nada ai faz sentido... Procure ver quais módulos você tem por aqui e que afetaria um checkout:

• Módulos de checkout (onesteps...)
• Métodos de Pagamento
• Métodos de envio
• Módulos do seu tema...

Sobre Region Isso é possível um indicativo de banco de dados conflitando region_id para o BRA

[elisei]

Olá @otachies

Teve algum progresso?

[otachies]

Opa, Bruno!

Na verdade não tive mais tempo de verificar isso. Mas percebi que no meu ambiente de testes a parte de identificação funciona corretamente. https://stage.inusual.com.br Vou analisar com calma o que pode estar causando isso.

O endereço continua o mesmo problema com o UF.

Em qua., 6 de abr. de 2022 às 15:29, Bruno @.***> escreveu:

Olá @otachies https://github.com/otachies

Teve algum progresso?

— Reply to this email directly, view it on GitHub https://github.com/elisei/full-checkout/issues/41#issuecomment-1090595993, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADZVHROYKXCYYTTBML36V73VDXJZVANCNFSM5SQKZFGQ . You are receiving this because you were mentioned.Message ID: @.***>

--

---

Otávio Manfroi Chies (54) 99923-9271

[elisei]

Olá @otachies

Bom por funcionar no stage você tudo que precisa para identificar o que ocorre e como corrigir a produção!

Sobre a UF verifique a sua tabela directory_country_region deve haver duplicidade ali para o "BRA". @redati Meu caro isso vale para ti tb!

PS. Notei o label bem estranho no formato, isso aqui resolve:

.fieldset .field.theme-full-checkout-fields-floating-label:not(.choice) .control ._additional-element-input { position: relative; }

[redati]

Salve @elisei SELECT * FROM directory_country_region WHERE country_id LIKE '%BR%' Minha tabela directory_country_region, não tem valor BRA, apenas BR, 27 registros mesmo relacionados ao BR como esperado.

SELECT * FROM directory_country WHERE country_id LIKE '%BR%' country_id | iso2_code | iso3_code BR | BR | BRA

[elisei]

@redati mas são 27! rs

[redati]

@elisei, sim, 27, eu que olhei errado rs.

[elisei]

@redati menos mau! rs

Eu preciso de ajuda para entender o erro (eu nunca vi) mas aqui: https://github.com/elisei/auto-complete-address-br/blob/Magento%402.4/Controller/Postcode/Address.php#L148 é a lógica que pega o UF + o BR e faz o load para saber qual o ID do region_id

Diga para mim, qual API está usando? Sabe quais CEP's não estão preenchendo?

---

A causa mais provável que imagino é alguma das respostas da API (lembrando que são 3 as possíveis) não estar retornado uma UF válida!

[redati]

@elisei , estou usando viacep. Estou tentando investigar aqui também.

Eu acabei não anotando os ceps de clientes que tiveram o problema, vou tentar localizar aqui.

[redati]

Estou achando que isso é apenas um problema para clientes antigos onde estavam com valores diferentes no cadastro, como já foi utilizado vários módulos e um bd migrado do magento 1. Encontrei BR, BRA, Brasil e null na tabela de endereços de clientes clientes, sendo esses valores deferentes de BR, de clientes mais antigos. Não tenho logs aqui de registros de novos clientes com este erro.

Esse era um deles, mas o retorno esta correto: https://viacep.com.br/ws/49026100/json/ { "cep": "49026-100", "logradouro": "Avenida Oviêdo Teixeira", "complemento": "", "bairro": "Jardins", "localidade": "Aracaju", "uf": "SE", "ibge": "2800308", "gia": "", "ddd": "79", "siafi": "3105" }

[elisei]

Era exatamente esse o ponto!

Eu tenho um módulo que em breve devo tornar público tb que corrige os "cadastros antigos" na essência é uma cli que da load nos address e deleta endereços inválidos... (alem de migrar o taxvat para o vat_id)...

[otachies]

Opa! Acho que estava tendo algum problema na compactação do CSS/JS. Agora a identificação voltou a funcionar normalmente. Não tenho certeza o que foi, pois fiquei um tempo fora, habilitamos alguns outros métodos de pagamento (pagar.me) e agora está funcionando a identificação.

Quanto ao UF, percebi que na minha tabela não tem os códigos (UFs). O que tenho é o nome nas duas colunas.

Alterando os códigos, tende a funcionar?

Aproveitando o tópico, percebi outra coisa. Hoje uma cliente não estava conseguindo finalizar, pois o telefone dela estava incompleto. Ela cadastrou com (11)- se cadastrar apenas o 11 o campo fica vazio. Mas com o traço passou e deu problema na hora de emitir o pedido pelo meio de pagamento.

[otachies]

UPDATE: alterei o código dos estados e funcionou normalmente. Obrigado.

Agora é só essa questão do telefone. Não sei como a cliente conseguiu a única forma de não cadastrar. Colocar os dígitos do DDD e um traço. Qualquer caractere vira um traço.

Parece que ele considera que se há um traço, o numero está completo.