Luiz Neto

Ou seja: em meu programa eu lia as configuracoes de meu arquivo config, com os protocolos utilizados, os dados do certificados mas por erro na sequencia dos procedimentos, `SSLLib` ficava em `libWinCrypt` (correto para A3), mas `SSLCryptLib`/`SSLHttpLib`/`SSLXmlSignLib` ficavam em classes vazias que não sabiam conversar com o CryptoAPI/token. Por isso o Windows nunca chegava a pedir o PIN do A3, e o ACBr estourava um erro genérico de "provedor" — porque a camada de assinatura configurada não tinha implementação real,. Eu havia inserido código para forçar libWinCript em meus programas, porem deixei falhas que não definiam corretamente os 4 ComboBox do protocolo e isso afetava as variaveis, identificando, colocando como comentario o código falho e definindo os ItemIndex como o codigo acima fez funcionar, o que importa é se certificar que o protocolo esteja corretamente definido para os 4. No meu caso defini: cbSSLLib.ItemIndex := 4; cbCryptLib.ItemIndex := Ord(cryWinCrypt); cbHttpLib.ItemIndex := Ord(httpWinHttp); cbXmlSignLib.ItemIndex := Ord(xsMsXmlCapicom);

Eu uso como no aplicativo de exemplo do eSocial Delphi da propria ACBr, apenas havia uma falha que fazia o aplicativo nao utilizar as 4 configuracoes da WinCrypt procedure TFExemploEsocial.LerConfiguracao; var IniFile, PathMensal: String; Ini: TIniFile; begin IniFile := mClssBDPrincipal.CaminhoBancoDeDados+'eSocial\MGP_eSocial.ini'; Ini := TIniFile.Create(IniFile); try IF (cbSSLLib.Items.Count>0) then begin cbSSLLib.ItemIndex := 0; IF (cbSSLLib.Items.Count>3) then begin // WinCrypt cbSSLLib.ItemIndex := 4; end; end; =======================> cbCryptLib.ItemIndex := Ord(cryWinCrypt); cbHttpLib.ItemIndex := Ord(httpWinHttp); cbXmlSignLib.ItemIndex := Ord(xsMsXmlCapicom);

Resolvi postar a sequencia de correçao que fiz, aqui e depois verifico e submeto código para revisão e inclusão: Achei a causa raiz. Confirmando: sim, `uExemploEsocial.pas` é o responsável pela config do certificado — e é lá que está o bug. ## Diagnóstico Em `TFExemploEsocial.LerConfiguracao` (uExemploEsocial.pas): **Linha 927-933** — força `cbSSLLib` para índice 4 (`libWinCrypt`), ignorando o que está salvo: ```pascal IF (cbSSLLib.Items.Count>0) then begin cbSSLLib.ItemIndex := 0; IF (cbSSLLib.Items.Count>3) then begin // WinCrypt cbSSLLib.ItemIndex := 4; end; end; ``` **Linhas 936-939** — a leitura real de `SSLLib`/`CryptLib`/`HttpLib`/`XmlSignLib` do INI está **comentada** (bloco `{ }`): ```pascal { cbSSLLib.ItemIndex := Ini.ReadInteger('Certificado', 'SSLLib', 0); cbCryptLib.ItemIndex := Ini.ReadInteger('Certificado', 'CryptLib', 0); cbHttpLib.ItemIndex := Ini.ReadInteger('Certificado', 'HttpLib', 0); cbXmlSignLib.ItemIndex := Ini.ReadInteger('Certificado', 'XmlSignLib', 0); } ``` Resultado: `cbCryptLib`, `cbHttpLib` e `cbXmlSignLib` nunca são atualizados e ficam com o valor default do `FormCreate` (`ItemIndex := 0`). Depois, nas linhas 1025-1027, esses índices zerados são aplicados direto: ```pascal SSLCryptLib := TSSLCryptLib(cbCryptLib.ItemIndex); // 0 = cryNone SSLHttpLib := TSSLHttpLib(cbHttpLib.ItemIndex); // 0 = httpNone SSLXmlSignLib := TSSLXmlSignLib(cbXmlSignLib.ItemIndex); // 0 = xsNone ``` Conferi no fonte do ACBr (`ACBrDFeSSL.pas`, `SetSSLCryptLib`/`SetSSLHttpLib`/`SetSSLXmlSignLib`): quando o valor é `cryNone`/`httpNone`/`xsNone`, cai no `else` e instancia uma classe **genérica/vazia** (`TDFeSSLCryptClass`, `TDFeSSLHttpClass`, `TDFeSSLXmlSignClass`), que não implementa nada de verdade. **Ou seja:** `SSLLib` fica em `libWinCrypt` (correto para A3), mas `SSLCryptLib`/`SSLHttpLib`/`SSLXmlSignLib` ficam em classes vazias que não sabem conversar com o CryptoAPI/token. Por isso o Windows nunca chega a pedir o PIN do A3, e o ACBr estoura um erro genérico de "provedor" — porque a camada de assinatura configurada não tem implementação real. ## Correção sugerida Em vez de reativar a leitura do INI (que nunca teve esses valores salvos, já que a gravação também está incompleta), o mais robusto é forçar os 4 índices de forma consistente com WinCrypt, junto do bloco que já força `cbSSLLib`: ```pascal cbCryptLib.ItemIndex := Ord(cryWinCrypt); // 3 cbHttpLib.ItemIndex := Ord(httpWinHttp); // 2 cbXmlSignLib.ItemIndex := Ord(xsMsXmlCapicom); // 3 (ou xsMsXml = 2, se CAPICOM não estiver instalado) ``

Vi no exemplo do manual, seriam rubricas proventos e descontos, incidindo apenas para IR com código 13.

Voces recomendam deixar com informativas ou seriam rubricas proventos e descontos? e o código de incidência tributação para o IR, deixar como 13 ou 11?

Estou utilizando os do ACBr

Tem como saber o que causa o erro Schema Inválido ao criar o S-1210 Pagamentos layout S-V.1.0.00, alguma forma de gerar um log? ou forçar mais detalhes do erro? se eu colocar um try..except o programa consegue criar o XML e consigo transmitir sem erro pelo eSocial, mas a mensagem está incomodando meus clientes, pois, se passa a transmissão porque a essa mensagem aparece? então aparentemente o XML está correto.

Forçei a geração do XML pra analisar e não vejo o que pode estar errado, ele ainda acusa erro de Schema Inválido <?xml version="1.0" encoding="UTF-8"?> <eSocial xmlns="http://www.esocial.gov.br/schema/evt/evtPgtos/v_S_01_00_00"> <evtPgtos Id="ID0000438150000002022020210000638743"> <ideEvento> <indRetif>1</indRetif> <perApur>2022-01</perApur> <tpAmb>1</tpAmb> <procEmi>1</procEmi> <verProc>1.0</verProc> </ideEvento> <ideEmpregador> <tpInsc>1</tpInsc> <nrInsc>29003815</nrInsc> </ideEmpregador> <ideBenef> <cpfBenef>00000000000</cpfBenef> <infoPgto><dtPgto>2022-01-04</dtPgto> <tpPgto>2</tpPgto> <perRef>2021-01</perRef> <ideDmDev>R</ideDmDev> <vrLiq>198.67</vrLiq> </infoPgto> </ideBenef> </evtPgtos> </eSocial> zerei o CPF e o ID por questao de sigilo do cliente, mas o resto é copia do XML Se puder comparar com o seu XML de pagamento de rescisão e dizer se vê alguma tag faltando ou sobrando eu agradeçerei muito.

Estou com um erro no S-1210 pagamento de rescisão usando o layout Simplificado que apresenta erro de Schema Inválido e descobri que uma das causas é que indGuia não deve ser preenchido, vocês estão conseguindo gerar o S-1210 para rescisões sem erro de Schema Inválido?

Vocês estão conseguindo gerar o S-1210 para pagamento de rescisão? versão S.V-1.0 Simplfiicada está dando erro de Schema inválido e ou no layout 2.05.00 transmite, mas ele dá erro que não achou o registro S-2299 correspondente ao pagamento.

Quando fui gerar o S-1210 no eSocial, acontece o erro de Schema inválido, gerei o XML antes de assinar e vejo que a estrutura está batendo com o XML gerado pelo site do eSocial quando faço esse registro manualmente, como parece que a assinatura e valdação do XML ocorre em DLL, tem como saber o que pode estar causando esse tipo de erro? alguma tag indesejada, erro na ACBr, ou no arquivo de Schema? <?xml version="1.0" encoding="UTF-8"?> <eSocial xmlns="http://www.esocial.gov.br/schema/evt/evtPgtos/v_S_01_00_00"> <evtPgtos Id="ID0000438150000002022020210000638743"> <ideEvento> <indRetif>1</indRetif> <perApur>2022-01</perApur> <tpAmb>1</tpAmb> <procEmi>1</procEmi> <verProc>1.0</verProc> </ideEvento> <ideEmpregador> <tpInsc>1</tpInsc> <nrInsc>29243815</nrInsc> </ideEmpregador> <ideBenef> <cpfBenef>00000000000</cpfBenef> <infoPgto><dtPgto>2022-01-04</dtPgto> <tpPgto>2</tpPgto> <perRef>2021-01</perRef> <ideDmDev>R</ideDmDev> <vrLiq>198.67</vrLiq> </infoPgto> </ideBenef> </evtPgtos> </eSocial>

Fiz uns ajustes do pcesGerador para corrigir erro na validação quando o trabalhador/sócio for estrangeiro mas residir no Brasil, não basta apenas saber se ele é estrageiro, é necessário verificar o país onde ele reside para gerar o endereço certo. procedure TeSocialEvento.GerarEndereco(pEndereco: TEndereco; pExterior: boolean); begin Gerador.wGrupo('endereco'); If Not pExterior Or (pEndereco.Exterior.PaisResid = '105') Or (pEndereco.Exterior.PaisResid = '') Then begin // Mora no Brasil GerarEnderecoBrasil(pEndereco.Brasil); end else begin GerarEnderecoExterior(pEndereco.Exterior); end; Gerador.wGrupo('/endereco'); end; pcesGerador.pas

TIdeEstabLotCollection e TIdeEstabLotCollectionItem precisam do mesmo refactoring para TIdeEstabLotCollectionS1200 e TIdeEstabLotCollectionItemS1200 pcesS1200.pas

Vou atualizar, obrigado pela resposta

É para evitar erro de execução na conversão quando t estiver vazia ou nula, tem situações com leitura do BD que podem gerar t nulo, isto é apenas para adicionar mais uma camada de verificação evitar o erro na execução. Não irá quebrar o código, é exatamente por ela ser chamada em várias rotinas e com isso dispensar inúmeros testes se t está vazio pelo código. Tem algumas opcoes onde o campo é opcional e aí o valor de t será vazio e vai dar erro de conversão no integer (t).