SM_84
| Pendência | Resolução |
|---|---|
| MILLEN-2274 | A API de integração com o Millennium estava calculando o campo SAIDAS.TOTAL de forma inadequada com relação ao valor do desconto. SOLUÇÃO: Foi feita a devida correção na versão Branches. |
| MILLEN-3615 | Causa/Motivo Havia uma falha no importador do Millenium que pegava o CFOP errado Solução Foi corrigido, estou anexando o arquivo Export.7z onde o cliente poderá testar sem esperar pela versão. |
| MILLEN-4806 | Explicação do Problema O Problema desta pendencia é que no XML enviado para a Sefaz o código(SKU) do produto possui um zero a mais, deixando o produto com um código inexistente e no momento que o Millenium processa esse código o sistema não encontra o produto no cadastro, o código do produto(SKU) conforme verificado é composto de 6 posições para o código do produto, 4 posições para o código da cor e 2 para o tamanho, totalizando 12 posições, notei que os pacotes cujo o produto está com 13 posições no XML dá a mensagem de produto não encontrado! A primeira ideia de solução é descobrir a causa raíz do problema, porém ao realizar novas vendas com o mesmo produto na versão do cliente o problema não ocorre mais, pois no XML o código é gerado corretamente com 12 digitos conforme se vê nas imagens abaixo. Provavelmente algum cadastro ou configuração não estava correto no momento da venda desses produtos, o sistema tem um parâmetro nas configurações do Store (em Vendas->Codigo Alfanúmerico) que se não estiver marcado o sistema pode entender como um código EAN 13 e gerar o 13º dígito, porém pelo arquivo storemanager.ini enviado esse parametro estava flegado corretamente. Solução Diante da não simulação da raíz do problema, estou anexando os dois pacotes já corrigidos manualmente para que essas vendas possar ser integradas ao Millennium. Abaixo os pacotes corrigidos: SM-20201223-03-1-291095551.zip SM-20201210-03-1-263111118.zip Esses pacotes estavam no diretorio da pendencia(imagem abaixo) e após o ajuste que fiz eles foram processados corretamente. Reincidência do Problema Se o problema voltar acontecer novamente, deve-se abrir o arquivo zipado do pacote com erro, e observar no(s) arquivo(s) XML_NFE.blob se o código gerado na tag <cprod> está com um 0 a mais totalizando 13 caracteres. depois pedir para o cliente realizar uma venda teste (valor simbólico) com o mesmo produto e tentar simular o mesmo problema, se conseguir simular enviar uma nova base do STORE e arquivo storemanager.ini da estação onde foi constado o problema para eu possa atuar na causa raiz com o cenário reproduzível, depois pode remover manualmente esse 13º digito para que essas vendas possam ser integradas sem a necessidade de esperar a analise do programador. |
| MILLEN-5431 | Alteração Storemanager.dll Causa/Motivo Sistema tinha um falha ao gerar o arquivo FDB a partir do DBCOPY.Bak das versões 3.0 e HQBird3 Solução Foi corrigido a falha, abaixo os passos para configuração das contingências do StoreManager nas versões do Firebird. CONTIGÊNCIA NO FIREBIRD 2.x Não é necessário realizar nenhuma configuração, apenas instalar o Store nas estações e todo o processo é feito de forma automática. (Processo igual ao que sempre funcionou) CONTIGÊNCIA NO FIREBIRD 3.x ou HQBIRD 3) 1) Em cada instalação deve ter um Firebird 3.0 instalado (Não é o HQBIRD mesmo que no server tenha HQBird) 2) No arquivo StoreManager.ini deve configurar as duas chaves abaixo. [Estação] VersaoAnteriorDB=0 VersaoDB=3 VersaoDb -> a versão do Firebird que o cliente estiver rodando no Server. VersaoAnteriorDB -> a versão anterior rodava antes, se é instalação nova, deixe com o valor 0. UPGRADE DE VERSÃO DO FIREBIRD O Mesmo processo deve ser feito também ao migrar de uma base de dados Firebird 2 para Firebird/HqBird 3 ou vice Versa. Toda vez que o Store é aberto, ele checa as duas chaves se estiverem com valor diferentes, ele recria a pasta C:\Store\WTSC de acordo com o versão configurada em VersaoDb. Se em versãoDb estiver valor 2, ele cria a pasta WSTC na estrutura do Firebird 2.x e assim por diante. Quando o Store cria a pasta WTSC, ele extrai um arquivo DBCOPY.FDB e coloca dentro desta pasta. neste momento as tags abaixo são igualadas(conforme abaixo) e não deve mais ser mexida em hipótse alguma. [Estação] VersaoAnteriorDB=3 VersaoDB=3 CONTIGÊNCIA NO STORE API (QUALQUER VERSÃO DO FIREBIRD) Não existe contingência no Store API (No formato convencional de trabalhar com o DBCOPY.FDB) ao ligar a Flag no Millennium Usa Exportador via API. o sistema nem cria mais a pasta WTSC. O Store API foi feito inicialmente na Versão por Caixa, a Versão por Servidor não foi implementada ainda. Na Versão por Caixa: cada Caixa deve ter um servidor Store Instalado com sua respectiva pasta wst_store configurada. Cada Caixa deve também ter um base do Store e um Firebird Instalado conforme a versão do Banco de Dados. o wtsdatasource.ini da pasta wts_store que está local neste caixa deverá apontar para esta base. Esta é a contingência na Versão API. caixa caixa é independente pois tem a sua base de dados local. e toda vez que ele consegue comunicação com o Millenium ele envia automaticamente as movimentações, bem como recebe os cadastros e alterações de preços realizados no BM POSSO USAR O STORE API com uma única do Store num servidor SEPARADO? Pode, mas não é recomendado, este servidor deve estar configurado a porta 6017 para enviar via API as movimentações de todos os caixas. Porém se esse servidor parar toda a operação vai parar porque os caixas não tem base local para trabalhar offline. Além disso, há reclamações de lentidão e travamento quando o Store está trabalhando desta forma com a base do Millenium no SAAS. |
| MILLEN-6136 | Após análise da base enviada pelo cliente não foi encontrado erro na leitura da etiqueta que foi lida normalmente, porém o sistema estava preparado para receber o peso nas posições de 08 a 12, e etiqueta consta o valor, então a etiqueta foi corrigida pelo cliente e o sistema passou a ler corretamente. |
| MILLEN-6187 | Alteração: CfeServer.exe Solução: Feita a Correção |
| MILLEN-6778 | CAUSA/MOTIVO Os produtos indicados possuíam kits cadastrados na tabela KITS com com apenas 1 produto filho, sendo que esses produtos filhos não estavam cadastrados na tabela PRODUTOS. SOLUÇÃO Aparentemente esses Kits não são reais, reavaliar esses Kits ou usar o comando sql abaixo. Usando o comando abaixo, eu negativei os códigos do produto pai e lancei novamente os produtos indicados na pendencia e foram bipados normalmente puxando o preço correto sem tb apresentar o erro. |