Versão/mobile/v3.13.19 - Histórico de revisão

10.0.0.166: /* Clientes atendidos */

2016-08-08T12:13:06Z

Clientes atendidos

10.0.0.134: /* Correção de bugs */

2016-08-08T12:01:13Z

Correção de bugs

10.0.0.134: /* Branches utilizados para essa versão desde a versão anterior */

2016-08-08T11:52:37Z

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

10.0.0.166: /* Clientes atendidos */

2016-08-05T14:54:46Z

Clientes atendidos

10.0.0.166: /* Correção de bugs */

2016-08-05T14:52:32Z

Correção de bugs

10.0.0.166: /* Branches utilizados para essa versão desde a versão anterior */

2016-08-05T14:32:36Z

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

10.0.0.166: /* Correção de bugs */

2016-08-05T12:29:02Z

Correção de bugs

10.0.0.166: /* Correção de bugs */

2016-08-05T12:25:47Z

Correção de bugs

10.0.0.166: /* Branches utilizados para essa versão desde a versão anterior */

2016-08-05T12:24:27Z

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

10.0.0.166: /* Clientes atendidos */

2016-08-05T12:24:01Z

Clientes atendidos

@@ Linha 24: / Linha 24: @@
 ** 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=

@@ Linha 45: / Linha 45: @@
 *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 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 continha espaços em branco o sistema apresentação incosistencia de informação.
+** 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.
 * Cliente afetado
 ** Vaccinar

@@ Linha 35: / Linha 35: @@
 * bugfix-vaccinar-cadastro-cpf
 * hotfix-tokenizacao-cond-pgto
 =Liberação de funcionalidade=

@@ Linha 23: / Linha 23: @@
 ** 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
 =Mudança na infraestrutura=

@@ Linha 45: / Linha 45: @@
 ** 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.
 * Cliente afetado
 ** Vaccinar

@@ Linha 50: / Linha 50: @@
 * 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.
 * Link para issue tracker
 ** N/A

@@ Linha 32: / Linha 32: @@
 * hotfix-remessa-futura-sempre-aprovavel
 * hotfix-verificacao-item-pendente
 =Liberação de funcionalidade=