FAQ sobre NT 003.2015
Olá,
Após a sessão webinar sobre NT002 e 003.2015 algumas perguntas ficaram pendentes de resposta. Neste post iremos publicar essas respostas e também abrimos um espaço para discussão de dúvidas sobre a NT 003 2015.
Caso você não tenha assistido ao webinar a gravação da sessão e a apresentação já estão disponíveis no blog post:
Webinar NT002 and 003 – Recordings and Presentation
FAQ
1. O que aconteceria se fossem faturadas ordens/remessas antigas ( anteriores a mudança ) após o dia 1º de janeiro? O que aconteceria no momento do faturamento?
O resultado do faturamento depende do que estiver configurado na regra de cópia (transação VTFL) de SD.
Se estiver com um pricing type ‘D’, por exemplo, não vai utilizar as novas condições.
Se estiver com um pricing type ‘C’, por exemplo, irá utilizar as novas condições, ou seja, se houver um ‘repricing’ no momento do billing, as condições criadas pela EC87 serão consideradas.
Esse é um cenário que precisará ser validado no ambiente de cada cliente para avaliar o comportamento de acordo com a configuração utilizada.
2. Em um processo de devolução de SD como funciona o cálculo do ICMS de partilha? Se for feita uma devolução com partilha (após dia 1º) de uma fatura de SD anterior ( sem partilha ) como funcionará o cálculo?
Entendemos que a devolução deve estornar os lançamentos da fatura. Neste caso, a regra de cópia (tCode VTAF) deve estar com um pricing type que não recalcule os valores, como por exemplo o ‘D’.
Ou seja, mesmo que seja depois de 01.01.2016, a devolução de uma fatura antiga deve seguir a situação original.
3. É possível implementar apenas a mudança do CEST no ERP agora? ?Isso sem implementar a mudança do ICMS com partilha no GRC?
No ERP pode-se implementar o CEST e não implementar a EC87/15, desde que ele não emita nem receba NF-e com EC.
No GRC, o SP23 vai ser necessário pelo menos por conta do CEST.
4. A BAdI para determinar se um cliente/filial não é contribuinte está disponível apenas para TAXBRJ?
A BADI_J1B_ICMS_PARTILHA tem 2 métodos, 1 pra definir se o cliente/filial é Não Contribuinte e outro pra interferir na Base de Cálculo. Para TAXBRJ, ambos os métodos são aplicáveis, mas para TAXBRA apenas o método da Base de Cálculo é aplicável.
No caso de TAXBRA, a definição de cliente/filial NC deve ser feita via fórmula na pricing (condition DINC).
5. Se a empresa possui uma exceção legal e o ICMS é isento na origem, como fica o cálculo da partilha do ICMS?
Este cenário ainda está sendo analisado e precisa de esclarecimentos adicionais. Após análise mais detalhada iremos atualizar o blog post.
6. Existem alterações na DANFE após a implementação da NT 003 2015?
Não haverá alteração no leiaute do DANFE, mas as empresas remetentes devem informar, no campo de “Informações Complementares”, os valores descritos no grupo de tributação do ICMS para a UF de destino.
Essa informação pode ser mapeada, por exemplo, via BAdI CL_NFE_PRINT, método FILL_HEADER utilizando o campo infcomp a partir da informação do tax type ICAP que estará presente na tabela de impostos da NF ( J_1BNFSTX )
7. Tenho um cenário com redução de base e gostaria de alterar o valor da partilha para o destinatário. É possível fazê-lo?
Sim. Para este cenário foi desenvolvido o método DETERMINE_INTRASTATE_ICMS_RED na BADI_J1B_ICMS_PARTILHA. Este método será chamado tanto para TAXBRA/TAXBRJ nos cenários de SD. Com este método é possível alterar o percetual da redução de Base de cálculo do ICMS.
att,
Renan Correa
Excelente Renan!
Tem ajudado muito o pessoal com essa EC87!
Renan, boa tarde.
Sobre o item 6, existe alguma previsão para algum desenvolvimento standard para entrega da informação preenchida?
Vc não comentou nada para a BAdl "nova", J_1BNF_ADD_DATA, mas entendo que o desenvolvimento seja o mesmo, já que o método já contem a tabela J_1BNFSTX, certo ?
Oi,
Na verdade já existe um mapeamento standard da SAP para o campo infcomp: e ele pode ser usado por quem está utilizando a BAdI nova.
Função J_1B_NF_MAP_TO_XML
Lê os textos da NF:
CALL METHOD cl_j_1bnf_longtext=>get_all_nf_texts "1844621
EXPORTING "1844621
iv_docnum = wk_header-docnum "1844621
iv_language = wk_header-spras_bupla "1844621
IMPORTING "1844621
et_nfdoc_text = wk_header_text "1844621
et_nflin_text = wk_item_text. "1844621
Se tiver um "Text ID: Header Additional text (Company)" então no
Include LJ_1B_NFEF70 ele é mapeado para o infcomp:
LOOP AT wk_header_text INTO ls_header_text
WHERE docnum = wk_header-docnum.
CASE ls_header_text-textid.
WHEN cl_j_1bnf_longtext=>gc_head_authorities.
xmlh-infadfisco_v2 = ls_header_text-text.
WHEN cl_j_1bnf_longtext=>gc_head_company.
xmlh-infcomp = ls_header_text-text.
ENDCASE.
ENDLOOP.
No caso da BAdI nova se esse texto já for populado no momento de salvar o documento então ele será lido depois no mapeamento.
att,
Renan Correa
Boa tarde Renan,
Estou com uma dúvida nas etapas manuais da aplicação da nota 2238556, item 22, atualização da view /XNFE/MAP_FIELD.
No primeiro item ele manda colocar o mapping scenario como 08, mas só é permitido 04 e 05. Tá faltando alguma coisa??
Bom dia Renan Correa
Estou utilizando o método DETERMINE_INTRASTATE_ICMS_RED, da BADI_J1B_ICMS_PARTILHA para alterar a base de cálculo interna do estado de Destino no cálculo de diferencial de alíquota. No entanto, tive dois problemas.
1º ele não passa pela BADI no momento de determinar qual a maior alíquota para inserir no preço líquido.
2º No momento de calcular a partilha do ICMS, ele chama a BADI, e carrega o percentual que eu defini dentro do método, mas logo em seguida ele sobrescreve pela base que veio da J1BTAX (no meu caso, está cadastrado na J1BTAX alíquota 17% Base 0 )
Este comportamento está correto? Mais alguém passou por esta situação?
Obrigada,
Kelly Ferreira
Oi Kelly,
Já vi esse erro de sobrescrever a determinação da BAdI.
Já estamos desenvolvendo uma correção para este cenário e ela deve sair em breve.
att,
Renan Correa
Bom dia Renan,
Acredito que estamos com o mesmo problema da Kelly e o Ronaldo (outro blog) sobre a Badi para Redução de Base.
Para exemplificar melhor: o Fiscal nos validou que a Partilha deve considerar a mesma base reduzida usada no ICMS normal, ou seja, conforme a BX10 abaixo, mas o standard esta considerando a IBRX:
Em debug conseguimos alinhar a base das condições de Partilha para a reduzida, mas o standard sobrescreve com o valor anterior, como a Kelly descreve.
Temos alguma posição quanto a isso?
Outra questão é, na Badi estamos reduzindo a BC da Partilha, depois o standard usa o valor da IBRX. Como a BX10 que deve ser usada para BC da Partilha, isso será ajustado também?
(os convênios possuem diversas aplicações de redução, por ex.: 12% de 40%, 4% de 70% (Res. 13), etc, mas o standard sempre usa a BX10).
Obrigado,
DanielGolin
Boa tarde Renan,
Tenho um processo de exceção para partilha de ICMS onde o produto na UF destino é base zero, pois o produto em questão tem o CST = 60 - "ICMS já cobrado por meio de Substituição Tributária".
Segue como está exibido na condição "ICVA".
Origem x Destino Ordem
Configuração J1BTAX Origem x Destino
UF Origem UF Destino Grupo de mercadorias Validade desde Validade até Taxa Base Base Imp
AL AL K1 01.01.2018 31.12.9999 18,00 0,00
Destino x Destino Ordem
Segue como está exibido na condição "ISIB".
Configuração Destino x Destino
Para fazer o cálculo do ICMS partilha, ativei a BADI_J1B_ICMS_PARTILHA~DETERMINE_INTRASTATE_ICMS_RED, e incluí uma lógica para determinar a base 100% (Perceba na figura que a base está vazia). Porém, quando ativo a BADI, no momento da chamada do método IS_ICMS_PARTILHA_SCENARIO, o sistema entende que a origem é igual ao destino e com isso o cenário fica irrelevante para o cálculo da partilha.
CALCULATE_ICMS_PARTILHA
* Check if it is a ICMS Partilha scenario
CHECK is_icms_partilha_scenario( ) = abap_true. "2443042
Only execute for interstate scenarios (SP->RJ)
lv_interstate = is_interstate(
iv_ship_from = iv_ship_from
iv_ship_to = iv_ship_to
).
CHECK lv_interstate = abap_true.
rv_return = abap_true.
Ele passa várias vezes por esse método e apenas no último momento ele determina novamente a origem. A origem era para ser SP.
Quando executo, sem a BADI está ativa, para outro processo onde a base seja diferente de '0,00' o processo funciona normalmente.
Você ou alguém do blog já depararam com isso?
Obrigado,
Assis
Olá, boa tarde.
Sobre a isenção de ICMS na origem, já existe alguma previsão? Há uma indefinição legal sobre o cálculo ou já está em desenvolvimento?
Obrigado!
Bom dia
Tiveram algum retorno sobre a isenção de ICMS na Origem?
Obrigada
Também estamos com o mesmo problema, alguma solução?
Obrigada.
Boa tarde pessoal.
A respeito do item 5 da FAQ, houve alguma definição?
No meu cliente há um volume considerável de saídas onde o produto é isento de impostos e para estes casos, mesmo a ICVA estando com valor zero, ele gera cálculo de partilha, contabiliza e envia para a NF. Segundo a Área Tributária da Empresa, isto está totalmente errado.
Obrigada!
Jane Zanini
Sobre o item 2 (Devolução) seguindo a orientação coloquei todos meus pricing type como D para não recalcular, porém está gerando esse erro ao criar uma devolução de venda antes da partilha, alguem passando por isso???
veja o erro:
"Erro de determinação de preço: falta condição obrigatória ICEO"
Essa condição não existe na venda.
Boa tarde. Alguém saberia informar qual sequencia de acesso utilizar para a DINC?
Fala Giulliano. Tudo bem?
A condição DINC deve ficar sem sequencia de acesso.
Abs
Gabriel Pinheiro
Obrigado pela resposta Gabriel. Fiquei em dúvida pois estou com a seguinte situação. A DINC está ativada, porém nenhum valor é apresentando nas demais condições. Peguei esta implementação pela metade e não identifiquei ainda o que pode estar faltando. Você já teve este problema ou algum semelhante?
Olá.
Tenha certeza que o cenário que está testando seja um cliente não contribuinte, para consumo e interestadual.
A condição DINC com 100% só indica que é um cliente não contribuinte. As outras condições são verificadas pelo standard através das notas aplicadas.
Fala Giulliano.
O cliente que está sendo feito o teste é Não Contribuinte? ou venda interestadual?
Isso pode ser analisado no novo campo criado no mestre de clientes.
Gabriel Pinheiro
Abs
Obrigado pelas dicas pessoal.
O cadastro está ok e trata-se de uma venda de SC para SE. Estou revisando a configuração geral, mas ainda não identifiquei o problema. Qualquer novidade coloco aqui.
Abs.
Gomes.
Obrigado Gabriel. O erro estava no IVA mesmo, estavam utilizando o IVA errado no teste.
Meu problema agora é outro; está tudo ok, porém as TAGS relativas não estão indo para o XML.
Bom Dia Senhores,
Alguma novidade a respeito do item 5?
Obrigada,
Silvana Santos
Bom dia!
A versão 1.92 da NT 2015/003 traz uma alteração no sentido de que, nas notas de devolução e retorno, o percentual do diferencial de alíquota de ICMS distribuído entre estados de origem e destino, refletirá a proporção vigente no ano da nota de referência (original), não do ano da nota de devolução.
O prazo para implantação das alterações trazidas pela versão 1.92 desta NT é:
• Ambiente de Homologação (ambiente de teste das empresas): 16-jan-2017;
• Ambiente de Produção: 30-jan-2017.
Em um exemplo prático, o que ocorre é que se fiz uma venda em 2016 onde a tabela J_1BTPARTILHA informa que a alíquota é de 40%, caso haja uma devolução/retorno para essa venda em 2017, deverá obedecer essa mesma alíquota, que no caso é 40%. E não a do ano atual que seria 60%.
A SAP irá lançar alguma Nota para esta correção?
Obrigado!
Respondi seu comentário no outro blog post, no futuro evite copiar e colar o mesmo comentário em vários blogs.