Italo Giurizzato Junior

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 Renê, Se ficarmos na tentativa e erro não vai sair nada. Acredito que melhor saída é entrar em contato com o provedor e questiona-los sobre o problema. Apresentar a eles o XML que esta sendo gerado para realizar a consulta e o retorno que esta obtendo. Quem sabe assim eles indicam o que pode ser. Comparando o XML de consulta com o schema não encontrei nada que justifica-se o problema. A minha duvida é quanto a tag transação que antes estava com o valor false e agora com o valor true, mas o problema deve ser o mesmo, correto? Sobre essa tag encontrei o seguinte no schema: <xs:element name="transacao" type="xs:boolean" default="true" minOccurs="1" maxOccurs="1"> <xs:annotation> <xs:documentation>Informe se as NF-e a serem consultadas farão parte de uma mesma transação. Informe sempre True.</xs:documentation> </xs:annotation> </xs:element> Em um primeiro momento entendo que devemos informar true quando se tratar do notas enviadas em lote, logo são de uma mesma transação, caso contrario false. Mas depois diz "Informe sempre True". Muito esquisito.

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.

Paulo, Eu uma outra postagem notei que você esta tendo problema com a NF-e usando o xsLibXml2 correto? Se sim, veja a minha resposta do outro tópico.

Bom dia Paulo, Esse erro esta ocorrendo ao executar a aplicação via Delphi? Se sim, tente executa-la fora do Delphi.

Bom dia Paulo, O lote de envio foi gerado e assinado com o componente configurado com xsMsXml?

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.

Carlos, Eu disse Enviar Evento de Manifestação do Destinatário. O primeiro se refere a criar e enviar o Manifesto de Documentos Fiscais Eletrônicos - MDF-e que não tem nada haver com evento. O segundo se refere ao cancelamento de uma nota, apesar de ser um evento, mas não é o evento de Manifestação do Destinatário. O terceiro se refere a inutilização de um numero ou faixa de números não utilizado pelo sistema, portanto não tem nada haver com evento citado. O quarto se refere ao envio do evento de carta de correção, logo não é um evento de Manifestação do Destinatário. Todos os métodos que são utilizados para a versão 3.10 funciona para a versão 4.00. Por favor não misture as coisas, esse tópico estamos tratando sobre a DistribuicaoDFePorChave, vamos seguir as regras do fórum.

Boa tarde Carlos, Veja que no final do nome do arquivo XML costa: -resNFe.xml, esse "res" significa resumo, quando isso ocorre é porque a nota informada ainda não foi manifestada pelo destinatário. Para Manifestar, basta enviar um evento de Manifestação do Destinatário.

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.