Italo Giurizzato Junior

Bom dia a todos, Esta semana consegui realizar algumas alterações nas classes primarias que são responsáveis por realizar a assinatura digital nos XMLs. Com essas alterações consegui fazer com que o componente ACBrNFSe assinasse tanto o RPS quanto o Lote, pois antes somente um deles era possível assinar. Desta forma é possível gerar o Lote assinado com os RPS também assinado que é o caso do provedor Digifred e outros. Os fontes alterados ainda não foram disponibilizados uma vez que precisamos realizar testes com a NF-e, CT-e e MDF-e. Repito alterei as classes primarias e isso pode gerar um efeito colateral nos demais documentos fiscais eletrônicos. O teste que realizei foi utilizando o Capicom, agora é preciso testar com o OpenSSL e fazer as devidas alterações necessárias, bem como os testes com os outros tipos de DF-e. Por favor tenham um pouco mais de paciência, pois não queremos disponibilizar algo que venha provocar problemas no que esta funcionando.

Bom dia Elias, Lembre-se que o Encerramento de um MDF-e é tratado pela SEFAZ como sendo um evento.

Boa noite Jemilson, Pelo que me consta esse problema já tinha sido resolvido, você esta com todos os fontes atualizados?

Boa noite Marcos, Alem de manter todos os fontes de todos os componentes atualizados diariamente eu visito os Portais Nacionais da NF-e / CT-e e MDF-e em busca de algum manual, nota técnica ou pacote de schemas novos. Tenho também acesso a informações bem antes delas serem colocadas em pratica e serem publicadas em manuais e notas técnicas.

Boa tarde Rodrigo, De qual repositório você esta baixando os fontes. O problema esta na compilação e instalação dos componentes ou na compilação da sua aplicação?

Akai, Antes via a informação e agora não, então o problema é no provedor. Eles devem ter alterado alguma coisa.

Boa tarde Adolfo, O que você acha? A SEFAZ ainda não implementou no ambiente de produção as novas TAGs, e consta em Nota Técnica que o só vai ser liberado no dia 01/12/2015. Agora se você quer ficar tentando todos os dias até terça-feira que vem, isso é problema seu. Se desejar em entrar em contato com a SEFAZ para saber por que eles não disponibilizaram ainda, fique a vontade. Agora, antes de você tomar uma decisão, faça um favor, baixe a Nota Técnica 2015/003 versão 1.20 que esta disponível no Portal Nacional da NF-e e leia atentamente o item 01 - Resumo que encontra-se na página 4. Nela consta dia e hora que as mudanças serão efetivadas pelas SEFAZ-Autorizadoras, ou seja, a implementação vai ocorre a nível nacional.

Boa tarde Akai, Altere o arquivo INI do provedor para que o mesmo assine o pedido de cancelamento e refaça o teste.

Bom dia Rodrigo, Sim, Primeiro você carrega o XML da Nota com o LoadFromFile e depois executa o Consultar. Lembre-se que o XML da Nota tem que estar assinado e tenha sido enviado para SEFAZ.

Bom dia, Segue em anexo uma que encontrei. Tabela_CEST.pdf

Bom dia a todos, Já estão funcionando os Web Services de DistribuicaoDFe do MDF-e, tanto o de Homologação quanto o de Produção. Favor configurar o componente para salvar os arquivos Soap e iniciem os testes. Configuracoes.WebServices.Salvar := True; (salva os arquivos Soap) Como vamos testar essa funcionalidade pela primeira vez é bom termos esses arquivos para eventuais correções no componente.

Bom dia Marcos, Não, a SEFAZ quer acabar com o Web Services de consultar o status de Serviço, que diz que o serviço esta em operação ou não. No meu entendimento um Web Service que não serve para nada, pois me diga qual é o serviço que esta em operação? É o de Recepção, Retorno de Recepção, Consultar a Situação Atual de um Documento, Envio de Evento, Inutilização de Numeração ? Se esse Web Service retornasse a situação de todos os Web Services, ai sim saberíamos quais serviços estão em operação e os que não estão.

Bom dia, Tome muito cuidado com consultas, pois isso pode levar a SEFAZ a bloquear o contribuinte por Consumo Indevido do Web Services. Não entendo o porque de consultar a situação de um documento que nem sequer foi enviado para SEFAZ. No meu entendimento a sua aplicação tem que ter um controle efetivo do que foi: gerado e não enviado; gerado, enviado e processado com sucesso; gerado, enviado e sem retorno da SEFAZ (somente neste caso é que devemos realizar a consulta para saber se foi processado com sucesso ou não). Não se deve também consultar o Status do Serviço antes do envio pela mesma razão acima (Consumo Indevido) e o segundo motivo, existe uma vontade muito grande da SEFAZ acabar com esse Web Service. Reveja o seu fluxo de execução para não ter dor de cabeça futura.

Boa tarde Raoní, Pelo que me consta a NFC-e não pode conter Frete e Seguro uma vez que a venda é presencial.

Boa tarde Akai, Fiz uma pequena alteração no seu arquivo INI e enviei para o repositório, favor atualizar e testar. Antes que eu esqueça, muito obrigado pela colaboração.

Boa tarde a todos, Ao alimentar o componente só podemos usar dois valores possíveis se tratando da NFC-e são eles: Ide.tpImp := tiNFCe ou tiMsgEletronica; Desta forma a TAG tpImp vai conter o valor 4 ou 5, conforme consta na NT 2013/005 versão 1.22 Por outro lado a configuração do DANFE pode receber dois valores possíveis: DANFE.TipoDANFE := tiNFCe ou tiNFCeA4; Quando o valor for tiNFCe subentende que o DANFE será impresso em uma impressora de bobina, por outro lado o valor tiNFCeA4 diz ao componente que a impressão será realizada em um papel A4. No meu entendimento uma coisa é a configuração do DANFE e outra coisa é o valor que será passado para o XML, portanto não se faz necessário termos dois tipos para indicar o tipo de impressão. Posso muito bem gerar todos os meus XML - NFC-e com o valor 4 em tpImp, mas imprimir o DANFE em uma impressora Laser papel A4.

Bom dia Marcos, O erro referente a primeira tela que apareceu somente uma vez, é bem provável uma instabilidade na sua internet ou na SEFAZ.

Bom dia Renan, O componentes ACBr são para o Delphi em não para C#.

Bom dia, Se eu entendi você quer saber como faz para alimentar essa informação, se sim: Prod.CEST := < informe aqui o CEST >; O CEST é um campo que pertence ao detalhando do produto como é a código do produto, descrição entre outros.

Bom dia Alberto, Você pode conferir a sua lista com os tipos de eventos definidos em: TpcnTpEvento (unit pcnConversao.pas) Acredito que todos os eventos publicados em manuais e notas técnicas estão definidos em TpcnTpEvento.

Bom dia a todos, Favor atualizar os fontes e testar novamente.

Bom dia ALA, Em uma verificação rápida no seu XML, não faz sentido essa rejeição. Favor entrar em contato com a SEFAZ, com certeza o problema é com a validação deles.

Bom dia Kenio, O problema que temos as URLs dos Web Services de homologação da NFC-e para o Estado de GO, mas não temos as URLs de Consulta e QR-Code. Entre em contato com a SEFAZ-GO e solicite essas duas informações para que possamos atualizar o componente. Sem essas duas URLs que estão faltando você não vai conseguir validar o XML da NFC-e com a TAG qrCode.

Bom dia a todos, Só tem um problema Juliomar, caso o desenvolvedor informe que o tipo de impressão será tiNFCeA4 tanto na configuração do DANFE quanto ao alimentar o componente: DANFE.TipoDANFE := tiNFCeA4; e Ide.tpImp := tiNFCeA4; A TAG tpImp será gerada com o valor 6 fazendo com que a nota não seja validada, uma vez que os valores permitidos para essa TAG vão de 0 até 5 conforme NT 2013/005 versão 1.22 - página 18

Bom dia Renato, Se o seu erro é o mesmo conforme a imagem em anexo do post do Werner, então vai a dica: 1. DFeUF e DFeUFCodigo estão definidos na unit pcnConversao. 2. No Library Path do Delphi tem que existir uma linha semelhante a esta: C:\ACBrTrunk\Fontes\PCNComum 3. Ela tem que aparecer antes dos Path referentes aos componentes. 4. Procure pelos arquivos pcnConversao.pas e pcnConversao.DCU por todas as unidades ou partições do HD da sua maquina, exclua todas as ocorrências exceto da pasta apresentada no item 2.