Italo Giurizzato Junior

Boa tarde a todos, Favor atualizar os fontes e testar novamente. As alterações realizadas por mim foram baseadas no Soap-Envelope disponibilizado pelo Haroldo e informações do Thiago Garcia. Muito obrigado a todos pela colaboração e aguardo o resultado dos testes.

Bom dia Fernando, A primeira CC-e de um CT-e tem que ter nSeqEvento = 1 já a segunda CC-e para o mesmo CT-e tem que ser igual a 2, esse é o conceito e o meu entendimento.

Bom dia Jackson, Essa cidade não esta implementada. Primeiro é preciso saber qual é a empresa (provedor) que foi contratada pela prefeitura para implantar a NFS-e.

Bom dia Tathiana, Você pode alimentar o componente com os dados de até 50 RPS, ou seja ADD até 50 RPS no componente. Ao executar o método Enviar o componente se encarrega de gerar um XML para cada RPS adicionado, assinar caso necessário (depende do provedor) montar o lote com todos os RPS adicionados, assinar o lote caso necessário (depende do provedor), validar o lote e por fim enviar. Por outro lado o método Gerar só pode contem apenas um RPS. Temos ainda o método EnviarSincrono cuja diferença entre o Enviar é que este o modo de envio é assíncrono. Dependendo do provedor só é aceito apenas um dos métodos ou todos.

Bom dia Daniel, Post como anexo o XML da NFS-e que consta: Regime Especial de Tributação, Incentivo Fiscal e Optante do Simples e que ao ler o mesmo para imprimir não aparece no DANFSE.

Bom dia, Será que ao ler através do LoadFromStream ele detecta um carácter do tipo fim de arquivo e para de ler, provocando o corte.

Bom dia, Já esta disponível, favor atualizar os fontes e testar.

Bom dia a todos, O componente ACBrNFSe possui um método chamado GerarLote onde passamos como parâmetro o numero do lote. Esse método pode ser utilizado por qualquer provedor ele simplesmente gera o lote e salva em disco. Dependendo do provedor, os RPS vão estar assinados ou não e lote poderá estar assinado ou não.

Bom dia a todos, Desculpe na demora em responder. Estamos trabalhando já a alguns meses em um Refactoring dos fontes de todos os componentes, visando a diminuição e padronização de código. Antes os componentes ACBrNFe, ACBrCTe e ACBrMDFe tinham suas próprias rotinas de envio e retorno, bem como de e-mail, agora todos eles vão utilizar a mesma rotina. Isso significa que se a rotina de envio de e-mail funciona para o ACBrNFe tem que funcionar para os outros dois. Uma boa parte já esta pronta, a ideia é incluir o ACBrNFSe, não sei se será possível visto a sua lógica ser bem diferente dos demais, mas vamos tentar. DATAC, no que diz respeito as cidades que você listou, todas estão implementadas para o provedor ISSNet que também já esta implementado. Dica: a unit pnfsConversao possui uma function chamada CodCidadeToProvedor, para saber se uma cidade já é atendida ou não pelo componente e qual é o seu provedor basta procurar ela na function citada, veja este exemplo: 3127701, // Governador Valadares/MG 3131307 // Ipatinga/MG : Provedor := 'Actcon'; No exemplo acima temos o código IBGE e o nome da cidade e no final o nome do provedor que atende elas. A outra maneira é através do programa exemplo, que ao ser executado temos um botão onde informamos o código IBGE e ele retorno o nome do provedor. Se retornar a palavra nenhum significa que o componente não atende a cidade informada.

Bom dia Idez, O provedor Thema não tem o web services para receber um lote em modo síncrono, apenas assíncrono. Bom dia Dercide, Qual é o erro?

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

Boa tarde Adilson, Primeiro até onde sei não existe CC-e para NFC-e. Segundo se o usuário registrou como dinheiro e era checa não vejo grandes problemas quanto a isso. Terceiro o grupo forma de pagamento hoje é obrigatório ou não dependendo da UF, sendo assim o jeito é testar para saber se uma determinada UF aceita sem esse grupo.

Boa tarde Fernando, O idLote não é usado pela SEFAZ, por enquanto, portanto sugiro que seja um numero sequencial. Por outro lado nSeqEvento é checado pela SEFAZ, sendo assim e se tratando de CC-e esse numero tem que ser sequencial. O nome da TAG já diz tudo, numero sequencial do evento. Todos eventos começam como nSeqEvento = 1, mas somente alguns podem possuir um segundo evento do mesmo tipo, como por exemplo a CC-e. Sendo assim se eu for enviar um segundo evento de CC-e para o mesmo CT-e o nSeqEvento desta segunda CC-e tem que ser 2.

Jhones, Inverta, deixe o atributo versão por último.

Boa tarde Gledson, A diferença entre os arquivos *-ped-sit.xml e *-ped-sit-soap.xml é que o segundo esta completo, ou seja é exatamente esse arquivo que é enviado para a SEFAZ. Note que o conteúdo do primeiro esta contido no segundo dentro da tag nfeDadosMsg. Logo não tem nada haver se a consulta foi pela chave ou não. O problema esta apontado no retorno que diz que esta sendo usado uma ação soap inválida.

Boa tarde Jhones, Simples esta faltando o namespace na tag consReciMDFe, você só colocou o atributo de versão. A titulo de exemplo veja como é a tag retConsReciMDFe do retorno, note que alem do atributo versão tem também o atributo xmlns.

Bom dia sil303, Se você envia uma nota e ela é rejeitada, você deve corrigir. Esse corrigir não significa alterar o XML e sim alimentar novamente o componente com os dados corretos, gerar, assinar, validar novamente. Se você simplesmente abre o XML e altera ele e tenta enviar novamente é claro que vai ocorrer o erro de assinatura. Gregory, post como anexo o XML de uma nota e seu respectivo EPEC para que possamos verificar.

Bom dia Fabricio, Favor atualizar os fontes e testar novamente.

Gledson, A configuração do programa exemplo esta para salvar os arquivos de envio e de retorno? Se sim, você checou se o arquivo de retorno da consulta foi salva em disco?

Bom dia Janderson, O cancelamento é um evento, o componente ACBrNFe só vai utilizar o endereço de evento do SVC-AN caso a Forma de emissão seja SVCAN caso contrario, ou seja, se for Normal vai utilizar o endereço de evento da SEFAZ-Autorizadora. Outra coisa segundo a Nota Técnica 2013/007 versão 1.03 que trata sobre o SVC, item 04.3, devemos usar o SVC somente para cancelar notas emitidas pelo SVC, notas emitidas pela SEFAZ-Autorizadora, devem ser canceladas pela mesma. Futuramente pode ser que seja possível utilizar o SVC para cancelar uma nota emitida pela SEFAZ-Autorizadora, conforme consta na nota técnica.

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

Bom dia Gledson, Acredito que o problema esteja em uma procedure chamada: LoadConsulta201 que existe no programa exemplo. Experimenta comentar a linha que chama essa procedure para ver se o erro desaparece.

Bom dia a todos, A SEFAZ-RS através do Portal do Manifesto Eletrônico de Documentos Fiscais, publico um nota contendo as novas URLs de todos os Web Services tanto de Produção quando de Homologação para a NF-e, NFC-e, CT-e e MDF-e. Nesse documento constam as URLs da SEFAZ-RS, SVRS (SEFAZ-Virtual RS) e SVC-RS (SEFAZ-Virtual de Contingência RS). Os componentes ACBrNFe, ACBrCTe e ACBrMDFe, já foram alterados e disponibilizados com as novas URLs. Favor atualizar os fontes e reportar eventuais problemas.

Boa tarde Amarildo, Só usamos o evento EPEC quando o problema é a internet do emitente (no caso o seu cliente). Quando o problema é na SEFAZ-Autorizadora, uma coisa é certa, a própria SEFAZ vai solicitar a habilitação da SVC - SEFAZ-Virtual de Contingência. O que o seu sistema tem que fazer: 1. Tentar enviar para SEFAZ-Autorizadora; 2. Se não ocorrer nenhum erro, ótimo, fim do processo; 3. Se ocorrer erro, checar se o SVC esta habilitado; 4. Se não estiver aguardar alguns segundos e checar novamente; 5. Se estiver enviar para o SVC; 6. Se não ocorrer nenhum erro, ótimo, fim do processo. O erro que eu me refiro nos envios, são de conexão e não de rejeição referente a dados inconsistentes informados na nota.

Boa tarde, Muito obrigado pela informação, por favor atualize os fontes e teste novamente.