Italo Giurizzato Junior

Bom dia Jamil, Eu não utilizo o ACBrNFeMonitor, mas até onde sei, imprimi o DANFE da NFC-e.

Felipe, No caso da cidade de São Paulo, o componente que encontra-se disponível no Repositório não atende. Pois o XML não segue o padrão ABRASF. Pesquise no fórum, você vai encontrar um grupo de pessoas que estão implementado as rotinas necessárias para usar o ACBrNFSe para a cidade de São Paulo. Essas pessoas são as mais indicadas a esclarecer as suas duvidas e até mesmo lhe passar uma versão do ACBrNFSe que esta sendo modificado por eles.

Felipe, O componente ACBrNFSe gera o XML para você segundo a estrutura usada pelo provedor que atende a cidade desejada. Estude o programa exemplo do componente ACBrNFSe. Você vai notar que o mesmo possui uma procedure chamada AlimentarComponente, é nessa rotina que passamos os dados pertinentes referente ao serviço prestado. Ao executar o método Enviar, por exemplo, o mesmo se encarrega de gerar o XML do RPS, assinar ou não (depende do provedor), montar o lote, assinar o lote ou não (depende do provedor), submeter o lote ao validador do próprio componente (ele se utiliza dos schemas do provedor), envia e se tudo estiver OK o Web Services do provedor vai retornar o XML da NFS-e, e este é salvo em disco. O método Enviar possui um parâmetro (segundo) que se o seu valor for True assim que o XML da NFS-e for retornado o DANFSE é impresso. Ao meu ver, você deveria primeiro saber se o componente já atende a cidade para qual pretende emitir a NFS-e.

Boa tarde, O problema é que antes o componente removia os acentos das vogais e trocava o cedilha por C que conta-se nos retornos e ao ler os XML. Se você abrir o XML que você postou com o bloco de notas e procurar por cedilha e vogais acentuadas e fazer as trocas, vai conseguir visualiza-lo sem nenhum problema com um navegador.

Boa tarde Felipe, Se você pretende usar o componente ACBrNFSe, favor estudar o programa exemplo do mesmo. Outra coisa a NFS-e não tem nada haver com a NF-e. No caso da NF-e você gera o XML, assina e envia, a SEFAZ retorna o protocolo de autorização que deve ser incluído no XML da NF-e assinado. No que diz respeito a NFS-e, o que é gerado é o XML do RPS depois do envio o Web Services do provedor retorna o XML da NFS-e caso tudo esteja OK.

Boa tarde Felipe, Por favor atualize todos os fontes de todas as pastas e compile a aplicação com a opção Build.

Boa tarde, Você já tentou realizar essa alteração nos fontes? Os dois provedores já estão implementados, são 3 fontes a serem alterados: ACBrProvedorGinfesV3, ACBrProvedorBetha e pnfsConversao. Por favor tente realizar as alterações e faça os testes. Estando tudo OK, post como anexo os fontes alterados.

Boa tarde, A NFC-e substitui o Cupom Fiscal. A NFC-e é um documento fiscal e a NF-e é outro, a estrutura do XML é a mesma, ambos os documentos possui serie e números próprios uma vez que o modelo é outro. Uma empresa pode emitir os dois: NF-e e NFC-e dependendo da situação e pode ocorrer de ser impresso uma NF-e de numero 500 série 001 e uma NFC-e também de numero 500 série 001. Não existe nenhum problema, uma vez que o modelo de documento fiscal da NF-e é 55 e o da NFC-e é 65. Quanto a impressora não há problema, um detalhe com certeza ela terá que possuir um driver gráfico, pois no final do DANFE devemos imprimir a imagem do QR-Code.

Boa tarde Pedro, Muito obrigado pela colaboração, já esta disponível.

Boa tarde, Se você tem o DANFSE em Fast Report instalado, basta abrir o fonte do programa exemplo do ACBrNFSe, remover as referencias ao DANFSE feito em Quick Report e incluir o que foi feito em Fast Report. Não esqueça de relacionar o ACBrNFSe com o DANFSE através da propriedade com o mesmo nome que encontra-se no ACBrNFSe.

Boa tarde Caetano, Post como anexo o arquivo de retorno. Você chegou a atualizar os fontes? Notou que inclui um IF antes dessas duas linhas?

Boa tarde Diogo, Em uma primeira analise não encontrei nenhum carácter que poderia estar provocando o problema. Você já tentou um contato com o provedor?

Boa tarde Joel, Muito obrigado pela colaboração, já esta disponível. Desculpa, não percebi que o arquivo em anexo estava logo na primeira linha da postagem.

Boa tarde Emerson, Muito obrigado pela informação, favor atualizar os fontes e testar novamente.

Boa tarde Wislei, Após realizar a consulta, tente ler a chave desta forma: chave := ACBrMDFe1.WebServices.ConsMDFeNaoEnc.InfMDFe.Items[x].chMDFe; coloque a linha acima dentro de um loop, onde x é o índice iniciando de zero.

Bom dia Gleidson, Em vez do DPEC já pensou em utilizar o EPEC ou SVC?

Bom dia a todos, Sérgio, se você é o destinatário da mercadoria, ao realizar uma consulta através do NFeDistribuicaoDFe não terá nenhuma informação acusando se uma nota foi manifestada ou não. A principio ao realizar a consulta é retornado um resumo da NF-e se você efetuar a manifestação dessa nota, por exemplo: Confirmação da Operação ao realizar novas consultas será retornado o XML completo da nota manifestada. Se a nota foi manifestada através do aplicativo da receita, agora você vai ter que colocar essa informação manualmente no banco de dados. Por outro lado, se quem esta realizando a consulta é o emitente da NF-e este sim, vai receber um resumo do evento de Confirmação da Operação, ou seja, a sua manifestação. Neste caso o emitente poderá se utilizar desse retorno para atualizar o seu banco de dados, desta forma, dando baixa da entrega da mercadoria. Resumindo, a Manifestação do Destinatário nada mais é do que a assinatura no canhoto de entrega da mercadoria, ou seja, temos agora o canhoto de entrega eletrônico.

Bom dia Wislei, Você chegou a estudar a unit pmdfeRetConsMDFeNaoEnc.pas ? Note que ao ler o retorno é montado uma lista chamada infMDFe. Essa lista possui duas propriedades: chMDFe e nProt que contem respectivamente a chave e o numero do protocolo do MDF-e não encerrado. Se esta lista não possuir nenhum elemento significa que todos os MDF-e emitidos estão encerrados.

Bom dia ncc, Vou analisar e assim que possível disponibilizar.

Boa tarde Diogo, Se possível post como anexo o XML de envio e que resulta na rejeição.

Boa tarde Joel, Por favor quanto postar correções em código fonte do componente, anexe a Unit alterada para que possamos realizar o merge. Não post as linhas alteradas como parte da postagem.

Caetano, Debugando você consegue descobrir qual é esse "método" que não existe?

Bom dia jGuto, Muito obrigado pela colaboração, assim que possível estarei disponibilizando.

Bom dia Diogo, No caso da NFS-e não existe uma padronização, infelizmente cada provedor faz do jeito que quer. A principio temos no caso do envio de um lote de RPS, métodos Enviar e EnviarSincrono: O lote é composto por 1 ou até 50 RPS, dependendo do provedor cada RPS deverá ser assinado ou não e o Lote também deverá ser assinado ou não. Por outro lado temos o método Gerar, esse método tem a finalidade de enviar somente 1 RPS, neste caso o RPS não é assinado somente o Lote e dependendo do provedor nem é assinado. A propriedade AssinaGerar faz com que o RPS não seja assinado quando enviado pelo método Gerar, mas o provedor requer que o mesmo seja assinado quando é enviado através dos métodos Enviar e ou EnviarSincrono. Não sei se ficou claro. Resumindo dependendo do método de envio o RPS deve ser assinado ou não.

Bom dia Caetano, O erro ocorre na compilação? Se sim, você deve estar com algum fonte desatualizado.