Painel de líderes

Inclusão do método SalvarPDF nas classes C# Olá comunidade! Visando manter a estabilidade e segurança das classes C# adicionaremos o método SalvarPDF Nossa recomendação para as classes MDFe, NFe e NFSe é a utilização do método SalvarPDF() ao invés do ImprimirPDF(Stream aStream); A motivação dessa mudança é que esse método utiliza operações assíncronas e pode causar Condição de Corrida. Além disso, mantém coerente a documentação da ACBrLib Se utiliza classes C# MT deve atualizar os pacotes o mais breve possível. Diferente de ImprimirPDF(Stream aStream), o SalvarPDF retorna uma String com o conteúdo do PDF em base64. Até a data da publicação desse tópico foram atualizados: NFe versão 1.0.37 MDFe versão 1.014 NFSe versão 1.0.17 CTe versão 1.0.14 Serão atualizados em breve: Boleto Exemplo de código antigo: // exemplo de código antigo Stream ms = new Stream() nfe.ImprimirPDF(ms); Código recomendado: string pdfStream = nfe.SalvarPDF();

Consegui superar este erro.. obrigado

Fez atualização e rodou o instalador do ACBr recente?

A título de informação, a única API que encontrei que possibilita a recuperação dos dados de pagamento (incluindo descontos, acrescimos) de BoleCode liquidado via Pix é a API de Conciliação PIX (QRCode): API Exclusiva (QRCode) https://devportal.itau.com.br/nossas-apis/itau-ep9-api-conciliacao-v1-externo?tab=informacoesAdicionais

Boa tarde, Só para reforçar... Não é toda cidade que está usando a IPM que está aceitando somente um registro por nota. Temos clientes usando IPM em outras cidades no PR que ainda estão aceitando mais de uma, exemplo é Colombo/PR.

Bom dia a todos. Abaixo um checklist do andamento da implementação das alterações para a versão 1.40 da NT. As tarefas estão avançadas, mas travadas na validação do XML gerado pois ainda não temos schemas atualizados para a atualização. Enquanto os schemas não forem liberados, as alterações não podem ser enviadas em produção.

Olá pessoal, Uma pergunta que temos recebido muito é sobre se o ACBr já está preparado para o CNPJ alfanumérico. Nosso time esta atuando de forma a atualizar nossas soluções para este novo cenário, e alguns componentes já foram atualizados e outros estão em andamento. É importante salientar que ainda não temos CNPJs ativos neste novo formato, e que de forma geral, diversos setores que fazem parte deste processo seguem se ajustando para que de fato exista uma empresa ativa com CNPJ neste formato. Outro fator relevante é que nem todos os schemas atualizados foram disponibilizados pelas SEFAZ, oque impede a utilização desse novo formato para tais documentos. Seguiremos atualizando este artigo conforme as soluções forem ajustadas. Soluções já Atualizadas ACBrBPe ACBrBoleto ACBrCTe (Componente ajustado e DACTE em andamento) ACBrNFCom (Componente ajustado e DANFE-COM em andamento) ACBrValidador ACBrNFe / ACBrNFCe (Componente ajustado e DANFE em andamento) ACBrDCe (Componente ajustado e DANFE em andamento) ACBreSocial ACBrMDFe (Componente ajustado e DANFE em andamento) ACBrGNRe ACBrPixCD ACBrReinf As demais soluções serão tratadas conforme disponibilidade de agenda do nosso time, com foco em entregar o mais breve possível. "Após cada componente ser atualizado as ACBrLib correspondentes e o ACBrMonitor também estarão atualizados em sua próxima versão." Lembre-se que além das Soluções ACBr, os principais impactos do CNPJ Alfanumérico em sua aplicação pode ocorrem em: Telas de entrada de dados: campos e máscaras que aceitam apenas números. Banco de dados: campos definidos como numéricos e validações no banco. Validação de CNPJ: regras próprias, expressões regulares e bibliotecas de terceiros. (ACBrValidador já está adequado) Integrações: APIs, WebServices, arquivos TXT, CSV e XML que esperam apenas dígitos. Importação e exportação de dados: planilhas e processos de migração. Relatórios e documentos: campos formatados como número. Código-fonte: rotinas que utilizam conversões numéricas (StrToInt, IsNumeric, etc.).

Boa tarde, Já esta no SVN a implementação do enumerado para o valor 4 do campo procEmi e a leitura do grupo infPAA no XML.

Olá comunidade ! Foi publicada a versão 1.01 desta nota técnica trazendo controles para emitente CPF e ajustes em regras de validação. Alterações A faixa de série 970-979 anteriormente reservada para emissor CNPJ utilizando PAA foi alterada. Agora a nova disposição é: 970-979: Faixa reservada para o PAA utilizando CPF do emitente. 980-989: Faixa reservada para o PAA utilizando CNPJ do emitente. Foram criadas novas regras de validação para: Impedir emissão em lote na SV-RS. Impedir emissão de NFC-e. Impedir emissão em ambiente diferente da SV-RS quando emitido por PAA. Impedir uso de série incorreta. Datas Implantação Teste: 03/08/2026 Implantação Produção: 08/09/2026 E como fica o ACBr? Essa versão não requer alterações nas soluções ACBr. Um agradecimento ao membro de nossa comunidade @mateusjurado por compartilhar a informação no canal #sefaz em nossa comunidade do Discord.

@Atenas Soluções Softwares, Até onde sei (mas confesso que não sou especialista em RT) o Split Payment ainda está em definição... tem vários modelos, em estudo... Mas fazendo um exercício de futurologia... talvez, seja necessário que a aplicação comercial, sinalize na transação TEF, o valor de Imposto, que a adquirente precisa efetuar o Split para o Governo... Enfim, ainda não há nada em definitivo, e nenhuma modificação no universo das TEF Houses, sobre isso..