Painel de líderes

Boa tarde. Está funcional.

Na data de criação deste tópico a Sefaz estava passando por instabilidade, mas o problema foi resolvido posteriormente, conforme notícia a seguir. Lembrando que a Sefaz não dá garantia da distribuição imediata dos NSUs após a manifestação. Caso os registros não estejam sendo recebidos após um longo período, ou se apenas alguns documentos não estiverem sendo recebidos, abram um fale conosco com a Sefaz para verificarem se existe algum problema.

Boa tarde! Parece que já corrigiram agora a pouco. O pessoal que estava enfrentando o problema tente reenviar por favor.

Você tem conflitos de atualização por ter alterações locais nos fontes. Use a opção "Resolve" do SVN pra decidir o que manter, ou a opção "Revert" para descartar as alterações locais e usar o do SVN.

depura e olha se ele tá passando true no parametro que tem sabe usar o F7 e F8? dai vai entrando na função

Realmente não havia percebido que tinha portal especifico para gerar as credencias de Teste e estava usando as mesma de Produção. Obrigado por reportar como já consegui testar em produção acredito que podemos concluir.

Olá pessoal! Desde o dia 03/02/2025 o estado do Paraná em seu ambiente de homologação algumas regras de validação que efetivamente obrigam o envio das informações do grupo do responsável técnico na íntegra nos XMLs das NF-es. Dentre estas regras de validação, temos a que devolve o cStat 975 com a mensagem: Esta rejeição é devolvida quando o web service não encontra no arquivo XML as tags do IdCSRT e do HashCSRT. No entanto, desde às 14h16 do dia 03/02/2025, temos recebidos múltiplos relatos de membros em nossa comunidade do Discord que estão recebendo esta rejeição mesmo com as informações devidamente presentes no XML. É importante ressaltar que está regra de validação foi ativada apenas no ambiente de homologação por hora e por isso, mesmo que consiga transmitir uma nota com sucesso para o ambiente de produção, isso não deve ser utilizado como parâmetro. Caso esteja enfrentando está rejeição, é importante que abra um Fale Conosco junto a Sefaz do Paraná relatando a questão.

Bom dia, Criada a TK-6583 para avaliação. Obrigado pela contribuição

Está correto, no caso do ICMS monofásico (CST 02, 15, 53, 61), será usado CST mesmo para emitente do Simples Nacional.

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Mas fiz uma alteração para garantir que se alguém estiver utilizando um arquivo anterior em cache continue conseguindo ler os dados. Acredito ter coberto todos os pontos, mas por favor, queira atualizar, testar e reportar qualquer problema. Subi as alterações para o SVN na Revisão 37224. Mais uma vez obrigado.

Ahh obrigado.. Então o código sem a correção não irá ler corretamente as Datas

Olá pessoal! Segue na íntegra e-mail disparado pela Sefaz informando sobre o fim dos tratamentos tributários diferenciados dos tipos 706, 707, 708, 709 e 710 para BP-e e NFC-e, além da orientação de que o credenciamento para emissão de ambos os documentos será concedido no momento da criação da autorização de uso do respectivo PAF pela empresa desenvolvedora.

Aplicativo não tem mas tem o componente ACBrBoleto e sim funciona no Delphi 7. ele não substitui pois ele não é igual cada componente tem suas particularidades no caso do cobrebem é de um jeito no ACBrBoleto é de outro mas ele funciona

Olá Devs ! Ontem recebemos relato de rejeição no banco Inter, como esta : {"title":"Dados inválidos.","detail":"Verifique se os dados informados estão de acordo com a documentação disponibilizada e tente novamente.","timestamp":"2025-02-03T10:25:14.27387669-03:00","violacoes":[{"razao":"O valor não pode ser nulo","propriedade":"incluirCobrancaAsync.body.desconto.valor","valor":"null"}]} Teve alteração da API na forma que é enviada o Desconto. Antes era um Array com 3 descontos e agora é um objeto somente Desconto 1. <<Atenção>> Se enviar desconto, desconto2 e desconto3 só será GERADO O DESCONTO1. Sendo assim desconto2 e desconto3 serão ignorados ! Obrigado ao usuário @Dangelo2010 que reportou o problema e realizou os testes no seu ambiente de produção. Agora no inter, pode aplicar apenas um desconto 1: Titulo.DataDesconto Titulo.TipoDesconto Titulo.ValorDesconto Foram removidos: Titulo.DataDesconto2 Titulo.TipoDesconto2 Titulo.ValorDesconto2 Titulo.DataDesconto3 Titulo.TipoDesconto3 Titulo.ValorDesconto3 O que diz o manual:

Salve Devs ! Agora o Banco Santander conta com mais uma API de apoio nos testes. Além do endPoint de Sandbox, agora o Santander permite testes em Homologação ! Este endPonit é o mesmo de Produção, mas na propriedade environment = "Teste". Isso permite você testar no mesmo ambiente de produção. O que diz no manual da API: Nota 3: Ambiente (environment): (pagina 49) Manual. Deverão ser enviados os seguintes domínios, de acordo com o ambiente de processamento para o registro do boleto: • PRODUCAO: Indica que o boleto deverá ser registrado normalmente no Banco • TESTE: Indica que a requisição está sendo enviada somente com a finalidade de teste, o boleto não será registrado no Banco. Para configurar, basta configurar o ambiente: Delphi Boleto.Configuracoes.WebService.Ambiente := tawsHomologacao; ACBrLibBoleto [BoletoWebSevice] Ambiente = 1 ACBrMonitorPlus Acesse Boleto, WebService: Lembrando que o ambiente pode ser configurado via cedente.ini tanto na lib quanto no monitor. [WEBSERVICE] ClientID= ClientSecret= KeyUser= Scope= IndicadorPix= Ambiente= Resumo:

Olá pessoal! Na tarde do dia 18/11/2024 o Sebrae promoveu junto aos auditores fiscais da Receita, Carlos Nacif e Hermano Toscano, uma Live para detalhar duas mudanças previstas para 2026 para todos os empreendedores. Dentre as mudanças mencionadas, uma delas se refere a unificação da emissão de NFS-e em todo o país utilizando o Padrão Nacional. Está mudança está prevista para Janeiro de 2026, sem uma data específica. As informações acima foram retiradas de notícia originalmente publicada pelo Sebrae e que pode ser lida na íntegra AQUI. Relembrando. No contexto da NFS-e, não há um leiaute único. Cada administração municipal pode optar por contratar através de licitação uma empresa que fornece o web service de emissão de notas de serviço (nós do ACBr chamamos esta empresa de "provedor"). Este web service pode ser implementado seguindo um leaiute da maneira que o provedor preferir, causando assim, no cenário da NFS-e, uma falta de padrão. O Padrão Nacional, como o nome diz, é um padrão que foi criado com o objetivo de centralizar isso, acabando com os padrões próprios utilizados. No entanto, apesar do nome Padrão, sua adesão até o momento desta publicação, é obrigatória apenas para os MEIs com adoção opcional para os outros casos. Nesta adesão opcional, até o momento, 1.140 cidades estão conveniadas, sendo 22 capitais. (Você pode conferir a lista completa AQU). O que se espera é que em 2026 todos estejam emitindo pelo Padrão Nacional. Também é importante lembrar! O componente nativo para Delphi/Lazarus e consequentemente o ACBrMonitorPLUS e a ACBrLib já estão adequados ao Padrão Nacional e podem ser utilizados para emissão de nota no mesmo. O tópico abaixo traz mais informações a respeito:

Olá Pessoal, O grupo sobre o Responsável Técnico esta presente em diversos DF-e, tais como: BP-e, CT-e CT-e OS, GTV-e, CT-e Simplificado, NF3-e, NFCom, NF-e, NFC-e e MDF-e. Para a maioria dos DF-e não existe uma obrigatoriedade de informar o Responsável Técnico, mas não custa nada informar os seus dados ao gerar o XML. Mas para a NF-e e NFC-e temos a NT 2018/005 versão 1.40 que determina que para as UF: AM, MS, PE, PR, SC e TO devemos informar, pois existe a obrigatoriedade, caso contrario a nota vai ser rejeitada: 972 - Obrigatória as informações do responsável técnico. Como alimentar o componente com as informações do Responsável Técnico? {Informações do Responsável Técnico pela emissão do DF-e} infRespTec.CNPJ := ''; infRespTec.xContato := ''; infRespTec.email := ''; infRespTec.fone := ''; Para quem gera o arquivo INI que é utilizado no ACBrMonitor e no ACBrLib devemos incluir a seção: infRespTec: [infRespTec] CNPJ = ''; xContato = ''; email = ''; fone = ''; Outra informação importante se refere ao CSRT (Código de Segurança do Responsável Técnico) que a SEFAZ-PR vai passar a exigir a partir de 03/02/2025 em ambiente de homologação para o modelo 55 (NF-e) e a partir de 01/04/2025 em produção. O CSRT bem como o idCSRT é obtido através de um credenciamento feito no Portal da SEFAZ, como dito acima hoje somente PR que esta exigindo esse credenciamento. Os componentes listados acima já possuem duas propriedades de configuração que são utilizadas para informar o idCSRT e o CSRT. Configuracoes.RespTec.IdCSRT := 0; Configuracoes.RespTec.CSRT := ''; Notem que o IdCSRT é uma informação numérica, já o CSRT é alfa numérica. Lembrando que essas duas propriedades de configuração só devem ser informadas no componente neste momento para quem emitir NF-e no PR, se não informar a nota vai ser rejeitada: 975 - Obrigatória a informação do identificador do CSRT e do Hash do CSRT. Pode ser que no futuro as demais SEFAZ venham a exigir também não só para NF-e como também para outros DF-e. Abaixo temos as regras de validação na integra sobre o Responsável Técnico que se encontra na NT 2018/005 versão 1.40:

ACBrSedex? CepCerto? O que você está falando? Embora os mais conhecidos sejam os componentes para documentos fiscais eletrônicos, impressão e boleto, a suíte do ACBr possui componentes para as mais variadas finalidades. Um deles é o ACBrSedex cujo exemplo pode ser encontrado em ..\trunk2\Exemplos\ACBrTCP\ACBrSedex e tem essa cara: Como é possível observar a finalidade do componente é permitir realizar cálculos relacionados ao prazo de entrega de encomendas e realizar o rastreio do mesmo. Em seus primórdios, o componente utilizava a API dos próprios correios para esta finalidade. No entanto, em determinado momento, esta API deixou de ter um plano gratuito e por causa disso, foi necessário migrar para uma API de terceiros chamada CepCerto que na época disponibilizava um plano gratuito e planos pagos. Recentemente a CepCerto removeu o plano gratuito mantendo apenas os planos pagos. Isso significa que se você tentar utilizar o componente ACBrSedex de forma a utilizar o plano gratuito vai receber a seguinte exceção devolvida pela API: Eu preciso desse recurso, o componente consegue comunicar com o plano pago? Sim! A diferença é que você precisa conseguir um Token junto ao pessoal da CepCerto. De posse dessa informação, você vai preencher a mesma em: ACBrSedex.Senha := Dessa forma, você vai conseguir comunicar com a API sem demais problemas. É importante ressaltar que esta mudança foi na API da CepCerto e não no ACBr. Os fontes do ACBr são OpenSource de livre acesso para todos.

Não, você não leu errado o título da notícia. A sefaz de São Paulo está dando adeus ao SAT! Foi publicado no dia 31/10/2024 a Portaria SRE 79, DE 31 DE OUTUBRO DE 2024 que modifica a Portaria CAT147/12(responsável pela definição do SAT), acrescentando na mesma os seguintes artigos: Efetivamente impedindo a ativação de novos equipamentos SAT para quem ainda não o tinha o aparelho e estipulando a data de 01/01/2026 para o fim do SAT como um todo. Mas se eu uso o SAT o que eu vou fazer agora? A NFC-e é o documento fiscal que deverá ser utilizado no lugar do CF-e. A muito tempo, esses documentos são "intercambiáveis", com o contribuinte podendo escolher se emite uma NFC-e ou um CF-e através do SAT para acobertar a mesma operação. Eu estou um pouquinho enferrujado, mas o SAT não era a contingência da NFC-e? Não mais! A Sefaz já havia publicado previamente uma portaria autorizando o uso da contingência off-line para NFC-e no estado. Veja mais aqui:

Olá pessoal, Apenas uma atualização: Fizemos mais uma separação com os métodos restantes numa unit chamada "ACBrUtil.Base.pas". Como vocês podem ver no post acima. Consideramos essa tarefa da ACBrUtil agora completa. Agora é remover warnings e hints gerados por essa separação e, por fim, ajustar os testes unitários também. Bom trabalho por aí.