Painel de líderes

Essa orientação de calculo se encontra no Manual Visão Geral Versão 7.03 - Página 148 Notem quem existem 2 situações de cálculos: A primeira se refere a: DE: Sul/Sudoeste (exceto ES), e - PARA: Norte/Nordeste/Centro-Oeste/ES A segunda se refere a: DE: Norte/Nordeste/Centro-Oeste/ES, ou - PARA: Sul/Sudoeste (exceto ES). Observação: Me parece que MG não esta seguindo essa sistemática de cálculo. Observação: A partir de 2019 o percentual da Partilha Destino passou a ser 100%, logo no exemplo acima temos: PARTILHA DESTINO (vICMSUFDest) = 140,00 E PARTILHA ORIGEM (vICMSUFRemet) = 0,00 Observação: A partir de 2019 o percentual da Partilha Destino passou a ser 100%, logo no exemplo abaixo temos: PARTILHA DESTINO (vICMSUFDest) = 140,00 E PARTILHA ORIGEM (vICMSUFRemet) = 0,00

Olá Pessoal, Essa rejeição ocorre quando o CST de ICMS = 00 e Valor do ICMS Interestadual para a UF do Remetente tag: <vICMSUFRemet> difere do calculo: ((vBCUFDest * pICMSUFDest) - (vBC * pICMSInter)) – vICMSUFDest Observação 1: Se o resultado do cálculo for menor que zero deverá ser informado o valor “0.00”. Observação 2: Se existir benefício fiscal de redução de base de cálculo no destino, o valor da base de cálculo no ICMS de destino (vBCUFDest) deverá ser informado considerando esse benefício. Observação 3: O valor resultante da multiplicação deve ser arredondado para um valor numérico com duas casas decimais. Considerar uma tolerância de R$ 0,01 para mais ou para menos na validação. O calculo esta em conformidade com a regra NA17-10 que se encontra na Nota Técnica 2020/005 Versão 1.20 Veja a sistemática de calculo em:

Eu fiz um teste agora, e consegui autorizar uma nota em MG. Parece que resolveram meu problema inicial, que eram as novas tags dessa NT.

Olá Pessoal, Essa rejeição ocorre quando CST de ICMS = 00 e o Valor do ICMS Interestadual para UF de Destino tag <vICMSUFDest> difere do calculo: ((vBCUFDest * pICMSUFDest) - (vBC * pICMSInter)) * pICMSInterPart Observação 1: Se o resultado do cálculo for menor que zero deverá ser informado o valor “0.00”. Observação 2: Se existir benefício fiscal no destino, o valor da base de cálculo no ICMS de destino (vBCUFDest) deverá ser informado considerando esse benefício. Observação 3: O valor resultante da multiplicação deve ser arredondado para um valor numérico com duas casas decimais. Considerar uma tolerância de R$ 0,01 para mais ou para menos na validação. O calculo esta em conformidade com a regra NA15-10 que se encontra na Nota Técnica 2020/005 Versão 1.20 Veja a sistemática de calculo em:

Pessoal estou com o seguinte problema: Na documentação o campo indResult não é obrigatório, no sistema estamos passando zero quando não queremos que o campo apareça no xml, mas, ainda sim o campo aparece no xml com o valor 1, como devemos fazer par não deixar esse campo aparecer no xml gerado? XML abaixo: <?xml version="1.0" encoding="UTF-8"?><eSocial xmlns="http://www.esocial.gov.br/schema/evt/evtMonit/vS01_00_00"><evtMonit Id="ID1652071770000002021100514461246116"><ideEvento><indRetif>2</indRetif><tpAmb>2</tpAmb><procEmi>2</procEmi><verProc>1.0</verProc></ideEvento><ideEmpregador><tpInsc>1</tpInsc><nrInsc>65207177</nrInsc></ideEmpregador><ideVinculo><cpfTrab>07426212602</cpfTrab><matricula>839</matricula></ideVinculo><exMedOcup><tpExameOcup/><aso><dtAso>2021-09-03</dtAso><resAso>1</resAso><exame><dtExm>2021-09-03</dtExm><procRealizado>295</procRealizado><ordExame>1</ordExame><indResult>1</indResult></exame><medico><nmMed>DRA. RUBIA SOUSA MACEDO</nmMed><nrCRM>86462</nrCRM><ufCRM>MG</ufCRM></medico></aso><respMonit><nmResp>DR. RICARDO AUGUSTO AFONSO RIOS</nmResp><nrCRM>50271</nrCRM><ufCRM>MG</ufCRM></respMonit></exMedOcup></evtMonit></eSocial>

Na listagem das notas tive que fazer uma pequena alteração. Original Response.XmlEnvio := '<notas>' + '<ano>' + Ano + '</ano>' + '<mes>' + Ano + '</mes>' + '<cpfcnpj>' + OnlyNumber(Emitente.CNPJ) + '</cpfcnpj>' + '<inscricao>' + OnlyNumber(Emitente.InscMun) + '</inscricao>' + '<chave>' + Emitente.WSChaveAcesso + '</chave>' + '</notas>'; Estava passando o na tag mes o ano também. Por esse motivo não estava retornando as informações corretas. Arquivo anexado corrigido e a alteração. Response.XmlEnvio := '<notas>' + '<ano>' + Ano + '</ano>' + '<mes>' + Mes + '</mes>' + '<cpfcnpj>' + OnlyNumber(Emitente.CNPJ) + '</cpfcnpj>' + '<inscricao>' + OnlyNumber(Emitente.InscMun) + '</inscricao>' + '<chave>' + Emitente.WSChaveAcesso + '</chave>' + '</notas>'; Sobre o envio vou fazer o teste também e já retorno com o resultado. Se quiser aguardar a resposta do envio para subir a alteração. Obrigado. RLZ.Provider.pas

Boa tarde Douglas, Já esta no SVN.

Boa tarde. Já viu estes tópicos? Att.

Boa tarde Joca, Já que com o código não é possível a você contribuir no momento, fica o convite para considera assinar o ACBr Pro e além dos benefícios do plano, também contribuir para o crescimento do projeto. https://www.projetoacbr.com.br/pro Att.

Pode ser, sem problemas.

Boa tarde a todos. Diante deste mesmo erro (em produção), recebemos a informação de uma contadora de cliente que venda a consumidor final não presencial de outro estado não poderia ser CST 60 mesmo que o produto seja sujeito à ST no estado de origem. Segundo ela, sempre deverá ser 00 com CFOP 6108. Passamos esta informação para o contador do outro cliente que estava com problemas para registrar a NFe. Após um tempo ele nos retornou dizendo que instruiu o cliente dele a alterar a tributaçao para 00 (calculando DIFAL normal). O que é estranho é que apenas um cliente entrou em contato conosco com esta rejeição. Consultamos vendas na mesma situação de outros clientes do mesmo ramo de atividade e todos utilizam a CST 000. Entao, por enquanto, nao fizemos nenhuma alteração em sistema. Acreditamos que realmente é uma trava nova sim, mas o cliente estava emitindo nota com tributação errada.

sim achei sem lógica alguma. mas.... foi assim que consegui. vamos ver se resolvem isso

Boa tarde, A quantidade de 4 casas decimais para a alíquota é padrão para todas as cidades atendidas por esse provedor? Ou corremos o risco de existirem cidades que a alíquota deve ser gerada com apenas 2 casas decimais?

Boa tarde @aocampioni. Deu, mas entendemos que está errado. Fizemos apenas para validar as notas fiscais e liberar os clientes. Estamos aguardando um posicionamento da nossa consultoria contábil. Atte, Fernando.

Boa tarde, atualizei meus fontes e esta tudo ok. obrigado.

Pode gerar tranquilo, mas ele realmente ele precisa ter inscrição estadual. O tratamento é similar a de uma empresa SIMPLES nacional.

Boa tarde. A SEFAZ-MG permanece com problemas, conforme novo aviso publicado em seu portal

O Diário Oficial da União publicou em 01/09/2021 a Portaria nº 62/2021 que coloca fim ao acesso aos dados e informações da Nota Fiscal Eletrônica (NFe), disponibilizados pelo Serviço Federal de Processamento de Dados (SERPRO), por terceiros, a partir do dia 1º de dezembro de 2021. Entre os dados que deixarão de ser fornecidos estão: CPF (número, situação, nome e data de nascimento) CNPJ (número, razão social, situação cadastral, CNAE, localização do estabelecimento, contatos, sócios. Certidão Negativa de Débitos (números, certidões, data de validade); Nota Fiscal Eletrônica (chave, informações de resposta, eventos); Conhecimento de Embarque-Mercante - Consulta da Data da Última Atualização; Manifesto - Consulta da Data da Última Atualização; Escala - Consulta da Data da Última Atualização; Consulta a Dados Conhecimento de Transporte Marítimo (CE-Mercante); Consulta a Dados do Manifesto Marítimo; Declaração de Importação - Consulta à Data da Última Atualização; Consulta à Declaração de Importação. Vale lembrar que a Receita Federal já prorrogou a entrada em vigor desta medida outras vezes. Fonte : PORTARIA RFB Nº 62, DE 30 DE AGOSTO DE 2021 - PORTARIA RFB Nº 62, DE 30 DE AGOSTO DE 2021 - DOU - Imprensa Nacional (in.gov.br)