MSS
-
Total de ítens
28 -
Registro em
-
Última visita
Tipo de Conteúdo
Blocks
Notes ACBrLibNFe
Fóruns
Downloads
Calendário
Posts postados por MSS
-
-
Bom dia.
Conforme solicitado, estou anexando as units alteradas.
[]s,
Mário
-
Boa tarde, Renato.
Eu estava logando no Fórum da ACBr para criar um post a respeito de correções no método LerXML das units pcesS1010 e pcesS2200; mas desisti de abrir o post e vou interagir nesse aqui.
O método LerXML dos eventos S-1010 e S-2200 atribuem valores para a propriedade Id utilizando-se de chamada para Leitor.rCampo e o correto seria Leitor.rAtributo.
Na realidade eu creio que essa atribuição para Id no método LerXML seja desnecessário; porque essa propriedade é alimentada previamente ao passar pelo método TeSocialEvento.SetXML, da unit pcesGerador;
Para solucionar o problema sem analisar maiores impactos eu apenas substitui o código, nas units pcesS1010 e pcesS2200:
Id := Leitor.rCampo(tcStr, 'Id');
por
if Self.Id = '' then
Self.Id := Leitor.rAtributo('Id=');[]s,
Mário
-
Bom dia, Rubinho.
Eu tinha atualizado a ACBr com a revisão 31188, semana passada, e tinha percebido que a correção mencionada ainda não havia sido aplicada; apliquei a correção na release e liberei uma versão RC (Release Candidate) do nosso sistema para o departamento de qualidade revalidar o processo do eSocial para as versões S1.01 e S1.02.
Vou aguardar o retorno da qualidade com relação a essa versão do nosso sistema e após farei uma nova atualização da ACBr antes de liberar o sistema novamente para homologação.
A solução que você aplicou está correta e foi a minha primeira opção de correção; porem eu optei por deixar mais claro o código da condicional e minimizar a possiblidade de eventuais problemas, se a ordem de definição do tipo for alterada.
Mas o que importa é que está funcionando e não há necessidade de alterar o código da ACBr a cada atualização.Obrigado.
[]s,
Mário Soares Santos-
1
-
-
Boa tarde, Alexandre e Renato!
Peço desculpas pela demora na resposta.
Segue anexo a unit pcesConversaoeSocial, da revisão 30975, com a correção aplicada.
Origem do código fonte: p/acbr/code - Revision 30975: /trunk2/Fontes/ACBrDFe/ACBreSocial/PCNeSocial/pcesConversaoeSocial.pas
Não tenho nenhum XML nesse momento para anexar; porem o erro é simples de reproduzir:
O XSD utilizado para validar o XML do evento S-1207, em versão de eSocial diferente da S-01.01.00 não é localizado corretamente porque o nome desse XSD é retornado incorreto (Schema).
Até a versão S-01.01.00 o schema era "schevtCdBenPrRP" e após é "schevtBenPrRP".
[]s,
Mário Soares Santos -
Dando continuidade ao tópico Evento S-1207 - Problema de identificação do evento e aprimorando a solução apresentada anteriormente; segue apresentação de solução para novo problema encontrado,relacionado ao tópico.
Resumo
Validação do evento S-1207 não está encontrando o XSD correto, devido a teste via IF incorreto.Localização
unit pcesConversaoeSocial;
function TipoEventoToSchemaeSocial
Linha +- 1508 - if (AVersaoeSocial <> veS01_00_00) thenAnalise
No commit [r26739] da ACBr, de 14/09/2022 foi adicionado um teste via IF, na localização mencionada acima, que atendia as condições especificas até esse commit (versão S-01.01.00 do eSocial).
No commit [r27742] da ACBr, de 08/12/2022 foi implementado recursos para atender a versão S-01.01.00 do eSocial, porem o teste via IF não foi modificado e o teste passou a retornar informação incorreta para a nova versão.Solução
Modificar o teste via IF, mencionado acima, conforme abaixo:
(-) if (AVersaoeSocial <> veS01_00_00) then
(+) if ((AVersaoeSocial = ve02_04_01) or (AVersaoeSocial = ve02_04_02) or (AVersaoeSocial = ve02_05_00)) then[]s,
Mário Soares Santos -
Boa tarde, Elton !
Analise realizada, correções e testes efetuados em ACBr - Trunk2 - Revisão 26002 - 30/06/2022
git-svn-id: https://svn.code.sf.net/p/acbr/code/trunk2@26002 6e92efe7-b92a-0410-a9ec-f9e4e41bb3a6Fontes\ACBrDFe\ACBreSocial\PCNeSocial
unit pcesGerador;
unit pcesIniciais;
unit pcesTabelas;
unit pcesNaoPeriodicos;
unit pcesPeriodicos;
unit pcesConversaoeSocial;Código disponibilizado para estudos, testes, uso e/ou eventual update no repositório do Projeto ACBr.
[]s,
Mário Soares Santos-
1
-
-
Em 07/06/2022 at 19:58, EMBarbosa disse:
Olá Mário, tudo bem?
Por algum motivo, seu tópico ficou pra trás...
Por acaso você poderia fazer o favor de atualizar o código para a versão atual do SVN e postar novamente?
Olá, Elton !
No momento estamos utilizando uma versão congelada da ACBr de 05/04/2022 e não podemos atualiza-la sem analisar antes os impactos das alterações ocorridas após essa data.
Assim que for possivel, baixarei a ultima versão da ACBr e realizarei um "compare" nas units que alteramos para verificar se as correções efetuadas permanecem válidas e não quebram o código da ACBr.
Informarei nesse post quando realizar essa analise.[]s.
Mário Soares -
4 horas atrás, Sebastiao Correa da Silva disse:
Bom Dia
Estou tentando enviar no Ambiente restrito dados de parlamentares e estou recebendo este erro:
Alguém tem ideia esta tendo uma incompatibilidade entre o XSD do Acbr e do site do e-social.
At.
WIllianBoa tarde, Willian.
- eSocial - versão S1.00
- Acbr - versão trunk2 de 20/04/2022
- XSD - desatualizadoSegue anexo nova versão dos arquivos XSD do eSocial, já renomeados para o padrão da Acbr.
-
Bom dia,Rafael.
Eu não conheço nenhum método no WebService do eSocial que possibilite o retorno de um numero de protocolo para um lote enviado; e como não existe uma fórmula infalível para tratar essa questão de timeout; minha recomendação é que você utilize a técnica que eu chamo de "dividir para conquistar".
Passo 1) Determine as condições iniciais para aplicação na formula a seguir: Exemplo: 50 eventos por lote em 10 segundos de timeout.
Passo 2) Teste com as condições iniciais para ver se funciona; se funcionar divida o tempo de timeout pela metade e repita o processo até achar o timeout que funcione a contento.
Passo 3) Se o passo dois não funcionar, mantenha as condições iniciais (ex: 50 x 10) e passe a dividir a quantidade de eventos pela metade; mantendo o timeout repita esse processo até encontrar a quantidade de eventos que possam ser enviados por lote no timeout inicial; ou até atingir um evento por lote no timeout inicial.Dicas:
Importante testar a combinação encontrada para cada instalação e em diversos dias e horários. As condições de comunicação são dinâmicas e mudam inumeras vezes.
Deixar esses parâmetros passiveis de serem alterados facilmente pelo sistema. Não engessar o sistema com a definição de valores fixos para todas as instalações; a comunicação entre o sistema local e servidor remoto depende de inúmeros fatores para que ocorra sem maiores problemas.Enfim; é na base da tentativa e erro que se encontrará a melhor combinação entre eventos x lote x timeout na instalação naquele momento.
[]s,
Mário-
2
-
-
Dando continuidade na solução apresentada no tópico "Eventos S-2400 e S-2410 - Problema de identificação de tipos de eventos"
As atuais alterações implementam a utilização da versão do eSocial, existente na configuração.
Foi necessário analisar e utilizar a versão do eSocial porque o problema apresentado no evento S-1207 está relacionado a tag <evtBenPrRP>, que na versão v2.5.xx é <evtCdBenPrRP>; então para manter a compatibilidade funcional entre as versões foi necessário implementar e validar a versão do eSocial.
As alterações realizadas estão indentificadas através da palavra "[MSS", contida em comentário, que pode estar em apenas uma linha ou abrindo e fechando um bloco de alterações.
As units afetadas são as seguintes:
unit pcesGerador;
unit pcesIniciais;
unit pcesTabelas;
unit pcesNaoPeriodicos;
unit pcesPeriodicos;
unit pcesConversaoeSocial;Estou disponibilizando o código para estudos, testes, uso e/ou eventual update no repositório do Projeto ACBr.
[]s,
Mário Soares Santos -
Em 28/03/2022 at 12:13, Adailton Rocha da Cruz disse:
Boa tarde, alguém pode me ajuda. Estou enviando o S-2300 pela primeira vez de uma Empresa que já esta cadastrada com os Trabalhador com Vínculo. Status Código: 201 Status Descrição: Lote Recebido com Sucesso, quando vou pesquisar no portal do e-social não consta.
desde já agradeço.
Bom dia, Adailton.
É necessário executar algumas processos para execução com sucesso da etapa de envio dos eventos do eSocial.
Esse XML que você passou é o processo de envio do lote de eventos e ele não é o último processo a ser executado.
Quando você executa esse processo com sucesso recebe um numero de PROTOCOLO.
O próximo processo que deve ser executado é uma consulta usando esse número de protocolo.
O retorno do processo de consulta irá informar se os dados enviados no lote estão corretos ou se ocorreu algum tipo de erro.
Se não ocorreu erros relacionado ao evento que está dentro do lote, a consulta irá informar o número de RECIBO do evento.
O evento somente irá aparecer no Portal Web se você receber o numero de RECIBO do mesmo no processo de consulta.[]s,
Mário Soares
-
1
-
-
2 horas atrás, LUIZTEC disse:
Boa tarde,
Desde 22/03/2022 (ontem) só consigo fazer transmissão dos eventos em produção real. Na produção restrita não estabelece conexão nenhuma com o webservice (como se ele não existisse mais). Alguém está com mesmo problema?
Atenciosamente,
Luiz Cláudio.
Boa tarde, Luiz.
O ambiente de produção restrita está aceitando conexão usando-se única e exclusivamente o protocolo TLS v1.2.
Eu tinha visto alguns meses atrás um informativo do eSocial que avisava sobre algumas mudanças nos processos de segurança de comunicação. Não sei se a questão do TLS está relacionada a esse informativo ou não, porque não localizei mais ele no site do eSocial.
Mas vale lembrar que em 26/06/2015 (conforme consta no manual de orientação do desenvolvedor v1.11 - item 6.4) houve alteração do protocolo de segurança da camada de transporte de SSL para TLS; e pode ser que somente agora o eSocial tenha resolvido desabilitar o protocolo SSL.
Cabe ainda ressaltar que no mesmo manual apresenta-se a criação de "Cifras", agora em 03/2022 e a aplicação da versão 1.3 do protocolo TLS. A TLS v1.3 não está em uso no ambiente de produção restrita, no ambiente de produção eu não verifiquei.
[]s,
Mário Soares
-
1
-
-
Em 11/02/2022 at 08:17, Digibyte disse:
Pessoal, como estão fazendo, após o envio deo evento, pra pegar o retorno do eSocial? Tempo fixo, ajustável, ... ?
Qual seria a melhor estratégia pra otimizar isso?
O tempo de processamento depende do evento e do dia pelo que vi até agora.
Olá,
Combinação de processos e configurações.
1) Na sequencia ao envio: Disparo da consulta imediatamente após o envio do evento, usando quantidade de tentativas de consulta e tempo de intervalo configuráveis/ajustáveis.
2) Na automatização/agendamento/cron job: Disparo da consulta do eventos pendentes de processamento usando quantidade de tentativas de consulta, tempo de intervalo e dias/horários configuráveis/ajustáveis.
3) Manual 1: No envio de novos eventos valida a existência de consultas pendentes e disponibiliza ao usuário a opção de realizar a consulta antes de processar o envio.
4) Manual 2: A qualquer momento o usuário pode disparar a execução da consulta de um evento especifico ou de vários; baseado em filtros.[]s
Mário
-
2
-
-
Em 24/02/2022 at 11:05, guilhermeVaz06 disse:
Acredito que o próprio web service do e-Social, mas minha duvida é se o ACBR tem algo implementado para consultar a matricula ativa de um funcionário utilizando o CPF do mesmo e um CNPJ do qual ele esta vinculado.
Olá, Guilherme.
No web service do eSocial não existe, até o momento, nenhum método que seja possível realizar a consulta/validação que você precisa.
A inexistência de tal método no eSocial inviabiliza a criação de rotinas, na ACBr, para efetuar a consulta mencionada; porque para tal seria necessário que a ACBr realizasse a gestão dos cadastros/eventos do eSocial o que não me parece ser a proposta do produto.
Desconheço a existência de quaisquer web service do governo que permita realizar tal tipo de consulta.
[]s
Mário-
2
-
-
Em 20/02/2022 at 22:21, EMBarbosa disse:
EDIT: Eu tive que fazer alguns ajustes por conta da compilação no Delphi 7.
Creio que esteja tudo correto. Mas as validações são importantes nesses casos.
Oi, Elton !
Verifiquei os ajustes que você realizou e a principio não vi nada que pudesse ser causador de problemas na alteração principal.
Porem; o próximo post veio demonstrar que uma coisa simples do ajuste quebraria todo o sentido da alteração principal.
19 horas atrás, Lucas G. dos Santos disse:Olá,
A alteração gerou um problema na identificação do evento S2220, no meu caso.
O inicio do XML contém:
<?xml version="1.0" encoding="UTF-8"?><eSocial xmlns="http://www.esocial.gov.br/schema/evt/evtMonit/v_S_01_00_00"><evtMonit Id="ID2040074 .....
Na linha 2821, do arquivo pcesConversaoeSocial está o seguinte código:
strSearchValue := Trim(Copy(s, intChar + 1, intLastPos - intChar - 1));
Utilizando o trecho do XML de exemplo, o valor atribuido a variável strSearchValue foi: "vtMonit I"
Esse evento não existe, a função copiou um caracter pra frente, deixei da seguinte forma:
strSearchValue := Trim(Copy(s, intChar, intLastPos - intChar - 1));
Apenas removi o "+ 1" e no meu caso resolveu. Passou a retornar: "evtMonit".
Anexei o arquivo com o ajuste.
Obs.: Utilizo a versão 2005 do delphi.
Oi, Lucas.
Você foi o felizardo premiado em descobrir o primeiro problema.
A correção que você fez funciona, mas ela não resolve a causa do problema na raiz, resolve parte do efeito causado.
A seguir apresento o que detectei debugando o metodo StringXMLToTipoEvento() e a correção aplicada.
O metodo LastIndexOf() retorna a ultima posicão encontrada da string e o metodo PosLast() retorna a proxima posição após encontrar a string; e isso gera inconsistências no processamento do metodo StringXMLToTipoEvento().
A correção foi aplicada nas linhas que utilizam o metodo PosLast(); corrigindo assim a informação desde o inicio e evitando-se que, ao debugar o código, as informações fiquem inconsistentes até o ponto de ajuste.
[]s,
Mário Soares Santos
-
1
-
-
Em 20/01/2022 at 10:03, EMBarbosa disse:
Oi Mário, talvez não tenha sido claro. Estou tentando fazer a avaliação sem quebrar nada.
Não precisa ser um aplicativo exemplo. Talvez só um xml que demonstre o problema já seja suficiente. Acha possível isso?
De qualquer forma agradecemos muito sua contribuição...
Oi, Elton !
Qualquer XML que obedeça a estrutura do S-2400, S-2410 e alguns outros, possíveis, porem ainda não analisados, irão passar pelo mesmo problema na função TEventos.LoadFromString.
Conforme solicitado, segue anexo um XML do S-2400 que ao ser carregado através da função TEventos.LoadFromFile não é identificado corretamente; por causa do mencionado no start deste post.
Os dados utilizados para preenchimento do XML anexo são fictícios.
[]s,
Mário Soares Santos -
2 horas atrás, EMBarbosa disse:
Olá Mário,
As suas alterações parecem fazer sentido.
Mas como ninguém mais mencionou esse problema, por acaso você tem um arquivo de exemplo onde essa identificação falha?
Edit: Adicionado no backlog (TK-2283)
Olá Elton,
Nesse momento estamos sob tensão total; porque desenvolvemos software exclusivamente para orgãos públicos e o eSocial é o projeto que estou responsável e focando em full time.
Para criar um exemplo prático sobre a questão eu precisaria gastar algum tempo e isso agora é impensável.
Vou tentar conseguir algumas horas livres mais lá pra frente e assim poder criar alguma coisa para apresentar.
Estamos gerando os XML dos eventos através do nosso sistema de RH e alimentando as classes de ACBreSocial através do metodo LoadFromString.
Mas posso adiantar que outros problemas decorrentes da falha na sincronização entre TEventoString e TTipoEvento irão ocorrer.
[]s,
Mário Soares Santos -
A identificação do tipo de evento errado nos eventos S-2400 e S-2410 causam problemas na geração/carga/assinatura/validação dos XMLs.
Explicação:
- Ao executar a função ACBreSocialEventos -> TEventos.LoadFromString é disparada a execução da função LoadFromString especifica referente ao grupo do evento do XML (pcesPeriodicos -> TPeriodicos.LoadFromString, pcesNaoPeriodicos -> TNaoPeriodicos.LoadFromString, pcesTabelas -> TTabelas.LoadFromString, pcesIniciais -> TIniciais.LoadFromString).
- As funções LoadFromString de cada grupo de eventos utilizam-se da função pcesConversaoeSocial -> StringXMLToTipoEvento para identificar o tipo do evento a partir da identificação contida dentro do XML.
- A função pcesConversaoeSocial -> StringXMLToTipoEvento utiliza um laço no array pcesConversaoeSocial -> TEventoString para localizar o enumerador pcesConversaoeSocial -> TTipoEvento.Problema:
- O array pcesConversaoeSocial -> TEventoString e o enumerador pcesConversaoeSocial -> TTipoEvento não são equivalentes na quantidade e nem na ordem de ambos; causando assim retorno incorreto pela função pcesConversaoeSocial -> StringXMLToTipoEvento.Solução:
- Buscando solucionar o problema acima mencionado, evitar maiores impactos em códigos legados e preparar um padrão que atenda aos antigos e novos eventos que estão por vir (S2500, S2501 e S5501 - v. S-1.0 - NDE 02/2021 - Processo Trabalhista) foram realizadas as seguintes alterações:
- a) Adição de item no enumerador pcesConversaoeSocial -> TeSocialSchema;
- b) Adição de itens no enumerador pcesConversaoeSocial -> TTipoEvento;
- c) Criação do enumerador pcesConversaoeSocial -> TMatrixEventoInfo;
- d) Criação do record pcesConversaoeSocial -> TRecMatrixEventoInfo;
- e) Criação da constante pcesConversaoeSocial -> __ARRAY_MATRIX_EVENTO_INFO;
- f) Criação da função pcesConversaoeSocial -> GetMatrixEventoInfo;
- g) Refatoração da função pcesConversaoeSocial -> StringINIToTipoEvento;
- h) Refatoração da função pcesConversaoeSocial -> StringXMLToTipoEvento;
- i) Refatoração da função pcesConversaoeSocial -> TipoEventoToStrEvento;Observações:
- Todas as alterações foram realizadas na unit pcesConversaoeSocial;
- Todas as alterações estão identificadas e são facilmente localizadas através da palavra "[MSS", contida em comentário, que pode estar em apenas uma linha ou abrindo e fechando um bloco de alterações.Estou disponibilizando o código para estudos, testes, uso e/ou eventual update no repositório do Projeto ACBr.
[]s,
Mário Soares Santos-
1
-
-
Boa Tarde, @Italo Jurisato Junior!
Testei a sua implementação e a mesma está correta (TeSocialEvento.GerarChaveEsocial), porem faltou aplicar o mesmo teste na procedure GerarIdeEmpregador, da unit pcesGerador.
Citarprocedure TeSocialEvento.GerarIdeEmpregador(pEmp: TIdeEmpregador);
-------
if (TACBreSocial(FACBreSocial).Configuracoes.Geral.TipoEmpregador in [tePessoaFisica,
teOrgaoPublicoExecutivoFederal, teOrgaoPublicoLegislativoFederal,
teOrgaoPublicoJudiciarioFederal, teOrgaoPublicoAutonomoFederal]) then[]s,
Mário Soares Santos
-
Bom dia, @Italo Jurisato Junior!
1 hora atrás, Italo Jurisato Junior disse:Favor atualizar os fontes e faça novos testes.
Estou atualizando a ACBr e modificando o código de preenchimento dos registros.
Assim que eu terminar os testes te informo.
[]s,
Mário Soares Santos
-
Bom dia, @anderson.mendonca!
Aparentemente está tudo certo com relação ao CEP enviado no XML; apenas um pequeno detalhe está sendo desconsiderado:
O eSocial valida o CEP informado contra a base de dados que eles possuem (deve ser os correios). Ao consultar o CEP , que você informou no XML, no site dos correios; recebemos como resposta os dados abaixo.
ATENÇÃO! O CEP 31785-740 FOI ALTERADO CONFORME ABAIXO. Logradouro/Nome: Bairro/Distrito: Localidade/UF: CEP: Rua José Gomes Domingues Jaqueline Belo Horizonte/MG 31748-075Dito isso, creio que o @Italo Jurisato Junior já resolveu o problema e basta você trocar o CEP INVÁLIDO (31785-740) pelo novo CEP VÁLIDO (31748-075).
1 hora atrás, Italo Jurisato Junior disse:No meu entendimento o que pode esta ocorrendo, ou o CEP informado não existe e o WebService faz essa checagem portanto isso explica a mensagem de erro.....
[]s
Mário Soares Santos
-
Bom dia, Italo !
3 minutos atrás, Italo Jurisato Junior disse:Pergunto, se for uma administração pública estadual ou municipal devemos informar somente as 8 primeiras posições do CNPJ, correto?
Correto. Ou as administrações públicas federais que não se enquadrem nas 4 naturezas juridicas especificadas.
5 minutos atrás, Italo Jurisato Junior disse:Existem outras naturezas jurídicas de administração publica direta federal além das 4 mencionadas?
Existem sim, mas para essas vale a regra das oito posições do CNPJ.
[]s
Mário Soares Santos
-
Olá, Rafael!
Em 30/04/2018 at 20:29, Rafael Dias disse:@MSS eu tenho certeza que isso já foi feito no código.
GerarChaveEsocial
if TACBreSocial(FACBreSocial).Configuracoes.Geral.TipoEmpregador in [teOrgaoPublico, tePessoaFisica] then Result := Result + copy(OnlyNumber(CNPJF) + '00000000000000', 1, 14) else Result := Result + copy(OnlyNumber(Copy(CNPJF, 1, 8)) + '00000000000000', 1, 14);GerarIdeEmpregador
if (TACBreSocial(FACBreSocial).Configuracoes.Geral.TipoEmpregador in [teOrgaoPublico, tePessoaFisica]) then Gerador.wCampo(tcStr, '', 'nrInsc', 14, 14, 1, pEmp.NrInsc) else Gerador.wCampo(tcStr, '', 'nrInsc', 8, 8, 1, Copy(pEmp.NrInsc, 1, 8));As partes de código mencionadas acima não atendem as regras especificadas, por isso, adicionei a propriedade NaturezaJuridica na classe de Configurações.Geral e alterei o código para o abaixo:
if (TACBreSocial(FACBreSocial).Configuracoes.Geral.TipoEmpregador = tePessoaFisica) or ((TACBreSocial(FACBreSocial).Configuracoes.Geral.TipoEmpregador = teOrgaoPublico) and (IndexText(TACBreSocial(FACBreSocial).Configuracoes.Geral.NaturezaJuridica, ['1015', '1040', '1074', '1163']) >= 0)) then // Natureza jurídica de administração pública direta federal Result := Result + copy(OnlyNumber(CNPJF) + '00000000000000', 1, 14) else Result := Result + copy(OnlyNumber(Copy(CNPJF, 1, 8)) + '00000000000000', 1, 14);Os 14 caracteres do CNPJF, somente são utilizados quando o tipo do empregador for Pessoa Fisica ou Orgão Público cuja Natureza Juridica seja Administração Pública Direta Federal [101-5], [104-0], [107-4] ou [116-3], a negativa dessas condições obrigam que sejam informados apenas os 8 primeiros caracteres do CNPJF.
[]s.
Mário Soares Santos
-
A geração da chave eSocial (function GerarChaveEsocial) e a geração da tag <nrInsc> (procedure GerarIdeEmpregador) não estavam atendendo as especificações do documento "Leiautes do eSocial v2.4.02"; quando o empregador é "Orgão Público"; fazendo-se necessário algumas modificações no código fonte das units mencionadas a seguir:
ACBreSocialConfiguracoes.pas
Adição da propriedade NaturezaJuridica na classe TGeralConfeSocial e tratamento nos metodos Assign, GravarIni e LerIni.pcesGerador.pas
Alteração da function GerarChaveEsocial e da procedure GerarIdeEmpregador para geração do ID e nrInsc corretos quando empregador for Orgão Público.OBS: As alterações foram realizadas usando-se como base a versão trunk2, revisão 15056, de 29/04/2018, da ACBr.
Erro "Argument out of Range"
em ACBreSocial
Postado
Bom dia, Ronald.
Verifique se não ocorreu problemas com o seu banco de dados, devido a queda de energia.
Estou percebendo pelo trecho de código, que o XML vem de um banco de dados e ele pode estar com alguns registros danificados.
[]s.
Mário