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).

Sugiro um refactoring das units pcesS1200.pas e pcesS2299.pas para alterar os nomes das classes TDmDevCollection para TS2299DMDevCollection e TDMDevCollectionItem para TS2299DMDevCollectionItem, pois elas são definidas em outra unit e causa erro de compilação se fizer Uses da outra unit pcesS1200.pas pcesS2299.pas

Sugiro a seguinte alteração function EnumeradoToStr2(const t: variant; const AString: array of string ): variant; // Atencao não Funciona em Alguns Enumerados ja existentes begin // Melhorar para testar se o valor consta na string IF Not ((VarType(t) = varUnknown) Or (VarType(t) = varNull) Or (VarType(t) = varEmpty)) Then Begin result := AString[ integer( t ) ]; end; end;

Bom dia Italo, não, é no nome da classe mesmo, estou fazendo um refactory nas classes do pces1200 e pces2299 e testando o impacto, está compilando agora, assim que terminar de testar compartilho aqui os resultados pra fazermos um refactory com orientações de vocês.

Obrigado por responder Juliomar. Ele não apresenta o erro, pois não faz o include do pces1200 e pces2299 no comando "uses", eu preciso usar pois faço declaração de procedures com parâmetros com essas classes. Não entendi a declaração das mesmas classes com os mesmos nomes mudando apenas alguma letra para maiuscula na pces2299 e pces1200. Eu poderia renomear as classes, embora sejam aparentemente iguais, mas fiquei sem querer alterar a ACBr sem analisar melhor.

Estou tendo erros de compilação pois algumas classes da unit pces2299 repetem o nome de classes que estão em outras units como pces1200, exemplo da classe TDmDevCollection e TDMDevCollection causando erro de compilação quando necessito colocar a unit pces2299 e pces1200 no "uses" da unit. Alguém pode ajudar?

Bom dia, vou enviar os arquivos que alterei, dê um Locate pela palavra 'Luiz:' que marquei onde eu alterei pcesS1005.pas pcesConversaoeSocial.pas

Estou tendo erros ao gerar o S-1005 do eSocial por causa da tag <indSubstPatrObra> que não deve ser gerada se não houver situação na empresa. A função infoEstab.DadosEstab.infoObraInst() testa se foi atribuída e aí gera ou não no xml, porém, como a propriedade no componente ABCr é do tipo enumerado, sempre esta função retorna Verdadeiro e gera a tag com valor 1. Fiz alterações nos fontes para a lista aceitar o valor ispVazio, alterei os métodos de geração das tags, porém gostaria de saber se vocês estão conseguindo gerar o XML sem a tag quando a empresa não utilizar essa situação, antes de perder tempo tentando alterar os fontes pces1005.pas. Este problema acontece com outras propriedades nos registros, onde existe uma lista de valores válidos, mas, não deva ser gerada a tag se a empresa não se enquadrar.

Estou tendo erro no registro S-1030 por causa dos dados de cargos publicos (minha empresa é privada), alguém sabe como resolver? Mesmo que eu deixe sem preencher estes campos, acusa erro na geração do XML pois S1030 - evtTabCargo.infoCargo.DadosCargo.cargoPublico.leiCargo não passa sem informações.

Fiz a alteração acima e funcionou bem. Existem varios campos com valor tipo 0,1,2..9 que só devem devem gerados em certas situações, porem como sao propriedades do tipo inteiro que nao pode ficar 'Null' sempre estarão com valor 0 ao iniciar e aí não saberemos se foi preenchida ou está vazia. Alguma sugestão de como modificar pcesConversaoeSocial.pas para para não atribuir valor zero, quando forem inicializadas ou convertidas para string? function eSIndSitPFToStr(const t: tpIndSitPF): string; begin result := EnumeradoToStr2(t, TGenericosString0_2); end;

Estou tantando enviar um evento S-1000 e está ocorrendo o seguinte erro: Código da ocorrência: 638 Descrição do erro...: O ambiente informado no evento é incompatível com a url utilizada. <?xml version="1.0" encoding="UTF-8"?> -<eSocial xmlns="http://www.esocial.gov.br/schema/evt/evtInfoEmpregador/v02_04_02"> -<evtInfoEmpregador Id="ID1182359010000002018083017304282694"> -<ideEvento> <tpAmb>2</tpAmb> <procEmi>1</procEmi> <verProc>1.0</verProc> </ideEvento> tpAmb está igual a 2 e configurei o ambiente para Homologação (1) Quando ele retorna o XML na consulta ele coloca tpAmb como 1 no XML de retorno -<recepcao> <tpAmb>1</tpAmb> <dhRecepcao>2018-08-30T16:21:24.273</dhRecepcao> <versaoAppRecepcao>0.1.0-A0340</versaoAppRecepcao> Alguem sabe como resolver? Verifiquei varias vezes a tag tpAmb e está certa no envio.