daycon

Boa tarde, Apos atualizar o ACBR, comecou a ocorrer erros de "Alíquota de serviço inválida" nas empresas da cidade de Itajuba. Parece que houve uma alteração no fonte do GovDigital do ACBr que passou a dividir a aliquota por 100. Para resolver foi incluido em ACBrNFSeXServicos.ini Params=NaoDividir100: Segue como ficou: [3132404] ; Atualizado em 10/07/2023 Nome=Itajuba UF=MG Params=NaoDividir100: Provedor=GovDigital Versao=2.00 ProRecepcionar=https://ws.nfe-cidades.com.br/ws/itj HomRecepcionar=https://ws.homolog.nfe-cidades.com.br/ws/itj Grato,

obrigado vc Italo

Boa tarde, A cidade de ITAJUBA-MG alterou o provedor de GINFES para NFE-CIDADES (GOVDIGITAL) Realizei a alteracao no arquivo ACBrNFSeXServicos.ini, conforme abaixo e conseguimos emitir a NFS. Por gentileza se puderem atualizar o repositorio. Dica: As empresas/clientes precisarao entrar no portal do NFE-CIDADES, clicar na opcao SOLICITACAO e pedir AUTORIZACAO PARA EMISSAO DE RPS. Infelizmente na transicao o pessoal da NFE-CIDADES deixou todas as empresas desativadas, mesmo as que ja emitiam NFS via WEBSERVICE pelo GINFES. Segue alteracao: [3132404] Nome=Itajuba UF=MG Provedor=GovDigital Versao=2.00 ProRecepcionar=https://ws.nfe-cidades.com.br/ws/itj HomRecepcionar=https://ws.homolog.nfe-cidades.com.br/ws/itj

Boa tarde, Algum comentario a respeito? Grato,

Boa tarde. Ao ocorrer um erro no ENVIAR() do ACBrNfe existe alguma propriedade que podemos utilizar para saber se o erro é uma rejeicao/sefaz (que deve ser tratada a nivel de alimentacao do XML), ou se é um erro de comunicacao que justifica entrar em contingencia? Notamos que alguns erros de comunicacao, seja no lado INTERNET/APLICATIVO ou seja do lado SEFAZ, acabam gerando um exception e no exception.message temos: Erro Interno: 0 Erro Interno: 10091 Erro Interno: 10090 e outros... Podemos assumir que ao detectar uma string "Erro Interno:" no e.message, seria motivo pra entrar em contingencia? Obs: Preocupacao é se este texto mudar no futuro ( AcbrConsts.pas ). Ou o melhor caminho seria verificar o cStat? Nos parece que erros de comunicacao, o cStat fica 0 e algumas vezes ja vimos -1 tambem. Se apos Enviar(), o cStat for > 0 apresentamos mensagem ao usuario, pois pode ser uma rejeicao/Sefaz que deve ser tratada na alimentacao. Caso contrario, se cStat <= 0, trata-se de erro de comunicacao, e marcamos este NFC como "pendente" e passamos pra modo contingencia... Seria algo neste sentido que estao fazendo para detectar contingencia? Ou existe uma propriedade confiavel no ACBrNfe que podemos consultar apos ENVIAR() para saber se houve erro na comunicacao? Obs: a informacao presente no cStat(AcNFE.WebServices.Enviar.cStat p/ sincrono e AcNFE.WebServices.Retorno.cStat para assincrono) é confiavel, quando ocorre erro de comunicacao? Grato,

Sim, deixamos de compilar manualmente e passamos a utilizar o AcbrInstall ja a alguns anos. Sobre AcbrLib no Delphi, ok, abortado a ideia... De inicio, pensamos em utilizar o AcbrMonitor, mas vimos que ele nao é multi tarefa, e como temos clientes que possuem 2, 3, 5 CNPJ no mesmo servidor, precisariamos rodar varias instancias do monitor, configurar portas diferentes (pra trabalhar em modo socket ao inves de arquivos) etc... Por hora, continuaremos com componente nativo mesmo entao. Daqui uns dias estaremos atualizando novamente o ACBR nas maquinas e vou analisar os passos que seguimos para desintalar e instalar uma nova versao. Obrigado pelo retorno Juliomar e Daniel.

Boa tarde. Existe alguma classe pronta do AcbrLib para ser usada a DLL no Delphi? como existe pras outras linguagens... Atualmente no Delphi instalamos o projeto ACBr direto na IDE. Mas sempre que precisamos atualizar os fontes do ACBR é um processo trabalhoso de desinstalar os pacotes, baixar versao atualizada via SVN (inúmeros arquivos), instalar os pacotes novamente. Assinando o PRO e usando o ACBrLib, bastaria baixar a DLL atualizada, sem envolver desinstalacao/instalação dos pacotes na IDE, correto?