Italo Giurizzato Junior

Bom dia Marcelo, Lembre-se que a CC-e, o Cancelamento são eventos, e se utilizam na mesma rotina de envio e de retorno. Portanto se você sabe pegar o Status e salvar o XML do Cancelamento por evento do CT-e no banco de dados, basta fazer a mesma coisa com a CC-e. Pegar o Status: sStat := IntToStr(ACBrCTe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.cStat); Pegar o XML: sXML := ACBrCTe.WebServices.EnvEvento.EventoRetorno.retEvento.Items[0].RetInfEvento.XML; Verifique se isso resolve.

Bom dia Alberto, Quantos documentos você esta adicionando a lista infDoc ? Dentro do grupo infDoc podemos ter apenas UM dos seguintes grupos: infNFe, infNF e infOutros. Esse apenas UM quero me referir ao tipo de documento e não a quantidade, sendo assim, podemos ter 200 documentos (por exemplos), mas todos tem que ser do mesmo tipo. Todos tem que ser NF-e, ou todos tem que ser NF ou todos tem que ser Outros. O que deve estar ocorrendo é que você adicionou um documento no grupo infNF e agora quer adicionar outro em infNFe, neste caso ocorre o erro na validação. Outra coisa, se tratando de NF-e não devemos preencher os dados do grupo infNF, somente a chave deve ser informada no grupo infNFe.

Bom dia Stivgiacon, A sua aplicação gera o XML, correto? Se sim, por favor, post o XML como anexo.

Bom dia André, No caso do Quick Report, entre uma versão e outra temos a presença ou ausência de algumas propriedades. A minha sugestão é: antes de compilar e instalar o pacote do DANFSE, faça a remoção dessas propriedades. A maneira mais pratica de se fazer isso é seguindo o passo a passo (Property_Does Not Exist.txt) que encontra-se na pasta ...\Fontes\ACBrNFSe.

Bom dia a todos, Por favor, atualize os fontes e teste novamente.

Bom dia Haverstaken, Por favor abra o fonte: ACBrProvedorPronim.pas Na function GetConfigCidade, temos que o RPS não deve ser assinado e o Lote até o momento somente 3 cidades requerem assinatura. O manual que você se refere deve ser uma cópia do manual da ABRASF, mas lembre-se que os provedores não seguem o manual a risca. Atenção, a NFS-e não é que nem a NF-e, onde geramos, assinamos e enviamos o XML da Nota Fiscal e temos como resposta da SEFAZ apenas o protocolo de autorização. No caso da NFS-e o processo é diferente, o que geramos, assinamos e enviamos é o XML do RPS - Recibo Provisório de Serviço, o Web Service do provedor por sua vez, processa, estando tudo correto, ele gera e nos retorna o XML da NFS-e. Concluindo: O componente ACBrNFSe apenas gera, assina e valida RPS, ou melhor, valida o lote de RPS. O XML referente da NFS-e é o resultado do processamento do lote de RPS enviado, portanto o componente apenas obtêm esse retorno, extrai dele a nota e salva em disco. Acredito que a sua última pergunta esta respondida.

Demóstenes, Checar o status do SVC-AN é possuivel, basta configurar o componente para o mesmo, da mesma forma que você faz a checagem para o normal.

Heto Andrade, A principio é só isso. Mas verifique se antes de gerar/enviar você não esta setando somente o modelo? Outra coisa na alimentação do componente você esta atribuindo também a versão? exemplo: if DMDFe.NFe.Configuracoes.Geral.VersaoDF = ve300 then infNFe.Versao := 3 else infNFe.Versao := 3.1;

Bom dia Heto Andrade, Você colocou na sua rotina de configuração do componente as duas linhas e na ordem que já sugerimos em vários outros posts? A ordem correta é configurar primeiro o modelo e depois a versão. ACBrNFe1.Configuracoes.Geral.ModeloDF := moNFCe; ACBrNFe1.Configuracoes.Geral.VersaoDF := ve310; Verifique se depois disso não existe em outra rotina alguma linha que esteja configurando somente o modelo.

Bom dia André, O provedor de Recife exige sim o Certificado, pois tanto o RPS quanto o Lote de RPS devem ser assinados. Com relação ao Usuário e senha, não precisa. Abra o fonte: ACBrProvedorRecife.pas Veja a function GetConfigCidade, note que as propriedades AssinaRPS e AssinaLote estão recebendo o valor True, isso significa que necessita do certificado. Veja também a function Gera_DadosSenha, note que ela retorna vazio, isso significa que não precisa de usuário e senha. Desta forma você pode checar os demais provedores e saber quais desses requisitos cada um exige.

Demóstenes, O caminho é esse. Mas cuidado, não abuse do StatusServico.Executar a SEFAZ poderá te bloquear por uso abusivo do respectivo Web Services.

Bom dia Masoro79, Simples: // Após o envio for i := 0 to (ACBrNFe.NotasFiscais.Count - 1) do begin if ACBrNFe.NotasFiscais.Items.NFe.procNFe.cStat = 100 then // Nota foi autorizada else // Nota não foi autorizada end;

Bom dia André, Pelo que pude perceber existem algumas diferenças na mesma versão do Quick Report, para as diversas versões do Delphi. Qual é o erro ou o problema que você esta enfrentando ao instalar o pacote no Delphi 2009 quando este tem a versão 5.04 do Quick Report?

Bom dia Demóstenes, Primeiramente a SEFAZ-RJ não tem estrutura para recepcionar as NF-e, ela se utiliza da SEFAZ Virtual do Rio Grande do Sul. Atenção, não confunda SVRS - SEFAZ Virtual do Rio Grande do Sul, com a SVCRS - SEFAZ Virtual de Contingencia do Rio Grande do Sul, com SEFAZ-RS - SEFAZ do Rio Grande do Sul. São Web Services de recepção distintos. A SEFAZ-RS só recepciona NF-e de empresas do Rio Grande do Sul. A SVRS recepciona NF-e de empresas de Estados que se utilização da SEFAZ Virtual como é o caso do Rio de Janeiro. A SVCRS recepciona NF-e de empresas cujos Estados não utilização a SEFAZ-RS e SVRS. Como o Rio de Janeiro se utiliza da SVRS para envio das NF-e (normal) no caso de contingência deve-se enviar para a SVCAN - SEFAZ Virtual de Contingência Ambiente Nacional. No caso de envio Normal deve-se configurar o componente para UF = RJ, o mesmo se encarrega de enviar para a SVRS. No caso de envio em Continência deve-se manter configurado o componente ( UF = RJ ), o mesmo se encarrega de enviar para a SVCAN. Se você já testou o envio Normal e o de Contingência, você tem que partir agora para o EPEC. Mas o EPEC é um evento, ou seja, você não envia a NF-e e sim alguns dados sobre ela. Sugiro você ler atentamente a Nota Técnica 2014/001 que trata sobre o assunto.

Bom dia, Atualize os fontes e certifique-se de estar utilizado o arquivo XSD correto. Detalhe importante, apesar do XSD estar gravado com o nome nfse_v2_01.xsd o nome dele para ser utilizado pelo componente ACBrNFSe tem que ser: nfse.xsd

Bom dia Helio, Se o componente estiver configurado para salvar os arquivos XML em disco, você tem como resultado final do cancelamento o arquivo: *-procEventoCTe.xml Este arquivo contem a solicitação de cancelamento, bem como o retorno da SEFAZ com o protocolo de cancelamento. Por outro lado, você pode realizar uma consulta, teremos como resposta um arquivo chamado: *-sit.xml, nele também vai contem o protocolo de cancelamento. Se os fontes estiverem atualizados, terá também uma arquivo: *-CTeDFe.xml, nele você terá o conteúdo completo do CT-e, mais o protocolo de cancelamento.

Bom dia Carlos, Só existem 2 maneiras de efetuar o encerramento de um MDF-e: 1. Usando o programa gratuito da SEFAZ, caso você tenha utilizado o mesmo para emitir o MDF-e 2. Usando um programa de terceiros, que permita você informar a chave do MDF-e e o numero de protocolo de autorização do mesmo. O Portal Nacional do MDF-e não lhe da nenhuma opção para efetuar o encerramento. Se você não esta conseguindo efetuar o encerramento através do programa gratuito, logo só lhe resta a segunda opção.

Bom dia Alberto, O tipo de documento informado não tem nada haver se o transporte é intermunicipal ou interestadual. Se o remetente da mercadoria é emitente de NF-e, no CT-e temos que informar a chave da mesma. Você só vai informar: o numero, série, valor, etc quando a Nota Fiscal for de papel, ou seja, o remetente da mercadoria não é obrigado ainda a emitir NF-e. A lógica é bem simples: Remetente que emite NF-e, devemos sempre informar a chave da mesma no grupo infNFe. Remetente que emite ainda NF comum (papel) devemos informar os dados da mesma no grupo infNF. Remetente não contribuinte ou isento de emissão de documento fiscal, devemos informar os dados da declaração no grupo infOutros. No Manual versão 2.00a do CT-e, você pesquisar não vai encontrar a palavra municipal, portanto não vai encontrar intermunicipal. Se procurar por estadual, você vai notar que sempre se refere a Secretaria da Fazenda Estadual ou Inscrição Estadual, portanto não faz referencia a interestadual. Página 134 do respectivo manual, grupo 262 = infNF diz: Informações das NF - Este grupo deve ser informado quando o documento originário for NF. Página 137, grupo 297 = infNFe diz: Informações das NF-e. Página 138, grupo 319 = infOutros diz: Informações dos demais documentos. Apesar de no manual não termos em infNFe e infOutros uma explicação como temos no infNF, mas fica claro que temos que informar o documento originário, ou seja, o documento emitido pelo remente da carga. Portanto a sua lógica de informar o documento originário de uma forma ou de outra dependendo se o transporte é intermunicipal ou interestadual esta errada.

Boa noite fpasqueto, Muito obrigado pela colaboração, fiz mais alguns acertos e já esta disponível.

Boa noite Alberto, Pela mensagem de rejeição, me leva a crer que o preenchimento não esta correto. Quanto o remetente é emitente de NF-e, esta sendo informado a chave da mesma, para ambos os casos, ou seja, transporte intermunicipal e interestadual?

Boa tarde Renato, Você não precisa realizar o Download do XML pelo site. O componente ACBrCTe tem um recurso interessante. 1. Alimente o componente carregando o XML do CT-e assinado e protocolado. 2. Realize a consulta. Se o componente estiver configurado para salvar os XML, o mesmo vai detectar que o CT-e possui eventos ao realizar a consulta e vai gerar um arquivo em disco com o seguinte nome: <chave>-CTeDFe.xml Esse arquivo contem todo o conteúdo do CT-e (assinatura + protocolo) e a lista de todos os eventos vinculados ao mesmo.

Boa tarde Alberto, Primeiramente vamos aos conceitos e o que pode ser informado em um CT-e: Ao emitir um CT-e devemos informar o documento emitido pelo remetente da carga. Esse documento pode ser 1 dos 3 tipos disponíveis: 1. NF-e 2. NF (Nota Fiscal comum de papel) 3. Outros (declaração, Carta Remessa de Mercadoria, ...) Quando o remente já é obrigado a emitir NF-e devemos simplesmente informar a chave da NF-e como sendo o documento originário. Quando o remente ainda não é obrigado a emitir NF-e, consequentemente ele ainda emite NF, neste caso devemos informar o numero, o valor, etc. Quando o remente não é contribuinte ou é isento de emissão de documento fiscal, ele deve emitir uma Declaração por exemplo, neste caso informamos a data o valor, etc como sendo Outros. Vamos agora, interpretar a mensagem de erro: "Grupo de documentos informado inválido para remetente que emite NF-e" Nela diz que o remetente emite NF-e e que as informações sobre o documento estão inválidas, ou melhor, lançado no grupo errado. Verifique se o erro não esta ocorrendo nessa situação: O remetente emitiu a NF-e e ao lançar no CT-e, esta lançando como NF (Nota Fiscal comum) ou como Outros.

Osocram, Uma coisa é a sua aplicação conseguir enviar e não conseguir obter o retorno, consequentemente o XML do CT-e ficou apenas assinado. Outra coisa é a sua aplicação não conseguir enviar pelo simples fato da SEFAZ ou o seu cliente estiver off-line. No primeiro caso resolvemos o problema realizando uma consulta. No segundo caso como o CT-e nem sequer foi enviado, basta então fazer o seu envio.

Boa tarde Roberto, O que você acha de realizar uma pesquisa no fórum antes? Veja se isso responde a sua pergunta:

Boa tarde Asterix, Revision: 7037 do dia 24/06/2014 Cheque se as units: pmdfeMDFe.pas, pmdfeMDFeR.pas e pmdfeMDFeW.pas estão com os seus icones (bolinha verde). Compilou a sua aplicação com a opção Build?