NT2015.003 Exemplo completo em SD – Partilha do ICMS e Fundo de Pobreza em Venda não contribuinte interestadual
Após aplicarmos todas as Notas e Customizações mencionadas na SAP Note KBA 2259931 e referidas, mostramos como devem ficar os cálculos em SD e reflexos em FI numa venda típica deste cenário,
Exemplo:
Venda a não-contribuinte do ICMS
SP-RJ
ICMS Interestadual 12%
ICMS Interno no destino 19%, contendo 1% de FCP
Pis 1,65%
Cofins 7,60%
Valor da Mercadoria contendo ICMS total de 19%: R$ 1000,00
IPI 10%
Base de Cálculo do ICMS: R$ 1100,00 (IPI incluso)
Pré-Cálculos para checagem:
Entrada do FCP: repare na chave, deve ser DESTINO-DESTINO (Como se fosse uma ST):
Cadastro correto do Cliente como não-contribuinte do ICMS:
Os nomes aqui podem variar, mas o importante são as correspondências. Deve levar ao 9 para a condition DINC ser ativada.
Valor NET (antes dos Impostos) R$6985,00:
Análise das Conditions na Ordem de Venda:
Estas conditions ISIC e ISFR vêm das entradas feitas na J1BTAX.
A DINC é a ativação da solução NT2015.003.
A ICVA é o ICMS interestadual, que já havia.
Na BX10 está contido o IPI.
No cálculo do valor, observe que foi incluso 19% do ICMS total, não do 12% interestadual.
Observe que a base de cálculo de IPI, Pis e Cofins não contém IPI.
Aqui aparece o resultado do cálculo para as novas conditions:
Esta parte não muda:
Análise do Billing Document:
Neste exemplo eu mantive a mesma conta que da MW2 para MW6, MW7 e MW8 na OB40, além de ter mantido na VKOA a chave BRI usada na ICMO para as novas offsets de ICMS também. Isso fica a critério do Contador de cada Empresa, se quer trabalhar com contas diferentes ou iguais:
Conditions mapeadas para a Nota Fiscal. As novas são: ICAP (partição destino), ICEP (partição origem) e ICSP (pobreza):
Partes do XML foram anexadas para visualizar o mapeamento das TAGS:
Há um ponto ainda polêmico (hoje 22 Dezembro 2015). Segundo a versão 1.50 da NT 2015.003, a TAG VICMSUFDEST deveria conter o valor não só da partilha ao destino, mas, conter, adicionalmente, o fundo de pobreza.
Neste exemplo acima, daria 264,00 +110,00 = 374,00, portanto na VICMSUFDEST.
A interpretação legal está mencionada no corpo da versão 1.50 da NT 2015.003:
DANFE: Não houve até o momento (hoje 22 Dezembro 2015) uma menção a requisitos de lay-out específicos.
(Apenas de que nas Info. Complementares deve estar mencionado o(s) valor(es) do ICMS para a UF de destino.)
No Projeto atual, o Cliente utiliza o GRC da SAP, SP23.
Por enquanto, está assim:
Observe que em cada linha aparece o cálculo total do ICMS, não somente o ICMS próprio.
Já ouvi comentários (a serem verificados) de que isto não estaria correto (?). Enfim, hoje, pelo Standard, está assim:
Texto legal mencionado nas Info. Complementares:
Com relação ao livro standard da SAP, disponibilizado na J1B_LB02, me parece incorreto, pois soma as conditions ICAP e ICEP na mesma linha, mostrando uma base duplicada, veja:
Tá certo que hoje em dia nem se deveria tratar deste Livro impresso, uma vez que os requisitos estariam no SPED, mas, para efeito de nossa checagem, muito bom seria se a SAP soltasse uma correção para isso, mostrando neste Report as linhas da ICAP e ICEP separadas.
Não encontrei na documentação legal os requisitos para o SPED neste tocante à NT2015.003
Até o momento é isso, pessoal.
Abraços a todos.
Boa implementação.
E meus parabéns à equipe técnica da SAP, em meu modesto parecer como Consultor independente, a solução foi limpa, precisa, eficaz e coerente com a linha geral de raciocínio utilizada pelo Standard para a Localização Brasil.
Ótimo post Sérgio Donaire!
Excelente iniciativa, Sérgio. E o post ficou muito bom!
Parabéns Sergio,
Muito bom!
Muito bom Sérgio!
Eu não consegui ver direito a imagem da DANFE, pois está muito pequena, mas parece que a aliquota do ICMS está errada. Está mostrando a aliquota do ICSP.
Também tivemos esse problema aqui e corrigimos no programa de impressão, mas também há um possível erro no código standard. Dá uma conferida nesse post.
Frisoni
Sem dúvida, Guilherme. Obrigado. Está incorretamente mostrando o percentual do FCP, de 1%.
Oi Guilherme,
Já estamos verificando este caso.
att,
Renan Correa
Boa tarde Renan!
Alguma novidade sobre ajustes ref. à alíquota de ICMS e Valor do ICMS relatados pelo Guilherme acima?
A princípio ajustamos o programa de impressão da DANFE, mas gostaríamos de continuar usando os campos ICMSRATE e ICMSVAL das estruturas standard ext_item and ext_header da função abaixo:
CALL FUNCTION 'J_1B_NF_VALUE_DETERMINATION'
EXPORTING
nf_header = wk_header
IMPORTING
ext_header = wk_header_add
TABLES
nf_item = wk_item
nf_item_tax = wk_item_tax
ext_item = wk_item_add.
Obrigado!
Flávio Lara
Olá Sergio,
Foi necessário algum desenvolvimento para preenchimento do texto das informações complementares?
Obrigado pela atenção e parabéns pelo post.
Bom dia, Alexandre, foi usado o programa de impressão e a tabela STX da nota como base para mapear valores.
Muito obrigado, e uma outra dúvida: como estão fazendo para emissão da gnre que acompanha a nota fiscal para o pagamento desta parte devida ao destino. Estou buscando por alguma coisa standard ou similar ao utilizado para st ou antecipação, mas sem sucesso.
Karen Rodrigues Renan Correa Sabem se existem planos para a sap desenvolver alguma solução?
Oi Alexandre,
Não existe nenhum projeto de desenvolvimento desta funcionalidade no ERP. Nunca tivemos geração de GNRE e não está nos planos do ERP.
att,
Renan
Sergio
Parabéns pelo post ! Aproveito e te peço um esclarecimento, talvez o Renan também possa ajudar. Somente agora estamos terminando de aplicar as notas aqui na empresa, sendo que 99,8 % de nossas operações não envolvem não contribuintes de ICMS. Iniciando os testes para clientes contribuintes vemos que não foram geradas as conditions de Fundo de Combate a Pobreza. Em resumo, o desmembramento do FCP só acontece nas operações interestaduais de não contribuientes do ICMS ? Ou seja, para vendas a clintes contribuintes do ICMS não se aplicam as alterações referents a FCP ?
Grato
Justino
Colega Justino, meus modestos conhecimentos me aconselham a que o Setor Fiscal de vossa Empresa confirme isso, mas, pelo que entendi, o FCP da NT2015.003 somente se aplicaria para os casos de NC fora do Estado. Entendi que não se aplicariam aos demais casos. Abraço, amigo.
Olá Sérgio,
Estamos trabalhando na questão do valor do campo vICMSUFDest.
Obrigado, querida. Nota 10 para vocês.
Sérgio, bom dia!
Muito bom ver conteúdo como este no SCN, parabéns pela contribuição.
Excelente blog!!!!
Karen Rodrigues
Obrigado, querida, você é que é um grande exemplo a todos nós. Tenha um Feliz Natal e um 2016 maravilhoso.
Excelente Sérgio Donaire!
Estávamos precisando disso!
Abs,
Leandro
Eu que agradeço o espaço que a SAP nos proporciona. Forte Abraço, colega, tudo de bom para você.
Excelente trabalho!
Obrigado, Gustavo, boa implementação. Um abraço.
Parabéns Sérgio pela síntese de todo esse novo processo de partilha do ICMS.
Creio que muitas águas vão rolar depois de 01.01.2016.
Nesse Natal temos que agradecer ao pessoal do CONFAZ que garantiu o emprego de muitos consultores nesse final de ano.
Feliz Natal a todos.
Haha verdade, Rodrigo.
Localização Brasil é o que diferencia nosso trabalho dos consultores de outros países.
Feliz Natal e boa implementação da NT2015.003 a todos.
Excelente blog! Parabéns.
Estou com uma dúvida: o tributário aqui entende que as bases de origem e destino deveriam ser diferentes, baseado na sistemática de cálculo da CONFAZ:
Porém tanto nesse blog, como no cálculo que está efetuando em nossa pricing e todos os demais posts que vi relacionado, as BX90 e BX91 trazem o mesmo valor.
Como que vocês veem o cálculo liberado pela SAP x CONFAZ?
Abs,
Fabricio Moreira
Querido Fabricio, esclarecendo sua dúvida.
O referido cálculo que o dileto colega mostrou, na verdade, refere-se ao apresentado na NT2015.003 versão anterior, 1.40, com Base Dupla.
O Convênio ICMS 152, de 11 Dez 2015, altera esta Sistemática, pois alterou o Convênio ICMS 93, estabelecendo a Base Simples. Desta forma, o cálculo proporcionado pelo Standard da SAP fica correto, aderente à NT 2015.003 versão 1.50.
Forte Abraço, boa implementação, Feliz Natal, amigo.
Veja a NT 2015.003, versão 1.50:
Sergio,
Adorei seu comentário!
Vibro ao ver um consultor que além de entender sistema também entende as mudanças e o que motivou estar alterações.
Mais uma vez esta de parabéns.
Karen Rodrigues
Você é que é muito querida, Karen, e eu modestamente gostaria de ter 10% de seu conhecimento Fiscal.
Tenha um Natal maravilhoso e excelente 2016, que venham novos desafios e teremos a certeza de que iremos resolvê-los.
Forte Abraço.
Viva a Comunidade SAP.
Feliz Natal e boas festas!!!
Muito obrigado Sérgio!!
Abs,
Fabricio Moreira.
Excelente! Parabéns!
Obrigado, Eduardo, feliz 2016.
Bom dia.
Alguém fez teste sem calcular IPI?
Aplique a nota de correção 2258220 para os casos sem IPI não ficarem distorcidos. Respondi isso na sua thread também. Abraços.
Caros,
Vocês estão com problemas com a rejeição 698 quando utiliza a alíquota interestadual de 4%? Parece que a regra de validação não considera ela:
Abs,
Fabricio Moreira
Fabrício, veja a regra NA09-10, que valida a alíquota de 4%, mas devendo ser compatível com a origem da mercadoria.
Oi Sérgio,
O problema é que com alíquota a 4%, a SEFAZ está devolvendo a rejeição 698 e não a rejeição 697.
De qualquer maneira, a origem da mercadoria está como 2 e é compatível para utilização de alíquota a 4%.
Abs!
Olá Fabricio,
Estávamos com esse mesmo problema até a semana passada, o mesmo não ocorre quando passa o XML pelo validador. Misteriosamente, as notas foram reenviadas e autorizadas. Acreditamos em um problema pontual da Sefaz/SP.
Olá Alexandre,
No meu caso, o cenário é GO - SP e, mesmo reenviando ou criando um novo cenário, a rejeição permanece.
De fato, o validador não exibe erro e, somando ao seu comentário, creio que seja do lado da SEFAZ mesmo.
Abs!
O erro acontecia por aqui tambem para as SEFAZ de RS, SP e PE. De repente, a SEFAZ começou a autorizar. Pode ser que a SEFAZ de GO ainda não atualizou...
Boa tarde Sérgio!
Primeiramente parabéns pelo POST. Está ajudando muito!
Pelo que consegui ver da sua DANFE, vocês estão imprimindo no valor total do ICMS somente o valor do ICMS interestadual e na linha do item o valor total (interestadual + parcelas de origem/destino + fundo especial). Aqui está da mesma forma.
Porém estamos na dúvida se não devemos ajustar o valor total do ICMS para considerar todas as condições de ICMS (assim como no item).
Na sua implantação, continua como no print do post, ou foi ajustado?
Obrigado!
Flávio
Nós aqui iremos refazer o exemplo após as últimas alterações, eu vou postar. Obrigado.
Boa tarde pessoal,
Novamente parabéns pelo Post.
Tenho uma dúvida sobre o mapeamento de condições para a NF. Considerando no exemplo acima que a alíquota interna no destino (ISIC) é de 19% e que o percentual de Fundo de Combate a Pobreza (ISFR) é de 1%, como vocês fizeram para que na aba impostos da NF aparecesse o percentual de 18% no tipo de imposto ICAP e ICEP? Vocês não utilizaram a ISIC como base no mapeamento?
Obrigado e agradeço desde já a ajuda de vocês.
Atte.,
Mauricio Shimada
Oi, Maurício, o mapeamento foi automático. Dos 19% é deduzido o 1% do FCP, resultando no 18% que você viu.
Sérgio, boa tarde.
Obrigado pela breve resposta.
O que quer dizer com "mapeamento" foi automático? Para o Tipo de Imposto ICAP - Alíquota você mapeou a própria condição ISIC e o sistema calcula o percentual alíquota destino - FCP? Ou você não utilizou o ISIC no mapeamento? Poderia mandar um print da sua tela de config do mapeamento de condição para a NF?
Muito obrigado
Maurício, bom dia.
Os mapeamentos foram os feitos pelo BCSET na RVABRA, só que fiz o mesmo para a específica daqui.
Automático é o cálculo da diferença 19% - 1% = 18%
Sérgio, bom dia.
Muito obrigado. Eu estava usando a ISIC para a linha do "Tax Rate Cond." e você usou a BX92 e BX93 no mapeamento.
Deu certo aqui pra mim tamém.
Obrigado
Criando esse mesmo cenário desse post de GO x RJ a NFe não autoriza nem com reza braba, ja tentei de tudo e nada, segue o erro:
"Rejeição: Valor do ICMS relativo ao Fundo de Combate à Pobreza na UF de destino difere do calculado"
Esse mesmo erro acontece de PE x PB, quem poderá me ajudar!!!!
Se limpar o calculo do Fundo de Combate a Pobreza a NFe autoriza.
Estou com o mesmo problema!
Achei que a SEFAZ pudesse estar com alguma validação quanto a tirar a taxa fome da tag de ICMS Destino, mas apliquei as notas hoje que fazem essa alteração (ref. v1.6 da NT 003/2015) e permanece essa rejeição...
Amigo, essa mensagem de erro citada é a rejeição 793, né?
A SEFAZ de GO está com problemas, disseram ter ajustado ontem a noite essa rejeição 793 porém o problema ainda persiste.
Se você fizer uma NF com o FCP com valor inteiro a NF é aprovada, ou seja, quando tem decimais está gerando essa rejeição indevida.
Att,
Bom dia a todos!
Estou testando um cenário onde está ocorrendo a rejeição 225: Falha no esquema XML
No meu cenário, tenho um ICMS de 18% na origem e 18% interestadual. Por isso nenhum calculo com relação a partilha e fundo de pobreza deve ser feito..
O mesmo cenário (mesmo cliente) funciona para outros materiais e a nota é aprovada na SEFAZ.
Desconfiei de algum problema na hora que as informações são enviadas para o GRC. pois os valores das TAG´s ICAP, ICEP e ICSP vão vazias (anexo).
Alguém já passou por esse erro?
Desde já muito obrigado.
Renato
Renato,
Copie o xml e utilize o validador do RS para apurar falha no schema xml:
https://www.sefaz.rs.gov.br/nfe/nfe-val.aspx
Obrigado Leandro!
Na verdade o erro era a alíquota. Estavam utilizando uma alíquota que não consta na Nota técnica.
Estranho é a mensagem ser a 225 e não uma especifica.
At,
Renato
Ótimo post!
Amigos,
Algum de vocês encontrou a solução para o problema do livro fiscal estar com as Bases de Cálculos erradas J1B_LB02?
A SAP disponibilizou alguma correção para isso?
Obrigado!
Marcos, infelizmente o Renan Correa disse no blog dele que a SAP não vai focar nisto.
Sergio, Obrigado pela resposta.
Que absurdo ouvir isso da SAP. Isso soa como uma falta de respeito com os clientes que gastam milhares de reais pagando taxa de manutenção de software a SAP.
Independente da informação ser extraída corretamente para o SPED, o mínimo que se espera de um sistema deste porte é que se possa visualizar no livro a informação correta.
Att.
Olá Marcos,
A informação de que os livros modelo 1 e 2 ( J_1blb01 e J_1blb02 ) não serão mais atualizados foi adicionada na SAP Note "1907815 - ERP Reports out of maintenance" justamente para informar aos clientes que estes livros estão fora do escopo de manutenção da SAP.
Os livros fiscais modelo 1 e 2 existiam para satisfazer uma necessidade legal, a qual não é mais relevante de acordo com a interpretação da SAP, pois foi substituída pelo SPED Fiscal, portanto a visualização dessas informações no livro não é mais necessária.
A maneira correta de verificar os dados do ICMS será utilizando o SPED Fiscal, porém a solução para a demonstração das informações de ICMS com partilha no SPED também dependia da divulgação do "Guia Prático da Escrituração Fiscal Digital - versão 2.0.18" que estava pendente por parte do governo e foi publicado recentemente apenas.
att,
Renan Correa
Obrigado por esclarecer, Renan.
Olá Renan,
Apesar de não concordar com a abordagem da SAP, eu agradeço o seu esclarecimento em relação ao tema.
Abs,
Boa tarde Sampaio, vc disse que a extração do SPED está correta, confirma por favor essa informação, pois aqui na minha empresa o registro C100 está com o valor da base de calculo do ICMS com erro, pois está somando os valores das bases do ICAP, ICEP e ICSP. Se o seu SPED está correto o meu tambem deveria está.
Me ajude nesse caso por favor.
OIa a todos e feliz 2016!
Sergio, muito legal este post, ajudou e muito.
Tenho uma duvida na parte do documento contabil do ICMS offset
na linha 12, 13, 14 os lançamentos estão como Debito (40), porém em todos os casos de partilha que estou faturando aqui, aparecem como 50 que esta incorreto.
Pode me explicar como fazer esta mudança? é alguma coisa na OB40?
Muito Obrigado
Bom dia, colega Emiliano.
As linhas 09, 10 e 11, lançamentos a Crédito, provém da OB40. São configurados pelas chaves MWx. São os impostos a recolher, Passivo.
As linhas 12, 13 e 14 são lançamentos a Débito. São configurados na VKOA. No exemplo que fiz acima, eu usei a mesma chave BRI, redutora de receita, usada para o ICMS normal.
Veja na Pricing a associação das chaves de conta com as conditions.
Em cada caso, deve-se consultar o Contador da Empresa, que definirá estas contas.
Para contas diferentes, deve-se criar e usar outras chaves na Pricing.
Se no seu caso está com problemas, reveja as linhas da Pricing (entre no modo de análise) e reveja as contas associadas com as chaves.
Boa implementação,
Feliz 2016.
Ola Sergio
Muito obrigado pela resposta. No caso eu confirmei aqui com o negocio e a conta esta correta. No meu caso, conforme imagem abaixo a linha 9 e 10 estão corretas com posting key esta 50. Já na linha 11 e 12 a conta esta correta, porém deveria ser posting key 40 (debito).
configuração da minha pricing esta assim, e apontando para os account key 'BRI'
eu não consegui entender como que o sistema pega o posting key como 50, sendo que na OB40 onde se define se a conta é credito ou debito não há registros da conta 314605.
o mais estranho ainda é que se ver a linha 13 na minha imagem a mesma conta esta como 40.
Agradeço novamente pela ajuda.
Obrigado
Caro Emiliano,
Os registros de condição dos offsets devem estar com -100% (negativos):
Verifique:
Para evitar este tipo de erro, você pode definí-los na V/06 como sempre negativos, daí um eventual esquecimento do sinal não fará diferença, sempre será salvo como negativo.
Sergio
Novamente agradeço pela imensa ajuda. Realmente o problema estava neste detalhe!
Você tem razão, melhor colocar isso ja na V/06.
Muitisimo obrigado novamente!
Sergio? Bom dia,
você teria uma documentação de como está sendo feita essa negativação?
Fico no aguardo,
obrigado.
Att,
Daryk William.
Bom dia galera, vi nos comentários acima que a extração do SPED está correta, poderiam confirma por favor essa informação, pois aqui na empresa o registro C100 está com o valor da base de calculo do ICMS com erro, pois está somando os valores das bases do ICAP, ICEP e ICSP, ou seja o mesmo erro dos livros fiscais.
Me ajude nesse caso por favor.
Bom dia Pessoal!
Estou fazendo alguns testes de partilha sem fundo de pobreza. Ou seja, deveria haver a partilha porém para o estado de destino não tem o fundo de pobreza.
Acontece que a minha pricing só calcula a partilha quando eu tenho um fundo de pobreza. Quando não tem a condição ISIB não é determinada com 100%.
Alguém já passou por esse erro?
obrigado,
Renato
Parabéns Sérgio Donaire , ótimo BLOG!
Grande abraço e feliz 2016!
Baroni
Querido amigo e colega Baroni.
Desejo a você um 2016 repleto de Projetos !!!
Bom ouvir isso de você, um Mestre no GRC.
Forte Abraço !!!
Ótimo post!!!
Obrigado, Daniel. Boa implementação. Abração.
Sergio, Boa tarde!
Temos um cenário de venda de ativo fixo que teoricamente atende aos requisitos do processo de partilha, ou seja, cliente não contribuinte e operação interestadual, porém por se tratar de venda de ativo a operação é Isenta (C0).
Quando enviamos a Nota é rejeitada com a msg 694.
Existe alguma solução STD para esse cenário? A SEFAZ esta aguardando que enviemos as tags de partilha, porém não há impostos a gerar.
Alguém teve um cenário semelhante? Se sim, poderiam indicar qual seria a solução proposta?
Obrigada,
Silvana Santos
Silvana,
Altere sua formula (DINC) para so pegar casos onde o tax code seja de consumo e o ICMS estiver marcado. Foi assim que fizemos..
Depois eu posto a formula pronta aqui... fizmos a parte do check se consumo mas falta o check se ICMS esta marcado no tax code.
Um abraço,
Felipe Nyitray
Felipe,
Muito Obrigada pelo retorno!
A principio utilizamos a DINC fazendo via sequencia de acesso. Mas se não encontrarmos outra opção, talvez seja nossa saida.
Se puder publicar a formula, agradeço.
Atenciosamente,
Silvana Santos
Oi Silvana, boa tarde.
Você conseguiu resolver este problema?
Tb estou com este cenário e hoje se a nota é enviada sem as tags da DIFAL é rejeitada com msg 694.
Até meados de janeiro se a nota fosse enviada sem as tags a nota era aprovada.
Obrigada, Pollyana
Boa Tarde Pollyana,
Na realidade estou acompanhando algumas sugestões feitas pelo pessoal do forum, mas aguardando também posicionamento da SAP quanto ao tratamento de ICMS Isento na origem.
Atenciosamente,
Silvana Santos
Silvana,
Segue copy and paste da formula DINC - alterada - para so calcular ICMS Partilha quando:
- Não contribuinte;
- Tax Code for para Consumo;
- Tax Code estiver marcado para calcular ICMS;
- Operações Interestaduais.
Espero que ajude.
Abs
Felipe Nyitray
FORM FRM_KONDI_WERT_988.
* Determination of non ICMS-Contributor according to Technical Note 2015/003
* Created according to SAP Note 2232757 - enhanced
* Relevant for Sales and Distribution Customizing
* Relevant only for Brazil
DATA:
lv_iedest TYPE j_1bnfe_iedest,
lv_custusage TYPE j_1btxsdu,
lv_icms TYPE j_1btxsdic,
lv_regio TYPE kna1-regio.
CONSTANTS:
lc_no_icms_contributor TYPE j_1bnfe_iedest VALUE '9'.
clear:
xkomv-kbetr.
* Select Taxable Partner Region
SELECT SINGLE regio INTO lv_regio
FROM kna1
WHERE kunnr EQ komk-kunnr_tx.
* Select Taxable ICMS Taxpayer identification
SELECT SINGLE j_1biedest
FROM j_1bticmstaxpay
INTO lv_iedest
WHERE j_1bicmstaxpay = komk-icmstaxpay.
* Select SD Tax Code Usage Code and ICMS Flag
SELECT SINGLE custusage icms
FROM j_1btxsdc
INTO (lv_custusage, lv_icms)
WHERE taxcode = komp-j_1btxsdc.
* Check if ICMS Taxpayer refers to non ICMS-contributor, plant location is different from partner location, SD tax code is to calculate ICMS and also for consumption.
IF sy-subrc EQ 0 AND
lv_iedest EQ lc_no_icms_contributor AND
t001w-regio NE lv_regio AND
lv_custusage EQ '2' AND
lv_icms NE space.
xkomv-kbetr = 100000.
ENDIF.
ENDFORM.
Boa tarde Sergio.
Tenho uma dúvida que talvez seja simples. Aqui vai
Verificando o detalhe do calculo que você demonstra percebo que, a alíquota utilizada para calculo do DIFAL está sendo feita com 6% (Interna18% - 12% Interestadual) = 660,00, porém a alíquota interna para o RJ é 19% assim sendo, entendo que o DIFAL seria (19% - 12%= 7%) Está correto? Abrimos um chamado na SAP visto que quando do calculo o sistema está abatendo 1% da alíquota fazendo o calculo do DIFAL com 6%, e segundo nosso IT a resposta da SAP foi para alterar a J1BTAX aumentando a alíquota interna de 19% para 20% assim quando o sistema efetuar o calculo a alíquota utilizada será 19%. Porém acredito que essa alteração vai afetar também os cálculos de substituição tributária.
Bom dia Valdomiro!
Estou atendendo um cliente que me passou essas mesmas informações. Ou seja, o Difal deveria ser de 7%. Consequentemente segundo o cliente os cálculos do ICMS origem e destino estão errados pois estão sendo calculados sobre 6%.
Você conseguiu tratar isso sem modificar a J1BTAX.
Na análise que fiz para tratar via J1BTAX teríamos que criar novas exceções, talvez por domicilio fiscal, para esse cálculo atender somente as vendas para consumo final.
Abs,
Renato
Bom dia! Sergio
Estava analisando o seu post e fiquei com uma dúvida quanto a alíquota utilizada, pois para o RJ a alíquota é 19% porém no exemplo demonstrado o calculo do DIFAL = 660,00 está sendo feito sobre 6% (18% - 12%), o correto não seria 7%?
Aqui na empresa onde trabalho observamos que quando há % do FECP o sistema está abatendo esse % do calculo do DIFAL, Alguém saberia me dizer o porque?
Obrigado,
Valdomiro Ramalho
Pessoal
Estou implementando o ICMS Partilha + FCP, e estou me deparando com problemas nos cálculos :
01.ICMS PARTILHA == SEM == FUNDO POBREZA
Base : 2.571,86
ISIC = % base icms origem = 18%
% ICMS Interestadual = 12%
BX94 – ICMS Origem = 92,59
BX95 – ICMS Destino = 61,72
BX96 – ICMS FCP = 0
Base : 2.571,86
Difal = 2.571,86 * (18-12) è 2.571,86*0,06 è 154,31
Base Difal = 154,31
60% = 154,31* 0,60 = 92,59
40% = 154,31* 0,40 = 61,72
SAP x CÁLCULO ICMS PARTILHA è OK
02.ICMS PARTILHA == COM == FUNDO POBREZA
Base : LÍQUIDO 817,35 + IMPOSTO 524,47 = 1.341.82
ISIC = % base icms origem = 18%
% ICMS Interestadual = 4%
Difal = 1.341.82* (18-4) è 1.341.82*0,14 è 187,85
Base Difal = 187,85
Cálculo atual da base Difal :
60% = (187,85 – 13,42 (FCP))* 0,60 = 104,66
40% = (187,85 – 13,42 (FCP)) * 0,40 = 69,7
BX94 – ICMS Origem = 104,66
BX95 – ICMS Destino = 69,77
BX96 – ICMS FCP = 13,42
O setor fiscal está me dizendo que o cálculo que o SAP esta realizando está errado, que o correto seria :
base Difal :
60% = 187,85 *60% = 112,71
40% = 187,85 * 40% = 75,14
FCP = 13,42
LÍQUIDO 817,35
IMPOSTO 524,47 + FCP 13,42= 537,90
Alguém já passou por esse problema ? ja verifiquei em vários blogs e todos dizem que o cálculo do SAP está correto, porém, se entro em qualquer simulador de ICMS Partilha, os cálculos não batem com os do SAP.Alguém já passou por isso ?
Grata
Ieda
Felipe, bom dia!
Obrigada pelo retorno.
Hoje estou efetuando a determinação da DINC através de sequencia de acesso e para clientes não contribuintes em operações interestaduais onde há tributação do ICMS e consequentemente partilha, funciona perfeitamente.
Porém no cenário de venda de ativo meu código é C0, pois não há tributação. Nesse caso o problema pelo que entendi está na composição das tags esperadas pela Sefaz.
Quando gero um docnum para essa operação as condições ICAP e ICEP nem vão para a nota, pois não existe o que partilhar.
Não consegui entender em que ponto essa fórmula iria tratar isso. Se puder me ajudar a entender o que afinal deve ser enviado no XML.
Agradeço sua atenção.
Silvana Santos
Pois é, Silvana.
A formula que modifiquei so visa ajustar o codigo inicialmente provido pela SAP via OSS Note, mas não trata essa rejeição.
A SEFAZ rejeita a Nota no ambiente de HOMOLOGAÇÃO com mensagem 694 - Não informado o grupo de ICMS para a UF de destino com base no criterio:
Não informado grupo de ICMS para a UF de Destino (tag:ICMSUFDest):
- Operação Interestadual (idDest=2) e
- Operação com Consumidor Final (indFinal=1) e
- Operação com Não Contribuinte (indIEDest=9) e
- Não é operação de prestação de serviços (não existe tag “ISSQN”).
A regra de validação não se aplica, em produção, para Nota Fiscal com data de emissão anterior a 01/07/2016.
Quando isso acontecer (Julho), (todos nós) teremos problemas na emissão de NFe sem ICMS para não contribuinte, interestadual, consumidor e nao serviço. Ou seja, OU a SEFAZ ajusta a regra de validação OU este tipo de operação terá que ser tributada --> o que duvido já que vários convenios de ICMS teriam que ser alterados.
Sim Felipe!
Até 01/07 não teremos problemas em Produção! Estou tentando me adiantar, mas ainda não identifiquei nenhuma forma de atender a esse cenário, pois não consegui entender o que a SEFAZ espera receber no XML.
Se alguém tiver essa informação por favor compartilhe conosco.
Abraço a todos.
Silvana Santos
Oi Silvana, bom dia.
Sobre este problema vi num fórum uma sugestão de como a nota deve ser emitida:
www.projetoacbr.com.br/forum/topic/26808-grupo-de-icms-para-uf-destino-produto-isento
Ainda não gerei uma nota desta maneira para confirmar se será aprovada mas entendo que se realmente tem que ser assim a SAP deveria tratar.
Att, Pollyana
Sergio,
Quando você efetua uma venda onde a aliquota interestadual é maior que a interna está funcionando? Pois no meu cenário está mapeando as condições com valor zerado na J1B3N e a tags do xml estão indo zeradas e a sefaz esta retornando o erro 793.
<ICMSUFDest>
<vBCUFDest>13.11</vBCUFDest>
<pFCPUFDest>1.0000</pFCPUFDest>
<pICMSUFDest>18.0000</pICMSUFDest>
<pICMSInter>12.00</pICMSInter>
<pICMSInterPart>40.0000</pICMSInterPart>
<vFCPUFDest>0.00</vFCPUFDest>
<vICMSUFDest>0.00</vICMSUFDest>
<vICMSUFRemet>0.00</vICMSUFRemet>
</ICMSUFDest>
Att
Fabricio
Sergio, bom dia !
Estou com o seguinte erro, para algumas Ordens de Vendas a pricing não esta refletindo corretamente. As Condições de ICVA e ISIC aponta um valor, porém deveria pegar outro valor para calculo, simplesmente o programa esta desrespeitando a J_1BTXIC1 (98) e pegando o valor J_1BTXDEF (99). Esse problema não acontece sempre e aparece para Estados diferentes.
O programa informa que a “O registro de condição existe mas não foi predefinido”.
Isto esta impedindo de ser efetuada a partilha de ICMS no Ecommerce, as notas estão sendo aprovadas mas incorretamente. Você ou alguém já presenciou um erro como este?
Verifiquei a Condição e esta valida e também não esta marcada para eliminação.
Desde já agradeço a atenção.
Att.,
Anderson Araujo
Oi Anderson.
Você chegou a fazer as migrações das tabelas de ICMS?
É uma etapa manual pós implementação, devido ao fato de que a estrutura das tabelas foi alterada.
Abrs.
Bom dia Sergio, tudo bem!
Voltando ao assunto da NT-2015-003, estamos adequando o cliente, e estou com duvida na criação da formula que de SD/MM. Minha duvida é: Onde o ABAP deve atualizar esse formula para adequação da NT?
Grato.
Prezados, bom dia !
Estou com um cenário que as condições BX90 e BX9D não estão puxando os valores de 40% e 60%.
Conforme print abaixo:
Alguém já viu esse caso? Tem ideia do que pode está acontecendo ou faltando ?
Fico no aguardo obrigado.
Att,
Daryk William.
Pessoal, bom dia,
Após implementar as notas da NF-e 4.0, os cálculos da Partilha do ICMS foram alterados conforme abaixo:
Cálculo correto:
Cálculo errado (após aplicação das notas):
Observem que o montante Origem acumulou o Montante do Destino.
Obs.: Voltei o esquema de cálculo (price) para a versão antiga (antes da aplicação das notas) e o cálculo continua errado.
Alguém passou por isso?
Grato,
Ola Gabriel, tudo bem ?
Estou exatamente com o mesmo problema, o valor da partilha se acumulou na origem (BX94). Parece que a view J_1BTPARTILHA não está sendo mais lida.
Notei que o método DETERMINE_PARTR_FOR_SALES foi descontinuado após a aplicação da sap note 2429856.
Você já conseguiu resolver ?
Obrigado
Ruy