Italo Giurizzato Junior

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.

Daniel, Fiz uma alteração no INI do provedor, favor atualizar e testar novamente.

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.

Tiago, Temos por volta de 17 provedores que precisamos migrar e que mesmo migrando não será possível ser utilizado uma vez que eles requerem que tanto o RPS quanto o Lote sejam assinados. E como dito anteriormente estamos enfrentando um problema ao tentar assinar o lote quando temos o RPS assinado, Enquanto isso vai tentando sugar do pessoal da prefeitura o maior numero possível de informações para que em breve possamos estar implementando um provedor para a cidade em questão.

Tiago, As informações contidas nesses manuais são poucas uma vez que não traz informações do tipo: relação das URLs dos Web Services, visto que existe o de Recepção, Consulta, Cancelamento, etc. Por ser próprio, teremos que implementar esse novo provedor e com poucas informações fica mais complicado a sua implementação. Outra coisa, com o Refactoring feito no componente ACBrNFSe ainda estamos migrando os provedores que já tinham sidos implementados. Ainda falta por volta de 19 provedores para serem migrados, alem de termos que resolver um problema de assinatura digital dupla, ou seja, devemos assinar o RPS e o Lote. Portanto não me leve a mau, a prioridade é migra o provedor que atende um numero grande de cidades e deixar para o final aqueles que atendem apenas uma cidade.

Boa tarde Tiago, Favor entrar em contato com a prefeitura e pede mais informações. Quando nós nos referimos a provedor, entenda como sendo a empresa contratada pela prefeitura para implantar a NFS-e. Existem prefeituras que investiram em pessoal e equipamento e hoje tem o seu próprio Web Service, portanto o provedor é ela mesma. Pode até ser o caso da sua cidade, mas é preciso entrar em contato.

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.

Boa tarde Daniel, O arquivo que eu mencionei é o único nessa situação alem do *-lista-nfse-soap.xml que esta exatamente igual ao outro. Os demais estão coerentes com o que é esperado. As rotinas que recebe e salvam os arquivos de envio e de retorno são exatamente a mesmas para todo o tipo de envio ou retorno. Logo podemos descartar que algo esteja diferente para esse retorno.Chequei todos os arquivos de envio e de retorno seguindo todo o Fluxo: Envio do Lote / Retorno; Consulta a Situação do Lote / Retorno; Consulta ao Lote / Retorno; Os arquivos que mencionei se referem ao Retorno ao Consultar o Lote, se você abrir um desses arquivos vai notar que nele consta a Nota, ou seja o conteúdo do XML da NFS-e. Concluo que, ou o Web Service esta retornando desta forma ou realmente os arquivos foram editados

Daniel, Obrigado pelos arquivos, vou analisa-los. ********* O arquivo: ee397d35-1062-4329-9885-62a2589c52b2-lista-nfse.xml foi editado? pois esta endentado.

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

Daniel, Configure o componente para salvar os arquivos soap (Configuracoes.WebServices.Salvar := True) depois post como anexo os arquivos de envio e de retorno para que possamos analisar.

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.

Bom dia Daniel, Esse erro ocorre para alguns provedores e esse problema foi contornado na versão antiga ( Trunk ). O problema ocorre ao tentar executar o InternetSetOption que esta na procedure OnBeforePost da unit ACBrDFeCapicomDelphiSoap. Peço que faça um teste, configure o ACBrNFSe, propriedade SSLLib com o valor libCapicom em vez de libCapicomDelphiSoap e tente enviar o lote de RPS para o provedor.

Bom dia, Vou conversar com o pessoal que cuida da NF-e / NFC-e para saber as razões do componente ACBrNFe salvar duas vezes a nota em lugares distintos. Realmente temos que padronizar, ou salva em apenas um lugar ou salva em dois lugares. Volto a dizer que não vejo vantagem nenhuma salvar o XML em dois lugares distintos. No meu entendimento o componente ACBrNFe esta realizando uma segunda gravação desnecessária.

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

O componente ACBrMonitorPlus se utiliza dos componentes ACBrNFe e ACBrCTe entre outros. No caso do ACBrNFe quando a nota é autorizada são executados dois métodos distintos chamados: Gravar e GravarXML que faz com que o XML da nota seja salvo em dois lugares diferentes. Por outro lado o ACBrCTe executa somente o método Gravar, dai a diferença. Podemos até alterar o componente ACBrCTe para que se comporte da mesma forma que o ACBrNFe, mas desculpem ainda não encontrei uma razão para isso.

Felipe, Testa usando CNPJ em vez de CNPJCPF.

Boa tarde Felipe, Em seu arquivo INI temos: [Entrega] xLgr=rua alexandre nro=100 xCpl= xBairro=paca cMun=3525904 xMun=jundiai UF=SP CNPJCPF=36469212000160 Altere para: [Entrega] xLgr=rua alexandre nro=100 xCpl= xBairro=paca cMun=3525904 xMun=jundiai UF=SP CNPJ=36469212000160 O campo CNPJ pode receber tanto um CNPJ quanto um CPF sem nenhum problema.

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.