MASTERSAF DFE VERSÃO 3.18.0
SUMÁRIO Novas funcionalidades / Melhorias... 1 Emissor de Nota Fiscal de Serviço Eletrônica NFS-e... 1 Municípios liberados na versão 3.18.0... 1 Correções... 1 Emissor de Nota Fiscal de Serviço Eletrônica NFS-E... 1 Municípios de Araquari (SC), Montes Claros (MG) e Ijuí (RS)... 1 Município de Contagem (MG)... 1 Município de Florianópolis (SC)... 1 Município de Juiz de Fora (MG)... 1 Municípios de Marília, Mogi Mirim e Mogi Guaçu (SP)... 1 Município de Mogi das Cruzes (SP)... 2 Município de Patos de Minas (MG)... 2 Município de Videira (SC)... 2 Integração WebService... 2 Município de São Paulo (SP)... 2 Pesquisa de Período... 3 Emissor de Nota Fiscal Eletrônica NF-e... 3 Campo Forma NT 2011.002... 3 Detalhamento de nota de cana... 3 Separadores de valores do DANFE... 4 Inutilização via WebService de nota autorizada... 4 Parametrização no DANFE... 5 Receptor de Nota Fiscal Eletrônica NF-e... 5 Assinatura na Importação de Nota... 5 Importação de Nota Fiscal de Recebimento... 5 Erro não catalogado... 5 Geral... 5 Configuração do servidor de e-mail Campo From... 5 Atualização...6 Pré-requisitos para Atualização6
NOVAS FUNCIONALIDADES / MELHORIAS EMISSOR DE NOTA FISCAL DE SERVIÇO ELETRÔNICA NFS-E Municípios liberados na versão 3.18.0: Cidade UF WebService Upload Itanhaém SP X Natal RN X CORREÇÕES EMISSOR DE NOTA FISCAL DE SERVIÇO ELETRÔNICA NFS-E Municípios de Araquari (SC), Montes Claros (MG) e Ijuí (RS) Situação: Na tela Listagem de NFS-e, não era exibido o botão Consulta da NFS-e na prefeitura. Solução: Incluído no sistema os links de consultas NFS-e das prefeituras. Município de Contagem (MG) Situação: A URL para o município de Contagem em ambiente de produção era apresentada com uma barra a mais. Solução: O problema foi corrigido para que apresente apenas duas barras de URL. Município de Florianópolis (SC) Situação: Na geração do arquivo da Prefeitura de Florianópolis, o sistema gerava um valor fixo para o campo CFPS (modelo Florianópolis). O campo vem do leiaute de integração, porém o programa sempre gerava o valor 9201. Ao integrar um RPS para a prefeitura, esta retornava a rejeição: CFPS 9202 impróprio para tomador de outro estado. Solução: O sistema foi corrigido para gerar as informações corretamente. Município de Juiz de Fora (MG) Situação 1: No retorno da Consulta de Lote, a prefeitura retornava uma mensagem de código E180 (lote ainda não processado), porém o sistema Mastersaf DFE possui tratamento para o código 180. Solução 1: Alterado o sistema para que passe a tratar o código E180 ao invés de 180. Situação 2: Quando a prefeitura retorna RPS Já Informado, o sistema não efetuava a consulta de NFS-e por RPS para a atualização do status do RPS já informado. Solução 2: Implementado método de consulta de NFS-e por RPS, para que quando o RPS retorne com a rejeição da prefeitura RPS Já Informado, o portal efetue nova consulta e retorne o RPS já convertido. Municípios de Marília, Mogi Mirim e Mogi Guaçu (SP) Situação: Ao importar o arquivo de RPS no portal da prefeitura ocorria o erro: Mensagem: linha 1 Tamanho inválido de linha do registro Tipo 1 deve ser 32. Tamanho encontrado: 33. 1
Ao gerar o arquivo de integração para a prefeitura, as configurações eram apresentadas incorretamente, mesmo com o conteúdo correto. Solução: Alterado o sistema para gerar as configurações corretamente do arquivo como Dos\Windows ao invés Unix. Município de Mogi das Cruzes (SP) Situação: Na geração do arquivo no leiaute da Prefeitura de Mogi das Cruzes, ao integrar com a prefeitura ocorria a rejeição Mensagem: Invalid data format 10/62/013J ". O sistema gerava o arquivo para a prefeitura retirando um caractere para cada comando de quebra informado, deslocando assim a posição do leiaute. Solução: O sistema foi alterado para normalizar a geração do arquivo. Município de Patos de Minas (MG) Situação: Ao integrar com Patos de Minas, enviando uma nota fiscal, a prefeitura retornava uma rejeição, disparando assim a consulta individual. Solução: Alterado o sistema para que atualize o status rejeitado quando retornado um erro da prefeitura. Município de Videira (SC) Situação 1: Ao enviar para o link de homologação (que não existe), o XML de RPS não era trazido no detalhe da RPS, ocorrendo o erro RPS Detalhe Nao existe RPS com id = 1294". Solução 1: O sistema passa a exibir somente o botão de Download quando existir um ou mais XML relacionados ao RPS. Situação 2: Ao enviar tomador estrangeiro, nos XML de envio e RPS na tag, o codcidade do prestador é trazido, sendo que no arquivo de integração era informado 9999999. Solução 2: Alterada a geração do arquivo XML para que busque o codcidade do tomador. Situação 3: Ao enviar o campo indicacaocpfcnpj com o valor 3 (tomador não informado) nos XML de envio e RPS o valor E é trazido na tag, sendo que E refere-se ao tipo de tomador estrangeiro. O valor E é trazido na tag mesmo ao enviar o valor 0. Solução 3: O sistema foi ajustado para obedecer o valor enviado em indicacaocpfcnpj da seguinte forma nas tags do XML: Quando 1, a tag é preenchida com F. Quando 2, a tag é preenchida com J. Quando 4, a tag é preenchida com E. Quando o indicacaocpfcnpj for diferente de 1, 2 ou 4, a tag informa o valor enviado e a prefeitura rejeitará o RPS. Integração WebService Situação: Ao enviar um RPS com retorno de erro da Prefeitura, no retorno do GET, a tag idprocessamentorps não estava correta. No WebService GET, o RPS era recebido com idprocessamentolote preenchido e idprocessamentorps null (incorreto). Solução: Alterado o sistema para que ocorra o Retorno correto das informações. Município de São Paulo (SP) Situação: Para o ambiente de homologação, ao converter uma nota, a prefeitura não retornava seu número, sendo considerado aprovado e a prefeitura retornava um alerta. Ao invés de alterar o status para aprovado, o sistema realizava consulta individual. Solução: O sistema passa a alterar o status do RPS para aprovado. 2
Pesquisa de Período Situação: Ao clicar em Listagem NFS-e na versão 3.17.2, o portal apresentava o período com data início e fim do dia pesquisado. No entanto, ao clicar novamente no mesmo botão, os períodos apresentavam datas undefined, persistindo o problema mesmo ao atualizar a página no navegador. Solução: Alterado o sistema para que não ocorra mais o erro. EMISSOR DE NOTA FISCAL ELETRÔNICA NF-E Campo Forma NT 2011.002 Acesse: Administração do Sistema > Empresa Situação: Em Cadastro de Empresas, quando parametrizado o parâmetro Forma NT2011.002: como Conforme NT em ambiente de homologação, era gerado no XML no grupo destinatário conforme abaixo, de acordo com a NT2011.002: < CNPJ > 99999999000191 < xnome > NF-E EMITIDA EM AMBIENTE DE HOMOLOGACAO - SEM VALORFISCAL < IE/> Porém, conforme a Nota Técnica NT2011.004 no item 6.1 são eliminadas as validações de alteração do CNPJ e IE, mantendo apenas a alteração da Razão Social. Solução: Alterado o sistema para que, no ambiente de homologação, quando parametrizado Conforme NT seja alterado somente a Razão Social, conforme exigência da SEFAZ. Detalhamento de nota de cana Situação: Nas notas fiscais que possuem grupo Cana, ao detalhar a nota fiscal no Portal era apresentada uma inconsistência no campo Data Emissão DAR. Solução: A inconsistência no detalhamento de nota de cana foi ajustada. 3
Separadores de valores do DANFE Situação: No DANFE, os valores que deveriam ser separados por vírgula (,) eram separados por ponto (.). Solução: O sistema foi corrigido para gerar o DANFE com os separadores corretos. Inutilização via WebService de nota autorizada Situação: Ao enviar uma solicitação de Inutilização via WebService (Rest Client) para uma nota com status Autorizada, era apresentado o erro HTTP 500 erro interno. Solução: Alterado o sistema para retonar o erro HTTP 400 (Erros ao de validação/parser/argumentos ilegais descritos no Response Body). 4
Parametrização no DANFE Situação: Ao imprimir os DANFE, o valor unitário do produto era exibido indevidamente com seis casas decimais ao mesmo tempo em que no parâmetro de impressão era configurado para apenas duas casas. Solução: Alterado o sistema para considerar a informações que estão no cadastro da empresa Parâmetros de impressão de NF-e. RECEPTOR DE NOTA FISCAL ELETRÔNICA NF-E Assinatura na Importação de Nota Situação: Ao importar uma NF-e, era apresentado o erro Assinatura do Xml Inválida. Porém, não eram apresentados os erros ao consultar o validador da SEFAZ. Solução: O sistema foi alterado, corrigindo a situação de erro. Importação de Nota Fiscal de Recebimento Situação: O sistema permitia a importação de XML de terceiros no módulo Receptor NF-e no qual a tag tpnf constava como 0. Essa nota era de Entrada emitida por um fornecedor como Recebimento. Solução: Alterado o sistema para que quando a nota se tratar de entrada ser movida para a pasta: nfe_recebimento_nao_importado. Erro não catalogado Situação: Quando a SEFAZ de origem apresentava algum problema de comunicação (como lentidão no processo), era exibido o erro 999 - Rejeicao nao catalogada, que retornava o status Rejeitada. Solução: O sistema foi alterado para interpretar o erro de modo diferente e realize consultas em determinados períodos. GERAL Configuração do servidor de e-mail Campo From Criado o parâmetro email.from no arquivo de configuração email.properties da Mensageria, com a finalidade de que quando parametrizado, seja o e-mail padrão do remetente nas notificações via e-mail pelo sistema (módulo Mensageria). Nas atualizações pela mídia padrão do sistema, o campo é criado automaticamente. Em outras formas de atualização (cópia de arquivos, por exemplo), deve ser criado manualmente o parâmetro no arquivo de configuração, evitando inconsistências na inicialização da mensageria. Criado o parâmetro mail.smtp.from no arquivo de configuração context.xml do Portal (TomCat), com a mesma finalidade mencionada acima, porém, neste não é necessária a configuração obrigatória para outras formas de atualização do sistema. 5
ATUALIZAÇÃO PRÉ-REQUISITOS PARA ATUALIZAÇÃO A versão 3.18.0 exige obrigatoriamente: versão 3.18.0 do IntegradorTXT (quando utilizado essa forma de integração) ATENÇÃO: A utilização do integrador em versões diferentes das indicadas acima poderá provocar erros/rejeição na emissão na NFS-e, NF-e, CT-e, Receptor CT-e e NF-e. Para usuários de versões anteriores a 3.18.0: Número Descrição 01 Versão mínima exigida para o servidor de aplicação: Glassfish v3, TomCat 6 e Weblogic10.3.3 02 Versão exigida para o Banco de Dados SQLServer 2005/2008, Oracle 11g. 03 Siga o procedimento do instalador/atualizador disponível em: Contact Center \ Base de Conhecimento \ Mastersaf DFE \ Manuais Técnicos 6