EMBarbosa

Fonte: https://portalsped.fazenda.mg.gov.br/spedmg/nfe/ Para utilizar as soluções do ACBr em contingência durante este período siga as orientações do tópico abaixo.

O Fisco de MG vem desobrigando a transmissão da Declaração de Apuração e Informação do ICMS - (DAPI) de alguns contribuintes conforme o comunicado logo abaixo. A geração dessa declaração será feita por meio da EFD que o contribuinte entrega. Veja: Fonte e mais informações: https://portalsped.fazenda.mg.gov.br/spedmg/efd/

Muito obrigado pela contribuição Adicionei no nosso backlog (TK-6112). Assim que possível daremos um retorno.

Não é uma solução para você, mas talvez possa ajudar caso queira se aventurar em implementar. Tivemos um caso semelhante para impressora Zebra e o código está no nosso SVN. Tópico de origem:

Por favor, verifique as implementações no seguinte tópico:

plugins de aplicações bancárias? https://support.microsoft.com/en-us/windows/add-an-exclusion-to-windows-security-811816c0-4dfd-af4a-47e4-c301afe13b26

@Artsio @Felipe Govoni, etc... Fiz um commit relacionado a esse caso com a ideia de levantar uma exception mostrando na mensagem de erro a falta da LibXML2. https://sourceforge.net/p/acbr/code/35504/ Favor reportar qualquer problema.

Parece que sim: https://www.projetoacbr.com.br/forum/topic/68001-o-recipiente-da-chave-não-pode-ser-aberto-erro-80090016/?do=findComment&comment=517680&_rid=775

Vale lembrar que atualmente tem essa opção no ACBrInstall.

Olá pessoal! Foi publicada uma versão do programa Validador EFD ICMS IPI versão 4.0.7, com a implementação da nova regra de formação da inscrição estadual do estado do Pará, que permitirá a validação das novas inscrições iniciando em "75". Fonte:http://sped.rfb.gov.br/pagina/show/7578

Wireshark or Fiddler são um dos mais conhecidos...

Aviso: Eu não entendo muito de PHP, mas me parece que o problema na verdade é no protocolo de comunicação. Acho que a questão é que mesmo que você force o header ser um application/json isso não significa que o conteúdo vai ser um application/json. Por exemplo, é como se você falasse para um amigo: "Olha só, vou te mandar uma carta em Inglês se prepara". Daí você manda uma envelope com a carta. Mas dentro do envelope tem uma carta em Japonês. Daí seu amigo está dizendo: "cara tu me mandou uma carta em inglês, eu tava esperando em Japonês". Você precisa fazer a aplicação realmente mandar os dados em formato application/json. Como meu PHP não é lá grandes coisas, nem vou analisar seu código. Mas acredito que se você avaliar o que foi enviado e recebido, por meio de algum monitor de comunicação, vai conseguir identificar exatamente o que foi enviado ou recebido fora do formato esperado.

Não está relacionado a uso de AI em automação, mas sim de desenvolvimento de AI em Pascal: https://www.youtube.com/@artificial-intelligence-pascal/ Que é do mesmo autor desse repositório: https://github.com/joaopauloschuler/neural-api

Nesse caso, acho que seria proveitoso para vocês trocarem para OpenSSL. Vejam, por favor, as configurações recomendadas no seguinte tópico:

Olá, O log não veio... pode verificar e anexar novamente por favor? Tem algum motivo específico para você não estar utilizando OpenSSL já que você faz acesso ao arquivo pfx?

Mas não teria que seguir o mesmo loop da ContinuarRequisicaoSiTef ? Essa parte é que acho que não entendi.

Não sei se eu entendi essa parte. Está que está no link que eu mandei antes. Veja abaixo o link no texto achei via buscador :

Se eu entendi bem, o código assume(1) que o Sitef vai retornar os dados de uma transação por vez e que sempre vai retornar valor da transação por último... Daí na primeira coleta de dado, o LRespostaTEFPendente é criado. Então, segue o loop os outros dados são coletados. Quando for coletar o valor (1319) é chamdo o método fpACBrTEFAPI.RespostasTEF.AdicionarRespostaTEF que clona o objeto LRespostaTEFPendente. De posse do clone na lista de objetos, o LRespostaTEFPendente é destruído, possibilitando o Sitef retornar outra transação que passará pelo mesmo processo. (1) Não sei se o que assumimos corretamente essas premissas pois o fluxo não é descrito na documentação.

Para o que serve essa informação TokenRegistro e o parâmetro TLSGWP mesmo?

Daniel acho que o @Juliomar Marchetti quando implementou essa parte e não quebrou propositalmente o layout do código atual. Me parece que esse loop do ContinuarRequisicaoSiTef vai retornando os dados da venda um por um e não me parece que a ordem da execução é garantida (não testei e não parece ter menção disso na documentação que achei via buscador da internet)... Por isso, eu até tinha notado essa possível falha, mas achei melhor não mexer até enxergar uma outra possibilidade. Talvez precisemos modularizar um pouco mais esse fluxo.

@adriano.quintino Não entendi o motivo de ter adicionado o parâmetro "Funcao" na procedure TACBrTEFAPIClassCliSiTef.ContinuarRequisicaoSiTef(Funcao:Integer); Não parece ser utilizado.

Oi Rodrigo, tudo beleza? Parece que a gente não está se comunicando bem... Me desculpe se eu não me fiz entender, ou se eu não te entendi... vamos tentar novamente... Foi mais ou menos o que fizemos, como eu disse acima... mas precisamos ter certeza que está ok. Pelo que o colega Adriano testou, parece que sim. Mas seria bom que você pudesse testar. Quanto maior o número de pessoas testando, melhor certo? Ninguém está falando para fazer assim... não sei se você chegou a ver o código atual no SVN da classe do Sitef ou o código que o colega Adriano compartilhou acima. Pelos seus comentários parece que não... mas olha minha resposta anterior que foi direcionada ao Daniel. Lá eu menciono que o código chamando a função 130 está ao inicializar a classe do Sitef e o tratamento do retorno na função ContinuarRequisicaoSiTef. Mas foi exatamente o que eu pedi: por favor faça testes o código atual do SVN e com os ajustes do Adriano acima. Daí nos dê um retorno. Bom trabalho.

Eu já verifiquei o seu código, mas como o Daniel postou lá no começo do tópico, suas alterações estão diferentes do código que está no SVN. Na verdade, você mesmo admitiu que não estão no padrão do ACBr: Então seria interessante verificar as alterações que foram feitas acima em conjunto com o @adriano.quintino, para verificar se resolvem seu problema.

Daniel, isso é a parte do código que o Juliomar implementou mas ainda está comentado. É a chamada da função ExecutarTransacaoSiTef('130') que está no final do método TACBrTEFAPIClassCliSiTef.Inicializar. Acho que esse código talvez deveria estar numa função que tenha a função de recuperar as transações pendentes. Mas com ajuda do @adriano.quintino, fizemos alguns testes e com alguns ajustes que vou listar abaixo parece que o código está quase tudo ok. @rodrigoogioni, pode por favor verificar o código implementado pelo Juliomar que está comentado no código atual da unit ACBrTEFAPICliSiTef com os seguintes ajustes abaixo? Temos que fazer algumas alterações nele para funcionar. Por exemplo, tem que descomentar as linhas que tratam os TipoCampo e alterar a classe de resposta pendente de TACBrTEFResp para TACBrTEFRespCliSiTef. Também ainda falta o código para cancelar as transações pendentes. Isso ainda falta fazer, mas é basicamente adicionar no final do método TACBrTEFAPIClassCliSiTef.ContinuarRequisicaoSiTef um loop para percorrer a lista fpACBrTEFAPI.RespostasTEF e cancelar as que precisam ser canceladas.

Sim, a @Juliana Tamizou pediu para eu dar um apoio a esse caso mesmo.