Ir para conteúdo
  • Cadastre-se

MSS

Membros
  • Total de ítens

    28
  • Registro em

  • Última visita

Tudo que MSS postou

  1. 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
  2. Bom dia. Conforme solicitado, estou anexando as units alteradas. []s, Mário pcesS2200.pas pcesS1010.pas
  3. 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
  4. 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
  5. 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 pcesConversaoeSocial.pas
  6. 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) then Analise 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
  7. 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-f9e4e41bb3a6 Fontes\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 ACBr-eSocial-2022-07-01.zip
  8. 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
  9. Boa tarde, Willian. - eSocial - versão S1.00 - Acbr - versão trunk2 de 20/04/2022 - XSD - desatualizado Segue anexo nova versão dos arquivos XSD do eSocial, já renomeados para o padrão da Acbr. veS01_00_00.zip
  10. 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
  11. 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 ACBr-eSocial.zip
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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. 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 pcesConversaoeSocial.pas
  17. 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 1455215570001062022012408463305320-S-2400-0.xml
  18. 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
  19. 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 pcesConversaoeSocial.pas
  20. 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. []s, Mário Soares Santos
  21. Bom dia, @Italo Jurisato Junior! 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
  22. 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-075 Dito 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). []s Mário Soares Santos
  23. Bom dia, Italo ! Correto. Ou as administrações públicas federais que não se enquadrem nas 4 naturezas juridicas especificadas. Existem sim, mas para essas vale a regra das oito posições do CNPJ. []s Mário Soares Santos
  24. Olá, Rafael! 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
  25. MSS

    eSocial - Orgãos Públicos

    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. ACBreSocial-change-log.txt OBS: As alterações foram realizadas usando-se como base a versão trunk2, revisão 15056, de 29/04/2018, da ACBr.
×
×
  • Criar Novo...

Informação Importante

Colocamos cookies em seu dispositivo para ajudar a tornar este site melhor. Você pode ajustar suas configurações de cookies, caso contrário, assumiremos que você está bem para continuar.