eDocs - 5.8.14.51

Problema: ao fazer uma consulta de NSU em NF-e e CT-e, o eDocs não validava se a filial tinha problemas de certificado ou não. Desta forma, a consulta de NSU era sempre enviada para a SEFAZ.

Correção efetuada: ajustamos a consulta de NSU para NF-e e CT-e: caso a filial tenha algum problema de certificado, o envio de consulta de NSU será bloqueado.

Problema: a documentação sobre Manifestações do Destinatário, no tópico Resumos da NF-e tinha um link incorreto para o Processo de Geração de Nota fiscal de Transferência Via Nota Fiscal de Saída, no manual do Gestão Empresarial | ERP.

Correção efetuada: ajustamos o link para a versão correta.

Problema: ao fazer uma consulta de NSU em NF-e e CT-e, o eDocs não validava se a filial tinha problemas de certificado ou não. Desta forma, a consulta de NSU era sempre enviada para a SEFAZ.

Correção efetuada: ajustamos a consulta de NSU para NF-e e CT-e: caso a filial tenha algum problema de certificado, o envio de consulta de NSU será bloqueado.

Disponibilizamos a emissão de NFS-e de tomador estrangeiro para o município de Chapecó - SC por meio do fornecedor Chapecó (leiaute próprio).

A partir desta versão, homologamos o fornecedor Thema para fazer a integração de emissões de NFS-e do município de Venâncio Aires - RS.

A partir desta versão, homologamos o fornecedor Thema para fazer a integração de emissões de NFS-e do município de Santo Antônio da Patrulha - RS.

A partir desta versão, homologamos o recebimento de NFS-e para o município de Fraiburgo - SC via .XML e .PDF.

Ao emitir uma NFS-e para o município de União da Vitória - PR, havia rejeições porque a versão do fornecedor não estava correta. Com a mudança da Betha nos web services, a prefeitura em questão passou a ser suportada somente na versão 1.00.

Problema: ao emitir uma NFS-e para Capinzal - SC, os valores das tags <Aliquota> e <ValorIss> eram enviados incorretamente.

Correção efetuada: para este município, as tags <Aliquota> e <ValorIss> não serão enviadas caso a NFS-e seja emitida e prestada no próprio município e a tag <OptanteSimplesNacional> seja diferente de 1.

Problema: ao receber uma NFS-e, os valores unitários do grupo <Item> eram arredondados e traduzidos incorretamente.

Correção efetuada: ajustamos a rotina de recebimento de NFS-e a fim de que os valores unitários do grupo <Item> não sejam arredondados, mas sim integrados com os valores originais.

Ao emitir uma NFS-e para um município do fornecedor IPM Rest, se a nota tivese mais de uma parcela o eDocs enviava apenas as parcelas com as seguintes condições de pagamento: 05 - A prazo ou 03 - Cartão de Crédito. Com isto, o valor total não correspondia ao valor da nota.

A fim de resolver isso, ajustamos o sistema de forma que, caso a primeira parcela tenha a condição de pagamento 05 - A prazo ou 03 - Cartão de Crédito, o eDocs envie todas as parcelas.