Italo Giurizzato Junior

Boa tarde Douglas, Vamos simplificar: Alimentar o componente >> Assinar >> Enviar >> Gravar XML no Banco O método Assinar já se encarrega de gerar e gravar o XML em disco. Você tem o retorno da SEFAZ que acusa que a nota foi denegada para que possamos analisar? Se sim, post como anexo.

Boa tarde Gabriel, Você atribuiu o valor True a: Configuracoes.Arquivos.Salvar ?

Boa tarde, Você esta atribuindo o valor True a propriedade de configuração: Configuracoes.Arquivos.Salvar? Outra coisa o GravarXML não grava o XML protocolado.

Boa tarde Paulo, Até onde sei a questão de gravação no método Enviar e Consultar já tinhão sidos sanados. É o arquivo *-NFeDFe.xml quando o componente cria por existir eventos vinculados a Nota que é salvo em outro lugar?

Bom dia Nilton, O seu entendimento não confere. A ideia é salvar todos os arquivos (envio, retorno, fiscais protocolados ou não, inutilização, eventos) em uma unica pasta definida em PathSalvar ou organiza-los em pastas definidas em PathCTe, PathInu e PathEvento.

Bom dia Jamil, Se você não alimenta a propriedade CEST a mesma não é gerada no XML e consequentemente o mesmo é autorizado. Se a alimenta a TAG é gerada e a SEFAZ rejeita com a mensagem: Falha do Schema XML. Essa mensagem de rejeição da SEFAZ indica que alguma TAG foi incluída no XML e a mesma não esta sendo reconhecida ou por ela não existir ou por estar escrita de forma errada. Neste caso a TAG existe pois consta em Nota Técnica, esta sendo gerada no XML conforme a NT, então nos leva acreditar que os Schemas da SEFAZ bem como o seus sistemas não foram atualizados para processar uma NF-e ou NFC-e com essa TAG. A solução neste caso é questiona-los para saber quando vai ser implementado e aguardar.

Bom dia Paulo, Você esta fazendo confusão. No titulo da sua postagem você se refere ao método DistribuicaoDFe, nesta última postagem você se refere a um arquivo chamado: *-NFeDFe.xml e ao método Consultar. O método Consultar tem como objetivo consultar a situação atual de uma NF-e, caso seja carregado o XML da NF-e (assinado e sem o protocolo de autorização) o mesmo será atualizado, ou seja, receberá o protocolo de autorização se foi autorizado pela SEFAZ. Com o XML da NF-e carregado ao executar o método Consultar, caso essa nota tenha eventos vinculados será criando um arquivo chamado *-NFeDFe.xml que contem o todos os dados da nota mais a assinatura, o protocolo de autorização e a lista de eventos. Por outro lado o método DistribuicaoDFe tem como objetivo realizar uma consulta na SEFAZ e obter lista de até 50 documentos, que podem ser resumos da NF-e, NF-e completa, resumos de eventos e eventos completos. Esse método veio para substituir o ConsultaNFeDest (consultar NF-e destinadas) e o DownloadNFe, pois podemos saber quem esta emitindo notas contra o nosso CNPJ e caso venhamos realizar a manifestação das mesmas em uma próxima consulta usando o DistribuicaoDFe obtemos o XML completo da NF-e manifestada. Como você pode ver, DistribuicaoDFe não tem nada haver com o Consultar e o arquivo *-NFeDFe.xml gerado pelo Consultar não tem nada haver com os arquivos gerados pelo DistribuicaoDFe. Precisamos saber qual é o arquivo que esta sendo gravado fora do lugar e qual é o método que você esta usando. Lhe dou uma dica, leia o Manual do ACBrNFe que esta na pasta: ...\Doctos\Manuais Mesmo sendo do componente que esta no Trunk mas os métodos são os mesmos, um ou outro tiveram pequenas alterações em seu nome ou nos parâmetros.

Bom dia a todos, Martins, preste atenção onde esta postando pois o tópico se refere ao componente ACBrMDFe que não tem nada haver com emissão de NF-e. Será fechado.

Bom dia Felipe, O envio esta sendo para o ambiente de homologação ou produção? O ambiente de produção somente em dezembro vai estar preparado para receber a TAG CEST.

Bom dia Paulo, O DistribuicaoDFe se utiliza do Path Configurado no grupo Download, propriedade PathDownload.

Bom dia, Favor atualizar os fontes e testar novamente.

Bom dia Nilton, No meu entendimento devemos ter em disco o XML Assinado protocolado ou não. Antes do envio temos o XML Assinado se após o envio esse arquivo continuar sem o protocolo quais são os motivos? 1. Ele pode ter sido rejeitado e neste caso você tem controle, pois é possível capturar o status e a mensagem e apresentar para o usuário para que o mesmo tome as providencias. 2. Ele pode ter sido denegado e neste caso você tem controle, pois é possível capturar o status e a mensagem informando que o CT-e foi denegado. 3. Ocorreu uma falha que no primeiro momento não se sabe se foi no envio ou no retorno, mas é possível detectar que ocorreu uma falha, sendo assim devemos no primeiro momento carregar esse XML assinado que esta salvo e executar o método Consultar, se foi uma falha no retorno e o CT-e foi autorizado pela SEFAZ, o método Consultar se encarrega de atualizar o XML acrescentando o protocolo de autorização, ou teremos a situação de rejeitado ou denegado e nestes casos temos as soluções nos itens 1 e 2. Agora se ao Consultar obtermos a resposta acusando que o CT-e não consta na base de dados, fica claro que a falha foi no envio, portanto devemos carregar o XML assinado e envia-lo novamente. Quanto ao Geral.Salvar, até onde sei essa propriedade ficou definida que se o valor dela fosse True seria salvo em disco os arquivos não fiscais, ou seja, os arquivos de envio e de retorno. Por outro lado o Arquivos.Salvar se o seu valor for True é salvo em disco os arquivos fiscais.

Bom dia Luciano, Note o que esta escrito na mensagem que aparece na TAG Correcao: "O município de incidência depende da atividade do contribuinte....." O que pode esta ocorrendo é que a atividade desse contribuinte não permite informar um outro código que não seja o do município do próprio contribuinte, ou seja, o prestador.

Boa tarde Oteniel, Não existe correria nenhuma. As alterações promovidas pela NT 2015/003 já podem ser testadas no ambiente de homologação. A partir do dia 01/12/2015 já podem ser enviadas para o ambiente de produção. E se não enviar o que vai ocorrer? Absolutamente nada. Uma vez que somente a partir de 01/01/2016 é que as regras de validação da SEFAZ vão começar a checar se o XML esta em conformidade com a NT ou não. Sendo assim meu caro você tem o mês de dezembro inteiro para atualizar os seus clientes.

Bom dia a todos, Eljak acredito que você esta se referindo ao componente ACBrNFSe. Se sim, lembre-se que agora os provedores são arquivos INI, você pode se basear nos que já existem. O provedor ISSCuritiba segue o padrão ABRASF versão 1.00 e somente o Lote é assinado como é o caso do Ginfes. Sendo assim a principio basta criar o arquivo INI para o provedor e iniciar os testes.

Bom dia, Muito obrigado pela colaboração, já esta disponível.

Bom dia Egon, Você costuma visitar o Portal Nacional da NF-e? Pelo jeito não, pois se visitasse diariamente iria ver que foi publicado uma nova Nota Técnica prorrogando o prazo para dezembro o ambiente de produção. Isso explica que uma nota enviada para o ambiente de produção é rejeitada com as notas TAGs.

Bom dia Régys, Você já pensou que maravilha se todas as cidades fizessem um convenio com a SEFAZ para aceitar a NF-e ou NFC-e somente com serviços? Iria acabar com essa zorra que é a NFS-e.

Boa tarde Cleyton, Com a NFC-e isso não será possível, como você já sabe. A saída que vejo é emitir a NFC-e no decorrer do mês e no fechamento emitir uma Fatura relacionando todas as notas e o valor total. Essa fatura com certeza terá um boleto para o pagamento, pois tudo indica que o pagamento é mensal.

Boa tarde a todos, Quando alimentar um campo do componente com o CNPJ ou CPF, favor informa-lo sem a mascara.

Boa tarde shdw, Tudo indica que você pode ter um NFC-e conjugada, ou seja, produtos mais serviços. Pois não encontrei nenhuma regra que rejeite uma NFC-e com item de serviço. Mas lembre-se que deverá ter no minimo um item de produto e tem que haver um acordo firmado entre o município e a SEFAZ do Estado.

Boa tarde a todos, No que diz respeito a numeração sequencial do evento, devemos levar em consideração o seu tipo. Cada tipo de evento tem a sua numeração sequencial iniciada em 1, sendo assim vamos a um exemplo: Foi solicitado uma CC-e para uma NF-e a numeração sequencial do evento CC-e é 1 pelo simples fato dela ser a primeira. Caso tenhamos uma segunda CC-e a numeração sequencial será 2. Suponha que em seguida essa mesma NF-e venha ser cancelada, qual será o numero sequencial do evento de cancelamento? A resposta é simples: 1 Porque? Leia novamente a linha acima em negrito. Complementando o que Régys escreveu, também não existe mais o PathCan.

Boa tarde, Se você criar um arquivo em memória cujo conteúdo é: <a>valor1</a><b>valor2</b> e salvar com o seguinte nome: teste.xml você acaba de criar um XML que possui uma TAG chamada "a" cujo conteúdo é a palavra "valor1" e a TAG "b" com o conteúdo "valor2". Como pode ver, não existe nenhum segredo.

Bom dia Agnaldo, Entendo perfeitamente o seu desabafo. Mas note que a NT 2015/002 versão 1.00 no final da página 2 consta as seguintes datas: 01/10/2015 para homologação e 03/11/2015 para produção. Eu baixei essa NT no dia 28/07/2015 portanto 2 meses antes do inicio para homologação, prazo este suficiente para que nós fizéssemos as devidas alterações no componente e depois mais um mês para realizar os testes de envio com a nova TAG em ambiente de homologação. Já a NT 2015/002 versão 1.10 no final da página 3 consta que a data para o ambiente de produção foi prorrogada para 01/12/2015 e no final da página 2 diz que as regras de validação na SEFAZ vão começar a valer somente a partir de 01/01/2016. Isso significa que se você pode gerar ou não o XML com a nova TAG depois de 01/12/2015 sem nenhum problema, uma vez que a validação da mesma só vai ocorrer a partir de 01/01/2016, portanto ganhamos mais 2 meses para deixar tudo redondo. Eu baixei a versão 1.10 da NT no dia 19/10/2015, portanto quase 15 dias antes do previsto para entrada em produção informada pela versão 1.00 da mesma NT. Sendo assim não vejo nenhuma falta de respeito por parte do ENCAT, pois informou com antecedência que o prazo seria prorrogado. Não estou defendendo ninguém apenas sendo justo. Não sei quanto a você, mas eu, todos os dias de manhã visito os Portais Nacionais da NF-e, CT-e e MDF-e em busca de algum Manual, Nota Técnica ou Schemas novos. Tenho todos os PDFs baixados desta forma sei se tem algo novo ou não, caso afirmativo, baixo e leio para saber do que se trata. Se você não fizer isso, sempre será pego de surpresa.

Bom dia Diego, Não existe nada implementado no componente ACBrNFSe sobre esse consulta ao numero do último lote enviado, uma vez que esse método não faz parte do padrão ABRASF. A solução é bem simples, basta a sua aplicação fazer o controle efetivo tanto do numero do RPS quanto do numero do lote enviado para o provedor.