Italo Giurizzato Junior

Alexandre, Você tem os XMLs gerados pelos fontes atuais? Se sim, anexa para que possamos analisar.

Boa tarde a todos, Estamos falando do provedor BHISS, correto? pois bem no Schema que temos, até tem a definição do tipo simples chamado IndicacaoCpfCnpj, como vocês podem ver abaixo: <xsd:simpleType name="tsIndicacaoCpfCnpj"> <xsd:restriction base="xsd:byte"> <xsd:pattern value="1|2|3"/> </xsd:restriction> </xsd:simpleType> Mas não existe nenhuma tag na estrutura do XML do RPS cujo o tipo é tsIndicacaoCpfCnpj. Se assim, não tem como criarmos uma tag, pois não sabemos onde ela tem que ficar e tem mais, ao validar vai ocorrer um erro acusando que foi encontrado uma tag inexistente. Favor entrar em contato com o provedor e solicitar os Schemas (arquivos XSD) mais atuais.

Boa tarde Alexandre, Se esta aparecendo uma mensagem em branco, para saber o que esta ocorrendo é preciso configurar o componente para salvar os arquivos soap e analisar os XML de retorno, pode ser que eles tenham alterado o nome de alguma tag e por conta disso o componente não consegue extrair o XML da NFS-e.

Bom dia Diego, Comentei a linha que permitia gerar o XML do evento com acentos. Favor atualizar todos os fontes de todas as pastas, reinstalar os componentes e faça um novo teste.

Bom dia Alisson, Veja se o programa exemplo do eSocial possa lhe ajudar nesses primeiros passos. Aconselho você baixar o manual do eSocial versão 2.4.01 onde você terá um detalhamento de todos os tipos de eventos e seus respectivos campos.

Edmar, Ao obter o retorno da consulta, era para salvar em disco o XML do evento retornado, pelo que notei isso não foi feito. A propriedade de configuração: Configuracoes.Arquivos.Salvar esta com o valor True? Não foi salvo nenhum XML chamado S5001.xml ?

Boa tarde Edmar, O layout do XML de envio do evento S5001 é o que se encontra no Manual do eSocial versão 2.4.01?

Edmar, Segundo o manual da versão 2.4 - final da página 38 inicio da 39 diz que os eventos 5001, 5002, 5011 e 5012 são eventos de retornos.

Boa tarde Iuri, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde fabibona, Se ao gerar o evento, antes do seu envio você guardar o ID do mesmo no banco de dados, ao consultar o lote, você pode comparar esse ID com o ID da lista de eventos retornados e assim saber quais eventos foram processados com sucesso e quais não foram. Para ler o ID após gerar o evento faça assim: (por exemplo) ACBreSocial1.Eventos.NaoPeriodicos.S3000.Items[ x ].EvtExclusao.Id Para ler o ID do retorno faça assim: ACBreSocial1.WebServices.ConsultaLote.RetConsultaLote.RetEventos.items[ x ].Id Se esses dois ID foram iguais você tem ai o resultado do processamento do respectivo evento. Espero ter ajudado.

Boa tarde Edmar, Muito obrigado pela colaboração, já enviei para o repositório.

Boa tarde Edmar, Até onde sei esses evento não são enviados e sim retornados e já estão implementado a leitura dos XMLs retornados. Mas acredito que falta mais coisas a serem feitas.

Bom dia, Segundo o retorno esta ocorrendo rejeição 999. Toda vez que ocorrer esse tipo de rejeição não importa o que foi enviado para a SEFAZ, isso significa que o Web Service esta com algum problema e acaba retorno uma mensagem de rejeição genérica.

Bom dia, Favor anexar o XML de retorno para que eu possa verificar.

Bom dia, Que eu saiba o grupo <infoPerApur> é opcional só deve ser gerado se não for gerado o grupo <infoPerAnt> ou se existir alguma informação referente ao grupo <infoPerApur>.

Bom dia Edmar, Muito obrigado pela colaboração, já enviei para o repositório, com uma correção. Baixe e compare com o que você fez.

Bom dia a todos, Para aqueles que em suas aplicações atribuem o valor -1 ao campo cNF (no caso da NF-e/NFC-e) ou cCT (no caso do CT-e/CT-e OS) ou cMDF (no caso do MDF-e) ou cBP (no caso do BP-e), tomem cuidado, pois agora a nova função responsável por gerar a chave vai considerar o valor -1 como sendo zero e portanto o código numérico passa a ser gerado como sendo um numero aleatório e não como um código com base no numero do documento, como era antes. Para resolver esse problema a sugestão é o seguinte: em vez de: ide.cNF := -1; mude para: ide.cNF := GerarCodigoNumerico(ide.nNF); isso vai fazer com que seja atribuído a cNF um código numérico gerado com base no numero do documento, vai ter o mesmo efeito na geração da chave como era antes ao passar o valor -1 para cNF. De forma semelhante fazer o mesmo para o CT-e, MDF-e e BP-e. Lembrando que a função GerarCodigoNumerico se encontra na unit ACBrDFeUtil, logo devemos declara-la no uses da unit que será utilizada.

Boa tarde Jean, Exato, essas informações não são impressas no DACTE.

Bom dia Henrique, Estranho, pois segundo o schema a tag Aliquota possui 4 casas decimais, veja: <xsd:simpleType name="tsAliquota"> <xsd:restriction base="xsd:decimal"> <xsd:totalDigits value="5"/> <xsd:fractionDigits value="4"/> <xsd:minInclusive value="0"/> </xsd:restriction> </xsd:simpleType> Precisamos saber se a geração do RPS é com 2 ou 4 casas decimais, já o XML da NFS-e é gerado pelo provedor e este gerá com quantas casas decimais ele bem entender. E outra coisa importante, essa alteração não vai afetar as demais cidades atendidas pelo mesmo provedor?

André, Não criei um tópico, é que participo de um grupo e nele tem pessoas que se utilizam do certificado A3, logo eles podem dar alguma dica. Assim que eu tiver alguma resposta, posto aqui.

ALA, A leitura do retorno inicia na unit ACBrNFSeWebServices, mais precisamente pela função ExtrairNotasRetorno. Esta por sua vez se utiliza da função LerXML que se encontra na unit pnfsLerListaNFSe que por sua vez se utiliza da função LerXML (classe TNFSeR) que esta na unit pnfsNFSeR. A minha sugestão é colocar um break point em ExtrairNotasRetorno (linha 3726 - linha em vermelho). function TNFSeConsultarLoteRPS.TratarResposta: Boolean; begin FPMsg := ''; FaMsg := ''; FPRetWS := ExtrairRetorno(FPConfiguracoesNFSe.Geral.ConfigGrupoMsgRet.GrupoMsg); Result := ExtrairNotasRetorno; <<== coloque um break point nesta linha FPRetWS := ExtrairGrupoMsgRet(FPConfiguracoesNFSe.Geral.ConfigGrupoMsgRet.ConsLote); end;

ALA, Entendi, mas você chegou a "debugar" a partir do método Enviar, pois este se utiliza internamente do ConsultarLoteRps quando o componente esta configurado para realizar a consulta após o envio do lote. Com esse "debugue" da para descobrir o porque dele não estar alimentado as propriedades que você deseja.

Bom dia Renato, Muito obrigado pela colaboração, já enviei para o repositório. Um detalhe importante, os seus fontes estão desatualizados.

Bom dia ALA, Chegou a realizar testes com o programa exemplo do componente ACBrNFSe? Veja este fragmento de código do botão [Gerar e Enviar Lote RPS]: ACBrNFSe1.Enviar(vNumLote); for I := 0 to iQtde - 1 do begin MemoDados.Lines.Add('Nome XML: ' + ACBrNFSe1.NotasFiscais.Items[ I ].NomeArq); <== aqui é para constar o caminho mais o nome do XML MemoDados.Lines.Add('Nota Numero: ' + ACBrNFSe1.NotasFiscais.Items[ I ].NFSe.Numero); MemoDados.Lines.Add('Código de Verificação: ' + ACBrNFSe1.NotasFiscais.Items[ I ].NFSe.CodigoVerificacao); end;

Leonard, Cada provedor trabalha de forma diferente dos outros, esse exige que o numero do lote seja sequencial.