Paulo Aguiar Junior

Boa tarde, Conforme demonstrado acima, o campo somente pode ser preenchido se for: 01 Acidente/Doença do trabalho ou 03 Acidente/Doença não relacionada ao trabalho Porém, não deve ser sempre preenchido. Tendo em vista que os códigos se referem a acidente ou doença do trabalho, não se trata necessariamente de um acidente de trânsito. O ACBr hoje está sempre preenchendo esse campo com um dos tipos... Segue uma sugestão de correção. Obrigado pcesS2230.pas pcesConversaoeSocial.pas

Envia novamente, e veja o retorno... Anteontem foi zerada a base de produção restrita

Seu erro é exatamente esse: Falta do S-1000 processado. Fiz o teste aqui enviando o S-2190 sem o S-100 processado e retornou exatamente as mesmas ocorrências que o seu XML.

Anderson, envie novamente o S-1000 com validade 2018-01, e poste o XML de envio e o da consulta do processamento. Vamos ver se vai retornar que foi recebido com sucesso, ou se vai apontar uma duplicidade.

Cara, seu xml está na versão 2.4.01 de novo...

Anderson, posta o XML de retorno...

Renato, boa tarde! Só uma observação, no layout que está em produção 2.4.01, não existe esse campo...No momento de gerar as informações no "GerarInfoConvInterm", talvez você precise verificar a versão para gerar ou não o campo no xml (se é que você já não fez isso)... Abraço!

Bom dia Arce, hoje já enviei diversos S-2200 e S-2205... Posta o XML para darmos uma olhada...

Os xml's que você postou não diz isso.

Você está gerando na versão 2.4.01, e o ambiente de testes está na 2.4.02

Boa tarde, está ocorrendo um erro na geração desse evento no momento de percorrer o zCount: "List index out of bounds". Embora a ocorrência na versão 2.4.1 seja obrigatória, quando não está atribuído ocorre esse erro e não chega nem na validação do Schema... Alterado de: zCount := StrToInt(IfThen((VersaoDF = ve02_04_01), '1', IntToStr(obj.Count))); Para: zCount := StrToInt(IfThen((VersaoDF = ve02_04_01) and (obj.Count > 0), '1', IntToStr(obj.Count))); pcesS2299.pas

Boa tarde! A partir de segunda-feira 09/04 (ficará fora do ar das 8:00 as 18:00) o ambiente de produção restrita passará a operacionalizar na versão 2.4.02 do layout. http://portal.esocial.gov.br/noticias/producao-restrita-sera-atualizada-para-a-versao-2-4-02-do-leiaute-em-09-04 Outra notícia importante é que a partir de segunda-feira (09/04) também começa a funcionar o eSocial Web para as as empresas, que poderão consultar os eventos enviados, o conteúdo, os recibos, etc. Também haverá a possibilidade de incluir/alterar/retificar/excluir os eventos diretamente pelo ambiente nas versões futuras. http://portal.esocial.gov.br/noticias/esocial-web-para-empresas-e-regras-de-eventos-extemporaneos-entram-em-producao-em-09-04

Sim, utilizo o mesmo mecanismo para todos os eventos. Resumindo: Usuário seleciona 50 eventos na grid, gero cada um deles e armazeno o ID de cada um. Após enviar, atualizo em cada registro enviado nesse lote, o Nº do Protocolo de Envio gerado. Ao consultar determinado protocolo de envio, dou um select retornando os registros que foram enviados nesse lote (ou seja, os que possuem o nº de protocolo que estou consultando). E ai basta percorrer o RetConsultaLote.RetEventos e ir localizando o RetConsultaLote.RetEventos.Items.Id na query, como expliquei no outro post. Não estou dizendo que seja a melhor maneira de fazer, tem gente fazendo de outras formas. Mas essa forma segue o "fluxo natural" das rotinas, e está funcionando bem.

try bValido := evtInfoEmpregador.GerarXML; except on e:Exception do begin AdicionaInconsistencia('ERRO', e.Message); end; end; if ( bValido ) then Result := evtInfoEmpregador.Id else begin dmESocial.ACBreSocial.Eventos.Iniciais.S1000.Delete(dmESocial.ACBreSocial.Eventos.Iniciais.S1000.Count-1); Result := ''; end; No exemplo disponibilizado pelo ACBr, adiciona-se todos os eventos, e no final, chama-se o ACBreSocial.Eventos.GerarXMLs, que percorre todas as estruturas (Iniciais, Periodicos, NaoPeriodicos) e sai gerando os xmls... Eu preferi fazer de outra forma, para cada evento que eu adiciono, eu já chamo o GerarXML para ele, e verifico se houve algum erro na geração desse xml (schema por exemplo), quando há erro, eu já removo ele do lote dmESocial.ACBreSocial.Eventos.Iniciais.S1000.Delete(dmESocial.ACBreSocial.Eventos.Iniciais.S1000.Count-1), pois mesmo quando há falha na validação do schema o evento já está adicionado ao lote. E quando não há erro na geração do xml desse evento, pego o atributo Id que foi gerado...

Alisson, Cada registro S-1000 corresponde a um registro no seu banco de dados, correto? Você precisa salvar o ID de cada evento gerado no seu respectivo registro no banco (é o único campo que você pode vincular quando efetuar a consulta), e após consultar, você deve percorrer a estrutura RetConsultaLote.RetEventos.Count, e ir localizando (em uma query, por exemplo) pelo RetConsultaLote.RetEventos.Items.Id. No meu caso, nessa query que eu citei, eu dou um select em todos os registros do banco de dados que contém aquele protocolo de envio que eu estou consultando, ou seja, esse é outro campo que eu preencho para cada registro que foi gerado no meu lote. Dessa forma, dou o select em todos os registros do lote que vou consultar, consulto, percorro o retorno (RetConsultaLote.RetEventos.Count), e faço um dmESocial.qryBuscaEventosProtocolo.Locate('ID_EVENTO', RetConsultaLote.RetEventos.Items.Id, []) para encontrar o registro no meu banco. No loop, você pode verificar o RetConsultaLote.RetEventos.Items.Processamento.cdResposta, para saber se o registro foi processado ou não. Caso tenha sido processado, o campo RetConsultaLote.RetEventos.Items.Recibo.nrRecibo estará preenchido com o devido recibo, caso em que você deve armazenar esse recibo (que é o seu comprovante de entrega), caso contrário, percorra a estrutura RetConsultaLote.RetEventos.Items.Processamento.Ocorrencias.Count, para pegar as ocorrências (erros) desse registro que está percorrendo e armazenar p/ mostrar para o usuário. Essa é mais ou menos a lógica que estamos utilizando aqui...

Bom dia! Estou tentando enviar agora o S-2200 também, e estou obtendo a mesma mensagem. Você chegou a conseguir enviar algum S-2200 em produção restrita?

Boa tarde! Você fez o update do repositório? Componente.Configuracoes.Geral.SSLLib := libCustom; Componente.Configuracoes.Geral.SSLHttpLib := httpWinHttp; Componente.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; Componente.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; Componente.Configuracoes.Certificados.NumeroSerie := dmESocial.qryCertificadoDigital.FieldByName('NR_SERIE').AsString; Estou utilizando assim, e está funcionando perfeitamente, inclusive, o Rafael disse que o PFX também funciona com essa config...

Boa tarde, Corrigido o número dos Grupos de Eventos, os Não Periódicos é o Código 2, e não 3. TeSocialGrupo = (egIniciais = 1, egNaoPeriodicos = 2, egPeriodicos = 3); Fui enviar o 2190 e Recebi a mensagem "O tipo de evento informado não é aceito para este tipo de lote/serviço". Aí fui ver no layout, e realmente estava errado... pcesConversaoeSocial.pas

Joceando, não estava funcionando mesmo nem o A3 nem o A1 instalado mesmo... A gente fez a correção aqui na empresa, e enviamos, e o Rafael implementou de acordo com o padrão aqui do ACBr e anexou aqui. Testei e está funcionando certinho também, provavelmente jájá eles versionam... Valeu!

Joceando, bom dia! Estou utilizando assim: Nesse momento aqui já foi validado se ele associou o certificado cadastrado a empresa e tal... Dessa forma estou enviando com A1 PFX, A1 instalado e A3. //Quando usuário cadastrou o certificado pelo PFX if dmESocial.qryCertificadoDigital.FieldByName('DS_CAMINHOPFX').AsString <> '' then begin dmESocial.ACBreSocial.Configuracoes.Geral.SSLLib := libOpenSSL; dmESocial.ACBreSocial.Configuracoes.Geral.SSLHttpLib := httpWinHttp; dmESocial.ACBreSocial.Configuracoes.Certificados.ArquivoPFX := dmESocial.qryCertificadoDigital.FieldByName('DS_CAMINHOPFX').AsString; end else begin //Assinando com o A3 dmESocial.ACBreSocial.Configuracoes.Geral.SSLLib := libCustom; dmESocial.ACBreSocial.Configuracoes.Geral.SSLHttpLib := httpWinHttp; dmESocial.ACBreSocial.Configuracoes.Geral.SSLCryptLib := cryWinCrypt; dmESocial.ACBreSocial.Configuracoes.Geral.SSLXmlSignLib := xsLibXml2; dmESocial.ACBreSocial.Configuracoes.Certificados.NumeroSerie := dmESocial.qryCertificadoDigital.FieldByName('NR_SERIE').AsString; end; dmESocial.ACBreSocial.Configuracoes.Certificados.Senha := TMetodos.fncCriptografia(Descriptografar, dmESocial.qryCertificadoDigital.FieldByName('DS_SENHA').AsString);

Bom dia Rafael, funcionou também, normalmente! A1 PFX, A1 instalado e A3 Abc

Boa tarde, Depois de muito tempo trabalhando em cima, conseguimos aqui na empresa corrigir o problema da assinatura com o certificado A3, e o A1 instalado na máquina para o e-Social (sha-256). Fizemos diversos testes, enviamos e recebemos os recibos normalmente... Segue a unit para análise, testes, e se for o caso ser versionada no componente. É só substituir a unit na pasta: \Fontes\ACBrDFe Valeu! ACBrDFeXsLibXml2.pas

Os prazos continuam os mesmos, não tem nem porque serem alterados... Os ambientes de produção e testes permanecem na versão 2.4.01 por enquanto. http://portal.esocial.gov.br/noticias/disponibilizada-versao-2-4-02-beta-do-leiaute-do-esocial

Entendi... Então, estamos para soltar uma versão para os nossos clientes, e, a idéia era não ter dependência com o .NET framework, tendo em vista que há diversos tipos de ambiente nos clientes, e certamente não estão todos aptos. Valeu!

Bom dia! O erro no processamento do lote assinado pelo A3 persiste... "Assinatura do evento inválida. Ações Sugeridas: Verificar se houve alteração do evento após a assinatura. Verificar a validade da assinatura." Estou tentando identificar o problema na assinatura do A3, mas está complicado... Alguém que tenha participado no desenvolvimento da ACBrDFeXsLibXml2 poderia nos ajudar? Obrigado