Painel de líderes

Nesta semana temos recebido relatos da comunidade de que a SEFAZ-MG tem retornado a rejeição Informada embalagem do produto a qual não deveria ocorrer. Pelo que analisamos nas Notas Técnicas, o InfProdEmb na verdade era um grupo que foi removido na versão 1.10 da NT 2021/002 e é destinado a NFF (Nota Fiscal Fácil). Entramos em contato com o Fale Conosco e assim que obtivermos retorno, postaremos aqui. Att.

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.

Entendo que o ideal, seria a implementação completa. Mas como o inter permite a geração do arquivo de remessa em formato CNAB (a documentação foi anexada acima), não seria interessante deixar disponível esta opção (ao invés de a cada atualização do repositório, ter que alterar manualmente os arquivos com as contribuições aqui enviadas)? Desta forma, poderíamos implementar já o envio de remessa nos aplicativos, reduzindo significativamente o trabalho dos clientes em ter que digitar manualmente os dados de cada boleto. O Inter hoje é uma das melhores opções para PJ para pequenas empresas, pois permite a geração de até 100 boletos sem custo.

Boa tarde Douglas, Já esta no SVN.

Referente ao código do cedente, informe no convenio e faça o teste; Referente ao Beneficiário Final é normativa da Febraban, conforme FB0061/2021, o componente está em acordo com o comunicado da Febraban FB0061/2021

complicado, cada banco com "leis" próprias, mas isso está na normativa da Febraban, neste tópico tem a normativa e os trechos extraídos dela, e os bancos precisam aceitar as normas da Febraban e atualizar as suas documentações.

me recordei desse rapaz homologando, pode ser banco desatualizado então:

Não existe papel de Pagador / Sacador Avalista, segundo FB0061/2021 é beneficiário final, todas as fichas de cobranças do componente estão no padrão da Febraban. Só falta a questão da ficha de pagamento, se conseguirem o manual para a geração, pegamos a sua contribuição avaliamos e submetemos.

Vou entrar em contato com o banco solicitando a documentação referente a " impressão por sistema próprio". Assim que tiver retorno adiciono aqui. att.

Boa tarde. Concordo com você Juliana, mas é assim os arquivos estão vindo com variação neste campo. Já argumentei que nos bancos não tem este problema. Vou usar uma propriedade lá por enquanto que ignora esta checagem. Obrigado.

Boa tarde. Está em nosso backlog, TK-2013 Att.

Boa tarde @joedbat Analisaremos melhor, mas antes precisamos entender melhor este cenário...vc consegue nos descrever como este banco opera e quem sabe por meio de um de seus clientes obter mais detalhes sobre a implementação completa (as vezes o banco se recusa a atender se não for relacionado a algum cliente deles) Att.

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

Grato pelo pronto retorno Ítalo.... deu certo agora vou para os próximos desafios

Boa Tarde, José Instalei a versão 1.4.0.59 e testei. Perfeito, leu o CTE completo. Obrigado

Olá Ítalo, Grato pelo seu breve retorno. Vou reavaliar se houve alguma mudança/alteração de layout que possa estar dando o erro aqui comigo e volto a lhe posicionar. Muito obrigado, Michel.

Bom dia Suzana, Isso esta errado: <ns4:CodigoTributacaoMunicipio>TIntegerField</ns4:CodigoTributacaoMunicipio> O conteúdo dessa tag é um numero e esta com o texto TIntegerField.

Tu diz a impressão. não foi criado o pacote ainda.

Bom dia Tiago, Verifica se não tem nenhuma unit com uma bolinha vermelha em seu ícone, caso afirmativo delete e atualize novamente os fontes. Detalhe, atualize todos os fontes de todas as pastas e reinstale o ACBr.

Certo, enviei outra NFe agora e retornou o mesmo erro. Continuarei enviando durante o dia, e assim que estiver resolvido irei postar aqui para ajudar outros da comunidade. Ótimo dia a todos Sérgio Alves Segue conteúdo do arquivo arquivo de retorno... OK: C:\ACBrMonitorPLUS\Logs\31211004156091000100550010000003241009600583-nfe.xml [Envio] CStat=833 CUF=31 DhRecbto= Msg=Rejeicao: Informada embalagem do produto NProt= NRec= TMed=0 VerAplic=14.4.28-OR3 Versao=4.00 XMotivo=Rejeicao: Informada embalagem do produto tpAmb=2

Gente acho que descobri o erro! vou testar aqui se for isso informo aqui ok!

Esse problema é real, nos leitores metrologic 700i antigos não ocorre esse problema porque ele tem um delay que não permite que o mesmo codigo seja lido 2x quase que instantaneamente, mas os ultimos leitores tanto Honeywell ou Megalan de todos os modelos fazem isso, o problema ocorre devido a má qualidade do codigo de barra da balança onde o leitor lê 2x o mesmo codigo, geralmente a segunda vez lê errado e troca os ultimos digitos e ajusta o DV, para resolver essa situação implementamos um temporizador para constrolar o tempo do registro do item atual com o item anterior que ocorrer menor que 300mllseg. impedindo assim o registro e duplicidade. não recomendamos mais uso de leitor serial!!!

Acho que o problema é na Sefaz MG... Vários usuários estão relatando problemas, e a resposta parece estar intermitente Se deseja testar a configuração das Libs no ACBr e liberação em Firewall, você poderia mudar para a UF de SP e tentar uma Consulta de Status do Serviço

Oi @Valter de Sousa - IDEASyS, sim. Coloque o código abaixo no seu .dpr que dá certinho. {$R *.res} var MutexHandle: THandle; hwind: HWND; N, D: string; begin N := ExtractFileName(ParamStr(0)); { Retira o path } D := ChangeFileExt(N, ''); { Retira a extensão } MutexHandle := CreateMutex(nil, TRUE, PChar(D)); if MutexHandle <> 0 then begin if GetLastError = ERROR_ALREADY_EXISTS then begin CloseHandle(MutexHandle); hwind := 0; repeat hwind := Windows.FindWindowEx(0, hwind, 'TApplication', 'Nome da Sua Aplicação'); until (hwind <> Application.Handle); if (hwind <> 0) then begin Windows.ShowWindow(hwind, SW_SHOWNORMAL); Windows.SetForegroundWindow(hwind); end; Halt; end end; Application.Initialize; .....

Boa tarde Italo! Nem no XML da nota inserida diretamente no site da Prefeitura tem essa TAG. Somente a TAG <IssRetido> = 1. Vou fazer contato com eles e retorno. Obrigado!

Olá Luciano, Avaliando seu código aqui... Notei que o arquivo teve o layout totalmente alterado. Além disso, ele está desatualizado. Queira por favor sempre atualizar antes de enviar e manter o mesmo layout do arquivo original. Isso facilita pra gente poder analisar. O que eu percebi no entanto é que você está utilizando um modelo para enviar diretamente para a balança. Então teria que ser o modelo modUrano ou o modUranoS. O modelo modUranoURF32 é apenas para quem utiliza o software URF32 para balanças Urano. Você pode notar que nesse tipo de arquivo, não vai caracteres de controle logo no início como está descrito na documentação que você anexou. Além disso, pode notar que que esses outros dois modelos já citados já não colocam separadores de milhares nos valores. A menos que tenha entendido algo errado, e nesse caso peço que me esclareça onde errei, não podemos enviar essa alteração, pois ela pode quebrar o funcionamento de quem utiliza o URF32...

@ricardobianchin, Você pode usar a rotina do ACBr de Validação, antes de Enviar o XML, ela faria uma validação contra os Schemas assim como esse site... Outra sugestão é validar os campos na tela de cadastro, como Telefone, CEP, Cidade, etc

Bom dia Leandro, Já esta no SVN.

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