Diego Foliene

Bom dia! Conforme foi orientado, precisaria conferir os valores nos XMLs gerados para correta apuração. Das informações que disponibilizou, consultando a chave de acesso da NFe referenciada no arquivo INI que disponibilizou, não tenho acesso a consulta completa, mas da para ver que constam 6 itens na nota. O valor total da nota no arquivo INI não coincide com o valor total que da para ver nos 6 itens(na ini está maior). O valor unitário do item, também não coincide com o valor unitário dos itens da nota referenciada. Isso está correto?

Olá pessoal! Foi publicado no dia 31/07/2024 a Nota Técnica 2024/001 abrangendo múltiplos DFes com o objetivo de adequá-los as modificações propostas pela Reforma Tributária. Introdução O PLP 68 estabelece que os estados, o distrito federal e os municípios devem padronizar seus sistemas autorizadores de documentos fiscais para permitir aos contribuintes que informem os dados relativos ao Imposto sobre Bens e Serviços (IBS), Contribuição sobre Bens e Serviços (CBS) e Imposto Seletivo (IS). Esta nota técnica, a princípio, trata em conjunto os seguintes documentos: Conhecimento de Transporte Eletrônico (modelo 57). Conhecimento de Transporte Eletrônico para Outros Serviços (modelo 67). Bilhete de Passagem Eletrônico (modelo 63). Nota Fiscal de Energia Elétrica (modelo 66). Nota Fiscal Fatura de Serviço de Comunicação Eletrônica (modelo 62). A versão final desta NT vai gerar NTs específicas para cada documento acima referido. A Nota Fiscal Eletrônica (modelo 55) junto da Nota Fiscal de Consumidor Eletrônica (modelo 65) vão ser tratadas em NT específica. Alterações Alteração do leiaute dos DFe Adiciona grupo para informação do IBS/CBS Adiciona no layout dos documentos mencionados o Grupo de Informações da Tributação IBS/CBS (IBSCBS) que fará parte do grupo imposto/imp, deverá ser adicionado em cada item nos documentos que apresentarem itens (NF3e/NFCom) ou diretamente no corpo do documento caso ele não possua itens (CTe/BPe). O IBSCBS é composto por um elemento para informação do Código da Situação Tributária do IBS/CBS (CST), um elemento para informação do Código da Classificação Tributária do IBS/CBS (cClassTrib) e um Grupo para as Informações Específicas do IBS/CBS (gIBSCBS), este último possuindo seus próprios elementos e subgrupos. Considerando apenas os elementos, o grupo IBSCBS adiciona um total de 48 novas informações a serem preenchidas no arquivo. O arquivo DFeTiposBasicos_v1.00.xsd adicionado ao pacote de schemas que compõe o DFe trás os referidos campos. Adiciona grupo para totalização do IBS/CBS Para a NF3e, NFCom e BPe TM também deverá ser adicionado no grupo total do respectivo documento um grupo para totalizar as informações do IBS/CBS (IBSCBSTot). Para CTe, CTe Simplificado, CTeOS e BPe não será criado. Adiciona campo para totalização do documento acrescida do IBS/CBS Na NF3e, NFCom e BPe TM adiciona no grupo total o campo vTotDFe que deverá receber o valor correspondente a (vNF/vTPrest + total do IBS + total da CBS). No CTe, CTe Simplificado, CTe OS e BPe a referida Tag será adicionada no grupo imp. Código Situação Tributária e Classificação da Tributação Será disponibilizado no portal dos respectivos documentos tabelas relacionando o CST x cClassTrib para o correto preenchimento das informações. Regras de Validação Esta nota técnica adiciona regras de validação que verificam dentre outras coisas se: Foi informado CST correto para o IBS/CBS Foi informado classificação tributária correta para o IBS/CBS. O grupo IBS/CBS foi preenchido quando não deveria. O grupo IBS/CBS não foi preenchido quando deveria. Os valores informados nos campos foram preenchidos corretamente. Os valores referentes a crédito presumido foram preenchidos nas situações em que são obrigatórios. Os valores referentes a desoneração foram preenchidos nas situações em que são obrigatórios. Os totalizadores correspondem a soma dos valores individuais. Datas Implantação Homologação: 01/09/2025 Implantação Produção: 31/10/2025 Vale ressaltar que como as discussões referentes a reforma tributária ainda estão em curso, a NT pode ser ajustada ao longo do processo. E como fica o ACBr? Serão necessários ajustes nos fontes do ACBr e novas compilações do Monitor e da Lib. Foi criada a #TK-5814 em nosso backlog para alteração dos fontes. Vale ressaltar que a NT é recente e existe um período expressivo até que seja liberada a homologação. Leia a NT na íntegra AQUI.

Olá pessoal! Foi disponibilizado no 17/07/2024 o Ato Diat Nº035/2024 que discorre sobre a obrigatoriedade dos campos relacionados ao código de benefício fiscal e ao crédito presumido nos documentos modelo 55 e 65 (NF-e e NFC-e) emitidos para a Sefaz de Santa Catarina. O artigo 1º estabelece de forma geral que: Quando houver isenção, redução de base de cálculo, diferimento, não incidência ou suspensão da exigibilidade do imposto para um produto, o campo do Código do Benefício Fiscal (cBenef) deve ser preenchido. Quando houver crédito presumido para o item, os campos Código de Benefício Fiscal de Crédito Presumido na UF aplicado item (cCredPresumido), Percentual de Crédito Presumido (pCredPresumido) e Valor do Crédito Presumido (vCredPresumido) devem ser preenchidos. Quando houver redução de base de cálculo, na hipótese de a operação estar submetida cumulativamente ao diferimento total ou parcial do imposto devido pelo sujeito passivo substituído o campo Código de Benefício Fiscal na UF aplicado ao item quando houver RBC (cBenefRBC) deve ser preenchido. A obrigatoriedade do preenchimento destas informações se aplica também para: os contribuintes que remetam produtos e mercadorias alcançados por incentivos fiscais, não incidência tributária, diferimento e suspensão da exigibilidade do imposto, em decorrência de regime especial ou benefício fiscal concedido exclusivamente ao destinatário da mercadoria ou produto estejam obrigados à emissão da contra nota, relativamente às entradas de mercadorias e produtos alcançados por incentivos fiscais, não incidência tributária, diferimento e suspensão da exigibilidade do imposto. Não se aplica a obrigatoriedade do preenchimento destas informações quando: NF-e ou NFC-e de devolução (finNFe= 4) e de ajuste (finNFe = 3), independentemente do tipo da operação. O artigo 2º estabelece de forma geral que deverá ser usado CST correspondente ao cBenef conforme tabela disponibilizada no portal da Sefaz de Santa Catarina. O artigo 3º estabelece de forma geral que os campos devem ser preenchidos no documento fiscal conforme layout do documento. O artigo 4º estabelece que o preenchimento destes campos vale tanto para o modelo 55 (NF-e) quanto para o modelo 65 (NFC-e). O artigo 5º estabelece que as informações devem ser preenchidas obrigatoriamente a partir de 01/10/2024. Por fim, o artigo 6º revoga o Ato Diat Nº 79/2022 que obrigava apenas o cBenef. Vale lembrar. A tabela de cBenef x CST para o estado de Santa Catarina pode ser encontrada em https://www.sef.sc.gov.br/servicos/servico/88/SPED_Fiscal Os campos de crédito presumido foram adicionados no layout da NF-e/NFC-e na Nota Técnica 2019/001 a partir de sua versão 1.60. Estamos atualmente na versão 1.62 desta NT, com as modificações já implementadas no ambiente de produção. O preenchimento destas propriedades pode ser feito da seguinte maneira caso utilize componente nativo: var NotaF: NotaFiscal; Produto: TDetCollectionItem; CredPresumido: TCredPresumidoCollectionItem; begin NotaF := ACBrNFe1.NotasFiscais.Add; //... Produto := NotaF.NFe.Det.New; //... Produto.Prod.cBenef := ?; Produto.Imposto.ICMS.cBenefRBC := ?; CredPresumido := Produto.Prod.CredPresumido.New; CredPresumido.cCredPresumido := ?; CredPresumido.pCredPresumido := ?; CredPresumido.vCredPresumido := ?; end; Caso utilize Lib ou Monitor: [ProdutoXX1] cBenef=? [gCredXX11] cCredPresumido=? pCredPresumido=? vCredPresumido=? [ICMSXX1] cBenefRBC=?

Boa tarde. Foi enviado ao SVN uma alteração adicionando a leitura do campo ValorTotalNotaFiscal na seção [Valores] do arquivo. Caso não seja informado, vai assumir ValorServicos - DescontoCondicionado - DescontoIncondicionado. Vale ressaltar, que o método de impressão espera receber um XML de uma NFSe, portanto, ao carregar um XML de RPS ou carregar um RPS via INI e mandar imprimir, é esperado que nem todas as informações sejam exibidas. Versões do Monitor e da Lib compiladas após 01/08/2024 deverão realizar a leitura de ValorTotalNotaFiscal.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Olá pessoal! Foi publicado no dia 30/07/2024, no portal SPED, comunicado informando sobre a versão 10.0.13 do programa ECF utilizado para transmitir arquivo do ano-calendário 2023 e situações especiais de 2024(item 10). A nova versão trás as seguintes atualizações: Fonte: http://sped.rfb.gov.br/pagina/show/7494

Foi publicada a versão 24.2.A das tabelas fornecidas pelo IBPT, as quais já se encontram também em nosso svn. As novas tabelas tem a vigência de 20/07/2024 até 31/08/2024 Para cumprimento da Lei 12.741/12, também conhecida como "De Olho no Imposto" não se esqueça de realizar a atualização de seus clientes. Fonte: De Olho no Imposto

Antes de mais nada é preciso entender o que é LCR. Como todos sabem, quando enviamos um documento fiscal para o web service da Sefaz, o mesmo deve ter sido assinado por um certificado digital que também é utilizado na comunicação propriamente dita para garantir a segurança e a veracidade dessa troca de informações entre o emissor e o servidor de destino. Este certificado digital usado pelo emissor, possui uma data de início e fim de validade, então você pode ter um certificado que ainda não está valido ou com validade expirada, tornando o certificado inválido. No entanto, as vezes, por algum outro fator, como por exemplo, extravio do certificado digital ou alteração do contrato social, pode ser que o certificado deixe de ser válido mesmo ainda estando dentro do período de validade vigente. Quando isso acontece o certificado é adicionada na Lista de Certificados Revogados (LCR) para dizer a todos que a consultarem que ele não é mais válido. Entendendo a rejeição. Agora que entendemos o que é LCR, vamos voltar a rejeição: Vejam que coloquei a palavra "acesso" em destaque. Isso porque quem a faz a consulta na LCR é o servidor que está recebendo a comunicação, ou seja, é o servidor de destino quem consulta a LCR, o que significa que a rejeição 296 está nos dizendo que o servidor da Sefaz não conseguiu acessar a LCR para consultar se o certificado que está comunicando é válido. E como eu resolvo? Infelizmente, este é um erro em que não se pode fazer muita coisa do lado da software house, pois é um erro que ocorreu do lado do web service da Sefaz ou do lado da própria certificadora digital. Portanto, se você está recebendo esta rejeição, o curso de ação mais indicado é: Orientar seu cliente para que ele possa entender que o problema é na Sefaz ou na certificadora digital, sendo assim, um problema externo. Abrir um Fale Conosco junto a Sefaz respectiva para deixá-los cientes do problema. Realizar novo teste após aguardar um período de tempo.

Olá pessoal! Foi enviado ao SVN na Rev-34583 a adição do novo comando SAT.ObterIniCFe. Este novo comando vai receber como parâmetro o caminho completo de um arquivo XML de um cupom fiscal ou o conteúdo do arquivo propriamente dito e devolver as informações que foram lidas pelo Monitor em um formato INI. Vejam um exemplo da estrutura de retorno: [infCFe] ID=35240600000000000000000000208790000741625864 VersaoDadosEnt=0,07 versao=0,07 versaoSB=40016 [Identificacao] cUF=35 cNF=123456 mod=59 nserieSAT=123456789 nCFe=74 dhEmi=26/07/2024 cDV=4 tpAmb=2 CNPJ=11111111111111 signAC=SGR-SAT SISTEMA DE GESTAO E RETAGUARDA DO SAT assinaturaQRCODE=XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXxxxxxxxxxxxxxxxxxxxx== numeroCaixa=1 [Emitente] CNPJ=11111111111111 xNome=Nome do Emitente xFant= xLgr=Logradouro do Emitente nro=1 xCpl= xBairro=Bairro do Emitente xMun=Municipio do Emitente CEP=12345678 IE=111111111111 IM=111111 cRegTrib=3 cRegTribISSQN=1 indRatISSQN=S [Destinatario] CNPJCPF=22222222222222 xNome=Nome do Destinatario [Entrega] xLgr=Endereço de Entrega nro=1 xCpl= xBairro=Bairro de Entrega xMun=Municipio de Entrega UF=SP [Produto001] cProd=1189 cEAN= xProd=OVO VERMELHO NCM=04072100 CEST= CFOP=5102 uCom=DZ qCom=510 vUnCom=2,7 vProd=1377 indRegra=A vDesc=0 vOutro=0 vItem=1370 vRatDesc=7 vRatAcr=0 cANP=0 vItem12741=137 infAdProd=Teste de Produto [ObsFisco001] xCampoDet= xTextoDet= xCampo=04.04.05.04 xTexto=Comete crime quem sonega [ICMS001] orig=0 CST= CSOSN=500 pICMS=0 vICMS=0 [PIS001] CST=01 vBC=0 pPIS=0 vPIS=0 qBCProd=0 vAliqProd=0 [PISST001] vBc=0 pPis=0 qBCProd=0 vAliqProd=0 vPIS=0 [COFINS001] CST=01 vBC=0 pCOFINS=0 vCOFINS=0 vAliqProd=0 qBCProd=0 [COFINSST001] vBC=0 pCOFINS=0 qBCProd=0 vAliqProd=0 vCOFINS=0 [ISSQN001] vDeducISSQN=0 vBC=0 vAliq=0 vISSQN=0 cMunFG=0 cListServ= cServTribMun= cNatOp=0 indIncFisc=2 [Total] vICMS=0 vProd=1377 vDesc=0 vPIS=0 vCOFINS=0 vPISST=0 vCOFINSST=0 vOutro=0 vCFe=1370 [DescAcrEntr] vDescSubtot=7 vAcresSubtot=0 vCFeLei12741=137 [ISSQNtot] vBC=0 vISS=0 vPIS=0 vCOFINS=0 vPISST=0 vCOFINSST=0 [pag001] cMP=01 vMP=1400 cAdmC=0 cAut= vTroco=30 [DadosAdicionais] infCpl=Teste emissao CFe/SAT

Foi gerada uma nova compilação da Lib. Por favor, queira atualizar e realizar novo teste.

Boa tarde! Apenas dando um retorno. Houveram modificações relacionadas a tratativa de codificação do retorno no dia 19/07(Rev-34491) Depois que relatou ainda estar com problema, confirmei com o responsável que está atuando na #TK-5632-1 que foi criada para ver essa questão e ele me informou que ainda faltava disponibilizar mais uma alteração. Modificação essa que foi enviada ao SVN no dia 25/07.(Rev-34567) Esta última não foi incluída na compilação da Lib, o que pode explicar você ainda estar tendo problemas. A compilação da Lib ocorre toda terça-feira na parte da manhã, mas eu solicitei uma nova compilação pontual. Assim que houver nova versão disponível, reporto aqui para que você possa atualizar.

Boa tarde! Conferindo aqui, de acordo com o log, a última alteração foi enviada no dia 19/07 e também houveram modificações no dia 24/06 com a mensagem do commit: Mas vou confirmar junto aos responsáveis.

Bom dia! Além das informações que o @antonio.carloslhe pediu. A ACbrLibHandle é utilizada na versão Multi Thread da Lib. Esta é versão que está utilizando? Na hora de distribuir a dll, você pegou ela de ACBrLibNFe-0.4.6.298\bin\MT\.... e se estiver usando o exemplo está usando o que tem MT no nome?

Bom dia @LeonardoRocha. Conferi junto aos responsáveis que estão atuando na tarefa. Foram enviadas modificações no componente nativo que consideram o retorno como ANSI e fazem a conversão para UTF8 para o provedor IPM. A nova versão da Lib que foi disponibilizada deve englobar a referida alteração. Por favor, queira atualizar para que possa realizar novo teste e reportar qualquer problema.

Olá pessoal! Foi publicado no dia 23/07/2024, no portal SPED, comunicado informando sobre a versão 10.0.10 do programa ECF utilizado para transmitir arquivo do ano-calendário 2023 e situações especiais de 2024(item 10). A nova versão trás as seguintes atualizações: Fonte: http://sped.rfb.gov.br/pagina/show/7488

Olá pessoal! Foi publicado uma notícia informando que a Secretaria do Estado da Fazenda de Santa Catarina resolveu interromper o processo de implementação do Dispositivo Autorizador Fiscal(DAF). Iniciado em 2018 e com a última movimentação do assunto em 2023, o DAF era um equipamento que viria a ser adotado pela UF nas vendas no varejo visando fornecer ao fisco um maior controle sobre os documentos emitidos principalmente em contingência. No entanto, após novo levantamento de informações por parte do fisco que indicou que o volume de documentos emitidos em contingência é pouco expressivo e que existem também outras alternativas para controle. Essas novas informações somadas ao objetivo de reduzir a burocracia na emissão de documentos fizeram com que a Diretoria de Administração Tributária (DIAT) da Fazenda concluíssem que o modelo definitivo de controle da emissão e autorização das NFC-e em Santa Catarina deve continuar usando os softwares emissores já existentes. Leia a notícia na íntegra AQUI.

Bom dia! Ainda não. Dando mais detalhes sobre o seu caso: O problema é que o Web Service do Provedor está devolvendo a resposta no formato ANSI e a leitura do retorno espera receber um arquivo codificado em UTF-8. A função que mencionei anteriormente é uma função que foi criada para tentar identificar qual é o encoding de uma string para que a Lib possa decidir se vai aplicar a conversão ou não. No entanto, depois de pesquisa e também testes com a referida função, viu se que não é possível determinar com 100% de precisão a codificação de um arquivo. Esta sendo analisado agora se será feita a conversão de ANSI para UTF-8 em todos os casos para este provedor ou se outro curso de ação deverá ser tomado. Entendo que esteja com problemas na emissão. Vou informar aos consultores que estão atuando que você pediu um status da situação.

Olá pessoal! Foi enviado ao SVN na Rev-34473 uma alteração que muda a lógica de geração dos campos quantidade tributada (qBCMono), quantidade tributada sujeita a retenção (qBCMonoReten) e quantidade tributada retida anteriormente (qBCMonoRet). O que mudou? Nas rotinas de geração do arquivo XML, o parâmetro que equivale ao número de ocorrências dos respectivos campos foi alterado de 0 para 1. Isso faz com que esses campos sempre sejam criados, independentemente de haver valor informado ou não na propriedade. Preenchendo com zeros quando valor não for atribuído. Por que mudou? Originalmente os campos foram adicionados na rotina de criação do XML com o parâmetro do número de ocorrências com o valor zero conforme o layout. Isso significa que o campo é opcional e nesse caso, quando o valor informado for zero ou não houver nenhum valor atribuído o campo não seja criado no XML. No entanto, apesar de o número de ocorrências ser zero, existem rejeições que obrigam o preenchimento desses campos mesmo quando o valor for zero. Um exemplo disso é a rejeição 767 cuja regra de validação é: E a mensagem de rejeição é: Por isso, entendemos que mesmo que o número de ocorrências indique que o campo seja opcional, logicamente falando, faz sentido que o mesmo seja sempre inserido. Para que a modificação tenha efeito, é necessário atualizar os fontes e reinstalar o ACBr. Para aqueles que utilizam ACBrMonitor ou ACBrLib, as versões compiladas após o dia 17/07/2024.

Olá pessoal! Conferindo no portal Sobre o SAT, consta um aviso informando que no dia 23/07/2024 será realizada uma manutenção na autoridade certificadora(AC) da Sefaz entre às 03h00 e às 10h00. Durante este período a orientação é de que não seja efetuada a ativação de equipamentos SAT e no caso de falhas, não seja alterado o código de ativação. Caso tenham problemas na renovação de certificados com o AC-SAT, a orientação é de que desliguem o equipamento e voltem a ligá-lo após a conclusão da atividade.

Boa tarde! Apenas confirmando, em sua primeira postagem, acredito que tenha ocultado os valores, mas você está preenchendo o Usuario e a Senha na seção [Email], correto? Você está colocando o endereço de e-mail do remetente no Usuario e a senha de app que foi gerada na Senha?

Bom dia! Seu caso segue em análise. Estamos testando uma função que acreditamos que possa resolver o problema. Assim que houver mais detalhes informamos aqui.

Bom dia! Apenas dando um retorno. A TK foi alocada no sprint dessa semana e estamos analisando o problema.

Obrigado por reportar. Fechando. Para novas dúvidas, criar um novo tópico.

Bom dia. Por favor, veja: