Patrick Alves

o tipo de integração que vc está fazendo...

@valterpatrick Se atenta para o tipo de aplicativo que vc escolher, quando vc escolhe app para computador não é preciso informar o redirectURI no cadastro do app no google. No caso que apresentou ele validou o redirectURI porque vc informou app para web. Da uma olhada: https://developers.google.com/identity/protocols/oauth2/native-app?hl=pt-br

Bom dia! Você precisa ter uma conta na Azure e criar um aplicativo lá. Depois é só configurar os parâmetros para autenticação no componente. Vou deixar aqui alguns links de referencia: https://learn.microsoft.com/pt-br/exchange/client-developer/legacy-protocols/how-to-authenticate-an-imap-pop-smtp-application-by-using-oauth https://learn.microsoft.com/pt-br/entra/identity-platform/quickstart-register-app?tabs=certificate

Essa é a unit do componente, só precisa reinstalar o pacote.

Boa tarde! Testes realizados com configurações para google e microsoft, emails enviados com sucesso. Correções : * Corrigir chamada do procedimento AutorizacaoInterativa. Executa mesmo depois do consentimento; * Corrigir parametro refresh_token para obter access token. Microsoft não aceita para aplicativos desktop; ACBrMail.pas

Correções e melhorias: * Adicionar tratamento de erros; * Adicionar propriedade AuthServerTimeout para o tempo de espera do consentimento do usuário; * Atualizar propriedade ExpiraEm na atualização do token; * Adicionar pmsOAuth ao enum TMailStatus e propagar seu status; * Refatorar procedure AutorizacaoInterativa; * Remover mensagem "Aguardando consentimento do usuário"; * Refatorar procedure AtualizarAccessToken; * Na requisição alterar o tipo do response de TMemoryStream para TStringStream; Em anexo (Unit1.pas e Unit1.dfm são do exemplo) ACBrMail.pas unit1.pas unit1.dfm

Ei @Márcio Baroni... to refatorando algumas coisas e incluindo o tratamento de erros. Vou trocar o memorystream aqui. Acho que a mensagem não precisa na realidade... algum tipo de timeout pode funcionar no lugar. Mais tarde eu coloco aqui as alterações.

Bom dia pessoal! Eu fiz um implementação do OAuth2 no ACBrMail a unit1 do anexo é alteração do exemplo do ACBr. Ainda falta o tratamento erros, mas já está funcional. Referencias: https://github.com/rvk01/google-oauth2/tree/master https://www.emailarchitect.net/easendmail/ex/d/23.aspx ACBrMail.pas unit1.pas unit1.dfm

@ISBS @EMBarbosa Nos eventos S-1250 e S-1260 o grupo "nfs" está sendo gerado incorretamente pelo componente, resultando em um xml inconsistente. No anexo arquivo corrigido. pcesGerador.pas

Caro @Elvis Pesconi, parece estar funcionando somente em produção, obtive os mesmos erros na restrita. Lembrando que a chave não é informada somente para consulta do S-1000, para as demais tabelas deve ser informada.

@Elvis Pesconi Olhando no manual o evento S-1000 aplica a regra "REGRA_INFO_EMP_VALIDA_CLASSTRIB_NATJURID" que define "b) A classificação tributária [85] somente pode ser utilizada se a natureza jurídica do declarante for Administração Pública (grupo [1])." Olhando no xml vc está enviando a classificação 85, e mesmo que no leiaute não tenha o campo da natureza, ele ainda valida a informação. Pode ser que a classificação a ser usada não seja a 85.

Que bom que deu certo @Jucemar Duarte! Numa horas dessas me paga um pizza! hehehe

Acho que seria isso mesmo, se vc pegar no leiaute a chave do grupo "ideEstabLot" é : "tpInsc, nrInsc, codLotacao" e deve ocorrer de 1 a 500 vezes para o trabalhador. Pelo que entendi o "contrato" do trabalhador é com o OGMO então acredito que devem estar juntos mesmo, mas serão apurados de acordo com suas categorias e lotações.

Será que não deveria ser o CNPJ de um estabelecimento do OGMO cadastrado no S-1005 e aí no cadastro da lotação (S-1020) vir o CNPJ do Tomador dependendo do tipo.

Boa tarde! Mais uma pequena correção na formatação das datas. ACBrBancoBanestes.pas

Boa tarde! Obrigado @Juliana Tamizou e @José M. S. Junior! Consegui os arquivos de retorno para testar, foi preciso alterar alguns pontos da função "TACBrBancoBanestes.LerRetorno240". ACBrBancoBanestes.pas

Bom dia @Juliana Tamizou! Sim, arquivo de remessa e boletos homolagados! Somente o arquivo de retorno não foi validado ainda, estamos esperando nosso cliente retornar os testes.

Adicionado leiaute CNAB240 para o banco Banestes. ACBrBoleto.rar

Ao ler o xml do provedor ISSIntel, este tem as tags de cancelamento geradas, porém sem conteúdo. Assim notas "normais" estão sendo importadas como canceladas. Nota cancelada: <NfseCancelamento> <Confirmacao> <Pedido> <InfPedidoCancelamento> <IdentificacaoNfse> <Numero>62</Numero> <Cnpj>11081549000174</Cnpj> <InscricaoMunicipal>30488</InscricaoMunicipal> <CodigoMunicipio>3200706</CodigoMunicipio> </IdentificacaoNfse> <CodigoCancelamento></CodigoCancelamento> </InfPedidoCancelamento> <ns2:Signature/> </Pedido> <InfConfirmacaoCancelamento> <Sucesso>true</Sucesso> <DataHora>2020-02-20T08:39:18.110-03:00</DataHora> </InfConfirmacaoCancelamento> </Confirmacao> </NfseCancelamento> Nota Normal: <NfseCancelamento> <Confirmacao> <Pedido> <InfPedidoCancelamento/> <ns2:Signature/> </Pedido> <InfConfirmacaoCancelamento> <Sucesso>false</Sucesso> </InfConfirmacaoCancelamento> </Confirmacao> </NfseCancelamento> Segue arquivo com correção para análise. pnfsNFSeR.pas

Jovem, 1 - Eventos de Tabelas 2 - Eventos Não Periódicos 3 - Eventos Periódicos

Entendi Jucemar, nesse caso não tem jeito, cada rubrica tem que identificar o beneficiário. Concordo com você que teria outras formas de prestar essas informações (algo parecido com o plano de saúde no S1200 talvez), pode ser que tenham bons motivos pra ter feito assim, ou na pressa pra entregar era o que tinha... kkkk. Como falei antes, aqui temos o beneficiário vinculado ao trabalhador e na hora de gerar o xml, ao identificar que é pensão, pegamos os dados do vínculo e montamos as tags. O e-Social tem evoluído bastante (veja quantas alterações no layout), pode ser que amanhã ou depois isso mude, mas isso é o que temos pra agora.

Opa! Então, para cada rubrica com incidência de IRRF 51, 52, 53, 54 ou 55 o grupo <penAlim> deve ser informado, nas demais o grupo deve ser omitido. Geralmente temos somente uma rubrica de pensão para cada demonstrativo do empregado. Se você tiver mais de uma talvez seja interessante junta-las. Assumindo que você é o desenvolvedor do programa e de todo modo precisa ter várias rubricas de pensão, o beneficiário deve ser informado para cada uma rubrica no xml, mas no seu programa você pode realizar esse vinculo somente uma vez e quando for gerar o evento busca esse vinculo e repete para cada uma. Como são dados cadastrais não vejo como poderia interferir em algum totalizador. É interessante que os valores do campo <vlrPensao> corresponda aos valores das rubricas, no meu caso o valor da rubrica e o valor da pensão foi sempre o mesmo. As rubricas de pensão alimentícia devem ser informadas porque interferem na formação da base de calculo do IRRF, então se você esta se referindo a totalizações que o sistema do e-Social faz, acho que o valor das rubricas que são importantes. Acredito que esses dados estão sendo solicitados mais para fazerem algum tipo de cruzamento de informação com a declaração do IR ou algo do tipo, para efeito de cálculo e fechamento da folha, o que vale é o valor da rubrica.

Correção do nome das propriedades indSubstPatr e indSubstPatrObra para correta leitura do xml de retorno. pcesS5011.pas

O evento S-2240 deve ser enviado por trabalhador, não podendo conter mais de um (trabalhador) no mesmo evento. O layout não permite.

Então... vc tem que partir do ponto de vista do empregador que está enviando a remuneração. Pegando o exemplo que vc passou, temos 3 empregadores e cada um deles vai enviar um evento de remuneração para o empregado em questão, acho que ficaria algo assim: Quando o Empregador 1 enviar a remuneração do Empregado B: <ideTrabalhador> <cpfTrab>XXXXXX64865</cpfTrab> <nisTrab>XXXXXX54243</nisTrab> <infoMV> <indMV>1</indMV> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 2</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>2000</vlrRemunOE> </remunOutrEmpr> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 3</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>1645.80</vlrRemunOE> </remunOutrEmpr> <infoMV> </ideTrabalhador> Quando o Empregador 2 enviar a remuneração do Empregado B: <ideTrabalhador> <cpfTrab>XXXXXX64865</cpfTrab> <nisTrab>XXXXXX54243</nisTrab> <infoMV> <indMV>1</indMV> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 1</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>2000</vlrRemunOE> </remunOutrEmpr> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 3</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>1645.80</vlrRemunOE> </remunOutrEmpr> <infoMV> </ideTrabalhador> Quando o Empregador 3 enviar a remuneração do Empregado B: <ideTrabalhador> <cpfTrab>XXXXXX64865</cpfTrab> <nisTrab>XXXXXX54243</nisTrab> <infoMV> <indMV>2</indMV> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 1</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>2000</vlrRemunOE> </remunOutrEmpr> <remunOutrEmpr> <tpInsc>1</tpInsc> <nrInsc>Empregador 2</nrInsc> <codCateg>101</codCateg> <vlrRemunOE>2000</vlrRemunOE> </remunOutrEmpr> <infoMV> </ideTrabalhador>