Felipe Augusto R.

Tempos atrás precisamos comunicar com a Balança Balmak BCK-30 e foi compatível com os protocolos da Toledo e Filizola. Funcionou normalmente utilizando o ACBrBal. Talvez esse modelo aí também funcione.

Boa noite pessoal. Estávamos tendo a seguinte rejeição ao validar a remessa com o suporte do Banco do Brasil: Tentamos questionar que o validador do próprio BB aceitava nosso arquivo normalmente, e o atendente respondeu: Portanto, realizei a alteração abaixo no arquivo ACBrBancoBrasil.pas, pedi para validarem novamente e informaram estar correto desta nova maneira: . Segue anexo o arquivo com as alterações para avaliação/inclusão ao repositório. Obrigado!! ACBrBancoBrasil.pas

O município de Barra Mansa/RJ alterou o provedor. De: TIPLAN Para: ISSNET Seguem os arquivos atualizados: Cidades.ini e ISSNET.ini Cidades.ini ISSNet.ini

Esse erro ocorre porque é necessário, antes de começar a transmitir, solicitar uma "faixa" de numeração RPS para utilização. Meio arcaico, mas é o que esse provedor orienta. Para fazer isso, leia o último parágrafo do manual no link que citei mais acima. Aqui tem mais detalhes sobre o erro e a solução também: https://basepro.com.br/wfenix//index.php?title=E004:_Esse_RPS_não_foi_enviado_para_a_nossa_base_de_dados._Número_do_RPS_em_que_ocorreu_o_erro:_1001

A Série para Barra Mansa/RJ exigida pelo provedor é 108. Dê uma olhada no "manual" de integração deles: http://www.issnetonline.com.br/barramansa/online/Login/Login.aspx?getFile=78

Isso aí parece um problema com a propriedade "DetalharServico". Desmarque a opção no componente do relatório e faça o teste.

Faça o teste alterando o arquivo Cidades.ini desta forma: [3300407] Nome=Barra Mansa UF=RJ Provedor=ISSNET NomeURL_H=barramansa NomeURL_P=barramansa E no arquivo ISSNet.ini, após a linha referente a cidade de Rio Brilhante, adicione a referência para Barra Mansa, conforme abaixo: ; Rio Brilhante/MS RecepcaoLoteRPS_5007208=http://www.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx ; Barra Mansa/RJ RecepcaoLoteRPS_3300407=http://www.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx Estando a ok a comunicação, comunique a troca do provedor neste tópico:

Boa tarde pessoal. Pesquisei, mas não encontrei nos fontes atualizados do ACBr. Houve alguma implementação referente a exibição da tag CodigoTributacaoMunicipio no DANFSe ?

Boa noite Juliana. Só consegui testar agora à noite no cliente e a comunicação funcionou com essas configurações. Atualize seus fontes que irá aparecer. Essa linha foi adicionada recentemente pelo @Italo Jurisato Junior.

Verifiquei aqui e será necessário ajustar no arquivo Cidades.ini a sessão de Duque de Caxias para: [3301702] Nome=Duque de Caxias UF=RJ Provedor=ISSNET NomeURL_H=www NomeURL_P=duquedecaxias E no arquivo ISSNet.ini, será necessário incluir a linha abaixo após a linha da cidade "Cascavel/PR": ; Cascavel/PR RecepcaoLoteRPS_4104808=http://www.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx ; Duque de Caxias/RJ RecepcaoLoteRPS=http://www.issnetonline.com.br/webserviceabrasf/%NomeURL_P%/servicos.asmx

Boa tarde! Também vi o comunicado ainda há pouco. No ACBr ainda não está atualizado, pois o novo provedor (ISSNET) entrou em operação hoje. Será necessário ajustar os arquivos .INI..

Muito obrigado, Juliana e Italo! Testada transmissão, cancelamento, consulta situação e RPS, impressão via site e DANFSE... Tudo funcionando 100%!

Bom dia! Conforme fora relatado no tópico abaixo, o webservice da prefeitura do Rio de Janeiro define as quebras de linhas com o próprio #13#10, não podendo ser removido ou substituído por ponto e vírgula, por exemplo, como faz o parse do ACBrNFSe atualmente (de forma correta, seguindo os padrões de tratamento do xml, mas que acaba embaralhando a discriminação do serviço ao visualizar via site). Esbarrei com o mesmo problema, pois quase todos os nossos clientes são da cidade do Rio de Janeiro e todos utilizam a impressão via site da prefeitura. E como no tópico relacionado não houve solução, mas um paliativo de alinhamento do dado com "." ou "_", então decidi abrir este tópico para apresentar a solução que encontrei e avaliarem se pode ser ajustado nos fontes. Conforme o Ítalo havia sugerido inicialmente, realizei a seguinte alteração na unit pnfsNFSeW_ABRASFv1 (linhas 374 e 436), mas deixando o parâmetro dinâmico somente para o município do RJ: Para que o dado não fique sem o parse com tratamento de retirada de acentos e espaços, ao alimentar o componente, sempre chamo a seguinte função de pcnAuxiliar para o texto de discriminação: Além disso, no arquivo RJ.ini, deixei vazio o parâmetro de quebra de linha: "QuebradeLinha=" E o mais importante: Como o webservice da prefeitura do RJ não exige a assinatura dos documentos e sempre enviamos assim quando fazíamos por fora do ACBr, então alterei para 0 todas as opções de assinatura no mesmo arquivo "RJ.ini", pois era o principal problema relatado no tópico anterior, devido o método de assinatura remover as quebras de linha (#13#10) do XML. Feito isso, a NFS-e foi transmitida com sucesso e com as devidas quebras de linha. Em anexo estão a unit e o arquivo RJ.ini com as alterações realizadas para avaliação. RJ.ini pnfsNFSeW_ABRASFv1.pas

Boa tarde! Estamos testando este layout do Fast. E em relação ao Fortes, procurei, mas não encontrei.. Então apenas para confirmar... Essa implementação do novo layout com QR Code também já está disponível para o Fortes Report no ACBr? Obrigado!

Boa tarde, pessoal. Há alguma notícia sobre a viabilidade/possibilidade dessa integração pelo ACBr? Segue documentação da API do webservice de transmissão da DU-e, caso necessitem: https://val.portalunico.siscomex.gov.br/docs/api/