Painel de líderes

Olá pessoal, Recebemos nas últimas semanas muitos relatos sobre problemas com emissão de NF-e ou NFC-e aparecendo uma das seguintes mensagens: "815-Rejeição: Erro não catalogado (código de status não localizado: 815)" "816-Rejeição: Erro não catalogado (código de status não localizado: 816)" Outra possibilidade são essas mensagens aparecerem como deveriam que é: 815 - Rejeição: Valor do ICMS Interestadual para UF de Destino difere do calculado [nItem: 999] (Valor Informado: XXX, Valor Calculado:XXX) 816 - Rejeição: Valor do ICMS Interestadual para UF do Remetente difere do calculado [nItem: 999] (Valor Informado: XXX, Valor Calculado:XXX) Queremos explicar o motivo dessa rejeição e como você pode fazer sua nota de um jeito aceitável. Vamos por partes.... O que sabemos sobre o problema? Não conseguimos ainda retorno de todas as SEF onde ocorreu a mensagem estar como erro não catalogado sobre o motivo de estar assim... Mas provavelmente é alguma atualização que foi feita de forma incompleta nos servidores da SEFAZ. (EDIT: Você pode ver nesse mesmo tópico nos posts seguintes, logo abaixo, os retornos que tivemos). Mas sabemos que a rejeição é porque os valores para o ICMS interestadual não estão batendo com o que a UF espera. Realmente, os cálculos mudaram com a NT 2020.005, mas teoricamente essas regras deveriam ter entrado em vigor em 01/09/2021 e não agora. Se você estiver recebendo a mensagem completa com o "valor informado" e o "valor calculado", fica mais fácil você avaliar as opções e saber o que o webservice está esperando. O detalhe é que pelos relatos que estamos recebendo, as UFs estão calculando de maneira diferente. Elas calculam diferentes dependendo do ambiente que você está (homologação ou produção), diferentes uma das outras (como é o caso de MG e BA), diferentes dependendo da situação (como está na NT 2020.005), mas também até diferente da forma que está na Nota técnica. Para piorar, se você não recebe a mensagem completa, não dá para saber qual o valor que a SEFAZ esperaria no seu caso. Ainda não recebemos confirmação sobre se isso vai ser alterado logo... mas manteremos todos informados (EDIT: Atualizações podem estar nesse mesmo tópico, em posts abaixo). O que causa a rejeição? Como dito, essa rejeição é causada porque o cálculo dos valores estão diferentes do esperado. Esses cálculos estão definidos na NT 2020/005, cuja última versão é a 1.20. Como essa NT foi atualizada esse ano, parece que o MOC ainda não consta as alterações. O melhor é verificar essa NT e o MOC. Essas são as rejeições conforme a NT, veja: Então em teoria seria apenas seguir esses cálculos que o seu problema seria resolvido. Continuo com problema... Como resolver? Em primeiro lugar queremos deixar bem claro que não somos uma consultoria contábil e que ainda estamos levantando mais informações. O objetivo desse tópico é ajudar a todos por dar alguma explicação e direção, de modo que ninguém fique perdido e possa consultar o contador dos clientes entendendo o problema. Isso evita perda de tempo e mal entendidos. Então lembre-se de consultar o contador de confiança e/ou o contador do cliente ao definir os cálculos de impostos. IMPORTANTE: Os valores para os cálculos podem depender da UF de origem e da UF de destino (por exemplo sudeste para nordeste, SP para BA, etc...). Essa informação é muito importante porque você pode receber rejeição para uma UF de destino, mas não para outras... Nesse caso, reveja a sistemática do cálculo nesse outro artigo aqui. Dito isso: Está havendo uma inconsistência nos relatos que temos recebido (como foi dito acima), assim, vamos passar o que alguns tem feito para resolver os problemas. 1) Rever a fórmula do cálculo. As fórmulas mudaram com as novas versões da NT 2020.005. Então a possibilidade de seu software estar fazendo o cálculo de forma desatualizada é real. As fórmulas novas são: vICMSUFDest = ((vBCUFDest * pICMSUFDest) - (vBC * pICMSInter)) * pICMSInterPart (explicação nesse link) vICMSUFRemet = ((vBCUFDest * pICMSUFDest) - (vBC * pICMSInter)) – vICMSUFDest (explicação nesse link) Essa é a melhor opção. Se isso funcionar significa que foi apenas uma atualização normal e já esperada... IMPORTANTE: A NT 2020.005 explica que benefícios fiscais no destino devem ser incluídos no valor da base de cálculo (vBCUFDest) Consulte o contador do seu cliente sobre quais produtos podem cair nessa situação, de forma a incluir esses valores no cálculo. Isso pode afetar o imposto que seu cliente paga. 2) Use as fórmulas antigas Parece que alguns webservices não foram atualizados e ainda estão usando as fórmulas antigas. Nesse caso, as fórmulas antigas são: vICMSUFDest = vBCUFDest * (pICMSUFDest - pICMSInter) * pICMSInterPart vICMSUFRemet = (vBCUFDest * (pICMSUFDest - pICMSInter)) – vICMSUFDest Note que eu não destaquei essas fórmulas, porque elas estão desatualizadas. Assim, se algum webservice estiver calculando desta maneira logo vai ter uma atualização e vai parar de aceitar esse cálculo novamente... (pelo menos em teoria...) Se testar essa opção e ela funcionar, sugerimos entrar em contato com a SEFAZ para esclarecer o motivo deles não terem atualizado ainda. 3) Zere os valores das tags do grupo ICMSUFDest deixando apenas os valores pICMSInter e pICMSInterPart preenchidos (veja também o ponto 5) Essa é uma opção que parece funcionar e recebemos relatos por meio do nosso discord por meio de um usuário ACBr PRO. Parece que pra consumidores que não são contribuintes do ICMS e são pessoa física, essa seria a única solução em alguns casos. Mas, não temos como dizer se está correta ou não. Consulte seu contador. Exemplo de como ficaria no XML nesse caso: -<ICMSUFDest> <vBCUFDest>0.00</vBCUFDest> <vBCFCPUFDest>0.00</vBCFCPUFDest> <pFCPUFDest>0.0000</pFCPUFDest> <pICMSUFDest>18.0000</pICMSUFDest> <pICMSInter>7.00</pICMSInter> <pICMSInterPart>100.0000</pICMSInterPart> <vFCPUFDest>0.00</vFCPUFDest> <vICMSUFDest>0.00</vICMSUFDest> <vICMSUFRemet>0.00</vICMSUFRemet> </ICMSUFDest> 4) A operação não envolve ICMS interestadual Verifique se a operação realmente envolve o cálculo de DIFAL. Por exemplo, se o consumidor é final e faz a compra presencial, mesmo que ele seja de outro estado, não houve operação interestadual. 5) A empresa é Simples Nacional e não deveria recolher o ICMS Interestadual (veja também ponto 3) Alguns usuários reportaram que o Supremo Tribunal Federal suspendeu a aplicação das novas regras de partilha do ICMS nas operações e prestações interestaduais destinadas a consumidor final não contribuinte do imposto, quando realizadas por optantes pelo Simples Nacional, por meio da Ação Direta de Inconstitucionalidade (ADI) 5.464/2016. Isso pode estar sendo levado em conta e por isso a rejeição em alguns casos. Outras informações importantes Os cálculos para ICMS interestadual (DIFAL) no momento são um pouco complicados mesmo. Em especial porque existem maneiras diferentes de calcular. Mas é possível entender com um pouco de paciência. Existem o chamado cálculo DIFAL por fora (ou cálculo com base única) e cálculo DIFAL por dentro (ou cálculo com base dupla). Encontrei esse link sobre o assunto e parece bem completo... Se você ver no link, esse cálculo muda de acordo com as UFs. Algumas UFs tem em sua legislação estadual alguma orientação sobre o assunto (como por exemplo essa de MG). Por outro lado, essas orientações talvez precisem ser adaptadas, incluindo um valor a mais ou a menos na base de cálculo por exemplo... Talvez uma consulta ao Fale conosco de sua SEFAZ ajude a resolver a dúvida. Temos certeza que essas informações são úteis, mas nos comprometemos a assim que tivermos mais informações voltar com novidades para todos. Mais uma vez queremos aproveitar a oportunidade para agradecer a todos os nossos usuários PRO pelo apoio que nos permite buscar mais informações. E queremos agradecer a todos que participam ativamente do Projeto ACBr no fórum e Discord. Bom trabalho pessoal.

Era a midas. Havia uma dll dessa lá na pasta system diferente da dll presente na pasta do sistema.

Conforme aviso publicado no portal da NFe, novamente SP encontra-se com a contingência ativada, com previsão de desativação as 10:00 de hoje (13/10/2021) Fonte: https://www.nfe.fazenda.gov.br/portal/principal.aspx

Atualizando um projeto pro Delphi 11 Alexandria me deparei com este erro e olhando os fontes do ACBrCTeDACTEFR.pas, necessita de colocar: frxPDFExport.Compressed := False; Adiconei a linha 1283 no fonte em anexo. https://quality.embarcadero.com/projects/RSP/issues/RSP-35516 ACBrCTeDACTEFR.pas

NF-e Ceará: Migração para Sefaz Virtual do Rio Grande do Sul A Secretaria da Fazenda do Estado do Ceará (Sefaz-CE) informa que, a partir do dia 10 de janeiro de 2022, as Notas Fiscais Eletrônicas (NF-e) emitidas por contribuintes do Ceará passarão a ser autorizadas por meio da Sefaz Virtual do Rio Grande do Sul (SVRS). Com a mudança no ambiente de autorização dos documentos fiscais eletrônicos modelo 55 no Ceará, os contribuintes obrigados à emissão de NF-e devem fazer a adaptação no sistema emissor, já que o ambiente antigo de autorização será desativado e não poderá mais ser utilizado. Para mais informações, o contribuinte pode entrar em contato pelo e-mail: [email protected] e ou pelo telefone (85) 3108-2200. Fonte:https://www.sefaz.ce.gov.br/2021/10/08/nf-e-migracao-para-sefaz-virtual-do-rio-grande-do-sul/

Pessoal estou com a ultima versão do ACBR atualizada e num cliente novo fiz exportação nos 3 formatos modUrano, modUranoS e modUranoURF32 Nenhum deles o aplicativo da Urano consegue fazer a leitura tem alguma outra configuração que deixei passar além de escolher certo o tipo da balança. ou o ACBR não suporta a carga para essa balança ? o Layout é esse em anexo. Configurações_txt - Topmax SS R1.0 geral.pdf Produtos_txt - Topmax SS R1.1 geral.pdf

Boa tarde Tiago, Favor atualizar os fontes e faça novos testes.

Boa tarde Douglas, Favor atualizar os fontes e faça novos testes.

Ok, Muito Obrigado, vou instalar hoje a noite

O problema estava na etiqueta. Como é um formato especifico, o cliente mandou confeccionar para testar. A impressora não estava reconhecendo a divisão das etiquetas, considerando uma etiqueta continua. Foi necessário fazer uma modificação ao confeccionar a etiqueta, dando mais destaque ao GAP. Ai o problema resolveu.

Boa tarde. Criamos em nosso backlog a TK-2006 para analise do caso. At.

Obrigado pela contribuição, em breve será validada para possível inclusão ao svn TK-2005

Entendi. Estou, aos poucos, encontrando o que preciso e adaptando o código. Agradeço pela sua atenção. Muto obrigado.

Bom dia Tiago, Favor atualizar os fontes e faça novos testes.

Bom dia. Com relação ao problema com o sacado ocorreu que ao enviar uma remessa onde o tipo de inscrição da empresa era CNPJ, como nas duas posições estão sendo preenchidas com o a mesma variável, quando o sacado era CPF, mudava também o tipo de inscrição do sacador. Sendo que o tipo do inscrição do sacador deve permanecer a mesma em todos os registros. Em relação ao tamanho máximo do nosso número foi apenas uma observação. Estava analisando o arquivo para verificar o motivo da inconsistência acima e vi essa propriedade. Não tive problemas a respeito.

Boa tarde, Aqui também utilizamos algumas impressoras bluetooth para imprimir nfc-e. Foi utilizado o código abaixo para conseguir imprimir. ACBrNFe1.DANFE := ACBrNFeDANFCeFortes1; ACBrNFeDANFCeFortes1.LarguraBobina := 280; ACBrNFeDANFCeFortes1.MargemDireita := 0.4; ACBrNFeDANFCeFortes1.MargemEsquerda := 0.6; ACBrNFeDANFCeFortes1.EspacoFinal := 0; ACBrNFeDANFCeFortes1.MargemSuperior := 0.4; ACBrNFeDANFCeFortes1.MargemInferior := 0.01; ACBrNFeDANFCeFortes1.ImprimeEmDuasLinhas := true; ACBrNFeDANFCeFortes1.AlterarEscalaPadrao := true; Qual é largura do papel?

Em contato com o suporte da DIMEP, o mesmo me posicionou que entre os dias 13 e 20 de outubro, irão homologar a nova versão do sistema junto ao SEFAZ. E que retornarão a informação se tudo der certo junto à SEFAZ. Assim que eu tiver alguma notícia a mais, retorno aqui. Grato a todos.

Outra coisa que pode afetar é a configuração de espaçamento entre linhas, se informado 0 usa a configuração padrão da impressora, que no caso da Bematech parece ser muito grande. ACBrPosPrinter.EspacoEntreLinhas := xx; xx sendo um valor entre 20 e 40 pra ficar bom.

Boa tarde, Obrigado.

Bom dia! Fechando o tópico por falta de resposta do autor do mesmo. Para nova dúvida, abra novo tópico.

Para o meu caso também resolveu a sua dica das DLL's 32. Grato

Eu tive um problema parecido com um cliente que usa GMail quando ia emitir a NFe e enviar o e-mail logo após a emissão. Não sei se isso vai te ajudar, mas vou dizer o que eu fiz para resolver meu problema Usei as propriedades SetSSL := True e SetTLS := True e também coloquei as DLLS versão x32 da pasta LibXml2 e as 3 dlls da pasta OpenSSL versão 1.0.2.13 dentro da pasta do meu executável. Também ativei as configurações do Gmail para aplicativos menos seguros.