Painel de líderes

Bom dia! A Sefaz de Minas Gerais está com contingência agendada, com previsão de inicio no dia 07/06/2023 as 18:00 e encerramento no dia 12/06/2023 as 12:00. Fonte: Portal da Nota Fiscal Eletrônica Um agradecimento especial a @Maria Gabriele Oliveira por chamar nossa atenção ao fato no canal #sefaz em nossa comunidade do Discord. Para transmitir em contingência usando o ACBr durante este período, siga as orientações do tópico abaixo:

Boa tarde Mario.. Em breve entro em contato contigo para conversarmos sobre a Parceria TEF ACBr PayGo.

Bom dia! Recebemos relatos em nossa comunidade do Discord de membros que ao tentarem transmitir NFC-e usando CSOSN 900 e CFOP 5.949 para o estado do Rio Grande do Sul receberam a rejeição 725. As alterações da NT mudam o texto das rejeições 382 e 386 para acrescentar a CFOP 5.949 para o RS. No entanto, se observarmos o texto da rejeição 725: Podemos observar que ela não considera o novo CFOP. Isso efetivamente inválida as alterações da NT, pois mesmo que não rejeite mais na 382 ou 386, a NFCe vai ser rejeitada na 725. Atualizaremos o tópico a medida que forem surgindo novas informações.

Bom Dia. Para colaborar: Fiz o mesmo processo novamente, coloquei novamente as dll junto do executavel, conferi todos os dados, o email tava em branco, preenchi novamente, gerei, validei no Digicert, enviei ao sicredi e hoje foi aprovado.

Realizando testes com esse evento o ACBr estava gerando um erro de schema: Falha na validação dos dados do Evento: --> 1845 - Element 'evCancPrestDesacordo': No matching global declaration available for the validation root. Verificando, a rotina DefinirDadosMsg estava sem tratamento para esse evento ao gerar o trecho que é validado. Adicionei essas linhas no arquivo e tudo funcionou: schevCancPrestDesacordo: begin AXMLEvento := '<evCancPrestDesacordo xmlns="' + ACBRCTE_NAMESPACE + '">' + Trim(RetornarConteudoEntre(AXMLEvento, '<evCancPrestDesacordo>', '</evCancPrestDesacordo>')) + '</evCancPrestDesacordo>'; end; ACBrCTeWebServices.pas

La no site do banco Inter, tem que solicitar os arquivos de retorno por periodo, eles não disponibilizam automaticamente...

Entendi! Olha só, o equipamento estava guardado e não era utilizado fazia algum tempo. Obrigado Juliomar, pelo retorno!

Corroborando ao agendamento da contingência, ao acessar o site da Secretaria da Fazenda de MG, o seguinte aviso é exibido:

Boa tarde, tudo certo? avaliaram a alteração? sabe se irão utilizar o que enviei ou se constataram algum erro? meus clientes já estão utilizando normalmente com este processo. Caso eu possa contribuir com algo a mais me informem, obrigado.

@softecmario, atualmente a PayGo direcionou todo o atendimento aos Distribuidores, como o ACBr... Em nossa página tem várias informações sobre nossa proposta: https://projetoacbr.com.br/tef/

Implemente o WS do Banco Inter. O ACBrBoleto possui suporte. Mais estável do que a remessa nessa instituição. Um detalhe: o nosso número é gerado pelo banco.

Não houve nada de alterações no Software básico do SAT para isso, então creio que não

Não tem tratamento . pois quem faz o consumo seria do seu lado. ele só repassa o que é solicitado

@Jéter Rabelo Ferreira @João Paulo B Silva Bom dia ! Primeiramente obrigado Jéter pela contribuição, foram feitas algumas modificações, como leiame.txt dentro do zip. Foi implementada algumas funções como de consultas, já que a princípio era apenas inclusão, mas por falta de certificado, não foi criado credenciais no Santander para que pudéssemos testar, ou seja, ele não foi homologado com outras funções como consultas, etc por falta de credenciais. Sendo assim, se puder testar por favor em ambiente de homologação para que possamos após homologado incluir em nossos repositórios. Aguardamos um feedback. Segue as units: SantanderAPI.7z Obrigado, bom dia !

Boa noite! O problema era que no componente zConexao esta fixo o caminho do Library Path para um caminho da minha máquina, que não é o mesmo do Cliente. Caso resolvido! Muito obrigado Juliomar! Abraço!

é alguma que tá faltando e tu não levou. cria um log e grava a exceção que tu vai ver qual

Consegui resolver. O problema do erro do CSR é as dll's mesmo. Precisa das libcrypto-1_1 e libssl-1_1 e aparentemente de todas aquelas dll's do MINGW. O segundo erro do openssl: values mismatch foi por que na geração do certificado no programa de exemplo, ele estava pegando a primeira chave que eu havia gerado. Espero que ajude aos demais que estiverem passando pelo mesmo erro. Att... Marcelo Carriconde

Boa tarde, Ainda não... está sendo migrado todas as fichas de relatórios primeiro

Bom dia! De fato, no manual está dividindo essas informações e no ACBrBoleto está enviando tudo junto como Código de Transmissão. No entanto, a informação é equivalente, ou seja, Código de Transmissão = Conta Movimento Beneficiário + Conta Cobrança Beneficiário. Como as posições são equivalente, o efeito também vai ser o mesmo, se você preencher o Código de Transmissão com a informação concatenada, elas vão ficar nas posições correspondentes.

se está gerando o registro 3 é porque você está informando chave de pix nas configurações do cedente. se está sendo rejeitada, a sua carteira não permite a operação ou você não está passando demais configurações coerentes.

Exatemente o que li no guia. Consultando contador, me passou que era para excluir, na verdade, somente nao informar sped. Mais pelo visto tem continar a inutilizar as numerações não utilizadas para o governo.

No guia diz apenas que foram descontinuados, deixando a entender que não deverão mais ser informados.

Não se informa mais notas inutilizadas, nem as denegadas. Recomendo a leitura do guia prático.

Boa tarde Pessoal, Os documentos: CT-e - Conhecimento de Transporte Eletrônico e CT-e OS - Conhecimento de Transporte Eletrônico Outros Serviços, possuem um evento chamado: Prestação do Serviço em Desacordo. O autor desse evento, ou seja, que envia ele para a SEFAZ é o tomador do serviço. Esse evento, permite ao tomador informar ao Fisco que o CT-e/CT-e OS que o relaciona esta em desacordo com a prestação do serviço. O tomador tem um prazo máximo de 45 dias a contar da data de autorização do CT-e/CT-e OS para enviar o evento. Detalhe importante: O evento tem que ser enviado para a SEFAZ do emitente do CT-e, supondo que o emitente seja de São Paulo devemos: 1. Configurar o componente para a UF do Emitente (Configuracoes.webservices.UF := 'XX'; // onde XX é a UF do Emitente do CT-e) 2. Ao alimentar o componente informar em cOrgao a UF do Emitente do CT-e. Como montar a rotina para enviar o evento: ACBrCTe1.EventoCTe.Evento.Clear; with ACBrCTe1.EventoCTe.Evento.Add do begin infEvento.nSeqEvento := 1; // Para o Evento de Prestação do Serviço em Desacordo nSeqEvento sempre = 1 InfEvento.cOrgao := UFtoCUF(xUF); // Devemos informar a UF do Emitente do CT-e infEvento.chCTe := Copy(ACBrCTe1.Conhecimentos.Items[0].CTe.infCTe.Id, 4, 44); infEvento.CNPJ := xCNPJ; // CNPJ do Tomador infEvento.dhEvento := now; infEvento.tpEvento := tePrestDesacordo; infEvento.detEvento.xObs := trim(sOBS); // minimo 15, máximo 255 caracteres end; iLote := 1; // Numero do Lote do Evento ACBrCTe1.EnviarEvento(iLote); No exemplo acima o XML do CT-e/CT-e OS foi carregado, mas não se faz necessário, caso não deseja carregar o XML basta informar a chave (44 dígitos) ao campo chCTe. No campo xObs deve constar uma observação do tomador que justifique o desacordo do serviço prestado. Em caso de dúvidas, clique aqui para criar um novo tópico.