Italo Giurizzato Junior

Boa tarde Edu, É muito estanho a mensagem "em branco" vai ser necessário "debugar" para saber o motivo, pois a principio o cancelamento esta sendo realizado com sucesso e esta ocorrendo o retorno, acusando o cancelamento.

Boa tarde Igor, Tentou alterar a rotina? Exemplo: case FProvedor of proGINFES: Gerador.wCampoNFSe(tcDe4, '#25', 'Aliquota', 01, 05, 1, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ); proRJ, proPublica, proBHISS: Gerador.wCampoNFSe(tcDe4, '#25', 'Aliquota', 01, 05, 0, (NFSe.Servico.Valores.Aliquota / 100), DSC_VALIQ);

Boa tarde Edu, Favor anexar os XML de envio e de retorno referente ao cancelamento.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Arturo, Se você envia uma nota para a SEFAZ mais de uma vez com a mesma chave, ocorre a rejeição: Duplicidade. Por outro lado se você envia a mesma nota, mas com chave diferente ocorre a rejeição: Duplicidade com diferença de chave. O que pode provocar essa diferença na chave? Uma informação que pode provocar essa diferença é o Código da Nota Fiscal - cNF. Alguns desenvolvedores atribuem ao campo cNF o mesmo valor de nNF (Numero da Nota Fiscal), esse procedimento esta errado e deixa a chave da sua nota vulnerável. Por recomendação da SEFAZ o valor de cNF tem que ser um numero aleatório com no máximo 8 dígitos. Se você atribui o valor zero a cNF o ACBr gera automaticamente um numero aleatório. Eu não aconselho você fazer desta forma, pois se você precisar gerar novamente a nota, um novo cNF será gerado provocando a Duplicidade com diferença de chave caso a nota já tenha sido enviada e processada pela SEFAZ. O correto é a sua aplicação gerar esse numero e guardar no banco de dados juntamente com os demais dados da nota. Quando for passar as informações da nota para que o XML seja gerado, você lê esse numero da mesma forma que os demais e atribui ao campo cNF. Desta forma a chave sempre será gerada igual.

Bom dia, Desculpe a demora, por favor atualize todos os fontes e faça novos testes. Note que fiz alteração no arquivo Sigep.ini Faça os testes usando o programa exemplo.

Bom dia Robério, Tente da seguinte forma: ideEvento.tpAmb := pcnConversaoReinf.taProducao;

Bom dia, O componente esta configurado para salvar os XML em disco? Configuracoes.Arquivos.Salvar := True; Configurracoes.Arquivos.DonwloadNFe.PathDowLoad := ???

Bom dia Sergio, Caso você queira colaborar implementando esse provedor, favor estudar como foi implementado outros provedores que não seguem o layout da ABRASF, como por exemplo os provedores: EL, SmarAPD, Equiplano, entre outros. E use o programa para realizar os testes.

Bom dia Mateus, Muito obrigado pela correção e colaboração, já enviei tudo para o repositório. Detalhe, no arquivo Cidades.ini não inclui o campo Banco_H, pois o componente ao ler esse arquivo se o campo Banco_H não existir ou não tiver valor é para ser considerado o valor "BANCO_DEMONSTRACAO". Por favor atualize e faça novos testes.

Bom dia Paulo, A minha sugestão é que você tenha todos os fontes (inclusive os Schemas) atualizados. Hoje o grupo <infRespTec> é opcional, mas futuramente poderá ser obrigatório, isso vai depender de cada UF. Eu já deixaria tudo preparado, inclusive o banco de dados com as informações do Responsável Técnico. Pois se amanhã a UF do seu cliente exigir esse grupo basta você mudar uma configuração na sua aplicação e pronto ela passa as informações e o grupo é gerado no XML.

Bom dia Joel, Desculpe pela demora, fiz a alteração favor atualizar os fontes e faça novos testes.

Bom dia Arturo, Ao tentar enviar novamente a nota a mesma é rejeitada por Duplicidade. A rejeição é por Duplicidade ou por Duplicidade com diferença de chave? Se for por Duplicidade isso significa que a chave que esta sendo gerada é exatamente igual ao da nota que já foi enviada. Neste caso em vez de enviar a nota, basta apenas gerar e assinar, mas não esqueça de pelo menos salvar o XML em disco ou no banco de dados conforme a dica do Felipe. Tendo o XML gerado e assinado, basta carregar e executar o método consultar. Desta forma você terá o XML atualizado, ou seja, XML assinado e com o protocolo de autorização.

Boa tarde Mateus, Já esta no repositório, favor atualizar os fontes e realizar novos testes. Veja a alteração que fiz no arquivo Cidades.ini para as cidades do provedor DataSmart.

Boa tarde, Abra as units referente ao DAMDFE feito em Fortes Report, clique no botão ignorar todas ao aparece a mensagem de propriedade inexistem mova algum componente do form e salve. Compile a aplicação com a opção Build e tente novamente. Esse tipo de mensagem de erro deixa claro que a versão que foi usada para fazer o DAMDFE não é a mesma que você esta usando.

Boa tarde a todos, Esse tópico esta sendo fechado pois a colaboração do Fernando Amando já se encontra no repositório. Persistindo duvidas ou problemas favor abrir um novo tópico.

Bom dia Raissa, Você esta com todos os fontes de todas as pastas atualizados? Se sim, reinstalou os componentes usando o ACBrInstall_Trunk2? Outra coisa o seu XML esta na versão 2.00 é preciso alterar para versão 3.00, pois é essa a versão que a SEFAZ agora aceita.

Mateus, Fiz uma alteração na unit ACBrNFSeConfiguracoes visando a leitura dos novos campos no arquivo Cidades.ini (Banco_P e Banco_H). Se o campo Banco_H estiver vazio ou não existir será considerado: BANCO_DEMOSTRACAO como sendo o valor desse campo. E alterei também a unit ACBrNFSeWebServices visando a troca da variável %Municipio% pelo valor das propriedades Banco_P ou Banco_H dependendo do ambiente setado.

Bom dia Rafael, Gostaria que você testasse com esse outro INI. Por favor faça todos os testes: Envio, Consulta, Cancelamento, etc. Anexa para mim a unit ACBrNFSeWebServices, para que eu possa comparar com as alterações que fiz. Giss.ini

Bom dia Rafael e Mateus, Primeiramente precisamos saber se em homologação sempre será: BANCO_DEMOSTRACAO não importando a cidade. Se sim, não faz sentido criar um campo no arquivo Cidades.ini para homologação. No caso do ambiente de produção precisamos saber se existe uma padronização na montagem do texto, pelo que notei deve ser "B_nomedacidadeUF (tudo em maiúsculo). Se existe um padrão não vejo necessidade de criar um campo no arquivo Cidades.ini para produção. Alguém poderia entrar em contato com o provedor e obter essas informações?

Boa tarde, Você esta com todos os schemas atualizados? Pela ultima mensagem de erro me parece que não foi gerado o grupo <pag>.

Boa tarde Marcio, Todo MDF-e deve ser encerrado ou caso não ocorra o transporte deve ser cancelado. Lembre-se não podemos cancelar um MDF-e encerrado, pois ao solicitar o seu encerramento estamos informando a SEFAZ que a carga foi transportada. Por outro lado não podemos encerrar um MDF-e cancelado, pois ao cancelar estamos informando a SEFAZ que a carga não será transportada.

Boa tarde Marcio, Não existe no webservice do MDF-e o serviço de inutilização de numero, portanto a mensagem de erro procede. Outra coisa importante é o conceito de Inutilização. Não inutilizamos um documento e sim um numero ou faixa de números. Quando solicitamos a inutilização de um numero ou faixa de números junto a SEFAZ, isso significa que estamos informando a SEFAZ que não existe nenhum documento com aquele numero ou faixa. Suponha que foi emitido a nota de numero 1500 e ao emitir a próxima ocorreu uma falha no sistema e por conta disso a nota seguinte saiu com o numero 1510. Neste caso podemos solicitar junto a SEFAZ a inutilização dos números de 1501 até 1509.

Bom dia Carlos, Com relação a versão, não devemos confundir a versão da Nota Técnica com a versão do Schema. Para você ter uma ideia a versão da NF-e é 4.00 e do Manual é 6.00 Eu particularmente não me simpatizo com esse procedimento. 1. Enviar o evento de Manifestação pelo simples fato de já possuirmos o DANFE. 2. Executar o método DistribuicaoDFePorChaveNFe. Pois qual é a garantia que o Ambiente Nacional já possui a nota para lhe retornar? As notas são manifestadas através de qual evento? Lembre-se que o evento Ciência da Operação hoje chamado de Ciência da Emissão, não é um evento conclusivo, sendo assim existe um prazo de 180 dias a contar da data de emissão da nota para o destinatário enviar um outro evento conclusivo que pode ser: Confirmação da Operação, Operação Não Realizada (requer justificativa) ou Desconhecimento da Operação. Por outro lado quando utilizamos o método DistribuicaoDFePorUltNSU temos uma relação de documentos que podem ser: Resumos de Notas, Notas, Resumos de Eventos ou Eventos. Se nessa lista temos o resumo da nota de numero 1500 isso significa que a SEFAZ-Autorizadora já compartilhou o XML da nota com o Ambiente Nacional. Neste caso posso enviar o evento de Manifestação do Destinatário e terei a certeza que nas próximas execuções no método DistribuicaoDFePorUltNSU terei o XML completo da nota.

Bom dia Carlos, Pelas imagens dos erros os testes foram feitos com dois CT-e, correto? No primeiro o problema é o valor "ISENTO" passado para a IE do remetente. Esse remetente é uma pessoa jurídica isenta de inscrição estadual? Se sim, deixe o campo IE em branco. No segundo o problema se refere o valor 11 passado para o nFat, esse erro esta estranho pois esse campo é uma string com no minuto 1 e no máximo 60 caracteres. Experimenta informar 011 e vez de 11.