eDocs - 5.8.14.20

Com o objetivo tornar as informações sobre as rotinas do sistema mais objetivas, inserimos a seguinte informação referente à composição do nome do arquivo PDF nas configurações de Empresas e Filiais:

• Quando for gerado o PDF agrupado, a informação da sequência do documento será adicionada no nome do arquivo dentro ZIP gerado. Este comportamento ocorre para diferenciar os arquivos e evitar a sobreposição daqueles que possuem o mesmo nome.

Visando manter a documentação atualizada de acordo com o comportamento do sistema, atualizamos as informações referentes ao campo Tipo autenticação, nas configurações de Empresas e de Filiais, incluindo o link do Roteiro para configuração do OAuth2 - Microsoft.

Problema: ao gerar o PDF de um CT-e emitido do tipo complemento de valores, o campo Tipo do CT-e era exibido com uma quebra de linha indevida.

Correção efetuada: ajustamos a rotina de geração do DACTE aumentando a capacidade do campo Tipo do CT-e. Abaixo, segue a relação dos modelos de template que receberam esta alteração:

• Cte_Padrao_3;
• Cte_Padrao_3_A5;
• Cte_Padrao_3_Estendido;
• Cte_Padrao_4;
• Cte_Padrao_4_A5;
• Cte_Padrao_4_Estendido.

Os modelos de CT-e de recebimento não foram alterados.

Visando tornar mais objetivas as informações das notas da versão do sistema, alteramos a especificação dos locais afetados pela implementação da tarefa Atualização de schemas e NF-e / NFC-e conforme a Nota Técnica 001/2023 V1.20.

Como objetivo de manter o eDocs alinhado com as demandas governamentais, a partir desta versão, implementamos o suporte à integração da versão 2.1.2 dos leiautes dos arquivos EFD-Reinf.

Problema: ao realizar a integração de uma emissão de NF-e com o sistema Gestão Empresarial | ERP Senior, os comprovantes de entrega não retornavam o código correto e era apresentada a seguinte crítica de integração no eDocs: Não foi possível integrar o arquivo (c:\senior\sde\integração_99999(...).xml): O arquivo não segue o formato esperado.

Correção efetuada: ajustamos a rotina de integração com o sistema Gestão Empresarial | ERP Senior para que os códigos de retorno das críticas de integração dos comprovantes de entrega e dos cancelamento dos comprovantes de entrega de NF-e sejam devidamente integrados.

Problema: ao realizar uma emissão síncrona de NF-e, quando ocorria uma rejeição, era apresentado um retorno incorreto para a crítica, sendo ele: Referência de objeto não definida para uma instância de um objeto.

Correção efetuada: ajustamos a rotina de emissão síncrona de NF-e para que, quando ocorrer uma rejeição, seja apresentado o retorno correto de acordo com a situação da crítica.

Com o objetivo de tornar as rotinas do eDocs mais completas e eficientes, a partir desta versão, implementamos em Configurações > Filiais o campo Enviar arquivos adicionais/boleto em anexo para que seja possível selecionar que o DANFSE seja enviado por e-mail juntamente com o XML da NFS-e. Caso seja selecionada a opção Não para este campo, será realizado somente o envio do arquivo XML.

Com o objetivo de manter a documentação do eDocs alinhada com rotinas das prefeituras, inserimos a seguinte informação para o fornecedor Fiorilli:

• A tag <MunicipioIncidencia> será enviada para a prefeitura apenas quando a tag <ExibilidadeISS> for igual a 1 - Exigível, 6 - Exigibilidade Suspensa por Decisão Judicial ou 7 - Exigibilidade Suspensa por Processo Administrativo. Nestes casos, a tag <MunicipioIncidencia> será preenchida com a tag InfSenior > MunicipioIncidencia. Caso contrário, ela será preenchida com as informaçõe sda tad Servico > CodigoMunicipio.

A partir desta versão, homologamos o fornecedor SigISS, versão 1.00, para realizar a integração de emissões de NFS-e para o município de Itapira - SP.

Problema: ao realiza a emissão de NFS-e pelo fornecedor NotaControl, versão 2.04, onde o município do prestador era diferente do município de emissão, a rotina calculava o município de incidência incorretamente e era gerada a seguinte crítica: E220 - Valor do ISSQN informado indevidamente. (Número RPS: XXX). 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 validação do município de incidência do fornecedor NotaControl, versão 2.04, para que o envio da alíquota e o valor do ISS sejam devidamente validados.

Com o objetivo de manter as rotinas do eDocs alinhadas com as demandas municipais, a partir desta versão, adicionamos a validação da ExigibilidadeIss para o fornecedor NotaControl, versão 2.04, no envio da alíquota. Para mais detalhes, acesse o Portal de Documentação Senior.

Com o objetivo de manter o eDocs alinhado com as demandas municipais, a partir desta versão, alteramos para Nota Control, versão 2.04, o fornecedor responsável pela integração de emissões de NFS-e do município de Duque de Caxias - RJ.

A partir desta versão, homologamos o fornecedor Betha Sistemas, versão 2.02, para realizar a integração de emissões de NFS-e para o município de Timóteo - MG.