Italo Giurizzato Junior

Boa tarde Thiago, Pela mensagem retornada em produção, o certificado é de uma pessoa e os dados informados na consulta é de outra pessoa. A minha sugestão é sempre usar o certificado da pessoa informada na consulta e esta tem que estar cadastrada no Ginfes para poder emitir NFS-e via Web Services.

Boa tarde Eduardo, Alem de ser necessário o certificado digital para que o RPS e ou Lote sejam assinados, há necessidade de se realizar um cadastro no provedor, caso contrario o lote é rejeitado. Alguns provedores retornam uma mensagem amigável e clara sobre o problema, por outro lado outros não.

Boa tarde João, Não entendi, você configurou o componente para utilizar o provedor de Natal para gerar o XML de Mossoró? Isso não esta correto. Se Mossoró não possui ainda Web Services, é preciso verificar se o XML a ser importado é versão 1 ou 2. O componente possui dois provedores cuja finalidade é gerar o XML. Provedor ABRASF V1 e V2 um para cada versão do XML. Abra a unit pnfsConversao e procure pela function CodCidadeToProvedor, logo no inicio temos os provedores ABRASFv1 e ABRASFv2, veja como foi incluído a cidade de Jaboatão dos Guararapes/PE. Algo semelhante você vai ter que fazer para Mossoró, a unica coisa que precisa saber é se é versão 1 ou 2.

Boa tarde Dércio, Configure o componente para ele salvar os arquivos soap. Configuracoes.WebServices.Salvar := True; E testa novamente o envio de outro RPS. O componente vai salvar alguns arquivos cujo nome contem a palavra soap. Anexe esses arquivos aqui no post para que possamos analisar.

Boa tarde Marcio, Todos estão empenhados em busca de uma solução. Como não utilizo não tenho muita certeza, mas o programa gratuito de emissão de NF-e não tem opção para realizar a inutilização de numeração? Se sim, e se você tem urgência nessa inutilização, poderia utilizar o programa gratuito da SEFAZ, desta forma o seu cliente não ficaria com essa pendencia. Desde já agradeço a paciência e compreensão de todos, muito obrigado.

Boa tarde Sérgio, Como dito anteriormente, o componente consegue carregar e imprimir sem nenhum problema o DACTE de um XML versão 1.04 desde que o documento originário seja uma NF-e. Se for NF ou Outros o documento não será impresso. Para corrigir esse problema falta incluir esses dois tipos de documentos na unit que faz a leitura do XML, mais precisamente onde existe um IF que identifica os documentos originários da versão 1.04

Boa tarde João, O arquivo que você anexou é 1-lot-rps.xml, mas o que aparece na imagem que contem o erro possui o seguinte nome: 3lotrps.xml, são os mesmos arquivos?

Sérgio, Se você testar com um XML da versão 1.04 que contenha NF-e como documento originário é para funcionar com a mesma rotina da versão 2.00 Por outro lado para os XML da versão 1.04 que contenham NF ou Outros não vai funcionar, pois não foi implementado.

Heronim, Se você notar o XML do RPS, os únicos dados que consta referente ao Prestador são o CNPJ e a Insc. Municipal. Você teria que montar uma impressão de RPS sem se basear no XML, ou seja, utilizando-se dos dados lançados no seu sistema que estão no banco de dados. Não vejo impedimento você fazer isso, uma vez que você esta imprimindo apenas um Recibo e não uma Nota.

Bom dia Meinardo, Pelo que pude ver o provedor Tinus segue o padrão ABRASF, onde devemos assinar o RPS e o Lote antes de enviar. Isso não é problema pois o componente ACBrNFSe já esta preparado para esta situação. Você pode pegar criar uma nova unit chamada ACBrProvedorTinus aos moldes de uma outra. O problema que encontrei na documentação que você disponibilizou é: No XML exemplo, abra ele com o navegar, você vai notar que o Identificador das TAGs LoteRps e InfRps é "Id" (a letra i esta em maiúsculo). por outro lado no arquivos nfsetinus.xsd (schema usando para validar o lote gerado) o identificador esta definido como "id", sendo assim não será possível realizar a sua validação. Ou XML exemplo esta errado, ou o XSD. Favor entrar em contato com o provedor e questiona-los sobre esse problema.

Bom dia Ricardo, Esta disponível a versão 0.8.12.2, por favor baixe, instale e teste.

Bom dia edjal, O caminho C:\ACBrFontes\PCN2 tem que ficar antes de ACBrNFe2 e não depois no Library Path.

Bom dia Jakson, Antes ocorria a troca do protocolo de autorização pelo de cancelamento no XML da NF-e. Agora pelo fato do cancelamento ser um evento e seguindo orientação dos manuais devemos manter o XML da NF-e sempre com o protocolo de autorização. Devemos portanto enviar ao cliente o XML da NF-e autorizado ao cliente assim que o mesmo recebe o protocolo de autorização, conforme legislação vigente. Caso a NF-e venha ser cancelada devemos enviar o XML que consta o pedido e o protocolo de registro do evento de cancelamento ( *-procEventoNFe.xml ). Sendo assim os XML das NF-e e de Processamento de Eventos das NF-e ficam separados. A sua aplicação tem que ter um efetivo controle das notas, no banco de dados devemos ter um campo que indique que a mesma esta ou não cancelada. Desta forma com base nessa informação antes de imprimir o DANFE devemos atribuir o valor True ou False a propriedade NFeCancelada. Se a propriedade NFeCancelada receber o valor True, ao executar o comando para imprimir ou imprimirPDF o DANFE terá uma TARJA acusando que a mesma esta cancelada.

Bom dia, Você utiliza o componente ACBrNFSe? Se sim, a cidade Porto Alegre/RS se utiliza do provedor BHISS que por sinal já esta implementado. Todos os fontes de todas as pastas estão atualizados?

Bom dia Heronim, É bem provável que você esta carregando o XML do RPS para imprimir, sendo que o correto é carregar o XML da NFS-e.

Boa tarde Alberto, Fiz uma alteração, por favor atualize os fontes e teste novamente.

Dércio, Essa TAG só é incluída no momento do envio. O XML de um RPS não contem essa TAG. Fiz uma alteração para liberar essa funcionalidade para o provedor Digifred. Por favor atualize os fontes e tente novamente.

Anderson, Mai uma vez muito obrigado, já fiz a alteração e disponibilizei.

Boa tarde Anselmo, O CT-e de Anulação não tem o objetivo de anular um CT-e, algo semelhante a cancelar. Você anula valores e emite um outro CT-e com valores corretos, e o termo correto é Anulação de valores. Veja se este link: http://www.ophos.com.br/app/publicacoes/detalhe/ct-e-de-anulacao-e-substituicao/

Boa tarde Anderson, Alteração realizada e disponibilizada. Muito obrigado pela colaboração.

Boa tarde Dércio, Se eles estão pedindo para incluir a TAG GerarNfseEnvio isso significa que eles querem que você envie apenas um RPS de cada vez e não um lote de RPS. Portanto você deve utilizar o botão [Gerar e Enviar um RPS] do programa exemplo. Esse botão se utiliza do método Gerar e não Enviar. O método Enviar, gera e envia um lote contendo de 1 até 50 RPS. O método Gerar, gera e envia somente um RPS.

Boa tarde a todos, Não se deve executar o Assinar antes de enviar. Tem que deixar o componente realizar essa operação sozinho, pois dependendo do provedor devemos ou não assinar o RPS e devemos ou não assinar o Lote. Os comandos de envio checam se há necessidade de realizar a assinatura ou não e em qual momento.

Boa tarde Sergio, with ACBrCTe1.Conhecimentos.Items[0].CTe do begin for x := 0 to infCTeNorm.infDoc.infNF.count -1 do svalor := infCTeNorm.infDoc.infNF.items[x].propriedade end; propriedade é a propriedade que contem o valor a ser lido (vite estrutura do XML no Manual e Notas Técnicas) Algo semelhante pode ser feito para infNFe e infOutros.

Boa tarde Joemil, Por favor atualize os fontes e tente novamente.

Boa tarde a todos, Régys a alteração que fiz foi para PI e não PA. Mas acabo de fazer essa nova alteração e estou disponibilizando.