Mudanças entre as edições de "Versão/mobile/v3.13.19"
Ir para navegação
Ir para pesquisar
| (8 revisões intermediárias por 2 usuários não estão sendo mostradas) | |||
| Linha 23: | Linha 23: | ||
** Atendendo a regra de negócio que diz que uma remessa futura não poderá ficar pendente de aprovação | ** 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 | ** 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 | ||
| + | ** Correção do erro da perda da informação de condição de pagamento no detalhe do pedido. | ||
=Mudança na infraestrutura= | =Mudança na infraestrutura= | ||
| Linha 32: | Linha 34: | ||
* hotfix-remessa-futura-sempre-aprovavel | * hotfix-remessa-futura-sempre-aprovavel | ||
* hotfix-verificacao-item-pendente | * hotfix-verificacao-item-pendente | ||
| + | * bugfix-vaccinar-cadastro-cpf | ||
| + | * hotfix-tokenizacao-cond-pgto | ||
| + | * hotfix-vaccinar-combo-cond-pgto | ||
=Liberação de funcionalidade= | =Liberação de funcionalidade= | ||
| Linha 41: | Linha 46: | ||
*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 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 | * Cliente afetado | ||
** Vaccinar | ** Vaccinar | ||
| Linha 48: | Linha 56: | ||
* Possíveis side effects da correção | * 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. | ** 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 | * Link para issue tracker | ||
** N/A | ** N/A | ||
Edição atual tal como às 12h13min 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
- Correção do erro da perda da informação de condição de pagamento no detalhe do pedido.
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