Mudanças entre as edições de "Versão/mobile/v3.13.19"
Ir para navegação
Ir para pesquisar
| Linha 45: | Linha 45: | ||
*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 | ** 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 | + | ** 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 atribuir ao valor 'S' também como aprovado como a regra define. |
| − | ** Quando havia a validação de CPF/CNPJ já existente, se o dado | + | ** Quando havia a validação de CPF/CNPJ já existente, se o dado tivesse espaços em branco o sistema apresentava inconsistência 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. | + | ** 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. |
| + | ** Quando o vendedor realizava um pedido e realizava o sincronismo em seguida, o aplicativo reseta os dados do buffer de condição de pagamento. Fazendo com que a comparação de objeto da condição de pagamento falhasse ao tentarmos editar o pedido, e não carregasse a condição de pagamento do pedido. A correção foi feita na hora de comparar os dados, que agora esta sendo feita pelo código da condição e não mais pelo objeto. | ||
* Cliente afetado | * Cliente afetado | ||
** Vaccinar | ** Vaccinar | ||
Edição das 12h01min de 8 de agosto de 2016
Público do documento
- Desenvolvimento
- Shady
- Anderson
- Suporte
- Teste
Detalhes
- Data de liberação
- 22/07/2016
- Nome da versão
- Versão pai
- Link para versão:
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 atribuir ao valor 'S' também como aprovado como a regra define.
- Quando havia a validação de CPF/CNPJ já existente, se o dado tivesse espaços em branco o sistema apresentava inconsistência 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.
- Quando o vendedor realizava um pedido e realizava o sincronismo em seguida, o aplicativo reseta os dados do buffer de condição de pagamento. Fazendo com que a comparação de objeto da condição de pagamento falhasse ao tentarmos editar o pedido, e não carregasse a condição de pagamento do pedido. A correção foi feita na hora de comparar os dados, que agora esta sendo feita pelo código da condição e não mais pelo objeto.
- 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