Patrick Alves

Boa tarde! Obrigado! Segue arquivos com as seguintes alterações: * remover propriedade Id em EventosEspecias e em Debitos, sera utilizado o indice das listas; * adicionar ordenacao por grupo de tributos na lista de debitos; * remover formatacao do cnpj para gerar nome do arquivo; * alterar ordem de inclusao dos debitos para validar ordenacao da lista (exemplo 3); ACBrMIT.zip

Boa tarde @EMBarbosa, @Alexandre de Paula Ainda sobre os testes, reparei que os arquivos que retornam o erro tem palavras acentuadas. Fiz a atualização dos fontes e o comportamento relatado ainda persiste. Pode ser que seja útil chamar ConverteXMLtoNativeString. Como falei antes, o usuário sempre escolhe o arquivo a ser importado, sendo assim existe a possibilidade de escolher um arquivo inválido ou que não seja de fato um evento de cancelamento. Vou criar um novo tópico para questão da verificação do arquivo para discutirmos melhor sobre.

Boa tarde @Alexandre de Paula! Pra te dar um contexto aqui utilizo ACBrNFe.EventoNFe.LerXML(UmArquivo) para carregar os xmls recebidos pelo cliente e cancelar as notas se estiverem cadastradas. Estou na revisão 37039, eu comparei ACBrNFe.EnvEvento.pas com a ultima revisão e não encontrei diferenças. Parece que são arquivos específicos recebidos pelo cliente. Infelizmente não tenho em mãos um arquivo de evento com essa situação. Nos testes que fiz aqui, coloquei a rotina para ler uma pasta inteira com muitos xmls que o cliente me enviou não só de evento mas de CT-e e NF-e também. Acabou acontecendo esse erro lendo alguns xmls de NF-e. Aproveito pra perguntar: Atualmente existe alguma forma de verificar que o xml é de fato um evento, ou uma NF-e? Porque notei neste teste que mesmo não sendo um xml de evento a função TRetEventoNFe.LerXml retorna True indicando sucesso na leitura.

Ao carregar xml de eventos de NF-e, vez ou outra recebo o erro: (EACBrXmlException) : Input is not proper UTF-8, indicate encoding ! Comparando com outras funções que carregam o xml, notei a falta da chamada a função ConverteXMLtoNativeString. ACBrNFe.EnvEvento.pas

Boa tarde! Adicionado validações restantes e atualizado com a última retificação do leiaute disponibilizada. ACBrMIT.zip

Foi publicada uma nova retificação do leiaute do arquivo JSON de importação do MIT, atualizando as definições de alguns campos bem como as regras de obrigatoriedade dos campos RegimePisCofins, Csll, AnoDebito e CnpjScp. Todas as alterações estão realçadas em amarelo. https://www.gov.br/receitafederal/pt-br/assuntos/orientacao-tributaria/declaracoes-e-demonstrativos/DCTFWeb/arquivos/mit_leiaute_json_importacao_20-02-2025.pdf

Boa tarde! @Juliomar Marchetti pelo que vi, parece que ainda não tem implementação. Vou deixar anexado o que tenho aqui, já está funcional, faltando apenas mais algumas validações. No programa de exemplo apenas repliquei os exemplos disponibilizados pela receita. ACBrMIT.zip

Boa tarde! Tem alguém que já iniciou o desenvolvimento da geração de arquivos para o MIT? Pergunto porque tenho algo iniciado aqui. Se já foi iniciado alguma coisa e precisarem de ajuda, posso testar ou até mesmo ajudar com algum código, se não, posso compartilhar o que já tenho aqui.

Boa tarde! Se ainda estiver com o problema, tenta trocar [infoComplemCont001001] por [infoComplemCont001].

@Daniel InfoCotidiano vamos atualizar os fontes e testar, assim que possível te posiciono aqui.

Bom dia @saulo.figueiredo 1. É necessário criar uma aplicação separada na conta Azure de cada cliente para realizar o envio, ou seria possível utilizar uma única aplicação criada na conta Azure da empresa para enviar e-mails em nome de todos os clientes? Vc só vai criar um aplicativo na Azure, os seus clientes vão usar esse aplicativo para enviar os emails. (por isso que configuramos o componente com o id do aplicativo, assim cada cliente seu libera (autenticação) o aplicativo pra enviar emails). 2. Você mencionou que o pessoal do ACBr ainda está analisando a solução. Há alguma atualização recente sobre isso? Além disso, poderia explicar melhor como essa questão está relacionada à LGPD? A ultima posição sobre isso eu vi nesse tópico, inclusive sobre a LGPD:

@Joffas Tenta essas configurações no ACBrMail: [Email] [email protected] Host=smtp-mail.outlook.com Port=587 [email protected] Pass=senha TLS=Sim SSL=Não [OAuth2] AccessTokenUrl=https://login.microsoftonline.com/common/oauth2/v2.0/token AuthorizationTokenUrl=https://login.microsoftonline.com/common/oauth2/v2.0/authorize ClientId=seu-client-id ClientSecret=(não informa) RedirectURI=http://127.0.0.1:1500 Scope=https://outlook.office.com/SMTP.Send offline_access TimeOut=120000 Verifica a configuração do app na microsoft. Supported account types = Accounts in any organizational directory and personal Microsoft accounts; Configure platforms = Mobile and desktop applications;

Alterações realizadas: * Adicionar propriedade UseAuthenticator para habilitar OAuth2; * Adicionar configuração para Proxy no OAuth2; @Joffas Adicionei a configuração do Proxy, só não consigo testar aqui... @EMBarbosa Só adicionei essas alterações por causa do amigo acima que precisou do proxy, a opção de ativar o OAuth já tinha um tempo que estava feita. Parece que ainda estão decidindo se vão adicionar a funcionalidade, vi em outro tópico que pode ter problemas com lgpd mas não entendi muito bem. Só pra informar: É possível usar o ACBrMail sem essas alterações para enviar o email com o OAuth2. O processo de autenticar e gerar o token de acesso pode ser feito usando componentes como TOAuth2Authenticator da paleta RestClient do Delphi, TIdHTTP da Indy ou THTTPSend da synapse (é o usado na implementação). Com o token de acesso gerado é só informar ele na propriedade Password do ACBrMail que vc vai conseguir fazer o login e enviar o email normalmente. ACBrMail.pas

@Leonardo Batista Verifica o numero da agencia (cooperativa) e do cliente, eles são usados para calcular o digito juntamente com o nosso numero. Pode ser que tenha alguma diferença do que vc esta informando para gerar o boleto para o que está definido no contrato do cliente.

Se usarmos GetAccessToken e a propriedade AccessToken estiver informada não vai ser chamado InteractiveAuthentication. A ideia do botão é justamente pedir o consentimento do usuário mesmo que em algum momento no passado já tenha sido feito isso, por isso que InteractiveAuthentication limpa os tokens, os que estavam informados não são mais válidos com o novo consentimento. Se ainda não foi dado consentimento, GetAccessToken vai fazer todo o processo. ACBrMail.Send já chama GetAccessToken capturando o AccessToken, mesmo que InteractiveAuthentication não faça todo processo e se InteractiveAuthentication ainda não foi chamado, GetAccessToken chama ele pra vc. Acho interessante por exemplo, na tela onde configura os parâmetros para envio do email colocar o botão chamando InteractiveAuthentication. No uso do programa para enviar os emails vai ser chamado ACBrMail.Send que chama GetAccessToken que se encarrega de obter ou atualizar o AccessToken. Supondo que no futuro vc precise alterar um scopo ou a chave secreta no seu app, é só o usuário ir nos parâmetros e clicar no botão para pedir o consentimento novamente e tudo volta a funcionar.

Pessoal eu acabei alterando o nome de algumas propriedades e métodos para seguir o padrão (inglês) adotado para o componente. Vai quebrar o código de alguém, mas achei que o melhor momento é agora que ainda não foi adicionado ao repositório. Desculpa ai!!! Alterações realizadas: * Mudar eventos de autenticação (antes e depois) para ACBrMail; * Alterar a classe Autenticador (SubComponent) para propriedade de classe (Persistent); * Alterar o nome da classe Autenticador para Authenticator (seguir padrão de nomenclatura) * Alterar o nome da property ExpiraEm para ExpiresIn (seguir padrão de nomenclatura); * Alterar as propriedades RefreshToken, AccessToken e ExpiresIn para leitura e escrita; * Alterar o nome do método AutorizacaoInterativa para InteractiveAuthentication (seguir padrão de nomenclatura); * Alterar o nome do método AtualizarAccessToken para GetAccessToken (seguir padrão de nomenclatura); * Adicionar propriedade ChallengeError para indicar se deve responder quando o login não é realizado com sucesso; * Adicionar método GetChallengeError para responder quando o login não é realizado com sucesso; * Corrigir identificação do login realizado (se for ESMTP, usuário e senha estiver informado, deve ser verificado SMTP.AuthDone); * Adicionar mensagem de erro decodificando o retorno quando não for possível realizar o login; * Enviar resposta com ChallengeError para capturar erros adicionais; * Alterar mensagens do tratamento de erros para inglês (seguir padrão de mensagens de erros); (unit1 é do exemplo) unit1.pas unit1.dfm ACBrMail.pas

@valterpatrick O meu problema foi que o email ([email protected]) que adicionei para testes no app não era email do gmail ([email protected]).

Parece que o Cliente ID que vc configurou no componente não existe. Verifica também se cadastrou corretamente o app no azure, quando cadastrei aqui segui essas orientações: https://learn.microsoft.com/en-us/entra/identity-platform/quickstart-register-app?tabs=client-secret. Em Supported account types eu selecionei Accounts in any organizational directory and personal Microsoft accounts e em configure platforms Mobile and desktop applications

No caso o email de teste cadastrado no app era de desenvolvedor e não tinha o gmail associado. Só removi esse email e utilizei outro.

Boa tarde Valter! Estava fazendo uns testes com outras contas do google aqui e me deparei com uma situação. A conta em questão era de desenvolvedor e não conta do gmail, dava erro ao tentar enviar e debugando percebi que o login no smtp não tinha sido feito, porém o componente indicava sucesso e tentava fazer o envio da mensagem. No google quando acontece erro no login do outh devemos responder um code challenge para capturarmos todas as mensagens. Fiz algumas modificações no componente para contornar isso... logo posto o fonte aqui. @RobsonLopes consegui enviar com essas configurações: [Email] [email protected] FromName=Patrick Host=smtp-mail.outlook.com Port=587 [email protected] Pass=strongpassword TLS=Sim [OAuth2] AccessTokenUrl=https://login.microsoftonline.com/common/oauth2/v2.0/token AuthorizationTokenUrl=https://login.microsoftonline.com/common/oauth2/v2.0/authorize ClientId=seuclientid ClientSecret=deixe em branco RedirectURI=http://127.0.0.1:1500 Scope=https://outlook.office.com/SMTP.Send offline_access

No seu passo a passo acredito ser necessário colocar o scopo, em tese vc tem que dar permissão pra alguma coisa, inclusive na tela de consentimento aparece a descrição dos acessos para os quais o usuário deve consentir

Acho que pode ser porque vc colocou o app para produção... acredito que a verificação é o processo que eles fazem pra certificar que é vc mesmo... Ainda não coloquei um app em produção... kkkk Se voltar o app para teste acho que não vai ter mais a verificação... Pra não ter erro nos testes que fiz eu coloquei o scopo global https://mail.google.com/

@valterpatrick Verifica se suas configurações estão parecidas com essa: [Email] [email protected] FromName=Patrick Host=smtp.gmail.com Port=587 [email protected] Pass=strongpassword TLS=Sim [OAuth2] AccessTokenUrl=https://oauth2.googleapis.com/token AuthorizationTokenUrl=https://accounts.google.com/o/oauth2/v2/auth ClientId=seuclientid ClientSecret=seuclientsecret RedirectURI=http://127.0.0.1:1500 Scope=https://mail.google.com/ * Lembrando que o scope deve estar definido também na configuração do aplicativo lá no Cloud Api Console do google

Vc conseguiu autenticar o usuário pelo componente? Capturou o AccessToken?

@valterpatrick UWP é para aplicativos publicados na Microsoft Store, acho que não é o seu caso! Tenta escolher app para computador.