eDocs - 5.8.14.9

Problema: ao tentar realizar a exclusão de uma filial no sistema eDocs, o processo não era concluído corretamente quando havia um evento de Reinf integrado no banco de dados do sistema.

Correção efetuada: ajustamos o comportamento do sistema para que, quando for solicitada a exclusão de uma filial, o processo exclua também os eventos de Reinf vinculados à filial selecionada para exclusão.

Com o objetivo de manter o eDocs atualizado de acordo com as demandas municipais, a partir desta versão, homologamos o fornecedor Web Iss, versão 2.02, para realizar as emissões de NFS-e do município de Catu - BA.

A partir desta versão, homologamos o fornecedor Web Iss, versão 2.02, para realizar as integrações de emissões de NFS-e do município de Extrema - MG.

Com o objetivo de manter o eDocs atualizado de acordo com as demandas municipais, a partir desta versão, homologamos o fornecedor IPM, versão 2.04, para realizar as emissões de NFS-e do município de Araucária - PR.

Problema: na documentação do fornecedor Smarapd havia uma observação dizendo que, devido uma alteração de URL da prefeitura, a emissão de NFS-e do município de Itapevi - SP poderia passar por instabilidades.

Correção efetuada: removemos da documentação a observação que falava sobre as emissões de NFS-e do município de Itapevi - SP, pois a URL da prefeitura já foi alterada e o processo está funcionando sem instabilidades. Para mais detalhes, acesse o Portal de documentação Senior.

Problema: ao emitir uma NFS-e para o fornecedor NotaControl, versão 2.04, sem a tag <RegimeEspecialTributacao>, com a exigibilidade 1 - Exigível e com o município incidência igual ao município gerador do documento, a nota era rejeitada pela prefeitura, pois a tag <ValorIss > não deveria ser enviada, e era apresentada a seguinte crítica de integração: Crítica: E220 - Valor do ISSQN informado indevidamente. (Número RPS: XXXX) Solução: O valor do ISSQN será calculado pela Prefeitura e não deve ser informado pelo contribuinte.

Correção efetuada: ajustamos a rotina de emissão de NFS-e para o fornecedor NotaControl, versão 2.04, para que, quando a nota estiver sem a tag <RegimeEspecialTributacao>, com a exigibilidade 1 - Exigível e com o município incidência igual ao município gerador do documento, a tag <ValorIss > não seja enviada, seguindo as orientações descritas no manual da prefeitura.

Problema: a atualização da documentação do fornecedor IPM Rest não estava contemplando a rotina para envio de faturas/parcelas para as prefeituras.

Correção efetuada: incluímos na documentação do fornecedor IPM Rest as informações sobre o envio de faturas/parcelas para as prefeituras.

Problema: ao receber uma NFS-e via monitoramento na prefeitura do município de Barueri - SP, a nota não era integrada e por isso não era registrada na base de dados do sistema.

Correção efetuada: ajustamos a rotina de integração para que, ao receber uma NFS-e por monitoramento na prefeitura do município de Barueri-SP, o documento seja devidamente reconhecido e integrado na base de dados do sistema.

Problema: ao receber uma NFS-e para o município de Curitiba-PR a tag <valores> era retornada com valores incorretos.

Correção efetuada: ajustamos a rotina de integração para que, ao receber uma NFS-e para o município de Curitiba-PR, a tag <valores> seja devidamente retornada com valores coretos.

Problema: ao receber uma NFS-e para o município de Curitiba-PR, a Razão Social do prestador não era retornada.

Correção efetuada: ajustamos a rotina de integração de recebimentos para que, ao receber uma NFS-e para o município de Curitiba-PR, a Razão Social do prestador seja devidamente retornada.

Problema: para os municípios de Louveira-SP, Niterói-RJ e Recife-PE, ao receber uma NFS-e, era gerada a seguinte crítica de integração: Retorno tradução NFSe: 12-Data at the root level is invalid. Line 1, position 1.

Correção efetuada: ajustamos a rotina de integração para os municípios citados anteriormente para que, ao receber uma NFS-e, o documento seja devidamente reconhecido e a integração ocorra corretamente.

Problema: a documentação na lista de cidades homologadas para recebimentos de NFS-e apresentava a informação que o município de Itapoá - SC possuía a funcionalidade de monitoramento na prefeitura.

Correção efetuada: ajustamos a documentação para informar que o município de Itapoá - SC realiza somente integração via e-mail para recebimentos de NFS-e.

Problema: o cadastro de filiais não era realizado quando o sistema possuía a rotina de recebimentos de NFS-e ativa e era apresentada a seguinte mensagem no log: Erro ao consultar NFSe de recebimento. 607|A licença da sua empresa está CANCELADA e não será mais possível emitir este tipo de documento.

Correção efetuada: ajustamos o comportamento do sistema para que o cadastro de filias seja realizado corretamente quando o sistema possuir a rotina de recebimentos de NFS-e ativa.

Problema: ao receber uma NFS-e que possuía o caractere hífen (-) no código de verificação e a mesma nota já estivesse registrada na base do sistema sem a presença do caractere hífen, o documento ficava duplicado indevidamente na base de dados do sistema.

Correção efetuada: ajustamos a rotina de integração de recebimentos de NFS-e para que, ao receber uma nota, seja verificado se já existe algum documento na base de dados com o mesmo código de verificação sem a presença de caracteres especiais evitando assim o registro em duplicidade.

Com o objetivo de manter a documentação atualizada de acordo com o comportamento do sistema, a partir desta versão, ajustamos a ocorrência dos campos inscricaoMunicipal e razaoSocial do grupo Prestador do Leiaute PDF/XML padronizado - Recebimentos NFS-e.