Italo Giurizzato Junior

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.

Boa tarde Wagner, Se não me falha a memória a rotina de envio de e-mail da NF-e e do CT-e são semelhantes. Também tenho dois sistemas rodando na mesma maquina, um emitindo NF-e e outro CT-e e não tive nenhum problema, ambos enviam sem problemas.

Boa tarde Aline, Acho um tanto complicado o que você pretende, pois não é só o valor que aparece apenas "0" e no seu sistema aparece "0-Pago", tem também o grupo e o campo. No meu entendimento essa alteração fica a cargo do desenvolvedor uma vez que os fontes estão disponíveis para que possamos altera-los, conforme a nossa necessidade.

Bom dia Paulo, A opção Síncrono é para a NFC-e e não NF-e. O Web Services Recepcao só aceitava o envio assíncrono, o novo chamado Autorizacao aceita tanto o assíncrono como o síncrono. Até onde sei as NF-e vão continuar no modo assíncrono, por outro lado os lotes de apenas UMA NFC-e devem ser enviado no modo síncrono e os lotes com DUAS ou mais NFC-e devem ser enviado no modo assíncrono.

Bom dia Orlando, Você fez alguma alteração no componente? Se sim, post como anexo os fontes que você alterou.

Bom dia Gledson, Note que o programa exemplo, possui 2 opções de consulta, uma delas é [Consultar Carregando XML] e a outra [Consultar pela Chave]. Qual das duas o erro ocorreu? Fiz um teste de carregar o XML e imprimir o DANFE não ocorreu nenhum problema, logo o problema não esta na leitura do XML.

Bom doa Wagner, O ACBr não utiliza o Indy e esse erro você só vai resolver configurando corretamente, porta, SSL, etc. Como essas configurações mudam de provedor para provedor de e-mail, o jeito é testar.

Como não tem o XML? A chave se refere a uma nota emitida por você ou pelo seu fornecedor? Se foi pelo seu fornecedor, esquece, o método Consultar é usado para consultar a situação atual de uma nota emitida por você.

Boa tarde, Sim, existem o DANFE NFC-e feito em Quick e outros Report que imprimem o QR-Code.

Boa tarde Caetano, Por favor atualize todos os fontes de todas as pastas e tente novamente.

Boa tarde Gledson, Post como anexo o XML da NF-e.

Boa tarde Rafael, Segundo o Manual versão 2.00a do CT-e página 39 temos a regra G048a executada pela SEFAZ e nesta regra diz o seguinte: Para CT-e de anulação de valores: Se UF de início da prestação = UF de fim de prestação (ambas <> EX) CFOP deve ser 1206 Se UF de início da prestação <> UF de fim da prestação (ambas <> EX) CFOP deve ser 2206 Se UF de inicio ou fim de prestação = EX CFOP deve ser 3206