Mudanças entre as edições de "Versão/mobile/v3.13.19"

De GeoSales
Ir para navegação Ir para pesquisar
Linha 35: Linha 35:
 
* bugfix-vaccinar-cadastro-cpf
 
* bugfix-vaccinar-cadastro-cpf
 
* hotfix-tokenizacao-cond-pgto
 
* hotfix-tokenizacao-cond-pgto
 +
* hotfix-vaccinar-combo-cond-pgto
  
 
=Liberação de funcionalidade=
 
=Liberação de funcionalidade=

Edição das 11h52min de 8 de agosto de 2016

Público do documento

  • Desenvolvimento
  • Shady
  • Anderson
  • Suporte
  • Teste

Detalhes

Clientes atendidos

  • Vaccinar
    • Atendendo a regra de negócio que diz que uma remessa futura não poderá ficar pendente de aprovação
    • Adicionando uma validação para remover espaços em branco do CPF/CNPJ
    • Correção do parceamento dos campos de parcela das condições de pagamento

Mudança na infraestrutura

Não foram feitas mudanças na estrutura da base de dados.

Branches utilizados para essa versão desde a versão anterior

  • hotfix-remessa-futura-sempre-aprovavel
  • hotfix-verificacao-item-pendente
  • bugfix-vaccinar-cadastro-cpf
  • hotfix-tokenizacao-cond-pgto
  • hotfix-vaccinar-combo-cond-pgto

Liberação de funcionalidade

Nenhuma

Correção de bugs

  • BUGS
    • O pedido de remessa futura estava ficando pendente mesmo a venda futura já ter sido aprovada Atendendo a regra de negócio que diz que uma remessa futura não poderá ficar pendente de aprovação
    • Quando um item de um pedido ia ser montado existia uma verificação que analisava o ID_AUTORIZADO. Essa verificação fazia com que se o campo tivesse vazio o item estava aprovado. Se o item tivesse os dados 'S' ou 'N' ele ficava pendente. Era nesse ponto aonde estava o erro. A correção consistiu de atibuir ao valor 'S' também como aprovado como a regra define.
    • Quando havia a validação de CPF/CNPJ já existente, se o dado continha espaços em branco o sistema apresentação incosistencia de informação.
    • Quando o pedido era instanciado os campos dsDiasParcelas e dsPrParcelas eram parseados por ; mas o campo dsPrParcelas tinha que ser parseado por , e por isso acontecia o erro.
  • Cliente afetado
    • Vaccinar
  • Versões onde o bug foi detectado
  • Possíveis side effects da correção
    • Essa mudança pode acarretar alguma incoerência caso ainda exista um local que não conseguimos visualizar que set os pedidos como pendente. Também pode acarretar uma piora da performace pois adicionamos mais verificações para salvar o pedido.
    • Se houverem outros cantos em que é utilizado o CPF/CNPJ e que não existe esse tratamento pode haver erro. Porém em nossa análise não conseguimos encontrar outro ponto de utilização desse dado.
  • Link para issue tracker
    • N/A