Italo Giurizzato Junior

Bom dia Caio, Você postou nesta quarta feira que foi comunicado sobre a alteração das URLs. O documento emitido pela SEFAZ-RS que trata sobre essas novas URLs foi publicado no final de Abri/2015 e no dia 01/05/2015 tanto o repositório trunk quanto o trunk2 já estavam com as novas URLs. Quem fez essa alteração foi eu e não tenho ninguém dentro da SEFAZ que me envia essas documentações em primeira mão, apenas visito diariamente os portais nacionais da NF-e, CT-e e MDF-e em busca de alguma novidade. E também diariamente verifico se tem atualização de fontes através do Tortoise. Essa é a dica que deixo.

Bom dia Leão, Não se deve atribuir nada a: infMDFe.Versao caso contrario vai ocorrer erros. Essa linha não deve existir na sua aplicação.

Boa tarde, Esse assunto já foi trata em dezenas de postagens, por favor realize uma pesquisa.

Boa tarde Leonardo, Entendo perfeitamente o seu problema, devemos usar o que a empresa adquiriu ou queremos usar por termos um conhecimento maior sobre um Report em relação a outro. Eu me incluo nesse dilema, tenho um ERP com 80 módulos e todos os relatórios foram feitos em Quick Report. O Quick Report pode não ser o melhor do mundo, mas é o que eu tenho um certo domínio. No momento eu optei por continuar a usar o Quick Report, sendo assim tive que colocar a mão na massa e fazer todas as alterações necessárias, inclusive no pacote de instalação para fazer com que o DANFE, DACTE e DAMDFE feitos em Quick Report funcionassem com o Trunk2. Mas lembre-se oficialmente o ACBr só terá suporte para o Fast e Fortes Report. Se você deseja usar o Rave por preferencia ou por obrigação faça como eu, coloque a mão na massa para compatibiliza-lo com o Trunk2.

O componente ao montar o nome do XSD, no que diz respeito ao modal e no que se refere a versão, ele se baseia na versão atribuída a propriedade infMDFe.Versao. Se na sua aplicação não existe essa linha, então algo esta de errado com os seus fontes do componente. Favor atualizar todos os fontes de todas as pastas.

Boa tarde Alexandre, Os arquivos INI estão sendo criados aos poucos, não criamos todos, pois ainda não conseguimos fazer funcionar alguns métodos. Queremos fazer o componente funcionar para os provedores cujos INI já foram criados, para que possamos depois começar a criar para os demais. Mas nada impede que você estude os já criados e crie um para o Betha. Dica, muitas das informações contidas no arquivo INI do provedor são extraídas da Unit do respectivo provedor, que no seu caso seria o ACBrProvedorBetha.pas

Boa tarde Leao, Na sua aplicação, mais precisamente na rotina onde o componente é alimentado.

Boa tarde, Você gera o XML e assina com um numero de nota provisório e submete ao validador do componente para saber se os dados estão corretos ou não. Se ocorrer erro na validação o usuário não vai ter que efetuar a correção? Com certeza que sim, então porque você não atribui o numero correto da nota de uma vez? Lembre-se que o numero da nota, ou seja, o campo nNF é usado para compor a chave da NF-e e seu conteúdo é usado para calcular o DisgestValue da assinatura. Eu compreendo o que você fez, o usuário lança varias possíveis vendas e a medida que elas vão se concretizando emiti-se a nota e a numeração tem que ser sequencial. Muito bem, em vez do usuário lançar uma venda, ele lançaria um orçamento que possui uma numeração sequencial, caso este se concretize é gerado a nota com a sua numeração própria. No meu entendimento no que diz respeito a validação esta tem que ser feita na entrada dos dados. Se você validar cada informação digitada as chances do validador do componente acusar algum erro é quase zero.

Boa tarde Diego, Você esta usando os fontes do Trunk ou Trunk2? De qual quer forma, favor olhar a rotina do botão enviar email que lá você o método e seus respectivos parâmetros. Resumindo o método EnviarEmail possui um parâmetro para fazer com que o componente gere o PDF e anexe junto ao XML para ser enviado por e-mail. Agora se você deseja gerar antes de enviar existe o método ImprimirPDF que pode ser executado após o Enviar.

Boa tarde Paulo, Eu em particular acesso os Portais Nacionais da NF-e, CT-e e MDF-e duas vezes ao dia, as 7 da manhã e as 13:30 da tarde, para saber sobre a disponibilidade dos serviços, checar se existem novos Schemas, Manuais e Notas Técnicas. Caso exista eu baixo e leio para saber do que se trata. Se é algo novo, ou seja, uma TAG nova no XML, verifico a possibilidade de implementar sem que ocorra nenhum problema. Para você ter ideia existem varias coisas implementadas nos componentes só aguardando a liberação por parte da SEFAZ. Tudo o que consta nessa NT já foi implementado. Estamos aguardando a liberação do ambiente de homologação para iniciarmos os testes.

Bom dia a todos, Não seria o caso de colocar no Library Path do Delphi a pasta que contem as BPL do Fortes?

Bom dia Pedro, Acrescentando o que o Juliomar disse: Se você ainda utiliza os fontes do Trunk deve o mais rapido possível migrar para o Trunk2, pois apartir de novembro/2015 as NFC-e emitidas pelo ACBrNFe que esta no Trunk serão rejeitadas pela SEFAZ, pelo simples fato do XML gerado por esse componente estar em desacordo com a nova estrutura do XML. Por outro lado o ACBrNFe que encontra-se no Trunk2 já esta em conformidade com a nova estrutura, logo será aceito pela SEFAZ. Ao migrar para o Trunk2, no que diz respeito ao DANFE para NF-e você terá disponível somente o Fast e Fortes Report, mas nada impeça que você faça as devidas alterações nos fontes do DANFE feito em Rave para funcionar com o ACBrNFe do Trunk2. Mas respondendo a sua pergunta você não vai poder utilizar o mesmo DANFE tamanho A4 que é usado para a NF-e para imprimir o DANFE da NFC-e, pelo simples fato de que esse DANFE não imprime o QR-Code. O DANFE NFC-e não tem a barra de código que representa a chave, mas por outro lado possui a imagem do QR-Code. Espero ter esclarecido as suas duvidas.

Bom dia a todos, Marcio, o componente gera sim a URL do QR-Code conforme consta no manual do DANFE NFC-e, manual este que contem toda a especificação de como deve ser gerado a URL. No que diz respeito a validação da URL por parte da SEFAZ, é que a URL vai constar no XML da NFC-e. Daniel, você lembra das linhas comentadas no método Assinar que são responsáveis por incluir a URL do QR-Code no XML da NFC-e? O QR-Code a principio era gerado e impresso no DANFE da NFC-e, agora alem disso o XML da NFC-e vai passar a ter essa URL. Já temos os novos Schemas que vão fazer uma validação primaria dessa URL e a SEFAZ por sua vez ao receber o XML vai fazer a sua validação que por sinal é mais completa, ou seja, não vai apenas validar se existem os campos que compõe a URL e sim o valor de cada campo. Marcio, em resumo o componente esta preparado para atender as alterações publicadas na NT 2015/001. Volto a lembrar que devemos iniciar os testes em 01/10/2015 para que no dia 03/11/2015 os XMLs das NFC-e já sejam enviados conforme a NT em ambiente de produção.

Bom dia rlind, Se você se refere aos fontes do Trunk a resposta é não. Agora se você esta usando os fontes do Trunk2 a resposta é sim.

Bom dia Leão, Verifique se na sua rotina que alimenta o componente se existe alguma linha onde é atribuído algum valor a propriedade Id. Se sim exclua essa linha, não se deve atribuir nada a propriedade Id, tem que deixar o próprio componente calcular o valor dela.

Bom dia a todos, Luis, no que diz respeito aos novos endereços publicado pela SEFAZ-RS, eu mesmo alterei tanto os fontes do Trunk quando do Trunk2. Essa alteração ocorreu em 01/05/2015, se você tem o abito de atualizar os seus fontes diariamente, as suas aplicações já estão enviando para os novos endereços a 4 meses. Sendo assim se você possui uma aplicação usando os fontes do Trunk ela não vai parar em 01/10/2015 em função dos novos endereços. Mas poderá parar depois dessa data em virtude de novas TAGs que a SEFAZ acrescentou ao XML. Os fontes do Trunk2 já estão preparados para atender essas novas TAGs, por outro lado os fontes do Trunk não estão. Reforço o que o Juliomar já disse, migre o mais rápido possível para o Trunk2.

Bom dia Igor, Verifique se você não esta atribuindo o valor 2.00 a propriedade Versao ao alimentar o componente. Algo do tipo: infMDFe.Versao := 2.00; Se sim, exclua essa linha.

Bom dia Rodrigo, Primeiramente é preciso ler com muita atenção a Emenda Constitucional 87 de 2015 uma vez que essa NT visa atender a mesma. Segundo é sempre bom consultar um bom contador.

Bom dia Matheus, É estranho essa rejeição, uma vez que o XML de pedido de consulta esta exatamente igual ao definido na Nota Técnica. Só resta fazer um último teste. Alterar o schema tirando o acento da palavra NÃO e fazer o mesmo na Unit do componente. Desta forma o XML será gerado sem o acento, será validado pois no schema também foi retirado o acento. Se a SEFAZ aceitar isso significa que a Nota Técnica esta errada e o schema também, ou eles acertaram o Web Services e esqueceram de disponibilizar um novo schema e uma NT informando a alteração. Se desejar fazer essas alterações e testar: Unit do componente: pmdfeConsMDFeNaoEnc.pas (...\Fontes\ACBrDFe\ACBrMDFe\PCNMDFe) Schema: consMDFeNaoEncTiposBasico_v1.00 (...\Exemplos\ACBrDFe\ACBrMDFe\Schemas) No schema devemos alterar a linha: <xs:element name="xServ" type="TServ" fixed="CONSULTAR NÃO ENCERRADOS"> Tirar o acento da vogal. Depois dessas alterações não esqueça de compilar a aplicação com a opção Build.

Bom dia Sergio, Dentro da pasta Exemplos existe uma pasta chamada ACBrTEFD.

Bom dia, A minha aplicação permite que o usuário lance diversas notas e depois escolhe a que deseja enviar para a SEFAZ. Quando os dados da nota vão ser gravados no banco de dados o cNF (código da NF conforme manual deve ser um numero aleatório) é gerado e salvo no banco de dados também. Quando o usuário seleciona a nota para Emitir (enviar para SEFAZ) é executado uma rotina que lê os dados do banco de dados e alimenta o componente e é nessa rotina que tenho a seguinte linha: Ide.cNF := DM_VEN.NotasNFChave.AsInteger; O campo NFChave da Tabela Notas é o que contem o numero aleatório gerado no momento da gravação da nota no banco de dados. Depois de alimentar o componente mando executar os métodos Assinar, Validar e Enviar. O Assinar se encarrega de gerar o XML e assinar o mesmo. Desta forma nunca tive problema com rejeição de assinatura diferente do calculado.

Boa tarde Sergio, Você esta instalando os componentes do Trunk2, muito bem, só tem um problema, não selecione o ACBrGNRE pois este ainda não esta pronto. O ACBrNFSe pode até compilar e instalar mas ainda não esta funcionando, pois existem alguns problemas que precisam ser resolvidos.

Boa tarde Matheus, Muito obrigado pela colaboração, já esta disponível no SVN. Com relação aos arquivos que você postou, poderia configurar o componente: Configuracoes.WebServices.Salvar := True; Para salvar os XMLs de envio e de retorno com as TAGs de envelopamento. Esses arquivos possuem a palavra soap no nome e nos ajuda bastante na detecção de erros.

Boa tarde Leão, Não sei qual é o software que você esta usando para visualizar o XML, mas não existe nenhum linha em branco em lugar nenhum desse XML. Ele só não esta assinado e protocolado e contem o valor 1 informado de forma errada a TAG qMDFe conforme eu já relatei em uma outra postagem sua.

Bom dia Leão, É bem provável que o seu MDF-e esteja sendo rejeitado pelo simples fato de você estar atribuindo o valor UM ao campo qMDFe. O campo qMDFe que fica no grupo <tot> não significa a quantidade de MDF-e que você esta emitindo e sim a quantidade de MDF-e que foi relacionado nesse MDF-e que você gerou. Um MDF-e pode conter uma lista de CT-e no caso de uma transportadora, ou uma lista de NF-e no caso de transporte próprio ou uma lista de MDF-e quando se tratar de transporte Multimodal. Quando o MDF-e possui uma lista de CT-e devemos informar em qCTe a quantidade de CT-e que constam nessa lista. Quando o MDF-e possui uma lista de NF-e devemos informar em qNFe a quantidade de NF-e que constam nessa lista. Quando o MDF-e possui uma lista de MDF-e devemos informar em qMDFe a quantidade de MDF-e que constam nessa lista. Sendo assim somente um desses campos terá um valor maior do que zero os demais são sempre zero. Logo o XML que você postou esta errado, pois aparece: <qNFe>3</qNFe> <qMDFe>1</qMDFe> Sendo que deve aparecer somente: <qNFe>3</qNFe> Faça as devidas correções e teste novamente.