SM_89
| Pendência | Resolução |
|---|---|
| MILLEN-2868 | Causa/Motivo O Método ListarTrocas não estava buscando o campo VENDEDOR_ITEM Solução Foi adicionado o campo Observação Alteração Aplicada na Branches Para resolver no cliente: 1) Acessar o servidor do store em: c:\wts_store e realizar uma cópia de backup do arquivo storemanager.wts 2) Abrir o ieditor e selecionar o arquivo storemanager.wts 3) Localizar o método API.MOVIMENTACOES.ListarTroca 4) Substituir todo o conteúdo do método pelo conteúdo do arquivo ListarTroca.txt |
| MILLEN-2896 | Causa/Motivo Sistema não gravava o campo DIFERENÇA quanto o fechamento não era por tela. Solução Feito a correção na dll do Client e também na integração para levar para o Millenium. |
| MILLEN-3102 | Configuração PAF TrakingFiles não lista certifica digital. Erro não ocorre mais. |
| MILLEN-3244 | CAUSA/MOTIVO SOLUÇÃO ALTERAÇÃO
|
| MILLEN-3277 | Causa/Motivo As implementações da Contingência para a base Firebird 3.0 aplicadas pela STOREMANU-976 causaram algumas instabilidades no processo de contingência com base Firebird 2.x. Foi feito implementação para adaptar o processo de contingência da versão 3.0 do Firebird e não foi devidamente testado o processo que já funcionava da versão 2.0 Solução Foram feitas as devidas correções para deixar o processo funcionando nas duas versões. Observação Ao instalar o Store o sistema por padrão irá subir o processo de contingência 2.0 (Fiz isso para diminuir trabalho de configuração nos clientes já implantados que tem muitos caixas e ainda não atualizaram para a versão 3.0) Caso o cliente deseje migrar para versão 3.0 do Firebird, deverá alterar o INI de cada estação na chave [Estação] os parâmetros abaixo: VersaoDb=3 VersaoAnterior=2 Desta forma, o sistema irá montar a pasta WTSC com a estrutura da versão 3.0. Se for firebird 2.0, não deve alterar nada no storemanager.ini e o processo deve funcionar normalmente. |
| MILLEN-3490 | Alteração Ajuste no cadastro de tipo de pagamento Causa/Motivo O Problema que ocorre está relacionado ao cadastro de tipos de pagamento, veja na imagem abaixo existe 3 cadastros de tipos de pagamento diferente para o mesmo propósito que é CRÉDITO - TEF Mesmo configurando TEF-CRÉDITO e TEF-DEBITO no meu de formas de pagamento na tela de venda do Store, quando for TEF o tipo de pagamento é selecionado automaticamente pelo sistema, consultando na base o tipo de pagto que acessa TEF conforme o cartão que foi passado (Débito ou Crédito), quando ele acha mais de 1 ele pega o primeiro que retornou no select. Importante lembrar que o tipo de pagamento é algo genérico, quando for TEF não deve ter tipos de pagamento indicando número de parcelas ou bandeiras, essas informações são devolvidas automaticamente pelo TEF, tipos de pagamento que acessam TEF deve possuir no máximo 2, TEF-CREDITO e TEF-DEBITO. Tipo de Pagamento impresso no Cupom Na impressão do Cupom o drive da impressora imprime como forma de pagamento as formas de pagamento que foram cadastradas direto no aplicativo da impressora fiscal. o que o sistema faz é fazer um DE-PARA, pelo nome do tipo que foi usado no Store para achar a forma de pagamento correspondente na impressora Solução Ajustar o cadastro deixando apenas 1 tipo de pagamento de TEF para crédito e outro para Débito. |
| MILLEN-4218 | Causa/Motivo Ocorria um erro na finalização da venda ao gravar os titulos Solução Foi corrigido o erro e também alterei a mensagem para que o cliente fique ciente, pois o crédito no Store só pode ser utilizado em sua totalidade, ou seja, ele não gera um novo titulo no millenium com o saldo restante a favor do cliente. Outro detalhe importante: O Store somente considera crédito do cliente se o titulo no contas a pagar estiver associado na mesma conta configurada em Configurações Gerais -> Comercial -> Gerais - Aba StoreManager -> Conta Caixa Crédito - StoreManager Observação Alteração aplicada na Branches do Store , porém como a dll storemanager.dll sofre poucas alterações, se colocar essa dll no cliente já vai funcionar. |