Italo Giurizzato Junior

Boa tarde Warquia, Você não pode ler esse arquivo como se fosse o arquivo de uma NF-e. Note que o seu inicio diz que se trata de um retorno de dowload de uma NF-e <retDownloadNFe ..... A NF-e propriamente dita esta contida nesse retorno e primeiramente tem que ser extraída e salva separadamente. O Método Download do componente ACBrNFe salva o retorto do download e salva também um segundo XML que é a nota fiscal que você poder ler, ou seja, carregar através do LoadFromFile sem nenhum problema.

Nota Técnica 2015/002 versão 1.10 - página 23 link: http://www.nfe.fazenda.gov.br/portal/listaConteudo.aspx?tipoConteudo=tW+YMyk/50s=

Boa tarde Edilberto, Quanto a essa propriedade AtualizarXMLCancelado ela foi removida por sugestão minha. A equipe ACBr esta avaliando se ela vai voltar ou não. A minha posição quando a esse assunto é: Não deve voltar, pois em nenhum Manual ou Nota Técnica diz que o XML assinado e com o protocolo de autorização tem que ser alterado caso a nota venha a ser cancelada. Portanto ao realizar essa troca do protocolo de autorização pelo de cancelado estaremos gerando um XML que não tem nenhuma validade jurídica. E desta forma o componente deixa de ficar em conformidade com os Manuais e Notas Técnicas. Resumindo: A nota foi emitida e autorizada, enviar por e-mail o XML da NF-e (*-nfe.xml) assinado e autorizado para o destinatário e transportadora (se necessário). A nota foi cancelada, enviar por e-mail o XML de processamento do Evento (*-procEventoNFe.xml) para o destinatário e transportadora (se necessário). O primeiro arquivo temos todos os dados pertinentes a venda bem com a assinatura digital do emitente mais o protocolo de autorização da SEFAZ, portanto temos um documento fiscal eletrônico com validade jurídica. O segundo arquivo temos a solicitação do cancelamento a assinatura digital do emitente mais o protocolo de homologação do cancelamento da SEFAZ, portanto temos um documento fiscal eletrônico com validade jurídica.

Boa tarde José, Esses campos se referem a Nota Técnica 2015/003, correto? Pois bem a SEFAZ ainda não disponibilizou os schemas que contemplam esses novos campos.

Boa tarde a todos, Segundo a Nota Técnica 2015/002 versão 1.10 - página 23 temos as seguintes regras de validação da NF-e na SEFAZ: Regra: 7GA01-10 Não informado o Grupo de Autorização para obter o XML, para a UF que exige a identificação do Escritório de Contabilidade na Nota Fiscal, conforme legislação estadual. Observação: Regra de Validação opcional, a critério da UF. A nota será rejeitada: Não informado o Grupo de Autorização para UF que exige a identificação do Escritório de Contabilidade na Nota Fiscal Regra: 7GA01-20 Verificar se o CNPJ/CPF informado na primeira ocorrência do Grupo de Autorização corresponde a um Escritório de Contabilidade cadastrado na SEFAZ, conforme legislação estadual. Observação: Regra de Validação opcional a critério da UF. A nota será rejeitada: Escritório de Contabilidade não cadastrado na SEFAZ O grupo de Autorização que as duas regras acima se referem é o autXML onde podemos informar o CNPJ ou CPJ de pessoas que o emitente esta autorizando a obter o XML, ou seja, realizar o Download. O XML do João Paulo não possui esse grupo e mesmo que tivesse é preciso garantir que o primeiro da lista seja o CNPJ de um escritório de contabilidade que esteja cadastrado na SEFAZ. Resumindo, o Estado que vier a aplicar essas regras, todos os escritórios de contabilidade terão que se cadastrarem na SEFAZ do Estado em questão e todos os emitentes de NF-e deverão incluir no seu XML o grupo <autXML> e o primeiro da lista deverá ser um CNPJ de um escritório de contabilidade, caso contrario a nota será rejeitada.

Boa tarde Daniel, Por favor preste mais atenção quando postar as suas duvidas, pois o ACBrMDFe não tem nada haver com o DANFE. DANFE se refere ao ACBrNFe. Movi para o local correto.

Boa tarde a todos, Dener, qual mensagem de retorno você necessita e de qual método? Duarte, os métodos: Gerar, EnviarSincrono e SubstituirNFSe não foram testados, pois os meus testes foram realizados em cima do provedor Ginfes e este não possui os 3 métodos mencionados. Já baixei os arquivos que você anexou e vou analisa-los para tentar descobrir algo. ************* Duarte, favor atualizar os fontes.

Bom dia Felipe, E não pesquisou. Pois se tivesse pesquisado saberia que o componente ACBrGNRE não deve ser selecionado ainda para instalar, pois não foi totalmente migrado para o Trunk2.

Bom dia Marcelo, Já tentou desta forma: ACBrNFe1.Configuracoes.Arquivo.Salvar := True; ACBrNFe1.NotasFiscais.LoadFromFile(nomearq, false); ACBrNFe1.Consultar; Pois o XML atualizado só será salvo em disco caso a propriedade Salvar valer True.

Bom dia Pedro, Favor atualizar e instalar novamente.

Bom dia Duarte, É interessante sempre realizar os testes com o programa exemplo. Na configuração do mesmo deixar ativo o "Salvar Soap". Com os arquivos soap podemos identificar o que esta faltando acrescentar para que o componente possa ler de forma correta os retornos.

Boa tarde Gabriel, Em função da grande diversidade da NFS-e, estamos migrando aos poucos. Em primeiro lugar pretendemos fazer com que o componente funcione para os provedores que seguem o padrão ABRASF versão 1.00 e que somente o Lote seja assinado ou os RPS. Depois vamos partir para os provedores que seguem o padrão ABRASF versão 2.00 e que somente o Lote seja Assinado ou os RPS. O passo seguinte é fazer funcionar os provedores da versão 1.00 cujo Lote e RPS são assinado, depois os provedores da versão 2.00 Cumprida essas 4 etapas vamos partir para os provedores que não seguem o padrão ABRASF que é o caso do ISSDsf e outros.

Boa tarde Marcelo, Devemos utilizar o LoadFromFile ou LoadFromStream ou LoadFromString quando o componente não contem os dados da nota. E pelo que eu vi o componente já esta com os dados da nota, loto não faz sentido carrega-lo novamente. Caso você tenha o XML assinado salvo em disco faça o seguinte: acbrnfe1.notasfiscais.loadfromfile(nomearq, false); // o segundo parâmetro é false para que o componente não gere novamente o XML. acbrnfe1.consultar; caso o XML assinado esteja salvo no banco de dados faça desta outra forma: acbrnfe1.notasfiscais.loadfromstring(varString, false); // varString é a variável que contem o XML assinado lido do banco de dados. acbrnfe1.consultar;

Boa tarde Alisson, Antes de executar o método de impressão do evento (Carta de Correção) deve-se carregar o XML do CT-e através do LoadFromFile. Desta forma será impresso alguns dados do CT-e na Carta de Correção.

Bom dia Robson, A questão é bem simples ou a SEFAZ-PB mude a URL usada para gerar o QR-Code ou ela mude a URL usada para gerar o QR-Code. Sugestão: infernize a SEFAZ-PB.

Bom dia, Em vez de informar 1 no campo CSC informe 000001 (com 6 dígitos).

Bom dia Roberto, Noto que você é novo no fórum sendo assim convido você a pesquisar antes. Erro Não Catalogado = SEFAZ com problemas. O que fazer? Nada simplesmente aguarde ou entre em contato com a SEFAZ.

Vamos supor que o MDF-e seja enviado e rejeitado por conter algum dado errado. Neste caso devemos efetuar a correção, gerar, assinar, validar e enviar novamente, correto? Se nesta situação esta gerando um segundo XML é por que o cMDF (código aleatório do MDF-e) é diferente do primeiro. Uma solução bastante simples é, quando for armazenar os dados pertinentes ao MDF-e no banco de dados, você já gera o cMDF com no máximo 8 dígitos e que seja maior que zero. Quando for alimentar o componente atribua esse numero ao campo cMDF, desta forma a chave sempre vai ser a mesma e consequentemente não vai ser gerado um novo XML para o mesmo MDF-e, ou seja, você não vai ter 2 XML, um que foi rejeitado e o outro que foi corrigido, enviado e protocolado. Se a chave é igual o corrigido vai subscrever o que foi rejeitado.

Bom dia Gabriel, Não é possível uma unica aplicação possuir um componente do trunk e outro do trunk2. O componente ACBrNFSe já foi migrado para o Trunk2, mas existem alguns problemas para serem resolvidos. Por exemplo: Criar os arquivos INI para cada provedor, resolver uma questão pendente que é quando o lote é assinado e os RPS também (o componente hoje só consegue assinar o lote se o RPS não for assinado), realizar testes e fazer as devidas correções nos métodos: Gerar, EnviarSincrono e SubstituirNFSe. Se o provedor que você necessita para emitir as NFS-e não requer que tanto o lote quanto o RPS sejam assinados e o método de envio é o Enviar, basta então verificar se o arquivo INI dele já esta disponível ou não, se não esta ou você aguarde ou baseado nos que já existem tente fazer e realize os testes, se tudo der certo não esqueça de disponibilizar o INI do provedor.

Bom dia a todos, Gilson, a coisa é mais simples o que parece, vamos aos passos: 1. A nota é enviada a SEFAZ; 2. Se não ocorrer nenhuma falha de conexão com a internet temos o retorno da SEFAZ; 2.1. Temos que analisar o cStat para saber se a nota foi autorizada, denegada ou rejeitada; 2.2. Se foi autorizada o XML é atualizado com o protocolo de autorização e o DANFE é impresso. 2.3. Se foi denegada o XML é atualizado com o protocolo de denegação e a venda não é realizada. 2.4. Se foi rejeitada é preciso efetuar a correção do dado errado, gerar, assinar e enviar novamente o XML (voltar ao passo 1); 3. Se ocorreu falha de conexão devemos carregar o componente com o XML assinado e realizar uma consulta; 3.1 Se nessa consulta não ocorrer nenhum erro de conexão temos que analisar o cStat, analise semelhante aos passos 2.2, 2.3 e 2.4 3.2 Caso a nota seja rejeitada por não constar na base de dados da SEFAZ, devemos efetuar o envio novamente, neste caso fica claro que o erro de conexão ocorreu logo no envio e não no retorno. Seguindo esses passos, você nunca vai ter problemas de notas em duplicidades. Quando lançamos mão a contingência? Quando o problema de conexão vai demorar para ser sanado. Outra coisa, temos que saber onde esta a origem do problema (SEFAZ ou contribuinte)? Dependendo de onde é o problema o tipo de contingência a ser executado é diferente. Se o problema é com a SEFAZ devemos alterar o tipo de emissão para offline (no caso da NFC-e), informar a data e hora de contingência mais a justificativa, gerar e assinar novamente o XML e simplesmente imprimir o DANFE. Quando os problemas forem sanados devemos enviar esse último XML para a SEFAZ. Agora se o problema é com o contribuinte, se este possuir uma conexão 3G (por exemplo) deve-se também alterar o tipo de emissão para EPEC, informar a data e hora de contingência mais a justificativa, gerar e assinar novamente o XML, imprimir o DANFE e por fim enviar via 3G o evento EPEC. Quando os problemas forem sanados devemos enviar esse último XML para SEFAZ.

Bom dia, Eu em particular não concordo muito com essa propriedade. Suponha que a sua aplicação salva os XMLs somente em disco, neste caso o XML será gerado, assinado e validado para que seja enviado para a SEFAZ. Caso ocorra algum erro no retorno, é possível carregar o componente novamente com o XML que já esta assinado e efetuar uma consulta, caso o mesmo foi recebido e processado pela SEFAZ com sucesso, teremos como resposta o protocolo de autorização e o componente por sua vez vai inclui-lo ao XML. Se o XML inicialmente gerado, assinado e validado não for salvo em disco em função da propriedade SalvarApenasMDFeProcessados, você não o terá para realizar essa consulta. Nas minhas aplicações o XML só gerado no momento do envio, sendo assim se existe um XML assinado mas sem o protocolo de autorização significa que ocorreu algum problema no envio do mesmo. Realizando a consulta mencionada acima se a SEFAZ retornar o protocolo significa que o problema foi no retorno, mas se voltar uma mensagem informando que o documento não existe na base de dados da SEFAZ, isso significa que o problema ocorreu logo no envio, sendo assim devemos envia-lo novamente.

Bom dia Mailson, Até onde sei é a NT 2015/002 inteira que será prorrogada para o ano que vem no que diz respeito ao ambiente de produção. Por outro lado as datas da NT 2015/003 ainda continuam valendo.

Bom dia DATAC, Pelo que andei lendo no fórum no caso do RS existe um CSC especifico para cada ambiente, sendo assim não se pode usar o de produção para realizar testes e também não é valido do que o Juniorsk8 postou para o RS.

Bom dia a todos, Jones, no seu primeiro post você diz que não pode migrar para o Trunk2 pelo simples fato de que necessita do ACBrGNRE e ACBrNFSe. Pois bem, eu lhe informei que os fontes do ACBrNFSe disponíveis no Trunk2 compila e instala, mas ele esta funcional para o provedor Ginfes, para os demais provedores serão necessários mais ajustes e criação dos arquivos INI de configurações. Lhe convidei a fazer as devidas alterações no fonte do ACBrGNRE que esta disponível no Trunk2 para que o mesmo possa ser compilado e instalado. Agora você disponibiliza os fontes do ACBrGNRE dizendo que é um quebra galho. Essas alterações que você fez foi baseado em que? Como você sabe que essas alterações será possível compilar e instalar na nova estrutura? No meu entendimento você tem que baixar os fontes do Trunk2 em uma maquina isolada, instalar (usando o ACBrInstall_Trunk2) todos os componente exceto o ACBrGNRE. Depois usando o pacote de instalação do mesmo tentar compilar e instalar. A medida que for surgindo os erros, deve-se resolve-los até que a compilação e instalação seja bem sucedida. O próximo passo é testa-lo de preferencia usando o programa exemplo. Finalizado os testes e funcionando como deve ser, ai sim você disponibiliza de forma zipada, os fontes do componente, o pacote de instalação e o programa exemplo caso este tenha sido alterado para funcionar.

Boa tarde Gilson, Como assim se retornar que a nota enviada já existe na SEFAZ você altera o tipo de emissão e envia novamente? Não entendi nada o que você esta fazendo. Outra coisa você só remove a assinado executando um Clear e alimentando o componente novamente do zero.