Italo Giurizzato Junior

Bom dia Heto Andrade, Dependendo da SEFAZ a conversão em hexa de alguns dados, as letras tem que fica em minúsculos e para outros em maiúsculos. Que eu me recorde foi feita uma alteração no componente visando esse problema. Todos os fontes estão atualizados?

Bom dia Eduardo, No meu entendimento, pela falta de padronização dos provedores de NFS-e, acredito que vai ocorrer problemas, uma vez que dependendo do provedor o XML do RPS deve ser assinado ou não.

Bom dia Heronim, Da forma que você fez esta errado, pois será removido o zero para todos os provedores que sejam diferentes de proGoiania, sendo que essa remoção deve ser feita somente para o provedor proVitoria, correto?

Bom dia, Você tem um programa Delphi que se utiliza do componente ACBrNFe para gerar o XML, então para que você se utiliza do ACBrNFeMonitor?

Bom dia Edson, O componente ACBrNFe, mediante configuração, permite emitir NF-e e NFC-e. No caso da NF-e existe o DANFE feito em Quick Report, Rave, Fast Report e Fortes Report, o seu Delphi XE7 não veio com nenhum desses Report?

Bom dia Sérgio, No que diz respeito aos Impostos não muda nada. Mas lembre-se que NFC-e é para venda ao consumidor sendo assim alguns impostos não devem ser destacados, por exemplo IPI. Aconselho você pegar informações por escrito do contador do seu cliente, ele é obrigado a saber quais são os impostos a serem destacados em uma venda ao consumidor. Se ele não souber, contador ele não é.

Bom dia Ricardo, Na minha aplicação o usuário executa os seguintes passos: 1. Através da tela de lançamento ele registra a venda, informando que é o cliente e quais são os produtos vendidos a ele. Caso o cliente não esteja cadastrado existe um botão nessa tela que apresenta a tela para que o cliente seja cadastrado. Obs: o usuário pode lançar quantas vendas ele desejar, uma vez que os dados vão para o banco de dados. 2. Através da tela de emissão, é apresentado ao usuário todas as vendas cujas notas não foram emitidas ainda. Ele deve seleciona-las e clicar no botão [Emitir]. Obs: o botão [Emitir] executa a rotina alimentar componente para cada nota selecionada, essa rotina lê os dados da venda que estão no banco de dados e são atribuídos as propriedades do componente (o programa exemplo possui essa rotina, mas os dados são fixos, portanto devemos alterar de tal forma que a informação seja lida de um campo do banco de dados. Após alimentar os dados de todas as notas selecionadas é executado o comando Enviar (do componente), esse comando se encarrega de gerar o XML, assinar e validar para cada nota incluída no componente. Estando todos OK, ele gera o lote e envia a SEFAZ, esta processa o lote estando todas OK é retornado o protocolo de autorização de cada uma das notas, que é acrescentado automaticamente ao XML e por fim o DANFE de cada nota é impresso. O envio do XML por e-mail é realizado através de um outro comando do componente. A rotina do botão [Enviar] deve ainda atualizar o banco de dados de tal forma que marque as vendas selecionadas inicialmente como notas emitidas. O programa exemplo traz as funcionalidades separadamente por questões de didática, mas nada lhe impede que você inclua em um único botão a funcionalidade de enviar e de enviar e-mail, por exemplo. Desta forma você simplifica a vida do usuário e automatiza o processo. Um conselho, vai montando a sua aplicação por etapas, não queria implementar tudo ao mesmo tempo, só passe para a tela de cancelamento quando o processo de emissão estiver pronto e funcionando 100%.

Boa tarde Ricardo, Em uma nota temos basicamente: 1. Dados do Emitente; 2. Dados do Destinatário (Cliente); 3. Dados dos Produtos vendidos; 4. Dados da Transportadora quando esta vier a ser a responsável pelo transporte dos produtos até o Destinatário. Sendo assim, o seu sistema vai ter que possui o Cadastro de Emitente, de Clientes, de Produtos e de Transportadoras. Será necessário uma opção para registrar a venda, ou seja, informar quem é o cliente a transportadora e os produtos, para isso será necessário 2 cadastros um de notas e outro de itens. Entenda que o cadastro de itens são os produtos contidos em uma nota. Quanto a NF-e, será necessário uma opção onde o usuário possa selecionar uma ou várias notas não emitidas (máximo de 50) para que seja gerado o XML de cada uma delas, seja realizado a assinatura digital e o envio, bem como a impressão do DANFE de cada uma delas e o envio do XML por e-mail ao destinatário. Uma outra opção para realizar o cancelamento caso haja necessidade e uma outra para realizar a consulta, muito útil quando ocorre algum problema e o XML da NF-e fica sem o procolo de autorização da SEFAZ. No que diz respeito o que deve constar no XML, te aconselho acessar o Portal Nacional da NF-e e baixar a Nota Técnica 2013/005 versão 1.21, neste documento publicado pelo ENCAT você encontra a estrutura completa do XML, desta forma será possível saber o que é obrigado e o que é opcional. Quanto ao componente ACBrNFe sugiro você imprimir o Manual ACBrNFe versão 1.04 que encontra-se na pasta: ...\Doctos\Manuais Outra dica importante é estudar o programa exemplo que encontra-se na pasta: ...\Exemplos\ACBrNFe2 Espero te ajudado.

João, No caso do Delphi 7 o Quick Report não é instalado automaticamente, portanto não há necessidade de desinstalar a versão 3 do Quick Report. Algo esta errado com a sua instalação, pois em 4 maquinas fiz o processo de desinstalar a versão 3 e instalar a 5 e tudo funcionou de primeira.

Boa tarde Eduardo, O ideal seria não seguir esse caminho.

Boa tarde João, Antes de instalar a versão 5 do Quick Report, você desinstalou a versão 3? A mensagem de erro ocorre assim que você instala a versão 5 do Quick Report? Se sim você tem algum outro componente de terceiro que se utiliza do Quick Report? Por exemplo, um componente que gera código de barras para ser incluído em um form do Quick Report.

Boa tarde, A ideia de emitir o DANFE da NFC-e em Quick Report é quando a quantidade de itens é pequena ou nem será impressa, ou seja, a tal da impressão ecológica.

Boa tarde, Esse problema já apareceu, mas em nenhum momento o componente seta o Content-Type como sendo Text/HTML.

Boa tarde Eduardo, Os schemas sofreram alteração? Alguns provedores utilizam schemas cujo atributo de identificação ID é todo minusculo, ou seja, "id", até ai sem nenhum problema. O problema é quando eles querem o XML assinado e o CAPICOM não consegue assinar o XML com o atributo todo em minusculo. Neste caso o XML é inicialmente gerado com o atributo "Id", para ser assinado e depois ocorre a troca por "id". Em alguns provedores o problema foi resolvido.

Boa tarde Leandro, O protocolo é retornado logo após o envio do lote. É equivalente ao Recibo retornado logo após o envio da NF-e ou CT-e ou MDF-e para a SEFAZ. No caso da NFS-e esse numero é chamado de protocolo em vez de recibo. Tem como objetivo acusar o recebimento do lote pelo Web Service.

Boa tarde Paulo, Tente apenas alimentar o componente com os dados pertinentes ao serviço e depois executar o ACBrNFSe.Enviar

Boa tarde Dércio, Talvez tenha que ser feito algum ajuste na unit pnfsNFSeR.pas para o provedor Digicred.

Boa tarde ALA, Mas você imprimiu ou melhor dizendo gerou o PDF do DAMDFE usando o XML com o protocolo de autorização. Você tentou imprimir ou gerar o PDF com o XML ainda sem o protocolo de autorização?

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

Leandro, Dependendo do provedor, podemos Consultar a Situação do Lote ou Consultar o Lote de RPS. No caso do Consultar a Situação vamos a resposta se o lote foi processado com sucesso ou não. Se o provedor não tem essa funcionalidade devemos consultar o lote direto, se ele foi processado com sucesso teremos como resposta os XMLs das NFS-e.

Boa tarde Dércio, Sim temos o tipo complexo chamado tcDadosPrestador, mas onde ele é usado? Na versão 2.00 do manual esse tipo não é utilizando em nenhum lugar. Vamos então nos basear na versão 2.02 do manual, página 32, temos a definição da TAG: PrestadorServico segundo o tipo tcDadosPrestador, mas note que essa TAG PrestadorServico faz parte de um outro tipo complexo chamado tcInfNfse. Por outro na página 31 temos o tipo complexo chamado tcInfDeclaracaoPrestacaoServico, onde temos uma TAG chamada Prestador cujo tipo é tcIdentificacaoPrestador. O tipo complexo tcInfDeclaracaoPrestacaoServico é praticamente toda a estrutura do RPS e como você pode ver ao fazer referencia ao prestador os dados informados são apenas o de identificação ou seja, CNPJ/CPF e Inscrição Municipal. Por outro lado o tipo complexo tcInfNfse é praticamente toda a estrutura da NFS-e e nela temos o PrestadorServico cujo tipo é tcDadosPrestador. No RPS devemos alimentar as propriedades do Prestador, por outro lado quando é lido o XML da NFS-e é alimentado as propriedades do PrestadorServico. Sei que o Manual é confuso, pois na verdade existem duas estruturas uma para o RPS e outra para a NFS-e, se você montar elas separadamente vai confirmar o que eu já tinha dito no post anterior.

Boa tarde Sergio, Desde já muito obrigado pela colaboração. Quando postar a Unit por inteira, por favor, post como anexo.

Boa tarde, Sim, e dependo do componente, por exemplo o ACBrNFe você encontra a impressão de eventos (carta de correção) em Rave, Fortes Report e Quick Report.

Dércio, Se o provedor segue o padrão ABRASF no XML do RPS, no que diz respeito ao Prestador só é informado o CNPJ/CPF e Inscrição Municipal e nada mais. Infelizmente a ABRASF criou um layout extremamente pobre em informações, como você pode perceber no que diz respeito ao prestador. Sem contar que não existe uma TAG para informar se o XML gerado será enviado para o ambiente de homologação ou de produção. Fizeram um coisa tão enxuta que no meu entendimento ficou uma porcaria.

Boa tarde Eduardo, Esta correto a URL que você informou como sendo a de RecepcaoLoteRPS? Me parece que você colocou a URL de consultar a situação do lote.