MASTERSAF DFE VERSÃO 3.21.2
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.21.2:... 1 Município de Ipatinga (MG)... 1 Município de Rio Grande (RS)... 1 Correções...2 Emissor de Nota Fiscal de Serviço Eletrônica NFS-E... 2 Município de Bragança Paulista (SP)... 2 Município de Londrina (PR)... 2 Município de Marília (SP)... 2 Município de Pirassununga (SP)... 2 Município de Simões Filho (BA)... 2 Município de Videira (SC)... 2 Listagem de Municípios... 2 Emissor de Nota Fiscal Eletrônica NF-e... 3 Log de Impressão Automática... 3 Quantidade de caracteres na Carta de Correção... 3 Receptor de Nota Fiscal Eletrônica NF-e... 3 Colunas trocadas na Exportação de XLS... 3 SEFAZ-AM ao realizar Evento de Manifestação... 3 Listagem DANFE sem XML... 3 Retorno no formato XML... 4 Evento Manifestação... 4 Emissor de Manifestação do Destinatário MDF-e... 4 Consulta MDF-e... 4 Atualização...5 Pré-requisitos... 5
NOVAS FUNCIONALIDADES / MELHORIAS EMISSOR DE NOTA FISCAL DE SERVIÇO ELETRÔNICA NFS-E Municípios liberados na versão 3.21.2: Cidade UF WebService Upload Agrolândia SC X Apiúna SC X Araxá MG X Brusque SC X Campo Largo PR X Campo Mourão PR X Castro PR X Concórdia SC X Farroupilha RS X Guaramirim SC X Igrejinha RS X Indaial SC X Mamborê PR X Novo Hamburgo RS X Pinhais PR X Porto Velho RO X Rodeio SC X Santa Rosa RS X Suzano SP X Timbó SC X Várzea Paulista SP X Município de Ipatinga (MG) A Prefeitura de Ipatinga trocou o sistema de NFS-e do modelo ISSINTEL para o modelo ACTCON. Este modelo segue o padrão Abrasf 1.0. Município de Rio Grande (RS) Realizada a atualização legal conforme manual disponibilizado pela Prefeitura de Rio Grande (RS), que utilizava a integração via upload e agora é via WebService. 1
CORREÇÕES EMISSOR DE NOTA FISCAL DE SERVIÇO ELETRÔNICA NFS-E Município de Bragança Paulista (SP) Situação: Ao importar um arquivo de retorno da prefeitura com os dados de conversão do RPS, o sistema gravava corretamente os dados da NFS-e, porém mudava o status para Cancelado, mas deveria ser convertido. Solução: O sistema foi alterado, corrigindo a ponto que gravava o status do RPS. Município de Londrina (PR) Situação: Após converter um RPS com sucesso para a Prefeitura de Londrina (em produção), porém no log do RPS era apresentada a mensagem NFS-e aceita em homologação (não gera NFE). Solução: Após ajustes, a mensagem passa a ser apresentada somente quando o RPS for convertido em ambiente de homologação. Município de Marília (SP) Situação: Ao efetuar a importação de um arquivo de retorno da Prefeitura de Marília, o portal informava que o arquivo foi importado com sucesso, mas os RPS não eram atualizados. Solução: Adicionado script para atualização do campo ignorar_cabecalho_retorno para leiaute de Marília e adicionado tratamento específico para o município quanto à quebra de linha dos arquivos de retorno recebidos (upload). Município de Pirassununga (SP) Situação: A prefeitura rejeitava o arquivo gerado. Solução: Alterado o modelo da Prefeitura de Pirassununga de CONAM para GENERATIVAS. Município de Simões Filho (BA) Situação: Ao finalizar a sessão (método POS_ENVIO_LOTE), a prefeitura retornava o erro Cannot find dispatch method for {}finalizarsessao. Solução: Após alterações, o sistema efetua a leitura do XML de retorno da consulta de situação do lote. Município de Videira (SC) Situação: Para a Prefeitura de Videira (Modelo IPM), o arquivo de retorno gerava uma tag que o sistema não conseguia tratar, gerando um erro. Solução: Com os ajustes realizados, ao receber o retorno de RPS convertido, o sistema passa a ignorar o conteúdo da tag codigo_html, pois esta tag não contém dados que são utilizados para a atualização do RPS. Listagem de Municípios Situação: Ao pesquisar o menu Administração do Sistema > Listagem de Municípios > Município, não era apresentada Listagem de WebServices. A situação ocorria devido a diferença que havia no select no banco Oracle, em função de letras minúsculas e maiúsculas. Solução: O sistema foi alterado, corrigindo a situação descrita. 2
EMISSOR DE NOTA FISCAL ELETRÔNICA NF-E Log de Impressão Automática Situação: No processo de impressão automática de documentos fiscais eletrônicos no Portal DF-e, o log do processo não era registrado. O log era registrado como enviado para impressora e o usuário que solicitou impressão somente quando era a impressão manual era realizada. Solução: Após correção, o log passa a ser registrado corretamente. Quantidade de caracteres na Carta de Correção Situação: No Oracle, quando um texto possuía caracteres especiais, ele ocupava um tamanho maior do que a quantidade de caracteres, sendo necessário aumentar o tamanho da coluna de descrição da Carta de Correção no banco de dados. Solução: Alterado o tamanho da coluna da carta de correção de mil para dois mil caracteres. O sistema deve continuar validando mil caracteres na tela. RECEPTOR DE NOTA FISCAL ELETRÔNICA NF-E Colunas trocadas na Exportação de XLS Situação: Em Listagem NF-e Recebidos do Módulo Receptor NF-e, ao selecionar algumas NF-e e solicitar Download XLS no grid, era gerado um arquivo XLS que podia ser salvo na máquina do usuário. Ao se abrir este arquivo, os campos CNPJ do Destinatário e CNPJ do Fornecedor eram apresentados trocados no arquivo exportado do Portal Mastersaf DF-e. Solução: Alterada a geração do arquivo XLS para que as informações de CNPJ do Destinatário e CNPJ do Fornecedor sejam geradas nas colunas corretas. SEFAZ-AM ao realizar Evento de Manifestação Situação: No Módulo Receptor NF-e, ao realizar o Evento de Manifestação para SEFAZ-AM, ocorria Erro de Comunicação. Solução: O sistema foi alterado, corrigindo a situação. Listagem DANFE sem XML Situação: Foi identificado que a nota fiscal ou CTE constava em um CNPJ. Além disso, um usuário que não estava vinculado a essa empresa tentava consultar a chave de acesso no Semáforo e era apresentada uma mensagem informando que a nota ou CTE não se encontrava no sistema, registrando informação na Listagem de DANFEs Sem XML. Solução: Alterado ponto comum para o Receptor NF-e e o Receptor CT-e, onde é realizada validação para verificar se o recebimento já existe em alguma empresa do grupo do usuário que executa a consulta da chave. Caso este exista, também é validado se o usuário tem permissão para este CNPJ; se não tiver, o sistema apresenta semáforo vermelho e a mensagem: Documento Fiscal já recebido em outra empresa do grupo. Usuário sem permissão na mesma. 3
Retorno no formato XML Situação: Ao parametrizar no integrador.properties tipo_retorno_recebimento=xml, o retorno para recebimentos de NF-e continuavam a ser gerados em formato TXT. Solução: Alterado o sistema para gerar corretamente o retorno em XML. Evento Manifestação Situação: Após realizar Ciência da Operação e Confirmação da Operação em Evento Manifestação, o emissor cancelava a nota e esta era apresentada como Rejeitada no Módulo Receptor NF-e. Solução: Alterado o sistema para apresentar as notas com status correto. EMISSOR DE MANIFESTAÇÃO DO DESTINATÁRIO MDF-E Consulta MDF-e Situação: Na consulta do MDF-e, tanto para homologação quanto produção, para chaves emitidas fora do estado do Rio Grande do Sul, não era gerado retorno, denxando os campos vazios e apresentando erro no TomCat. Solução: Alterado o sistema, corrigindo a situação descrita. 4
ATUALIZAÇÃO PRÉ-REQUISITOS A versão 3.21.2 exige obrigatoriamente: versão 3.21.2 do IntegradorTXT (quando utilizada essa forma de integração). ATENÇÃO: A utilização do integrador em versões diferentes das indicadas acima pode 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.21.2: Número Descrição 01 Versão mínima exigida para o servidor de aplicação: Glassfish v3, TomCat 6, WebSphere 8 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 5