Italo Giurizzato Junior

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.

Boa tarde Carlos, Com certeza os seus schemas não estão atualizados.

Boa tarde, Favor atualizar os fontes e testar novamente.

Boa tarde Thiago, Primeiramente, se atente ao seguinte: Quem pode emitir o MDF-e? Transportadoras, neste caso deve relacionar os CT-e que ela emitiu. Empresas que realizam o transporte da própria mercadoria vendida. Por exemplo você tem uma loja de moveis e possui um caminhão. A sua sua loja vai emitir a NF-e referente a venda e caso o destinatário seja de uma cidade em outro estado, será necessário emitir o MDF-e. Vale lembrar também que a emissão do MDF-e é para transporte interestadual e carga fracionada, ou seja, serão realizadas diversas entregas para destinatários diversos. Sendo assim o emitente do MDF-e é o mesmo da NF-e. O XML que você postou traz como emitente uma empresa (vide a TAG CNPJ do emitente - final é /0001-12) e outra como emitente das NF-e (vide CNPJ contido na chave das NF-e - final é /0001-76) Esse CNPJ que aparece no emitente tem que ser o mesmo que aparece nas chaves das NF-e. Com certeza esse CNPJ com final /0001-12 não esta habilitado junto a SEFAZ a emitir NF-e.

Bom dia Werner, Para se obter o XML assinado e protocolado de forma legal existem 3 formas: 1. O emitente da nota deve enviar por e-mail o XML conforme consta na legislação, se ele não faz isso você esta recebendo a mercadoria sem nota, pois o DANFE para o Fisco não tem validade jurídica a não ser que o destinatário seja pessoa física. 2. Pelo site da SEFAZ; 3. Usando o método DistribuicaoDFe; Vamos então a esse método: 1. Na pasta Doctos\Manuais você encontra o PDF: Manual ACBrNFe versão 1.04 caso você já esteja usando os fontes do Trunk2 com certeza alguns métodos estão diferentes, mas o DistribuicaoDFe não mudou nada e na página 15 você encontra uma breve explicação bem como o significado de cada parâmetro dele. 2. No Portal Nacional da NF-e em Notas Técnicas você encontra a NT 2014/002 versão 1.01 que trata sobre o Distribuição DFe são apenas 13 páginas, considero a sua leitura muito importante. 3. A sua utilização é bem simples mas para poder obter o tão desejado XML assinado e protocolado é necessários alguns passos a mais. Devemos inicialmente executar o método DistribuicaoDFe para obter os resumos das NF-e, em seguida devemos realizar a manifestação do destinatário em cada uma delas (lembrando que a manifestação é um evento, vide NT 2012/002 versão 1.02) ao executar pela segunda vez o DistribuicaoDFe, dependendo do tipo de manifestação teremos como resposta o XML completo da NF-e. Não é preguiça ou não querer explicar o que é e como faz, eu sempre peço para que as pessoas leem os manuais e notas técnicas, pois estarão lendo um documento que foi publicado pelo ENCAT e disponibilizado no Portal Nacional da NF-e da SEFAZ, pressupõe que as informações contidas sejam corretas. Ocorrem alguns erros sim, ninguém é perfeito. Estamos aqui para esclarecer algumas duvidas.

Bom dia, Já postei em um outro tópico que as chances de prorrogar o inicio em ambiente de produção são muitas, acredito que somente para o ano que vem vai ser necessário, visto que algumas SEFAZ não implementaram ainda em ambiente de homologação.