Diego Foliene

Olá pessoal! No dia 07/04/2024 foi publicada a versão 1.20 desta nota técnica. A nova versão entre em vigor nos ambientes tanto de homologação quanto de produção de maneira imediata a sua publicação. Ela altera a regra de validação YA09-20, dando a ela o seguinte texto: Efetivamente aumentando o limite do troco para R$ 300.000,00 Leia a versão 1.20 na íntegra AQUI.

Boa tarde @Infoel. Por favor, pode disponibilizar um MVP que simule o problema?

Boa tarde! Por favor, veja este tópico:

Realmente, não tem mesmo. Um ponto que vale destacar é que as datas 30/12/1899 correspondem a data "zero", o que quer dizer que a Lib não está recebendo os valores. Não domino a sua linguagem, mas pelo que pude averiguar, ela faz uso de tipagem dinâmica. Por favor, faça um teste forçando os valores para os tipos esperados pelo método. De acordo com o GPT, ficaria assim: local cFunction := 'PIXCD_ConsultarCobrancasCobV' local ADataInicio := CTOD('02/10/2024') // Converte uma string para data local ADataFim := CTOD('03/10/2024') // Converte uma string para data local ACpfCnpj := '42792981067' local ALocationPresente := .F. // Valor booleano (False) local AStatus := '1' local PagAtual := '1' local ItensPorPagina := 50 // Valor numérico local sResposta := '' local esTamanho := 0 nResult := dllCall(self:nHandle, self:nCallingConvention, cFunction, ADataInicio, ADataFim, ACpfCnpj, ALocationPresente, AStatus, PagAtual, ItensPorPagina, @sResposta, @esTamanho) Conferindo nos exemplos disponibilizados por membros da comunidade em nosso SVN, também é possível observar que nos parâmetros de string, é utilizado este método hb_StrToUTF8 no parâmetro.

Bom dia! Conferindo no fonte da Lib, esta é a ordem de parâmetros para este método na Lib: PIXCD_ConsultarCobrancasCob(ADataInicio,ADataFim,CpfCnpj,ALocationPresente,status,PagAtual,ItensPorPagina) Transcrevendo a chamada do seu Log, fica: PIXCD_ConsultarCobrancasCob( <ADataInicio>: 30/12/1899, <ADataFim>: 30/12/1899, <CpfCNPJ>: 1, ALocationPresente>: -1, <status>: , <PagAtual>: 0, <ItensPorPagina>: 1699904 ) Por favor, reveja a sua rotina e confirme se os valores passados estão sendo transmitidos para a Lib. Tente fazer um teste com o exemplo também.

Conferindo no log, é gerada uma entrada PIX_CDConsultarCobrancasCobV? Se sim, qual é o valor que consta no mesmo? O valor do parâmetro foi passado sem espaçamentos?

Boa tarde. Neste tópico tem as configurações recomendadas por tipo de certificado. Veja que além das configurações SSLLib, SSLCryptLib, SSLHttpLib e SSLXmlSignLib. Também muda a forma como é atribuído o certificado ao componente. Com o A1, é recomendado preencher as propriedades CaminhoPFX e Senha, enquanto que para o A3 é recomendado preencher a propriedade número de série. Como uma dica extra, também recomendo que você adicione as dlls da OpenSSL e da LibXML2 no mesmo diretório do .EXE. Lembre-se de escolher as dlls de acordo com a arquitetura que compila a sua aplicação e não a do SO.

Boa tarde. Fiz um teste em meu ambiente onde carreguei as configurações do arquivo INI que disponibilizou tanto no exemplo em C# quanto no exemplo em Java. Em ambos apresentou erro. O valor 5 para ambos LogNivel e NivelLog estão incorretos. 4 é o valor mais alto em ambos os casos. Após corrigir o valor em ambos, os exemplos carregaram e salvaram as configurações sem apresentar erro. Por favor, corrija o valor e veja se ele ainda apresenta erro para você e caso afirmativo, veja se o log trás informações mais detalhadas.

Arquivo recebido, faremos alguns testes e reportamos assim que descobrirmos algo.

Conferindo junto aos demais consultores, foi questionado se seria possível disponibilizar um MVP reproduzindo o problema.

Comparando com os fontes do meu ambiente, eles estão semelhantes. Pedi um apoio aos demais consultores. Por favor, apenas confirmando, o mesmo comportamento ocorre se testar com o programa exemplo?

Bom dia! Parece estar em ordem. Por favor, envie para [email protected] o seu arquivo ACBrLib.ini para que eu possa fazer um teste com o exemplo do C# e do Java em meu ambiente carregando ele e vendo se também recebo o mesmo erro. Não se esqueça de colocar no corpo do e-mail o link do tópico do fórum para posterior identificação.

Esses arquivos estão refletindo a operação que de fato apresentou o problema? Veja que o arquivo acbr_lib_pix.log possui apenas algumas linhas e nenhuma delas é relacionada a requisição. O log foi configurado para o nível mais alto possível? No arquivo ACBrLibPIXCD-20241003.log, o erro de Acess Violation parece ter sido devolvido quando tentou gravar as configurações. Por favor, tente fazer um teste: 1. Renomeie seu arquivo ACBrLib.ini. 2. Inicie a aplicação, será criado um novo arquivo ACBrLib.ini em branco. 3. Utilizando o arquivo ACBrLib.ini renomeado, vá preenchendo aos poucos as configurações seguindo fluxo: 3.1 Preencha uma seção de configuração. 3.2 Inicie a aplicação. 3.3 Não deu erro? Finalize a aplicação. Va repetindo o processo até dar o erro novamente ou preencher toda a config. Assim, pode identificar se há alguma configuração sendo preenchida com um valor inválido/incorreto.

Boa tarde. Por favor, compacte a sua pasta ACBrNFe dos fontes do ACBr e disponibilize a mesma. Se ficar muito grande e não conseguir anexar aqui, envie para [email protected] com o link do tópico no corpo do e-mail para posterior identificação.

Boa tarde! Por favor! Em seu arquivo ACBrLib.ini, defina na seção [Principal] um caminho em LogPath e o valor 4 em LogNivel. Este é o log da Lib. Ainda no mesmo arquivo, na seção [PIXCD], defina um caminho e nome de arquivo em ArqLog e o valor 4 para NivelLog. Este é o log específico do PIXCD. Por favor, disponibilize ambos os arquivos para análise.

Boa tarde! Fiz um teste e de fato será necessária uma correção. Criada a #TK-6049 para alteração. Qualquer novidade será comunicada aqui neste tópico.

Boa tarde! Esta Consulta Schemas pode ajudar com a visualização. Você também pode conferir para NF-e/NFC-e diretamente no MOC versao 7.03 Anexo I Leiaute NFe e para o SAT em Especificacao_SAT_v_ER_2_30_03

Boa tarde! Apenas complementando a resposta do meu amigo @Victor H. Gonzales - Panda, isso procede tanto para o SAT(que é o exemplo que ele colocou) quanto para NF-e/NFC-e, vide MOC versao 7.03 Anexo I Leiaute NFe:

Olá pessoal! Caso o envio tenha sido solicitado pelo Discord e você não tenha um tópico no fórum ainda, no corpo do e-mail você deverá enviar o link da mensagem do Discord para posterior identificação e resposta por parte da equipe de consultores. Para pegar o link da mensagem, coloque o mouse sobre a mensagem e clique no ícone de 3 pontos que aparece. Em seguida, clique na opção "Copiar Link" Fazendo isso, o link estará na sua área de transferência(no seu CTRL+V).

Olá pessoal! Recentemente temos recebido relatos de membros da comunidade com problemas para realizar o envio de e-mail quando o provedor é o da Microsoft(@hotmail, @outlook e afins). Um membro de nossa comunidade compartilhou a seguinte mensagem que recebeu da Microsoft: Esses "métodos modernos de autenticação" se referem ao Oauth 2.0 (Veja mais em Os Métodos de Autenticação Modernos agora necessários para continuar a sincronizar o E-mail do Outlook em aplicações de e-mail não Microsoft). O que é o Oauth 2.0? O Oauth 2.0 é um protocolo de autorização que funciona através de tokens de acesso e foi projetado primariamente com o objetivo de conceder acesso a determinados recursos de aplicações de usuários. Neste caso em questão, seria o acesso ao e-mail. Como fica o ACBrMail? Atualmente o ACBrMail não tem suporte a Oauth 2.0, foi criada em nosso backlog a tarefa #TK-6042 para análise e implementação da mesma. É o fim do ACBrMail então? O que eu faço agora? Não é o fim do ACBrMail. Conforme mencionado anteriormente, será analisada implementação do Oauth 2.0 no mesmo. Enquanto isso não ocorre, para provedores como o g-mail, por exemplo, ainda é possível fazer a comunicação com a Senha de App. Para a Microsoft, nos testes realizados pela equipe de consultores, Microsoft365 ainda demonstra estar funcionando, o HotMail e o Outlook que pararam de funcionar. Outra opção também seria o uso de um provedor de e-mail próprio.

Olá pessoal! No dias 24/09/2024 e 01/10/2024 respectivamente foram publicados o Correio Eletrônico SEF/DIAT/Nº 16 / 2024 e o SEF/DIAT/Nº 17 / 2024 respectivamente. Ambos trazem mais informações a respeito do fim do PAF-ECF. Em resumo: As emissões de NFC-e e BP-e deverão ser feitas por programas de aplicativos fiscais (PAF) credenciados. A emissão de NFC-e e BP-e exige credenciamento prévio por meio dos Tratamentos Tributários Diferenciados (TTD) de número 707 e 709. Deverá ser gerado o CSC para emissão de NFCe, um manual de como solicitar o TTD 707 e gerar o CSC pode ser encontrado em www.sef.sc.gov.br/nfce. Uma vez iniciada a emissão de NFC-e e BP-e a empresa interventora deve cessar o uso do PAF-ECF indicando "Adesão a NFCe" como o motivo. Foram revogados os Atos DIAT nº 46/2022 e nº 55/2022, responsáveis pela implementação da exigência do Bloco X, dispensando a sua obrigatoriedade. Não é feita a distinção do CNAE principal ou secundário, por isso a obrigatoriedade se inicia na primeira data de enquadramento do anexo. Por exemplo, um estabelecimento que possua como CNAE primário 4511101 (Anexo V do Ato DIAT cujo inicio da obrigatoriedade é 01/07/2025) e CNAE secundário 4732600 (Anexo I do Ato DIAT cujo inicio da obrigatoriedade é 01/03/2025) terá o início da obrigatoriedade no dia 01/03/2025. Os estabelecimentos que realizam atividades de venda a consumidor final não citadas de forma explícita no Ato DIAT 56/2024 estão obrigados ao uso da NFC-e a partir de 01/08/2025. A obrigatoriedade de uso da NFC-e refere-se ao estabelecimento e não apenas a atividades específicas. Desta forma, iniciada a obrigatoriedade, todas as saídas internas do estabelecimento para consumidor final, não contribuinte, deverão ser acobertadas por NFC-e. Novas Inscrições Estaduais estão obrigadas ao uso da NFC-e e BP-e desde a publicação do Ato DIAT 56/2024 No momento, os contribuintes que não estão obrigados ao uso do ECF em razão de seu faturamento, continuam dispensados do uso da NFC-e e do BP-e. Todavia a previsão de que isso seja alterado ainda em 2024, por isso, é recomendado que os contribuintes se atentem ao cronograma exposto no Ato DIAT 56/2024. As alterações do regramento não afetam empresas MEI, as quais continuam dispensadas da emissão de documentos fiscais, salvo nas condições explicitadas na LC 123/06. A partir de 01/08/2025 não será mais permitido o uso de Emissor de Cupom Fiscal (ECF) em Santa Catarina.

Olá pessoal! Ao acessar o Portal da Nota Fiscal Eletrônica - SVRS foi exibido o seguinte aviso informando que como os contribuintes MEI ganharam IE, as regras de validação relacionadas a mesma passarão a ser aplicadas e que os contribuintes que não souberem sua própria inscrição poderão consultar no CCC.

Olá pessoal! No dia 01/10/2024 foi publicada a versão 2.00 do Informe Técnico 2024/001, alterando novamente a tabela de NCMs. A partir de 01/10/2024: Extinção dos NCMs: 32071010, 39069041, 39069042, 39069043, 39069044, 39069045, 39069046, 39069047, 39069048, 39069049 e 73151100. Inclusão dos NCM 32071020, 32071030, 39069051, 39069052, 39069053, 39069054, 39069059, 39069061, 39069062, 39069063, 39069064, 39069065, 39069069, 73151110 e 73151190. Para NFes que não sejam de exportação, os NCMs extintos serão aceitos até 04/11/2024. Os novos NCMs serão aceitos a partir de 02/10/2024 de acordo com a implantação da UF. Leia o Informe na integra AQUI.

Olá pessoal! Ao acessar o portal SPED MG consta um aviso com a seguinte informação: A mesma deixa claro que no ambiente de homologação, será devolvido a mensagem de consumo indevido caso uma mesma rejeição de Duplicidade de NF-e com diferença na Chave de Acesso seja devolvida mais de 200 vezes em um período de uma hora. Por isso, é importante que verifiquem se sua aplicação possui um processo em loop que possa causar uma situação como esta. Por que isso é tão importante? Porque conforme observações nas regras de consumo indevido presentes na NT2018/002, a rejeição de consumo indevido faz com que seja necessário aguardar o período de uma hora para poder voltar a consumir o web service, no entanto, a critério da UF, após 50 bloqueios o contribuinte pode receber a rejeição 656 permanentemente até entrar em contato com a UF autorizadora para regularização.