...
Painel | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
Atualizar versões da(s) aplicações abaixo.
|
Painel | ||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||
|
Painel | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
01 - Foi relatado que o cliente estava usando a flag "USA_DESCONTO_PGTO" e na Tela do F10 onde chama essa rotina, não estava capturando o desconto qtde. Após a análise foi acrescentado o parâmetro de forma de pagamento na consulta da função "est_prod_desc_final". 02 - Havia uma dependência do PostgreSQL ,procedure de desconto , Orçamento e também por causa do PDV estava na ultima versão que fazia com que não valida-se corretamente. Não estava caindo na "p_est_prod_desc_final", porque esse orçamento estava deixando de passar o 6º parâmetro da rotina. Após a análise foi acrescentado o parâmetro de forma de pagamento na consulta da função "est_prod_desc_final",solucionando o problema. 03 - Estava permitindo finalizar um orçamento sem informar o cliente, quando a venda era para entrega. Foi alterado então o fluxo de finalização do orçamento para impedir a finalização caso não tenha o cliente informado. 04 - Quando havia caracteres especiais (acento/"ç") no nome do Comprador, ocorria um erro no serviço do novo concentrador de PBM's e, que impedia a Autorização da PBM TrnCentre. Após a análise foi alterado o método que faz a requisição junto ao concentrador, forçando o envio do JSON em codificação UTF-8, com a finalidade de solucionar o problema. 05 - Ao realizar um orçamento com pagamento por convênio, estava permitindo finalizar a venda sem informar o cliente. Foi então alterado para impedir a finalização da venda nestes casos. |
...
Painel | ||||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||||||||||||||||||||||||||
|
Painel | ||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
01 - Com esta nova integração foi solicitado que tanto o Gestão Pedidos quanto o orçamento possa além de realizar as vendas com emissão de cupom ,também permita realizar as vendas com emissão de nota fiscal, dedes a criação da pré-autorização até a confirmação/finalização da mesma, visto que com o Web Service não há dependência do TEF(pendente/atrelado ao PDV). 02 - Nesta customizações foi feito o gerenciamento de descontos diferenciados para clientes credenciados junto ao Parceiro Unimed, tendo a possibilidade de cadastrar novos clientes através desta nova forma de integração e dando e gerencia informações referente a parceria, validando efetivação da Parceria 03 - Link para a documentação completa desta customização: https://share.linx.com.br/x/0_MhDQ 03 04 - Havia a necessidade de integrar ao Orçamento\Pedidos a consulta de clientes e solicitação de autorização, aproveitamento deste dados para gerar um Orçamento/Pedido, avaliações e validações de receitas e envio automático dos XML das vendas realizadas por meio das pré autorizações, a gestão destes envios e relatórios da integração como um todo. 04 05 - Nessa customização foi criado o parâmetro "SIN_SOLUTION_CONDICAO_PAGAMENTO_DEFAULT" .Este parâmetro deve permitir informar uma condição de pagamento que foi cadastrada no sistema, para que seja acatada como default nos pedidos com Origem Sin Solution. Será exibido apenas o Código da condição de Pagamento selecionada. Sugestão de Local: Configuração > Cadastros Especiais > Configurações> Empresa > Aba: TeleVendas O televendas deve fazer a leitura do parâmetro supracitado e trazer por Default essa condição de pagamento para pedidos com Origem Sin Solution (Galderma). Ao realizar o lançamento de pedido Sin Solution deve ser apresentada esta condição por default, porém o usuário pode realizar alteração de condição sem nenhum problema. 05 - Foi relatado que o cliente estava usando a flag "USA_DESCONTO_PGTO" e na Tela do F10 onde chama essa rotina, não estava capturando o desconto qtde. Após a análise foi acrescentado o parâmetro de forma de pagamento na consulta da função "est_prod_desc_final". 06 - Havia uma dependência do PostgreSQL ,procedure de desconto , Orçamento e também por causa do PDV estava na ultima versão que fazia com que não valida-se corretamente. Não estava caindo na "p_est_prod_desc_final", porque esse orçamento estava deixando de passar o 6º parâmetro da rotina. Após a análise foi acrescentado o parâmetro de forma de pagamento na consulta da função "est_prod_desc_final",solucionando o problema. 07 - Quando havia caracteres especiais (acento/"ç") no nome do Comprador, ocorria um erro no serviço do novo concentrador de PBM's e, que impedia a Autorização da PBM TrnCentre. Após a análise foi alterado o método que faz a requisição junto ao concentrador, forçando o envio do JSON em codificação UTF-8, com a finalidade de solucionar o problema. |