Painel de líderes

Demorou mas finalmente a SEFAZ-MG decidiu seguir o modelo de outras UFs e passará a utilizar o Servidor Virtual do RS (SVRS) para a emissão dos documentos fiscais eletrônicos definidos no acordo de cooperação técnica, entre os quais estão a NFe e NFCe. Mas não para por ai, além de MG, a SEFAZ-PR também optou por seguir o mesmo caminho e também adotar o SVRS. Trata-se de uma excelente noticia em especial para quem emite DFes em MG, afinal é de conhecimento de todos que as instabilidades tem sido frequentes. Prazos Apesar do acordo de cooperação atualizado entrar em vigor em 01/01/2024 precisamos acompanhar a manifestação das SEFAZ para confirmar se será de fato nesta data. Links Fonte: Portal Sped Brasil Link para o acordo de cooperação 05/2023 aqui EDIT: Vale acrescentar que apesar da divulgação do acordo de cooperação técnica Nº 5, a Sefaz de MG ainda não se pronunciou oficialmente sobre o mesmo e também não consta nenhuma informação oficial na página da mesma. Por isso, é importante aguardarmos antes de tomarmos qualquer medida para alteração.

Com aproximaçao do fim do prazo para a migração para a versão 4.0 vou deixar aqui dois xmls completos para exemplo que pode servir de referência para quem desenvolve Consulta status do servidor <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <cteDadosMsg xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CTeStatusServicoV4"> <consStatServCTe versao="4.00" xmlns="http://www.portalfiscal.inf.br/cte"> <tpAmb>2</tpAmb> <cUF>50</cUF> <xServ>STATUS</xServ> </consStatServCTe> </cteDadosMsg> </soap12:Body> </soap12:Envelope> CTe SincV4 sem soapheader e com dados compactados na base64 <?xml version="1.0" encoding="utf-8"?> <soap12:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap12="http://www.w3.org/2003/05/soap-envelope"> <soap12:Body> <cteDadosMsg xmlns="http://www.portalfiscal.inf.br/cte/wsdl/CTeRecepcaoSincV4"> dadoscompactados </cteDadosMsg> </soap12:Body> </soap12:Envelope> CTe.xml descompactado (Esse é um exemplo só para mostrar como proceder a compactação na base64 , esta incompleto) <CTe xmlns="http://www.portalfiscal.inf.br/cte"> <infCte versao="4.00" Id="CTe50231200172038000167570500000000031003067083"> </infCte> <infCTeSupl> </infCTeSupl> <Signature xmlns="http://www.w3.org/2000/09/xmldsig#"> </Signature> </CTe> Para obter os dados compactados utilizando a linha de comando em Linux cat CTe.xml | gzip | base64 > dadoscompactados Espero ter ajudado alguem

Complementando a resposta do @Diego Foliene caso deseje fazer as imlementações e nos enviar ficaremos gratos em adicionar ao nosso repositório de exemplos para a comunidade!

Boa tarde! A classes em C# podem sem problema algum serem usadas no seu projeto. No entanto, o intuito delas é apenas de demonstrar o uso da Lib no C#. Por causa disso, apenas as tratativas para o TipoResposta do retorno em formato INI foi implementado.

Bom dia! Analisamos o vídeo e os arquivos disponibilizados, a princípio o processo parece estar correto. Por favor, vou lhe pedir para fazer mais alguns testes: Foi citado que o certificado é o A3. É possível testar com um certificado A1 para ver se o problema também ocorre? Este certificado A3, funciona com outros DFes? Se testar ele em site de validadores como Certsign - Teste seu Certificado Digital, Serasa Experian - Teste seu certificado digital e Cerpro - Teste de Certificado Digital ele não apresenta erro? Na lib, nós temos um método chamado NFSe_ObterCertificados, é possível fazer um teste com ele para ver se ele trás as informações corretamente? Apenas para desencargo, se puder fazer um teste colocando todos os caracteres do NumeroSerie na seção [DFe] do seu arquivo INI em maiúsculo. Se o problema persistir depois disso: Você disse que usa a versão StdCall, single thread e x86 correto? Vou lhe enviar uma versão da Lib modificada local para que possa fazer um teste. Nesta versão, modifiquei o método NFSe_GerarLoteRps, adicionando mais linhas de log nele para tentar facilitar encontrar a linha em ocorreu o erro. EDIT: Arquivo enviado via mensagem privada aqui no fórum.

Fora erros no servidor do Fisco, geralmente isso acontece por haver diferença apenas do cNF. Verifique se não tem alguma nota já enviada mas com um cNF diferente.

Muito possível ser um erro no servidor, tentando processar o seu pedido duas vezes. Me parece que você vai precisar entrar em contato com o provedor da prefeitura e reportar o caso. Talvez eles tenham mais informações.

Oi Siro. Obrigado pelo esforço. Nesse caso, agora parece que você tem um ambiente limpo de duplicidades, que é o problema mais comum desse erro (99,9%)... Sendo assim, talvez o problema então não seja bem um arquivo "duplicado". Para gerar esse erro basta ter duas compilações diferentes (arquivos dcus) da mesma unit. Então, talvez seja um arquivo compilado para fins diferentes (exemplo Debug e release, ou plataformas diferentes). O seu FastReport tem separação de bpls ou dcus para debug e release? Mas mesmo se não tiver, o Delphi talvez esteja se "confundindo". Nesse caso, uma hora ele gera em release para compilar o ACBr. Mas depois, ele está gerando em debug para compilar sua aplicação. Daí geraria esse erro se o ACBr não tiver compilações diferentes ou o Delphi não estiver conseguindo recompilar os pacotes e units do ACBr. Então, outra pergunta, no ACBrInstall, você marcou a opção "Deixar somente a pasta LibXX no Library Path do Delphi"? Se a resposta for sim. Poderia reinstalar o ACBr deixando essa opção desmarcada?

Em se tratando do componente ACBrNFSeX, para que a alteração no .ini faça efeito, você precisa: - Copiar o arquivo ACBrNFSeXServicos.ini para o diretório da aplicação, e reiniciar a mesma. ou - Executar o Compila_RES.bat para que seja gerado o ACBrNFSeXServicos.res - Reinstalar o ACBr para que os arquivos .ini e .res sejam atualizados na pasta ACBr\Lib - Recompilar a aplicação

Bom dia Informando que a NFSe de Limeira provedor iiBrasil teve uma troca do endereço de https://limeira.iibr.com.br/api/soap/notafiscal.php para https://limeira.iibrasil.com.br/api/soap/notafiscal.php

Bom dia A prefeitura de Limeira alterou o endereco do WS de https://limeira.iibr.com.br/api/soap/notafiscal.php para https://limeira.iibrasil.com.br/api/soap/notafiscal.php Segue ACBrNFSeXServicos.ini Atualizado. ACBrNFSeXServicos.ini

Muito obrigado pela contribuição. Fiz a implementação baseada nela. Subi as alterações para o SVN na Revisão 31581. Pelo que vi está tudo certo. Queira por favor atualizar, testar e reportar qualquer problema. Mais uma vez obrigado.

Já estamos com a TK-4859 em andamento para essa alteração. Quando estiver concluída informamos aqui tbm.

UTF-BOM veja no exemplo na geração da imagem

Olá, Estou trabalhando no código para atualizar o componente, de acordo com o Porem, como faz tempo que não programo, estou com bastante dificuldades em atualizar o sistema e estou com um cliente parado já alguns dias sem emitir NF. Estou compilando o sistema e indo erro por erro para corrigir e finalizar, acho que está no final, mas com ajuda seria mais rápido. Preciso dessa ajuda remota para finalizar essa demanda URGENTE.

Boa tarde!! Efetuei os seguintes testes, conforme solicitado: 1 - Utilizar o método chamado NFSe_ObterCertificados (ocorreu o erro, segue o log em anexo); 2 - Todos os caracteres do NumeroSerie na seção [DFe] foram alterados para maiúsculo. 3 - Atualizei a Lib com a versão modificado e utilizei o método "NFSe_GerarLote" (ocorreu o erro, segue o log em anexo); ACBrLibNFSe-20231214 NFSE_ObterCertificados.log ACBrLibNFSe-20231214 NFSe_GerarLoteRPS.log ACBrLib.ini

Boa tarde!!! Claro, já vou efetuar os testes !!! Obs: * Em relação ao certificado A3, ele está funcionando normalmente, o cliente emite NFe/NFCe. * Em relação ao teste com certificado A1, já havia efetuado o teste (achei que poderia ser isso) e erro também ocorre. Obrigado.

SIM, RE-enviei os arquivos para eles tb!

Bom dia! Convenhamos, é uma resposta bem simplória para o problema exposto. Eles testaram com as mesmas informações que você está utilizando? Com tomador que devolve no xml de retorno com acento no nome que você citou aqui:

Bom dia! Conferindo no MOC, a rejeição 204, possui a seguinte descrição: Com base nisso, podemos deduzir que o número do Recibo só será concatenado se o envio for feito de forma assíncrona. Se síncrono, deverá vir apenas a chave. E mesmo no envio assíncrono, a concatenação é opcional a critério da UF.

No site https://app.developers.bb.com.br/ você precisa criar uma aplicação. Assim vai receber as credenciais Após isso tem q seguir a documentação. Lembre-se que é obrigatório o uso de dados fictícios informado por eles. Entao vc tem q preencher com os dados de testes. CNPJ/CPF Conta, Agencia, Convenio.. etc.. tudo o que precisar. Dados como scopo e como configurar, clique aqui:

Bom dia, Temos a TK-4859 para essa alteração. Obrigado pela contribuição.

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

Olá Diego, Vou tirar as linhas e ver como irá funcionar. Vou testar e logo digo se resolveu. Agradeço

Realmente é o tema que está dando problema. Desativando o tema funciona normalmente. Estou usando o componente TSkinData da VclSkin.

Bom dia, Lembre-se de remover este arquivo da pasta da aplicação nas próximas atualizações, pois ele prevalecerá sobre as novas alterações no ini. Obrigado pela contribuição. Criada TK-4857 para envio ao SVN.

@WesleySantos É para funcionar como no componente, já que utilizamos a mesma classe de impressão. pode enviar os 2 xmls q vc testou ai para nós ? [email protected] No corpo da mensagem favor colar o link deste post.

Olá pessoal! Foi publicada uma notícia no Portal da Sefaz do Paraná informando que no dia 16/12/2023, haverá uma paralisação programada no sistema de banco de dados da SEFA para manutenção de servidores. O paralisação iniciara às 09h00 e tem previsão de término às 16h00. Durante este período, ficarão indisponíveis os serviços de Autorização de CT-e e os contribuintes precisarão fazer o envio usando as formas de contingência previstas na legislação. Um agradecimento ao membro @Rafael - ATS Informática por compartilhar a notícia em nossa comunidade do Discord.

Boa tarde. Para que a alteração tenha efeito você precisa seguir os passos especificados neste tópico.

Boa tarde! Não tem um método Assinar. Isso foi automatizado pelo novo componente, se o provedor requerer que seja assinado o arquivo, o componente vai assinar ele para você, se não precisar, ele não vai assinar.

Olá pessoal! Caso estejam recebendo uma rejeição estranha ao tentar realizar um cancelamento, no Portal da Nota Fiscal Eletrônica consta o seguinte aviso: Um agradecimento aos membros da comunidade que chamaram atenção para o aviso no canal #sefaz em nosso Discord.

Bom dia pessoal. No dia 12/12/2023, por volta das 07h50, recebemos em nossa comunidade do Discord relatos de membros que conseguiram realizar a manifestação.

Olá Pessoal, Parece meio contraditório, termos nessa nova versão da NT a seguinte informação: Inclusão da Obrigatoriedade do cBenef para Santa Catarina e depois na tabela das UF que implementaram algumas regras validação e outras não. Já Santa Catarina consta que não vai implementar as regras. Não é muito estranho? Estranho é mas vamos entender isso. A tag cBenef conforme consta no Manual da NFe que contem o layout diz que a tag é opcional, portanto essa informação poderá ou não constar no XML. O Estado de Santa Cataria através de sua legislação própria, vai rejeitar notas que não contenha a tag, ou seja, para Santa Catarina a tag passa a ser obrigatória, sendo assim devemos informar o cBenef do Item. Por outro lado essa informação não vai ser validada. Isso não quer dizer que podemos informar um código de beneficio qualquer (aleatório), pois Santa Catarina poderá mudar de ideia e implementar as regras e passar a validar.

Olá pessoal. Foi publicado no dia 12/12/2023 a versão 1.54 da Nota Técnica 2019/001. Vamos a um resumo das novas alterações: Atualização de informações: As regras N12-85, N12-86 e N12-94, que validam o CST e o Código do Benefício Fiscal (cBenef) tiveram a informação atualizada na NT para o Distrito Federal, alterando a data de implantação em produção para 04/09/2023. As regras N12-85, N12-86 e N12-94 que validam o CST e o cBenef e as regras N12-90 e N12-97 que validam as informações de ICMS Desonerado e diferimento tiveram a informação atualizada na NT para o estado de Goiás, alterando a data de implantação em produção para 01/07/2023. Nova regra de validação Adiciona a regra I08-171 que para validar e rejeitar NF-e (modelo 55) com os CFOPs de aquisição ou prestação de serviços 1933, 2933, 5933 e 6933. A nova regra passará a ser validade pela Sefaz seguindo o cronograma: Implantação em homologação: 12/01/2024 Implantação em produção: 01/04/2024 Inclusão da obrigatoriedade do cBenef para SC conforme legislação interna do estado. A tabela com as unidades federativas que implementam as regras de validação N12-85, N12-86, N12-90, N12-94, N112-97 e N12-98 que são opcionais a critério da UF, foi atualizada incluindo Santa Catarina.

Boa noite, Para baixa do boleto você deve utilizar tpBaixa ../trunk2/Fontes/ACBrBoleto/WS/ACBrBoletoW_BancoBrasil_API.pas procedure TBoletoW_BancoBrasil_API.DefinirURL; var DevAPP, ID, NConvenio : String; begin FPURL := IfThen(Boleto.Configuracoes.WebService.Ambiente = taProducao,C_URL, C_URL_HOM); DevAPP := '?gw-dev-app-key='+Boleto.Cedente.CedenteWS.KeyUser; if ATitulo <> nil then ID := ATitulo.ACBrBoleto.Banco.MontarCampoNossoNumero(ATitulo); NConvenio := OnlyNumber(Boleto.Cedente.Convenio); case Boleto.Configuracoes.WebService.Operacao of tpInclui : FPURL := FPURL + '/boletos' + DevAPP; tpConsulta : FPURL := FPURL + '/boletos' + DevAPP + '&' + DefinirParametros; tpAltera : FPURL := FPURL + '/boletos/'+ ID + DevAPP; tpConsultaDetalhe : FPURL := FPURL + '/boletos/'+ ID + DevAPP + '&numeroConvenio='+ NConvenio; tpBaixa : FPURL := FPURL + '/boletos/'+ ID + '/baixar'+DevAPP; tpPIXCriar : FPURL := FPURL + '/boletos/'+ ID + '/gerar-pix' + DevAPP; tpPIXCancelar : FPURL := FPURL + '/boletos/'+ ID + '/cancelar-pix' + DevAPP; tpPIXConsultar : FPURL := FPURL + '/boletos/'+ ID + '/pix' + DevAPP + '&numeroConvenio='+ NConvenio; end; end;

Resolvido, foi erro aqui de configuração Faltava o código da Loja e Terminal, só pra deixar registrado o que era o erro.

Olá, Sabemos que muitos que passam a utilizar a ACBrLib sentem a necessidade de implementar as mesmas por API, para isso temos um exemplo em .NET onde poder ser realizado testes com a lib NFe e Boleto. Essa API não deve ser utilizada como aplicação final, pois implementa apenas um serviço de cada biblioteca, com objetivo de retornar o PDF do documento gerado, mas pode servir como referencia de como implementar a sua API com os serviços que necessita a partir das bibliotecas do ACBr. É importante ressaltar que o uso de API junto à lib deve ser ponderado, se existe a real necessidade de uso por API, pois implementando as bibliotecas de forma a serem utilizadas diretamente pela aplicação local, o seu uso será mais fácil e performático. O uso de APIs pode ser utilizados para aplicações totalmente WEB. Já para aplicações Desktop, como por exemplo um PDV, opte por utilizar as libs de forma local junto ao executável da aplicação. Segue abaixo a apresentação de como configurar e testar o exemplo ACBrAPI do repositório ACBr: Link do aplicativo Demo no repositório SVN: http://svn.code.sf.net/p/acbr/code/trunk2/Projetos/ACBrLib/Demos/C%23/ACBr.API/ Link Downloads das libs (Versão Demo):