Painel de líderes

Valdir, Na unit ACBrNFeNotasFiscais procure pela função ObterNFeXML. Ela tem que ficar da seguinte forma: function NotaFiscal.ObterNFeXML(const AXML: String): String; var DeclaracaoXML: String; begin DeclaracaoXML := ObtemDeclaracaoXML(AXML); Result := RetornarConteudoEntre(AXML, '<NFe xmlns', '</NFe>'); if not EstaVazio(Result) then Result := '<NFe xmlns' + Result + '</NFe>' else begin Result := LerTagXML(AXML, 'NFe'); if not EstaVazio(Result) then Result := '<NFe xmlns="' + ACBRNFE_NAMESPACE +'">' + Result + '</NFe>' end; if not EstaVazio(Result) then Result := DeclaracaoXML + Result; end; A linha que devemos alterar é a linha: Result := '<NFe>' + Result + '</NFe>' o correto é: Result := '<NFe xmlns="' + ACBRNFE_NAMESPACE +'">' + Result + '</NFe>'

Amigos, com bastante insistência e pesquisa e claro com ajuda aki do forum! Descobri q o nosso amigo ítalo estava certo, o cliente emitia por outro software e não se lembrava! Pra kaba! Obrigado amigos !

bom dia.. REferente cade a chave.. Para resolver esse problema adotamos o seguinte no nosso sistema: Algumas coisas sao guardados no banco de dados, na hora da emissao da nota, independente se transmitiu ou nao. é guardado a Chave que gerou, é guardado o xml que enviou assinado, e depois guardado os retornos, tanto do transmitirdo como dos retornos de erros.. Dessa maneira tenho tudo no banco, e ai se o cliente mandar gerar a transmissao de novo, ja sei com isso, se pega o que tem ou gera um novo. e se precisar, esta ali as chaves ou outra informacao.

Bom dia a todos, O que tenho a dizer quanto a rejeição: Duplicidade. A sua aplicação esta ERRADA, esta permitindo que o usuário envie a mesma nota de forma indiscriminada. Se envia e ocorre erro de internet como por exemplo timeout, não se deve enviar novamente. Neste caso, a aplicação deve possuir uma opção para tentar regularizar a situação da nota. O que essa opção deve fazer: 1. Carregar o XML da nota que ocorreu o erro de internet; 2. Consultar a situação dela na SEFAZ. Já expliquei isso em outra postagem nesse mesmo tópico.

Olá pessoal, Para quem ainda não sabe estou promovendo um Refactoring no componente ACBrNFSe. Ele praticamente foi reescrito do zero e infelizmente teremos algumas quebras de código quando ele for liberado. Mas vamos falar de coisas boas. Hoje temos que disponibilizar para os nossos clientes além do executável, DLLs, os famosos arquivos INI, o arquivo Cidades.ini e os arquivos INI dos provedores. Pois bem, isso acabou. Os arquivos INI referente aos provedores se transformaram em Unit, ou seja, fazem parte do fonte do componente. O conteúdo do arquivo Cidades.ini migrou para o arquivo ACBrNFSeServicos.ini que é transformando no ACBrNFSeServicos.res através do BAT: Compila_RES. O arquivo ACBrNFSeServicos.res é incorporado ao executável, logo vocês só vão precisar distribuir o executável e as DLLs para os seus clientes. O que vocês acharam dessa mudança? Ainda não esta 100%, em função das diferenças dos provedores, mas criei um novo método chamado Emitir que tem por finalidade gerar o XML do RPS, assinar se necessário, gerar o Lote e assinar se necessário, enviar, aguardar o retorno do XML da NFSe. Independente do serviço que o provedor se utiliza para recepcionar o XML do RPS. Vou dar um exemplo: O provedor 4R que segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRpsSincrono para recepcionar o RPS, sendo que no Manual da ABRASF versão 2 estão previstos os métodos: EnviarLoteRps, EnviarLoteRpsSincrono e GerarNfse. Por outro lado o provedor ISSJoinville que também segue a versão 2 do layout da ABRASF implementou somente o método EnviarLoteRps. Se vocês tem clientes cujas cidades utilizam o provedor 4R e tem clientes em Joinville, ou vocês tem duas aplicações ou a aplicação tem uma tela de configuração para definir qual método a ser utilizado. O método Emitir vem para tentar resolver esse problema da seguinte forma: se o provedor for 4R ele vai se utilizar do método EnviarLoteRpsSincrono automaticamente, agora se for ISSJoinville vai usar o EnviarLoteRps. Desta forma não precisamos de nos preocuparmos com qual o método devemos usar para enviar o RPS para o webservice. Acredito que vai ficar muito bom e pratico. O que vocês acham? Muita coisa já foi feita e muito mais precisa ser feito. Para que vocês tenham uma ideia foi criado 32 Units, ou seja, uma para cada provedor que segue a versão 1 do layout da ABRASF, mais 53 Units para os provedores que seguem a versão 2 do layout da ABRASF e mais 19 Units para os provedores que tem o seu próprio layout. Até o final deste mês de outubro estarei disponibilizando o programa exemplo compilado para que vocês possam fazer mais testes. Em breve vou explicar como vão ser os testes e como reportar os resultados. Antes que eu esqueça, esse Refactoring visa poder incluir a emissão da NFS-e no ACBrMonitor Plus e a criação do ACBrLibNFSe (DLL). Um forte abraço a todos.

Bom dia BigWings, Realmente se o programa exemplo não encontra o arquivo INI de configuração ele entra em parafuso. Mas clicando em OK na primeira mensagem de erro e depois na aba "Geral" informarmos o path da pasta ArqINI e clicarmos no botão "Salvar Configuração" o arquivo de configuração vai ser criado no disco. O próximo passo é sair do programa e carregar ele novamente, desta forma ele vai encontrar o arquivo Cidades.ini e desta forma vai ser possível selecionar a cidade desejada.

Bom dia, esse número NÃO pode ser único deve ser diferente para cada NFe / NFCe e deve ser aleatório pela segurança, se for sequencial por exemplo suas chaves poderiam ser facilmente identificadas por eventuais fraudadores. Para cada Chave que gerar você deve armazenar a mesma antes do envio, se por algum motivo você não obter o retorno ou receber timeout, vai conseguir consultar posteriormente e da mesma forma vai conseguir cancelar ou inutilizar essa chave se necessário. Por isso a importância de ter o controle das chaves enviadas, mesmo sem ter o XML já autorizado. Essa informação não é retornado pela Sefaz nesse tipo de rejeição. Pois se trata da mesma composição principal da chave que está sendo enviando, ou seja, uma chave com mesmo (CNPJ Emitente, Modelo, Série e Numero) já foi transmitida. A diferença é que essa mesma chave está sendo reenviada com diferença em alguns desses campos: (Data Emissão, Tipo de Emissão, Código Numérico). Falamos bastante sobre isso na palestra sobre (Rejeições que podem Impossibilitar a emissão da NFe e NFCe) no Dia do ACBr On-Line, em breve estará disponível.

Galera, saiu hoje algumas novidades sobre o PAF-ECF prorrogação do vencimento da data de vencimento do credenciamento Post completo em: https://blogafrac.org/2020/10/23/santa-catarina-publica-regras-para-emissao-de-nota-fiscal-eletronica-nfc-e/

Pelo log o parametro esta vazio por isso não foi enviado nada.

Seus Schemas estão atualizados conforme repositório do ACBr? Sugiro que realize o mesmo teste utilizando o Demo, pois testando por aqui não é possível simular... Ao carregar e tentar enviar apresenta apenas inconsistência nos dados, mas não ocorreu o erro acima. Outro detalhe... Verifique se a verão do e-Social está configurada corretamente e se o IDEmpregador e IDTransmissor estão devidamente configurados no componente. Se mesmo assim persistir, por favor descreva um passo a passo para que possamos simular utilizando a aplicação Demo do ACBr.

É isso aí pessoal, quando roda o programa e ele não encontra o .ini dele mesmo dá pau! Ignora o erro, escolhe uma cidade e manda salvar configuração que ele cria o ini e já deixa uma cidade qualquer escolhida. Notei que, se criar o ini mas não escolher cidade, continua dando exception da "cidade [0]". Novamente, só ignorar o erro e escolher, depois salva de novo. Italo, muito obrigado! Agora já posso começar a estudar como me virar de novo.

Boa tarde André, Já leu esse artigo?

Se não me engano, no WebExchange, tem uma configuração em contas de Grupo, que indica se elas podem ou não ser remetentes ..

Ok. Muito obrigado pela ajuda.

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

Ítalo, Vou refazer os teste seguindo sua recomendação, mais uma vez muito obg pela atenção. Assim que terminar meus testes volto com um feedback. Abs,

entao achei o problema consegui contato pelo telefone a baixo com o pessoal da prefeitura ai eles me auxiliaram na resolução, era o encodding que precisa estar obrigatoriamente como uft-8 na conexão alem de estar no xml muito obg pelo retorno doutor espero que isso seja util telefone da Ti da prefeitura: 3381 6901 / Paulo

Valdir, Vamos aos porquês. Porque no validar da SEFAZ diz que o XML é valido? Simples, se o XML possuir a tag procNFe o validador da SEFAZ se utiliza do schema procNFe_v4.00.xsd, se não tem a tag e sim a tag NFe ele usa o schema nfe_v4.00.xsd para validar o XML. O tem XML possui a tag procNFe e esta tem o namespace, logo ele é validado com sucesso. Porque no validador do ACBrNFe diz que o XML é invalido? Simples, o componente extrai da tag procNFe a tag NFe e suas filhas e usa o schema nfe_v4.00.xsd para validar, como a tag NFe esta sem o namespace ocorre o erro. O componente tem esse comportamento de pegar somente a tag NFe e suas filhas para validar, pois antes de enviar a nota para a SEFAZ a mesma é validade e o XML antes do seu envio não tem a tag procNFe. Analisando o código do componente notamos que é mais simples acrescentar o namespace caso este não exista no momento da validação em vez de trocar os schemas. O XML original não é afetado, pois tudo ocorre em memória e o XML é validade sem ocorre o erro por falta de namespace.

O interessante q pelo outro sistema, havia pulado a nfe 1 q meu sistema imprimiu!! Pra kaba!!! Mas valeu alem do sufoco esses dois dias foi bom q corrigi alguns problema de lógica no meu sistema...

Sim é possivel, mas precisa da dll nativa no Path para poder ser carregada pela classe. Agora o SAT não funciona na web pois precisa de acesso físico ao SAT e pelo browser isso não é possivel.

Camilo, Cantei a bola. Se espremer o usuário ele confessa a kaka que ele fez. Agora através desse outro programa quem sabe você consegue saber a chave correta dessa nota.

Prezado Italo , Obrigado pela resposta , tambem ja executei desta forma , té trocando o formato de data , mas mesmo assim sem sucesso , vou tentar o suporte da prefeitura mas não sei se terão uma resposta plausivel , mesmo assim obrigado pela ajuda , vou fazer a tentativa

É um bug do instalador, que usa o ACBr.inc desatualizado da pasta Lib na compilação e só atualiza ele no final... Apagar a pasta ACBr\Lib e reinstalar resolve.

Correto, de acordo com as Notas Técnicas. Mas por os eventos de manifestação serem enviados para o Ambiente Nacional, pode acontecer de a confirmação demorar pra chegar na SEFAZ do emitente e este assim conseguir cancelar a nota.

Boa tarde Diego, Já esta no repositório.

Não é necessário realizar a ciência, pode manifestar como um dos três tipos de manifestação definitiva diretamente. Ainda pode fazer correção da manifestação uma única vez. Se foi realizada a Confirmação, pode fazer nova manifestação como Desconhecimento ou Operação não realizada, e vice-versa entre estas. Caso a última manifestação não seja a confirmação, a NFe pode ser cancelada pelo emitente.

sugerir abrir um novo tópico pois esse é antigo. vou estar fechando ele

consegui compilar, no meu caso coloquei nova versão do lazarus, e baixei todo novo repositório, obrigado.

Verifique se realmente isso está acontecendo debugando sua aplicação. Note que no programa de exemplo uma coisa não automaticamente altera a outra. É tudo validado por meio dos eventos. Se seus eventos estiverem validando variáveis diferentes ou em forms diferentes, isso pode explicar o motivo do que você está descrevendo.