Dicas para implementação da MP135, com a utilização do CBT

I. Grupos de Impostos de exceções dinâmicas X Seqüências de Acesso

Com a utilização do método de cálculo de imposto baseado em condições (CBT), toda

vez que um novo grupo de imposto for criado, a sua inclusão em uma determinada seqüência

de acesso deverá ser feita de forma automática pelo sistema, através da transação J1BTAX.

O mesmo deverá ocorrer sempre que forem executadas modificações no grupo de

imposto, ou ainda sua eliminação.

Mensagem após criação, modificação ou eliminação de um grupo de imposto:

O procedimento para a atualização do grupo de imposto dentro de uma seqüência de

acesso é o seguinte:

1. Acessar a transação J1BTAX

Menu: Preparação da Condição/ Migração/ Grupos de Impostos nas seqüências de acesso.

2. Para inserir um novo grupo de imposto em seqüências de acesso:

*** Ao executar esta transação, serão exibidos os logs da operação na tela seguinte, p/ análise.

Renata Karla 22/09/2006

3. Para atualizar modificações efetuadas em um grupo de imposto nas seqüências de

acesso:

*** Ao executar esta transação, serão exibidos os logs da operação na tela seguinte, p/ análise.

4. Para eliminar um grupo de imposto das seqüências de acesso:

*** Ao executar esta transação, serão exibidos os logs da operação na tela seguinte, p/ análise.

Exemplo de Tela de Exibição de Logs:

Renata Karla 22/09/2006

Exemplo de inclusão do novo grupo de imposto dentro da seqüência de acesso:

*** OBS.: a etapa “5” funciona como um modelo para os novos grupos de imposto a serem

incluídos automaticamente na seqüência de acesso.

II. Tabelas de Impostos X Registros de Condições

A criação de registros de condições para impostos também ocorre de forma automática

com a utilização do CBT. Tais condições são criadas pelo sistema, com base nos dados

alimentados nas tabelas de impostos de exceções dinâmicas (acessadas pela transação

J1BTAX).

O procedimento que dá início à criação automática de condições é o seguinte:

1. Acessar a transação J1BTAX:

Menu: Preparação da Condição/ Migração/ Tabela de Impostos para condições.

2. O sistema exibirá todas as tabelas de impostos, conforme abaixo:

3. O ícone verifica os registros de condições gerados para determinada tabela de

imposto. Para fazer esta verificação, selecione uma tabela e, em seguida, clique sobre

o ícone mencionado, conforme exemplo:

Renata Karla 22/09/2006

Resultado Obtido

4. Em situações em que algum registro apareça com o status amarelo ou vermelho,

selecione a opção e utilize o ícone

para gerar um novo registro correto, conforme exemplo:

Renata Karla 22/09/2006

***A expressão “nvo” indica que foi criado um novo registro de condição. Observe que tanto o

status da tabela quanto o da condição estão verdes, indicando que tabela e registro estão OK.

III. Programa J_1B_CBT_CONSIST

Uma ferramenta indispensável para a verificação de consistência entre as tabelas de

impostos e os registros de condições gerados é o programa J_1B_CBT_CONSIST.

Normalmente, o relacionamento entre um dado de imposto e seu respectivo registro de

condição é de 1:1. Isso significa que, para cada taxa de imposto haverá um registro de

condição. E, para cada registro de condição (de um tipo de condição utilizada na determinação

de imposto) haverá uma entrada correspondente em uma tabela de imposto.

Assim, poderá haver dois motivos para a existência de uma inconsistência, quais

sejam: quando não há um registro de condição correspondente para uma taxa de imposto; ou

quando não há uma entrada correspondente em uma tabela de imposto para um registro de

condição existente.

As razões para a existência de inconsistências podem ser:

Renata Karla 22/09/2006

a) A geração automática de condições foi desativada e, durante o período de desativação,

um dado de imposto foi criado ou modificado em uma tabela de imposto (tipo de

inconsistência 1);

b) A geração automática de condições foi desativada e, durante o período de desativação,

um dado de imposto foi deletado de uma tabela de imposto (tipo de inconsistência 2);

c) Registros de condição de impostos foram criados manualmente, através das

transações VK11 – aplicação “V” – e FV11 – aplicação “TX” (tipo de inconsistência 2);

d) Registros de condição de impostos ou a base de dados de impostos foram deletados

por algum programa existente no cliente (tipo de inconsistência 1 ou 2).

Para detectar a presença dos tipos de inconsistência acima mencionados, o

procedimento é o seguinte:

1. As inconsistências do tipo 1 são identificadas através da transação J1BTAX,

menu: Preparação da Condição/ Migração/ Tabela de Impostos para

condições, conforme descrito na seção II.4 deste manual.

2. As inconsistências do tipo 2 são identificadas através do programa

J_1B_CBT_CONSIST, que deverá ser executado via SE38. O sistema

exibirá uma lista de tabelas de condição. Pelo duplo-clique em uma tabela, o

sistema exibe todos os registros de condição existentes. A análise deverá

considerar o status de cada condição, ou seja: o status vermelho significa

que não há registro correspondente na tabela de imposto; o status amarelo

significa que existe um registro na tabela de imposto, porém, os dados não

são compatíveis; o status verde significa que existe uma entrada

correspondente na tabela de imposto. No exemplo abaixo, é possível

identificar os três tipos de status. Observe que, quando o status é vermelho,

não é determinado o nome da tabela e nem a identificação do índice.

Renata Karla 22/09/2006

Para correção destas inconsistências, deverá ser feita uma seleção de todas as

entradas com status vermelho e amarelo. Em seguida, proceder à exclusão de cada uma,

pressionando o botão , conforme abaixo:

O sistema exibirá a seguinte mensagem:

Para que o cálculo de impostos funcione corretamente, todas as tabelas de condições

deverão conter apenas entradas com status verde, conforme abaixo:

Renata Karla 22/09/2006

Para certificar-se de que há registros de condições para todos os registros de impostos,

efetuar novamente a migração de tabelas de impostos para condições, conforme descrito na

seção II.4 deste manual.

OBS.: Tabelas modificadas apresentam o ícone .

Tabelas apenas verificadas apresentam o ícone .

IV. Condições de preço+impostos:

No caso de haver mais de uma condição de preço em uma mesma pricing, todas

deverão ter entradas na tabela J_1BKON1SDVV (IMG: Contabilidade Financeira/

Configurações Globais Contabilidade Financeira/ IVA/ Configurações Globais/ Brasil/ Define

quais impostos estão contidos em condições para determinação de preços SD). Exemplo: a

pricing ZTCIEX possui duas condições de preço, quais sejam, ZSER e ZTOT (esta última é o

resultado do percentual representado na condição ZCIE sobre o valor encontrado na condição

de preço ZSER), conforme exemplo abaixo:

Pricing ZTCIEX (transação: V/08)

Resultado na Ordem de Venda (transação: VA03):

Renata Karla 22/09/2006

Entradas na tabela J_1BKON1SDVV:

Em um teste realizado apenas com entradas na tabela J_1BKON1SDVV para a

condição ZSER, quando da tentativa de faturar a ordem de venda, ocorre um erro: “Condição

‘ISSF’ não contida na fórmula de cálculo de imposto”. A condição “ISSF”, neste caso, refere-se

ao cálculo do imposto ISS e o erro ocorre com ela pois é a primeira condição de imposto a

aparecer na pricing. O que significa que tal erro se repetiria para todas as outras condições de

imposto existentes na pricing, que aparecem mais abaixo (PIS e COFINS). Como apenas a

condição ZSER tinha entradas nesta tabela, o sistema interpreta que ocorre uma

inconsistência, uma vez que a condição ZTOT é um percentual da condição ZSER, devendo,

portanto, apresentar as mesmas características (Preço + ISS + COFINS + PIS).

V. Registros de Condições:

1. Condições: DCOF, DPIS e DWHT

Registros de condições gerados automaticamente pelo sistema. Devem conter todas as

entradas existentes na tabela de códigos de imposto SD (J_1BTXSDCV). Exemplo:

Renata Karla 22/09/2006

2. Condição BCO1

Registro de condição gerado automaticamente pelo sistema, com base no registro da taxa de

COFINS, alimentado na tabela J_1BTXCOFV. Deve conter todas as entradas existentes na

tabela mencionada. Exemplo:

3. Condição BCO2

Registro de condição gerado automaticamente pelo sistema, com base no registro do montante

de COFINS, alimentado na tabela J_1BTXCOFV. Deve conter todas as entradas existentes na

tabela mencionada. Exemplo:

4. Condição BPI1

Registro de condição gerado automaticamente pelo sistema, com base no registro da taxa de

PIS, alimentado na tabela J_1BTXPISV. Deve conter todas as entradas existentes na tabela

mencionada. Exemplo:

5. Condição BPI2

Registro de condição gerado automaticamente pelo sistema, com base no registro do montante

de PIS, alimentado na tabela J_1BTXPISV. Deve conter todas as entradas existentes na tabela

mencionada. Exemplo:

Renata Karla 22/09/2006

6. Condição DISS

Registro de condição gerado automaticamente pelo sistema, com base nos códigos de imposto

SD que apresentam flag em “ISS”, existentes na tabela J_1BTXSDCV. Exemplo:

7. Condições BW11, BW21, BW31 e BW41 – BW12, BW22, BW32 e BW42

Registros de condição gerados automaticamente pelo sistema, com base nos dados

alimentados na tabela J_1BTXWITHV. Devem conter todas as entradas existentes na tabela

mencionada. Exemplos:

BW11

OBS.: os registros referentes às demais condições BW*1 são idênticos, visto que o montante-

base para cálculo dos impostos será sempre de 100%.

BW12

OBS.: os registros referentes às demais condições BW*2 são idênticos, respeitando a

diferença de alíquota cadastrada para cada imposto.

8. Condição BW51

Registro de condição gerado automaticamente pelo sistema, com base nos dados alimentados

na tabela de imposto retido com regra de acumulação (J_1BTXWITHV). Deve conter todas as

entradas existentes na tabela mencionada. Caso esse registro de condição não tenha sido

gerado corretamente pelo sistema, alguns problemas podem ser detectados diretamente na

pricing da ordem de vendas, como, por exemplo, a população tanto das condições de retenção

(final “W” – exemplo: IPSW – PIS Retido na Fonte) quanto das condições de acumulação (final

Renata Karla 22/09/2006

“Q” – exemplo: IPSQ – PIS Retido na Fonte Acumulado) de impostos. Quando a funcionalidade

de retenção/ acumulação de impostos está sendo executada corretamente pelo sistema,

apenas as condições de acumulação de impostos (IPSQ, ICOQ, ICSQ e IIRQ) e suas

respectivas condições offset (BPSZ, BCOZ, BCSZ e BIRZ) são populadas. As condições de

retenção de impostos (IPSW, ICOW, ICSW e IIRW) devem apresentar valor de condição igual a

zero. Exemplo deste registro de condição, gerado corretamente pelo sistema:

9. Condições BXWA e BXWT – cadastro via FV11. Exemplo:

10. Condição IBRX

Condição que serve de referência para várias outras condições, inclusive para as condições de

retenção e acumulação de impostos, bem como a suas respectivas condições offset. Exemplo:

11. Condição ICMO

Condição que serve de referência para várias outras condições, inclusive para as condições

offset dos impostos sobre faturamento ISS, PIS e COFINS. Exemplo:

VII. Programa RV64ANNN

Uma das instruções da SAP Note 916.003, desenvolvida para atender à necessidade de

acumulação de impostos da MP135, é a criação de duas fórmulas, que são utilizadas

diretamente na pricing standard de SD, quais sejam, fórmulas 900 e 901. Tais fórmulas devem

ser incluídas no programa RV64ANNN, conforme exemplo abaixo:

Transação: SE38

Renata Karla 22/09/2006

OBS.: a não inclusão das fórmulas 900 e 901 no programa acima acarretará a população tanto

das condições de retenção quanto das condições de acumulação de impostos, fazendo com

que as respectivas condições offset apresentem valor em dobro, e, conseqüentemente, cálculo

e contabilização de impostos incorretos.

Renata Karla 22/09/2006