Italo Giurizzato Junior

Ricardo, Não encontrei nada estranho na sua rotina de configuração. O componente esta configurado para salvar os arquivos soap? Configuracoes.webservices.salvar := True Favor anexar os arquivos gerados para que eu possa analisar.

Bom dia, O ID de um evento é gerado automaticamente pelo componente através da função: GerarChaveEsocial(const emissao: TDateTime; const CNPJF: string; sequencial: Integer): String; Note que é levado em consideração a Data/Hora de emissão, o CNPJ e um numero sequencial que pode ser aleatório.

Olá Pessoal, Muitos desenvolvedores acabam escolhendo um dos 3 métodos de envio de RPS e nem sempre funciona, porque? É muito simples, primeiro temos que separar os provedores em 3 grupos: os que seguem a versão 1 do layout da ABRASF, os que seguem a versão 2 e os que tem o seu próprio layout. Os provedores que seguem a versão 1 do layout da ABRASF oferecem somente o serviço de envio assíncrono, portanto só podemos usar o método Enviar do componente, esse método permite o envio de um lote contendo de 1 até 50 RPS. Os provedores que seguem a versão 2 do layout da ABRASF a principio oferecem os serviços: envio assíncrono, envio síncrono e gerar NFSe, respectivamente no componente temos os métodos: Enviar, EnviarSincrono e Gerar, onde os dois primeiros permite o envio de um lote contendo de 1 até 50 RPS e o último o envio de apenas 1 RPS. Destaquei "a principio" porque ao implementar dezenas de provedores que seguem a versão 2 no componente, notei que vários não disponibilizaram os 3 serviços e sim apenas um ou dois dos três sugeridos pelo layout. Logo não é possível afirmar que todos os provedores que seguem a versão 2, disponibilizam os 3 serviços de envio. Já os provedores que tem o seu próprio layout, não tem como estabelecer uma regra, pois cada um implementou o serviço que melhor lhe convém. Além dos serviços de envio, temos também os de consulta, cancelamento e substituição de NFSe. Como faço para saber quais são os serviços disponibilizados pelo provedor que vou utilizar, bem como o layout que ele segue? É muito simples, basta abrir o arquivo INI do mesmo. Na seção XML temos o campo Layout que pode conter os seguintes valores: ABRASFv1, ABRASFv2 ou outro valor (normalmente o nome do provedor). No caso de um valor diferente de ABRASFv1 e ABRASFv2 fica claro que não segue nenhuma das versões da ABRASF, logo tem o seu próprio layout. Para saber os serviços oferecidos pelo provedor basta olharmos para as seções: [Recepcionar] => Responsável por montar o envelope de Envio assíncrono, se consta a definição do envelope significa que este serviço esta disponível. [ConsSit] => Responsável por montar o envelope de Consulta a Situação do Lote, se consta a definição do envelope significa que este serviço esta disponível. [ConsLote] => Responsável por montar o envelope de Consulta ao Lote, se consta a definição do envelope significa que este serviço esta disponível. [ConsNFSeRps] => Responsável por montar o envelope de Consulta NFSe por RPS, se consta a definição do envelope significa que este serviço esta disponível. [ConsNFSe] => Responsável por montar o envelope de Consulta NFSe, se consta a definição do envelope significa que este serviço esta disponível. [Cancelar] => Responsável por montar o envelope de Cancelar NFSe, se consta a definição do envelope significa que este serviço esta disponível. [Gerar] => Responsável por montar o envelope de Gerar NFSe, se consta a definição do envelope significa que este serviço esta disponível. [RecSincrono] => Responsável por montar o envelope de Envio síncrono, se consta a definição do envelope significa que este serviço esta disponível. [Substituir] => Responsável por montar o envelope de Substituir NFSe, se consta a definição do envelope significa que este serviço esta disponível. Exemplo de um Envelope não definido, portanto serviço não disponibilizado no webservice do provedor: [ConsSit] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1= Exemplo de um Envelope definido, portanto serviço disponibilizado no webservice do provedor: [ConsSit] IncluiEncodingCab=0 IncluiEncodingDados=0 Texto1=<S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> Texto2=<S:Body> Texto3=%DadosMsg% Texto4=</S:Body> Texto5=</S:Envelope> Conselho: Tenha uma tela de configuração que permite ativar ou não a execução de cada um desses métodos, assim a sua aplicação pode enviar o RPS através do método ou outro dependendo da configuração estabelecida por conta do provedor a ser utilizado.

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

Bom dia Rafa, Você esta com todos os fontes atualizados? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção: apagar arquivos antigos marcada? Configurou o programa exemplo corretamente?

Bom dia Ricardo, Vendo com mais calma o seu XML, notei que o tipo de emissão é 9 = contingência off-line, esta correto isso? O mais grave é você esta usando o numero da nota (nNF) como o código da nota (cNF), esse não foi o motivo da rejeição mas vai ser quando a SEFAZ aplicar a nova regra de validação. Aconselho você ler os artigos: Como tratar a contigência da NFC-e e Como funciona o campo cNF e nNF na chave da NF-e/NFC-e.

Bom dia Jair, Pelo manual me parece ser o provedor IPM que por sinal já esta implementado. Logo basta alterar o arquivo Cidades.ini mudando o provedor da cidade Osório de DBSeller para IPM. Feito isso basta iniciar os testes com o programa exemplo.

Bom dia Ricardo, Acabei de fazer um teste de envio (método Enviar) usando o programa exemplo do componente e não ocorreu o erro 500. Você esta com todos os fontes atualizados? Reinstalou a suíte ACBr usando o ACBrInstall_Trunk2 com a opção: apagar arquivos antigos marcada? No caso da sua aplicação ela esta usando os arquivos INI atuais?

Bom dia Luís, Infelizmente tem provedor que não consegue estabelecer um padrão para todas as cidades que ele atende. Isso faz com que para algumas cidade tem que ser gerado de uma forma e para outras de outra forma. O estranho é o schema não aceitar o valor 0.00, talvez se for zero tem que ser apenas 0 e não 0.00

Bom dia Rodrigo, Gerar em qual versão você se refere?

Boa tarde, Na unit ACBrBPeWebServices temos: with TACBrBPe(FPDFeOwner) do begin EventoEhValido := SSL.Validar(FPDadosMsg, GerarNomeArqSchema(FPLayout, StringToFloatDef(FPVersaoServico, 0)), FPMsg) and SSL.Validar(AXMLEvento, GerarNomeArqSchemaEvento(SchemaEventoBPe, StringToFloatDef(FPVersaoServico, 0)), FPMsg); end; É preciso "debugar" essas linhas para descobrir qual dos dois Validar esta gerando essa mensagem de erro.

Boa tarde Ricardo, Acredito que você ainda esteja confuso de como implementar corretamente a NFC-e, principalmente no que diz respeito a contingência. Peço que leia o artigo: Como tratar a contingência da NFC-e. Quanto ao erro de hash, por se tratar de MG tenho quase certeza que o problema é na SEFAZ. Outra coisa, você esta usando o idCSC e CSC correto para o ambiente de produção? Colocou na maquina do seu cliente as DLLs atualizadas?

Boa tarde @Dream Sistemas, A alteração que você promoveu em ACBrDFeWebService gera um tremendo efeito colateral nos demais componente DF-e. Você deve implementar esse GerarLote no ACBreSocialWebService.

Boa tarde Ricardo, Se eu entendi, na filial tem dia que funciona e outro não, correto? Sem nenhuma alteração na aplicação ou atualização dos fontes do componente? Se existe uma intermitência chego a conclusão que o problema é na SEFAZ. Tanto a matriz quanto a filial estão localizadas na mesma UF? Caso contrario cada uma terá que ter o seu CSC.

Boa tarde, Já que você esta usando o componente, porque esta montando o arquivo INI, para depois carregar e por fim enviar? Porque você não monta a rotina de cancelamento conforme o exemplo

Lucas, Na maquina do seu cliente não tem duas pastas com schemas? Se sim, a sua aplicação esta apontando para a pasta correta com os schemas atualizados?

Bom dia Ricardo, Porque o tipo de emissão esta 9 = off-line, em vez de 1 = Normal?

Bom dia Júlio, Após o envio, você realizando a consulta? Se sim, a explicação é que a nota não consta na base de dados da SEFAZ. Verifica se você não esta enviando a nota para o ambiente de produção e consultando em ambiente de homologação. Verifica se realmente a nota esta sendo enviada. Pode ter ocorrido um erro no envio e o try que talvez você tenha colocado na sua aplicação esta mascarando o erro.

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.

Bom dia Lucas, Os Schemas na maquina do cliente são os mesmos que você tem na sua maquina?

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.