Painel de líderes

Boa tarde Felipe, A coisa é mais simples que você imagina: sProvedor := ACBrNFSeX1.Configuracoes.Geral.xProvedor;

Muito Obrigado! Vou passar para nosso suporte fazer a alteração manual.

Bom dia Fabricio, Já esta no SVN.

O problema aí é que não deveria vir NULL... o problema é no banco. Senão teriamos que fazer o tratamento para todos os campos e posições, já que não sabemos o que pode ser enviado... não faz sentido e não seria viável. Imaginando que foi um caso pontual no seu caso eu faria a alteração no arquivo subtituindo o NULL por zeros e faria a leitura. Caso a situação se repita em outros arquivos sugiro novamente acionar o suporte do banco, inclusive se for o caso solicitando que eles enviem uma documentação atualizada prevendo essa informação no arquivo.

Boa tarde Italo, Muito obrigado pelo retorno. a emissão eu estou usando o componente, para o cancelamento, o cliente me passou que estava usando um serviço próprio, vou pedir a ele, pra testar todos com o componente.

Boa tarde, Eu acredito que a falha estava na aplicação que estava enviando os DadosPFX, pois depois que instalava o certificado e exportava novamente exportando as chaves privadas, emitiu. No casos destes clientes estou fazendo pegar o ArquivoPFX que contem essas informações e consegui passar desta parte, agradeço as respostas e peço desculpa pelo transtorno.

Boa tarde, estou precisando desenvolver a comunicação com a balança Siciliano, não encontrei este modelo no Acbr, porem encontrei uma implementação de uma classe neste link peguei e adicionei ao projeto e a principio funcionando ok, pra min não aconteceu o erro que o colega mencionou, estou anexando aqui os fontes alterados e a classe criada pelo nosso amigo, para incorporarmos ao projeto Acbr. ACBr_Serial.dpk ACBrBAL.pas ACBrBALSiciliano.pas

Os links de web service desta cidade mudaram para: [4318200] Nome=Sao Francisco de Paula UF=RS Provedor=Thema ProRecepcionar=http://grp.saofranciscodepaula.rs.gov.br/nfse/services/NFSEremessa ProConsultarSituacao=http://grp.saofranciscodepaula.rs.gov.br/nfse/services/NFSEconsulta ProConsultarLote=http://grp.saofranciscodepaula.rs.gov.br/nfse/services/NFSEconsulta ProConsultarNFSeRps=http://grp.saofranciscodepaula.rs.gov.br/nfse/services/NFSEconsulta ProConsultarNFSe=http://grp.saofranciscodepaula.rs.gov.br/nfse/services/NFSEconsulta ProCancelarNFSe=http://grp.saofranciscodepaula.rs.gov.br/nfse/services/NFSEcancelamento ProRecepcionarSincrono=http://grp.saofranciscodepaula.rs.gov.br/nfse/services/NFSEremessa Grato pela atenção.

Claro, assim que resolver posto aqui!

Sim, testando com o ACBrTEFD, funciona direito

Boa tarde, Criada a TK-4367 para avaliar a contribuição. Obrigado!

Acredito que não será mais necessária, porquê a inutilização foi descontinuada na 4.0, e na 3.0 alguns estados não estão mais aceitando inutilização.

Meu Deus que fácil kkkkkkkkkk. Consegui funcionou perfeitamente SetComponenteNFSe; // PEGA O PROVEDOR DO USUÁRO sProvedor := NFSe1.Configuracoes.Geral.xProvedor;

já mandei e-mail até o momento sem resposta

Tudo certo, muito obrigado @Diego Foliene!

Boa tarde Jovito, Eu fiz essa alteração para o provedor BHISS (versão 1.00 do layout da ABRASF), porque você é o primeiro a ter esse problema com um cliente. Tanto o componente antigo quanto ao novo ninguém reclamou da presença dessa informação, e olhe que o ACBr emite NFS-e desde 2011. Você tem alguma informação que a prefeitura vai mudar da versão 1 para 2.04? Como assim BH esta adotando o novo layout?

Boa tarde Diego, Tentei da forma que você mencionou, porém não foi possível estar gerando. Consegui estar realizando a emissão da GNRE seguindo os exemplos do tópico abaixo. Mantive a receita 100102 e no documento de origem foi informado '00', outra mudança no arquivo foi informar a tag <campoExtra> com o código 86 e a chave de acesso da nota conforme a Tabela de campos adicionais. Em anexo o modelo do arquivo gerado que obteve sucesso. 001-gnre.xml

Eu atualizei e realmente esse campo foi corrigido, irei passar o arquivo para o email informado. Desde já, obrigado pela atenção.

O problema era a rejeição pelo mal preenchimento do campo "c28_tipoDocOrigem".

Esse erro indica que a chave privada utilizada na requisição é diferente da que foi utilizada para gerar o CSR que originou o certificado.

olhe bem ele está com units do componente antigo declarado é só remover e deixar somente do ACBrNFSeX tá facinho de resolver

Bom dia, http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/ Nesta pasta acima vc encontra os exemplos em diversas linguagens para uso da lib. O Monitor usa comunicação via TCP ou arquivos. A documentação do uso do Monitor você pode encontrar aqui: https://acbr.sourceforge.io/ACBrMonitor/ComousaroACBrMonitor.html

Faltou a unit IPM.Provider.pas Incluir o override no final das 2 funções para que funcione o "virtual" IPM.Provider.pas

Bom dia Italo, segue meu parecer: 1. Em relação à alteração que vc fez, o município não foi impresso, o que resolve parcialmente. Gostaria de pedir que não imprimisse também o label do campo porque ficou com o label e conhecendo usuário, vai ter alguém que vai falar, "olha o campo Local de prestação dos serviços está vindo vazio". 2. Considerando a solução adotada de comparar código do CodigoMunicipio com o CodigoMunicipio do Prestador, acho que resolve hoje, mas no futuro teremos um novo problema, quando realmente tiver que imprimir o Local de prestação dos serviços(mesmo sendo igual ao CodigoMunicipio do prestador), caso que vai ocorrer quando a prefeitura atualizar seu leiaute para a versão 2.04. Então a minha sugestão é: como você fez especificamente para bhiss, caso tenha a tag MunicipioIncidencia, significa que bh já está adotando o novo leiaute, logo a tag CodigoMunicipio é especificamente para o Local de Prestação dos serviços e portanto pode imprimi-lo na Danfe, caso não tenha MunicipioIncidencia, signicica que BH esta usando a tag CodigoMunicipio para informar o municipio de incidencia e portanto não imprime na Danfe o Local de prestação dos serviços..

O Sefaz MG nos retornou e confirmou que o problema era com eles mesmo, conforme texto abaixo, e voltou a funcionar sem alterar nada nos fontes. Retorno da SEFAZ: Em relação à ocorrência de problemas ocorridos nos últimos dias, relacionados aos documentos fiscais eletrônicos, segue retorno do setor responsável. 1- Problema na solicitação de Cancelamento extemporâneo no SIARE: A STI informa que o problema foi corrigido, favor tentar novamente. 2- Registro de saída: A STI está trabalhando na solução do erro. 3- Bloqueio Automático (RECF). ASTI está trabalhando na solução do erro. 4- Sincronismo NF-e/NF-A: A STI está ciente e trabalhando na solução do problema. 5- Retorno "vazio". Problema na emissão CT-e: A STI está trabalhando na solução do erro. 6- PED: STI está trabalhando na solução do erro. 7- Erro no credenciamento no SIARE (CT-e CT-eOS): A STI está trabalhando na solução do problema. Previsão de solução dos erros: até dia 1/9/2023 (podendo ocorrer antes). Pode encerrar o tópico...

Criada a TK-4365 para avaliação. Obrigado.

Funcionou o GNRE, obrigado.

Bom dia @Léo Para cobrança/boletos que eu saiba, não precisa. https://app.developers.bb.com.br Qdo fiz meu cadastro foi de boa. Lembre-se de utilizar os dados fornecidos por eles. conta, agencia, cedente, cpf emitente e pagador... Se não estiver correto em homologação não passa.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia DIego, você esta correto, usei o now dai pega a data e hora correta o problema estava aqui 30/12/1899 17:56:54 essa data 30/12/1899. Detalhe que não percebi. Em outros cliente que utilizam IPM não da esse erro mesmo estando o codigo assim. Somente neste de pinhalzinho que ocorre. Mais utilizando Now ficou tudo certinho. Muito obrigado pela atenção.

Obrigado Diego pela atenção e esclarecimentos, vou repassar estas informações para o meu cliente, inclusive a sugestão de incluir na observação o CIOT

Ola, https://dfe-portal.svrs.rs.gov.br/NFE/Gtin

use o ACBrCTe já tá pronto ou senão programa em delph ou lazarus use o monitor ou a libcte

Boa tarde! Analisando seu XML em algumas ferramentas de parse, não apontou erro na estrutura. Não encontrei informações a respeito deste erro. Conferindo no seu XML, você preencheu: Conferindo nas Tabelas Disponíveis. O documento de origem me parece correto, no entanto a receita parece estar errada: Por favor, é possível verificar?

Boa tarde, Por favor quando enviar o novo fonte para análise, anexe o XML utilizado para os testes. Se entender que contém dados sensíveis, envie para [email protected] e mencione este tópico.

Uma correção. Em 27/06/2023 foi corrigido os totalizadores para CNAB 240 Itau, por favor atualize seus fontes e rode o instalador.

Lhe enviei via mensagem privada no fórum, novo compilação da Lib com alteração visando corrigir essa questão do grupo prop.

Bom dia Danny, Da forma que esta no SVN a tag CodigoPais do tomador só vai ser gerada se o CodigoMunicipio do tomador for igual a 9999999, ou seja, o tomador é estrangeiro. O provedor esta exigindo que a tag CodigoPais seja gerada mesmo que o tomador não seja estrangeiro?