Italo Giurizzato Junior

Bom dia Adilson, A consulta a situação do lote só pode ser feita em provedores que seguem a versão 1 do layout da ABRASF. Os provedores que seguem a versão 2 não tem esse serviço em seus webservices. Os provedores que seguem a versão 1 só tem o serviço de envio assíncrono que no componente é o método Enviar. Já os provedores que seguem a versão 2 a principio tem os serviços de envio assíncrono (método Enviar), envio síncrono (método EnviarSincrono) e gerar nfse (método Gerar), este permite o envio de somente um rps. Por que a principio? Porque tem provedor que segue a versão 2, mas disponibilizou somente o Gerar nfse, outro somente o Enviar síncrono. De duas ou uma, ou você vai na tentativa e erro para saber quais os serviços que o provedor lhe oferece, ou abra o arquivo INI dele e veja quais seções de serviços foram montados os envelopes. Veja este exemplo: TcheInfov2.ini É um provedor que segue a versão 2 do layout da ABRASF, compare o conteúdo das seções: [Recepcionar], [ConsSit], [ConsLote], [ConsNFSeRps], [ConsNFSe], [Cancelar], [Gerar], [RecSincrono], [Substituir] Notou que somente os que eu coloquei em negrito esta definido o Envelope Soap? Sabe porque? Simples esse provedor apesar de seguir a versão 2 do layout a ABRAF em seu webservice implementou somente os serviços: Gerar NFSe, Cancelar NFSe e Consultar NFSe por RPS. Sendo assim para esse provedor o envio será feito pelo método Gerar, portanto um RPS por vez, logo não tem como enviar um lote de RPS. Não tem como consultar a situação do Lote, não tem como consultar o Lote, não tem como consultar a nfse e muito menos enviar um lote de RPS no modo assíncrono ou síncrono e nem o serviço de substituir nfse foi implementado. Entendeu agora que a sua aplicação tem que ter uma tela de configuração onde você define quais os serviços vão poder ser utilizados?

Bom dia Luís, Você esta usando o OpenSSL? Em vez de alterar os Schemas, você pode alterar o arquivo INI do provedor, para que a validação não ocorra antes do envio.

As NFC-e emitidas em contingencia, você se refere a off-line, correto? Se sim, note que elas não foram enviadas para a SEFAZ. Sendo assim não vejo a necessidade de corrigir esses XMLs.

Bom dia, O XML é gerado pela sua aplicação? Pois note que os dois encoding são diferentes, uma contem utf-8 e o outro UTF-8, além disso um tem os valores dos atributos entre apostrofe (aspas simples) e o outro esta entre aspas. O componente se utiliza de aspas e não de apostrofe.

Bom dia a todos, Procurando nos manuais da NF-e, principalmente a versão 6.00 que esta disponível no Portal Nacional da NF-e, bem como a versão 7.02 que esta disponível do Portal da NF-e SVRS, não existe nenhuma orientação sobre a troca do sufixo no nome do arquivo XML quando se tratar de NFC-e. Tomei como base esses manuais pois eles se referem a NF-e e NFC-e. Ultimamente as minhas consultas estão embasadas nos manuais disponibilizados no seguinte Portal: Portal dos Documentos Fiscais Eletrônicos - SVRS. Outra coisa, o ENCAT não alterou a tag <NFe> para <NFCe> e muito menos o prefixo da chave no atributo ID de NFe para NFCe. O layout é exatamente o mesmo, o que muda é simplesmente o valor da tag <mod> = Modelo do Documento Fiscal. Os sufixos nos nomes dos demais documentos que você mencionou tem os seus nomes baseados nos manuais e não por eu achar que deveria ser diferente.

Bom dia, Experimente remover o sinal "+" que esta na tag verProc.

Bom dia Udenilson, Para mais informações sobre o Distribuição DF-e, por favor leia: Como obter o XML do Fornecedor.

Bom dia Patrick, Muito obrigado pela colaboração, ainda hoje estarei enviando para o repositório.

Bom dia @MFincotto, Você chegou a testar nessas UF com as URLs que se encontram atualmente no arquivo ACBrNFeServicos? Se sim, qual foi o resultado?

Bom dia, Muito obrigado pela colaboração, já enviei para o repositório.

Bom dia, Em qual momento ocorre esse erro? É o componente que esta lhe apresentando essa mensagem ou você esta pegando o XML e tentando validar ele em algum site? Pois pelos os XMLs que você anexou, o XML assinado do BPe foi gerado, foi enviado, a SEFAZ retornou o protocolo de autorização e o XML assinado foi atualizado, ou seja, agora ele tem o protocolo de autorização. Foi gerado o XML do evento de pedido de cancelamento, ele foi enviado, a SEFAZ retornou o protocolo de homologação do cancelamento e foi gerado o arquivo *-procEventoBPe.xml que contem o pedido e o protocolo, até ai perfeito. Foi solicitado uma consulta por chave, o XML foi gerado e enviado, a SEFAZ retornou o resultado dessa consulta, no XML de retorno temos a situação atual (cancelado), o protocolo de autorização e por fim o pedido de cancelamento com o protocolo de homologação do mesmo. Resumindo, fazendo uma analise pelos arquivos XML, tudo ocorreu conforme o esperado.

Boa tarde, Você chegou a fazer testes com essa cidade usando o programa exemplo do ACBrNFSe? Se sim, qual é o problema que esta ocorrendo?

Boa tarde, Você esta com todos os fontes de todas as pastas atualizados? O problema ocorre também com o programa exemplo? Esta sendo enviado para o cliente o arquivo INI do provedor atualizado? Qual é exatamente o problema que esta ocorrendo e qual é a cidade?

Boa tarde Freitas, Esse fórum é para tratar sobre o componente ACBrNFSe - Nota Fiscal de Serviço Eletrônica, não tem nada haver com o seu problema que é NF-e e pelo que entendi você utiliza o ACBrMonitor. Peço que tenha mais cuidado quando postar, pois você pode acabar postando em lugar errado e não ter resposta para sanar o seu problema.

Boa tarde Adilson, A mensagem é clara, o RPS não foi aceito por já existir outro com o mesmo numero, serie e tipo. É preciso descobrir qual foi o ultimo RPS enviado para dar continuidade na numeração.

Boa tarde Jozimar, Favor anexar a unit alterada para que possamos analisar.

Boa tarde Luís, Por favor atualiza mais uma vez e faça um novo teste.

Boa tarde, Notei que a quantidade de caracteres informado no campo xJust (justificativa do cancelamento) tem menos de 15 caracteres. Favor realizar um novo teste de tal forma que a quantidade de caracteres informado no campo xJust tenha no mínimo 15 e no máximo 255.

Boa tarde Paulinho, Favor anexar o XML assinado e autorizado desse MDF-e. Devemos ter em mente que a Data/Hora de Emissão se refere a Data/Hora da UF do Emitente, já a Data/Hora de Autorização de Uso se refere a Data/Hora da SEFAZ-Autorizadora que neste caso é a SEFAZ-Virtual do Rio Grande do Sul. Se Rio Grande do Sul em relação a UF do Emitente esta 1 hora a mais, isso é devido ao fuso horário. Como lhe disse, o outro sistema diminuía em uma hora o horário de Autorização para ficar dentro do mesmo fuso horário. Que ao meu ver não é o correto, pois esta sendo alterado uma informação que foi gerada pela SEFAZ.

Luís, Observando o seu XML acredito que os seus fontes estejam desatualizados.

Bom dia Adilson, Veja que nesse XML o código do Item de Serviço é 01.07, já o código de tributação do município é 20107. No seu RPS temos o código do Item de Serviço igual a 07.02 e o código de tributação do município igual a 0702, experimente mudar para 20702.

Bom dia, As URLs do webservice se encontra no arquivo INI do respectivo provedor. Esses arquivos INI se encontram na pasta: ...\Exemplos\ACBrDFe\ACBrNFSe\ArqINI

Bom dia Luís, Esse XML é da versão 1.0 ou 1.1?

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

Bom dia Paulinho, É bem provável que o sistema da outra empresa editava o XML, como essa informação consta no retorno que contem o numero do protocolo e é adicionado ao XML assinado, mesmo fazendo essa alteração no retorno não invalida o XML final. Agora me diz uma coisa, ao Consultar o Serviço, Imprimir o DAMFE, ... o seu sistema apresenta na tela o XML de retorno da SEFAZ? Pois a informação TZD só consta no XML.