Italo Giurizzato Junior

Bom dia Ale, Você pretende enviar o RPS para qual cidade: Mossoró ou Parnamirim?

Bom dia Gustavo, Favor anexar o XML de envio do lote para que eu possa analisar.

Bom dia Alan, Se não ocorreu nenhuma mudança, conforme consta no arquivo Cidades.ini a cidade de Feira de Santana se utiliza do provedor WebISS para recepcionar o RPS e retornar a NFS-e. Conforme consta no arquivo WebISS.ini esse provedor segue o layout da ABRASFv1, ou seja, segue a versão 1 do layout da ABRASF. Para os provedores que seguem essa versão o fluxo é: 1. Enviar um lote com até 50 RPS através do método Enviar; 2. Consultar a Situação do Lote através do método ConsultarSituacao; 3. Por fim Consultar o Lote através do método ConsultarLote; Ao consultar o lote temos as seguintes situações: Se a situação do lote for 3 teremos como retorno a lista de rejeições que devemos corrigir e enviar novamente. Se a situação for 4 teremos como retorno os XMLs das notas. Aconselho realizar testes usando o programa exemplo com 1 ou 2 RPS no lote. Só depois partir para implementação da emissão da NFS-e na sua aplicação.

Boa tarde Felipe, Exemplifique melhor essa situação.

Boa tarde Anderson, No arquivo 4040-can.xml que é o retorno referente ao envio do pedido de cancelamento, consta a tag Sucesso com o valor True, isso para mim significa que a nota foi cancelada. Você diz que no final ocorre um erro, que erro é esse?

Boa tarde, Em uma postagem sua acima, diz que o retorno é -12 = Chave invalida. Favor anexar o XML do CT-e que você deseja cancelar bem como o XML de pedido de cancelamento deste CT-e, para que possamos analisar.

Boa tarde Eptus, Eu acredito que sim, pois tem que seguir o horário de onde o webservice se encontra. Você esta tendo alguma rejeição com relação ao horário?

Boa tarde Monteiro, Esse XML que você anexou é o de envio do lote de RPS, e parece que esta tudo OK. Depois do envio, chegou a consultar o lote através do programa exemplo? Se sim, favor anexar o XML de envio e de retorno da consulta.

Boa tarde Lucio, Você precisa incluir a cidade no arquivo Cidades.ini aos moldes das demais cidades que também utilizam o provedor Sigep. O passo seguinte é usar o programa exemplo para fazer os testes. Estando tudo OK, anexe o arquivo Cidades.ini aqui para que possamos validar e disponibilizar no repositório.

Boa tarde Ale, Acredito ter encontrado o problema, vou enviar para o repositório uma possível solução. Favor atualizar os fontes e faça novos testes.

Boa tarde, Já se encontra no repositório uma alteração que fiz tanto no arquivo do provedor quanto no Cidades.ini visando simplificar a inclusão de novas cidades.

Monteiro, Você esta enviado o lote de notas através do método Enviar. O provedor ISSDSF possui um layout próprio, ou seja, não segue o padrão ABRASF. Te aconselho a fazer testes com o programa exemplo do componente. Após o envio você consulta o lote informado o numero do lote e o numero do protocolo. Desta forma você vai saber o que ocorreu com os RPS que foram enviados. Procure sempre fazer testes com poucos RPS 2 ou 3 e ir aumentando a medida que os RPS são processados com sucesso.

Vou alterar o componente para deixar de usar essa unit. Até o final desta semana envio para o repositório.

Bom dia Claudio, Uma coisa é a SEFAZ não obrigar, outra é boas praticas e não deixar a chave do documento do seu cliente vulnerável. No caso da NF-e / NFC-e a SEFAZ estabeleceu uma regra de validação para validar a tag cNF e por conta dessa regra muitos desenvolvedores tiveram que fazer a alteração em suas aplicações a toque de caixa pois os seus clientes estavam parados sem poder emitir notas. Para mim é uma questão de tempo para a SEFAZ fazer o mesmo para o CT-e, MDF-e e outros DF-e que existem. O erro 500 as vezes esta relacionado ao XML enviado, com algo a mais ou a menos do que esperado pelo webservice. Em vez de você gerar o XML pelo seu sistema, seria mais pratico você gerar o arquivo INI e deixar o Monitor fazer o resto.

Bom dia Monteiro. A principio o lote de RPS deve conter no máximo 50 RPS. A não ser que o webservice do provedor esteja capacitado receber um lote com uma quantidade maior.

Bom dia, O provedor Elotech segue a versão 2 do layout da ABRASF, portanto não deveria existir essa unit. Inclusive nela tem procedure para criar o lote, sendo que quem faz isso é a unit pnfsNFSeG. Você tem os schemas que validam o XML gerado segundo essa versão 2.03 do layout da ABRASF?

Bom dia Léo, Já enviei para o repositório a sua colaboração.

Bom dia Fellipe, Já enviei para o repositório a sua colaboração.

Bom dia Ivo, O provedor Giap esta sim implementado. Dentro da pasta: ...\Fontes\ACBrDFe\ACBrNFSe\PCNNFSe temos a unit pnfsNFSeW_Giap que é responsável por gerar o XML do RPS segundo o layout desse provedor. E no arquivo Cidades.ini já consta a cidade de Bragança Paulista configurada para esse provedor. Você esta com todos os fontes de todas as pastas atualizados?

Bom dia Ale, Se o município não consta no arquivo Cidades.ini e ele se utiliza do provedor Tinus, o primeiro passo é acrescentar o município no arquivo Cidades.ini aos moldes de outros que se utilizam do mesmo provedor. O segundo passo é iniciar os testes usando o programa exemplo do componente ACBrNFSe. Funcionando, você anexa o arquivo Cidades.ini aqui no fórum para que possamos analisar e estando tudo OK enviaremos para o repositório.

Bom dia Claudio, Com a URL de produção: http://www.issnetonline.com.br/webserviceabrasf/cuiaba/servicos.asmx, não funciona?

Bom dia Luciane, Favor anexar tanto o arquivo Cidades.ini quanto o Smarapd.ini para que eu possa analisar.

Bom dia Eptus, Primeiramente peço que tome mais cuido ao postar pois você tinha postado em ACBrMDFe que não tem nada haver com Manifestação do Destinatário. MDF-e trata-se de um documento usado no transporte de carga para simplificar a vistoria nos postos de fronteira. Segundo, os Eventos de Manifestação do Destinatário não são enviados para a SEFAZ-Autorizadora do Destinatário e sim para o Ambiente Nacional,

Olá pessoal Confirme prometido estou anexando aqui nessa postagem o programa exemplo do componente ACBrNFSe refatorado para que vocês possam realizar os testes com os provedores de seus clientes. Caso tenham algum problema, em alguma funcionalidade favor anexar os XMLs de envio e de retorno que funciona atualmente e os gerados com o novo componente para que eu possa fazer as devidas correções. Foram implementados nesse novo componente 32 provedores que se utilizam da versão 1 do layout da ABRASF, 55 provedores (inclusive: SiapSistemas e DSFv2) que se utilizam da versão 2 do layout da ABRASF e 20 provedores que seguem o seu próprio layout, totalizando 107 provedores, abrangendo 1215 cidades. Como realizar os testes: Na sua maquina de desenvolvimento crie uma pasta (Por exemplo: NovoACBrNFSe) descompacte o arquivo ACBrNFSe_Exemplo.rar dentro dessa pasta. Ao executar ele pela primeira vez vai aparecer a tela de erro: O motivo de aparece essa tela é porque ainda não existe o arquivo de configuração. Clique no botão [OK] E configure da mesma forma que você configurou o programa exemplo do componente atual, ou antes de executar copie para dentro dessa pasta o arquivo de configuração (ACBrNFSe_Exemplo.ini) do programa exemplo que esta na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\Delphi Note que nesse novo programa exemplo temos um botão chamado Envio: Foi criado um novo método chamado Emitir que tem por finalidade abstrair os métodos de envio de cada provedor. Vamos a alguns exemplos: Os provedores que seguem a versão 1 do layout da ABRASF só possuem 1 método de envio que é o Enviar, logo o método Emitir vai usar esse método, por outro lado o provedor 4R que segue a versão 2 do layout da ABRASF e deveria ter disponibilizado os métodos Enviar, EnviarSincrono e Gerar, disponibilizou somente o EnvioSincrono, logo o método Emitir vai usar esse método. O provedor MegaSoft que também segue a versão 2 do layout da ABRSAF e que deveria ter disponibilizado os 3 métodos citados acima, só disponibilizou o método Gerar, logo o método Emitir vai se utilizar do método Gerar para enviar o RPS par o WebService. Assim que liberarmos os fontes do novo componente conto com todos para melhorarmos o método Emitir, pois acredito que ele vai simplificar bastante. Por fim peço a todos que postem os resultados dos testes aqui no fórum. Para quem não é membro do SAC favor postar em: Home / Fórum Aberto - ACBr / ACBrDFe / ACBrNFSe Para quem é membro do SAC favor postar em: Home / Suporte Pago - SAC / DFe - Documentos Fiscais Eletrônicos Programa exemplo do novo componente ACBrNFSe: ACBrNFSe_Exemplo.exe(compilado: 11/11/2020 as 16:14) Desde já muito obrigado pela colaboração de todos.

Bom dia Claudio, O problema é que você esta gerando a chave de forma errada. O digito que vem logo após o numero do MDF-e é o tipo de emissão (tag tpEmis) e não o tipo do emitente (tag tpEmit). Outra coisa, você esta atribuindo a tag cMDF um numero fraco que me parece ser o valor de nMDF + 1. O valor de cMDF tem que ser um código aleatório, conforme consta no manual. cMDF - Código numérico que compõe a Chave de Acesso. - Código aleatório gerado pelo emitente, com o objetivo de evitar acessos indevidos ao documento. O código deve ser gerado pela sua aplicação e salvo no banco de dados juntamente com os demais dados. Na hora de gerar o XML esse código é lido do banco de dados. Outra coisa que notei é que você esta gerando o XML com quebras de linha, recomento que não faça isso.