Sunteți pe pagina 1din 65

TÓPICOS SELECIONADOS DE CONFIGURAÇÕES CO

Leandro Negreiros
Marina Bellini
PriceWaterhouseCoopers
Indice

Validações utilizando user exits....................................................................................4


1) Criação da exit de validação..........................................................................................4
2) Alterar o nome do programa para validações...............................................................7
3) Criar validação e associar à Área de Contabilidade de Custos...................................8
Validações sem utilização de user exits........................................................................9
1) Criação dos sets...............................................................................................................9
2) Criação da mensagem de erro para períodos em fechamento ou já fechados..........10
3) Criação da etapa de validação de lançamentos em custos no período de
fechamento.........................................................................................................................10
4) Transporte da etapa de validação criada..................................................................11
Cenário: Validações ativas com adiantamentos para pedidos de compra sem
classificação contábil..................................................................................................11
Apropriação de ordens de produção – Melhoria de performance............................15
Apropriação de Ordens de Produção x PRD gerado.................................................15
Geração de PRD e UMB.............................................................................................16
PRD e UMB lançados por centro – sem utilizar a divisão........................................16
Contas de Receita / Deduções de Venda lançadas por centro – sem utilizar a divisão
.....................................................................................................................................17
Atualização simultânea de receitas / deduções de vendas em CO-PA e CCA (ou
OPA)............................................................................................................................17
Utilização de moedas internas adicionais – Aspectos na conversão de documentos
de faturamento x Lançamentos em FI e CO-PA.......................................................18
Conversão dos campos de valor de cost estimate em CO-PA.........................................19
Planejamento Centros de Custos : alteração cotação USD planejado após
planejamento realizado...............................................................................................37
Marcação do Cálculo de Custos.................................................................................38
Cálculo de custos automático na ordem de vendas...................................................38
Cálculo de custos para materiais sem lista técnica....................................................39
Cópia de Grupos de Classes de Custo e de Centros de Custos entre mandantes......40
Mensagem “Margem de lucro é pequena demais” em ordens de venda..................40
Devolução de material configurável..........................................................................40
Tarifas Planejadas – Estratégias de Avaliação..........................................................40
Tarifas reais – iteração independente em moeda da ACC e do objeto......................41
Tamanho do Lote........................................................................................................41
Esquema de Elementos de Custos..............................................................................41
Grupos de Origem.......................................................................................................42
Inclusão de chave de desvio em materiais já cadastrados.........................................42
Desbufferização de number ranges............................................................................43
Motivo do Investimento e outros campos informativos em ordem interna de
investimento.................................................................................................................43
Criação e preenchimento automático de características definidas pelo usuário em
ordens de produção e ordens internas........................................................................43
1) Criação da característica...........................................................................................43
2) Criação da função para preenchimento automático da característica...................43
3) Criação da dependência de objetos que chamará a função criada.........................45
4) Ativação da dependência...........................................................................................46
5) Exemplo para recuperação de característica numérica..........................................46
Documento de Origem em outro sistema lógico........................................................47
Notas OSS a serem consideradas...............................................................................48
Regras de Exceção......................................................................................................51
Configuração.....................................................................................................................51
Utilização...........................................................................................................................51
Inclusão de novas características / campos de valor CO-PA num sistema e
transporte para outro..................................................................................................53
Transporte configurações e dados mestre CO-PA.....................................................53
Estorno de documentos de faturamento em CO-PA..................................................54
Reinicialização de Campos de Valor em Ordens de Venda.......................................54
Características com o mesmo nome – seleção em relatórios.....................................55
Aumento do número de posições das descrições de características nos relatórios
CO-PA..........................................................................................................................55
Cenário – Produção, Expedição e Faturamento – Negócio DCS.............................57
Cenário – Produção, Expedição e Faturamento – Negócio SID..............................57
Cenários – Faturamento sem reconhecimento da receita – receita só reconhecida
na remessa...................................................................................................................57
Cenário – Problema em lançamento em conta de custo antes da criação da classe
de custo........................................................................................................................57
Cenário – Eliminação de classes de custos de despesas com o mesmo significado de
classes de custo industrial (duplicadas).....................................................................59
Cenário: Teste de stress...............................................................................................59
Instalação sapgui 4.5..................................................................................................60
Inicialização de Classes de Custo – em centros de custos e ordens internas...........62
Inicialização de Saldos de Estoques - Alternativas....................................................62
Cenário: Procedimentos para conversão de estoques – necessidades......................63
VALIDAÇÕES UTILIZANDO USER EXITS

1) Criação da exit de validação

Copiar, através da transação SE38, o programa modelo RGGBR000, com o nome


ZGGBR000. Utilizar uma classe de desenvolvimento iniciada por Z (classes de
desenvolvimento para usuários – por exemplo, ZDES). Alterar o código fonte para adaptação
às necessidades da empresa.

Abaixo, um exemplo de código fonte, comentado:

PROGRAM ZGGBR000 .
*--------------------------------------------------------------------
*
*
*
* Substitutions: EXIT-Formpool for Uxxx-Exits
*
*
*
* Esta user-exit está sendo usada para
*
* regras de validação ou substituição.
*
*--------------------------------------------------------------------
*
INCLUDE FGBBGD00. "Data types
TYPE-POOLS: GB002.
TABLES: BKPF,
BSEG,
COBL,
GLU1, Tabelas utilizadas pela exit
AUFK,
CSKS.
*--------------------------------------------------------------------
*
* FORM GET_EXIT_TITLES
*
*--------------------------------------------------------------------
*
* A tabela a seguir contém os forms de cada regra criada
*
* Sempre que for adicionado um novo form, incluir nesta tabela
*
*--------------------------------------------------------------------
*
* TYPE Description Usage
*
* ------------------------------------------------------------
*
* C_EXIT_PARAM_NONE Use no parameter Subst. and Valid.
*
* except B_RESULT
*
* C_EXIT_PARAM_CLASS Use a type as parameter Subst. and Valid
*
*--------------------------------------------------------------------
*
* --> EXIT_TAB table with exit-name and exit-titles
*
* structure: NAME(5), PARAM(1), TITEL(60)
*--------------------------------------------------------------------
*
FORM GET_EXIT_TITLES TABLES ETAB.

DATA: BEGIN OF EXITS OCCURS 50,


NAME(5) TYPE C,
PARAM LIKE C_EXIT_PARAM_NONE,
TITLE(60) TYPE C,
END OF EXITS.

EXITS-NAME = 'U100'.
EXITS-PARAM = C_EXIT_PARAM_NONE.
EXITS-TITLE = TEXT-100. "Validações Centros de Custos
APPEND EXITS.

EXITS-NAME = 'U101'.
EXITS-PARAM = C_EXIT_PARAM_NONE.
EXITS-TITLE = TEXT-101. "Validações Ordens Internas
APPEND EXITS.

REFRESH ETAB.
LOOP AT EXITS. *1 - Verificar na documentação a
seguir como atualizar o título da exit
ETAB = EXITS.
APPEND ETAB.
ENDLOOP.

ENDFORM.

*eject
*--------------------------------------------------------------------
*
* FORM U100
*
*--------------------------------------------------------------------
*
* ler os centros de custos na tabela CSKS .
*
* Exemplo de validação de centros de custos
* Nesse exemplo, se a conta contábil estiver entre 34000000 e
* 35000000, o tipo de centro de custos deve ser Produtivo (F) ou
* Auxiliar da produção
* Se a conta contábil estiver entre 44000000 e 45000000, o centro
* de custos não deve ser um produtivo ou auxiliar da produção
*--------------------------------------------------------------------
*
* <-- B_RESULT T = True F = False
*
*--------------------------------------------------------------------
*
FORM U100 USING B_RESULT.

IF COBL-HKONT >= '0034000000'


AND COBL-HKONT < '0035000000'.

SELECT * FROM CSKS


WHERE KOSTL EQ COBL-KOSTL
AND KOKRS EQ COBL-KOKRS.
IF CSKS-DATBI >= SY-DATUM AND
CSKS-DATAB <= SY-DATUM.
IF CSKS-KOSAR = 'H'
OR CSKS-KOSAR = 'F'.
B_RESULT = B_TRUE.
ELSE.
B_RESULT = B_FALSE.
ENDIF.
ELSE.
ENDIF.
ENDSELECT.
ELSE.
IF COBL-HKONT >= '0044000000'
AND COBL-HKONT < '0045000000'.
SELECT * FROM CSKS
WHERE KOSTL EQ COBL-KOSTL
AND KOKRS EQ COBL-KOKRS.
IF CSKS-DATBI >= SY-DATUM AND
CSKS-DATAB <= SY-DATUM.

IF CSKS-KOSAR = 'H'
OR CSKS-KOSAR = 'F'.
B_RESULT = B_FALSE.
ELSE.
B_RESULT = B_TRUE.
ENDIF.
ELSE.
ENDIF.
ENDSELECT.
ELSE.
* b_result = b_false. "para simulação
ENDIF.
ENDIF.
ENDFORM.

*eject
*--------------------------------------------------------------------
*
* FORM U101
*
*--------------------------------------------------------------------
* Exemplo de validação de ordens internas
* ler tipo de ordem ;
* ordens de investimento = só podem ser
* lançadas em classes 7; outras ordens internas = classes 34
* outros tipos de ordem = não validar
*--------------------------------------------------------------------
*
* <-- B_RESULT T = True F = False
*
*--------------------------------------------------------------------
*
FORM U101 USING B_RESULT.

IF NOT COBL-AUFNR IS INITIAL.

SELECT * FROM AUFK


WHERE AUFNR = COBL-AUFNR.

** ordens lançadas somente nas classes 34 - manutenção


** atividades também podem ser lançadas nas ordens de manutenção -
** classes 9
IF COBL-HKONT IS INITIAL.
B_RESULT = B_TRUE.
ELSE.
IF AUFK-AUART = 'MT'.
IF COBL-HKONT > '0034000000'
AND COBL-HKONT <= '0035000000'.
B_RESULT = B_TRUE.
ELSE.
IF COBL-HKONT > '0090000000'
AND COBL-HKONT <= '0099999999'.
B_RESULT = B_TRUE.
ELSE.
B_RESULT = B_FALSE.
ENDIF.
ENDIF.
ELSE.

** ordens lançadas apenas nas classes 71 - investimento


** atividades também podem ser lançadas nas ordens de investimento -
** classes 9
** a apropriação de atividades pode ser lançada na conta 34999030

IF AUFK-AUART = 'INV'.
IF COBL-HKONT > '0071000000'
AND COBL-HKONT <= '0072000000'.
B_RESULT = B_TRUE.
ELSE.
IF COBL-HKONT > '0090000000'
AND COBL-HKONT <= '0099999999'.
B_RESULT = B_TRUE.
ELSE.
IF COBL-HKONT = '0034999030'.
B_RESULT = B_TRUE.
ELSE.
B_RESULT = B_FALSE.
ENDIF.
ENDIF.
ENDIF.
ELSE.

** todos os outros tipos de ordens - que não ordens internas

B_RESULT = B_TRUE.
ENDIF.
ENDIF.
ENDIF.
ENDSELECT.
ELSE.
B_RESULT = B_TRUE. "para simulação
ENDIF.
ENDFORM.

*1 – Para atualizar os títulos dos forms no programa, na transação SE38, escolher Elementos
de Texto e o botão Modificar. Na tela a seguir, escolher Símbolos de Texto e novamente o
botão Modificar. Para cada form criado (U100, U101...), criar ou modificar o título.

2) Alterar o nome do programa para validações


Após criar o programa, alterar, utilizando a transação SM31 (tabela T80D, utilizando
Atualização de Visão) o nome do programa chamado pela área funcional GBLR (Saídas para
validação) para o nome do programa gerado (ZGGBR000).

Essa configuração é dependente de mandante. Deve ser refeita a cada mandante.

3) Criar validação e associar à Área de Contabilidade de Custos

Utilizar a transação OKC7. Para criar a validação, escolher o caminho de menu Ambiente >
Validação. Escolher o momento da chamada da validação (0001 – na linha do documento ou
0100 – no cabeçalho do documento).

Incluir tantas etapas quantas forem os forms codificados na exit de validação criada – vide
item 1 (na exit de exemplo, teríamos duas etapas – U100 e U101). Para cada etapa:

Validação VALIDCO Validações CO x Classif. Contábil


Etapa 001 Validações Centros de Custos

Pressuposto
TRUE True ou False – Se false, antes de entrar na exit, assume
que sempre há erro. A exit deve mudar o valor para true.

Verificação
U100 Número do form que será chamado na exit

Serão substituídos posicionamente pelos campos de


saída HKONT (no conta) e KOSTL (no centro custo)

Tp. E Nº 000 Text U100 - A conta & não pode ser usada com o centro de custo &
Campos saída 1 COBL - HKONT 2 COBL - KOSTL
3 - 4 -

Para criar a mensagem que será exibida (no exemplo acima, a mensagem 000), escolher o
caminho de menu Ambiente > Atualizar Mensagens (ou ir diretamente na transação SE91).
Se for necessário, criar uma classe de mensagem iniciada por Z (Z0, por exemplo), criada
numa classe de desenvolvimento também iniciada por Z (por exemplo, ZFUN ou ZDES).

Após criada a classe de mensagem, clicar em Mensagens e no botão Modificar. Dar Duplo
clique num número de mensagem livre e escrever a mensagem resumida (a que aparecerá
na tela em caso de erro).

Para criar a mensagem descritiva (a que aparece com o duplo clique em cima da mensagem
de erro), escolher o caminho de menu Saltar > Documentação > Texto Descritivo e, por
exemplo:

....+....1....+....2....+....3....+....4....+....5....+....6....+....7..
U2 Diagnóstico
* Se a ordem interna informada for do tipo INV (Investimento), a classe
/ de custo informada no lançamento deve iniciar por 71.
/ Se for do tipo MT (Manutenção), ela deve iniciar por 34.
U2 Atividades do Sistema
* Mensagem de erro
U2 Procedimento
* Em um lançamento direto de FI, altere a classificação contábil (conta
/ contábil) do lançamento.
/ Numa requisição de compras ou pedido de material, verifique a categoria
/ de classificação contábil do item (Deve ser F para ordens internas de
/ manutenção e Y para ordens internas de investimento)
/ Num movimento de material (consumo de estoque, por exemplo), existem
/ tipos de movimento específicos para ordens de manutenção e
/ investimento.
OBS:

U2 - Highlight
* - Salta uma linha antes de escrever
/ - linha normal

Após criada a validação, suas etapas e mensagens, associá-las às áreas de contabilidade de


custos necessárias e ativá-las (Grau de ativação na transação OKC7).

VALIDAÇÕES SEM UTILIZAÇÃO DE USER EXITS

Exemplo: Bloquear as contas de custos industriais para que elas só possam receber
lançamentos realizados por usuários que trabalhem no fechamento de custos. Dessa forma,
os centros de custos produtivos não receberão mais lançamentos feitos por usuários de
materiais, vendas ou contabilidade, impedindo rateios insuficientes.

Esta validação será incluída nas validações de FI (ao invés das validações de CO), pois
necessitaremos utilizar dados que estão no cabeçalho do documento (usuário e data do
lançamento) e nos itens (conta contábil). Na validação em CO (OKC7), não podemos
misturar as duas informações.

Serão criados:

1) 1 set contendo todas as contas de custos industriais


2) 1 set contendo os usuários autorizados a efetuar lançamentos (usuários autorizados ao
fechamento de custos)
3) 1 set contendo os intervalos de datas para os quais o lançamentos estarão bloqueados
para os demais usuários

Vantagem dessa solução em relação ao bloqueio através de grupos de


autorização pela transação OB52 (Fechar período de lançamento):

A transação OB52 somente permite que sejam informados grupos de autorização para todas
as contas (Tipo de conta = +). Pode acontecer que no fechamento, usuários da contabilidade
precisem estar nesse grupo, sendo possível que eles lancem valores nas contas de custos
industriais. A solução pela validação é mais restritiva.

Passos a serem executados:

1) Criação dos sets

Utilizar o menu funcional, no caminho Sistemas Info > Relatórios ad hoc > Report painter >
Report writer > Set > Criar (transação GS01)

1.1) Set de contas de custo industrial

Informar um nome para o set, por exemplo ZSET_CONTA. Em dados básicos, informar
Tabela = BSEG; Em tipo de set, marcar Set-básico. Enter. Na janela a seguir, informar nome
do campo (da tabela) = HKONT.

Na próxima tela, informar uma descrição; deixar o campo verificação de univocidade como
“só antes de gravar” (é o default). Ainda nessa tela, selecionar o caminho de menu Saltar >

Linha Set (ou clicar o botão ). Informar o intervalo de contas permitido (por exemplo de
34000000 até 34999999). Salvar.
1.2) Set de usuários autorizados

Proceder da mesma forma que 1.1, com os seguintes dados:

Nome do set: ZSET_USER

Tabela: BKPF
Campo: USNAM

Nas linhas do set (botão ), informar as chaves de usuários permitidos (FSLXXXX,


UZ020XX, por exemplo).

1.3) Set de datas em fechamento

Proceder como em 1.1, com os dados:

Nome do set: ZSET_DATA


Tabela: BKPF
Campo: BUDAT

Não se deve informar nenhuma linha de set, no momento da criação desse set. Os seus
valores devem ser atualizados no momento do fechamento contábil. Antes de iniciar o
fechamento contábil, atualizar esse set (chamando a transação GS02 – Modificar set –

clicando o botão ), e incluindo uma linha contendo a data inicial (em de) e a data final
(em até) do mês em fechamento. Por exemplo, antes de iniciar o fechamento do período
09/1999, incluir no set ZSET_DATA o intervalo 01.09.1999 até 31.09.1999 (ou então alterar o
intervalo já existente, colocando como data até 31.09.1999).

2) Criação da mensagem de erro para períodos em fechamento ou já


fechados

Se a classe de mensagens ZF não estiver criada, proceder de acordo com o item 3 do tópico
Validações utilizando user exits. Se já existir, chamar a transação SE91, informando a classe
ZF; clicar no botão Modificar. Dar Duplo clique num número de mensagem livre e escrever a
mensagem resumida (a que aparecerá na tela em caso de erro), por exemplo: UCO1 -
Período &/&fechado para lançamentos em contas de custos industriais. Gravar a mensagem.

Para criar a mensagem descritiva (a que aparece com o duplo clique em cima da mensagem
de erro), escolher o caminho de menu Saltar > Documentação > Texto Descritivo e, digitar
por exemplo:

....+....1....+....2....+....3....+....4....+....5....+....6....+....7..
U2 Diagnóstico
* Lançamentos em classes de custos iniciadas por 34 só são permitidos na
/ data de lançamento informada para usuários autorizados ao fechamento de
/ custos
U2 Atividades do sistema
* Mensagem de erro
U2 Procedimento
/ Verificar a data do lançamento. Caso esteja correta, contactar o
/ responsável pelo fechamento contábil para que o lançamento seja efetuado
/ por ele.

3) Criação da etapa de validação de lançamentos em custos no período


de fechamento
Se a validação já estiver criada, proceder como a seguir. Senão, referir-se ao item 3 do
tópico Validações utilizando user exits. Apesar das transações utilizadas serem diferentes (no
item 3 é utilizada a transação OKC7; aqui, utilizaremos a transação OB28 – caminho no IMG:
Contabilidade financeira > Opções básicas da contabilidade financeira > Doc. > Cabeç.doc >
Definir validações para lançamentos), a interface é igual, mudando ACC por Empresa, e
criando uma validação para o momento 2 (item do documento).

Utilizando a transação OB28, dar duplo clique na validação para a empresa desejada. Na
próxima tela, entrar . Escolher o caminho de menu Processar > Inserir entrada. Dar um nome
para a nova etapa, por exemplo, Fechamento de custos

Validação BL_S_RN Bloqueio Solicitação de Adto


Etapa 001 Fechamento de custos

Pressuposto
BKPF-BUDAT IN 0000ZSET_DATA AND BSEG-HKONT IN
0000ZSET_CONTA Se a data de lançamento estiver cadastrada no set de
datas onde o lançamento não é permitido para todos
os usuários e a conta contábil estiver no intervalo de
contas de custos …
Verificação
BKPF-USNAM IN 0000ZSET_USER … então, para que o lançamento seja
permitido, é necessário que a chave do
usuário esteja cadastrada no set de
usuários

Serão substituídos posicionamente pelos campos de


saída MONAT (período contábil) e GJAHR (exercício)

Tp. E Nº 001 Text UCO1 – Período &/& fechado para lançamentos em contas de custos
Campos saída 1 BKPF - MONAT 2 BKPF - GJAHR
3 - 4 -

4) Transporte da etapa de validação criada

Na transação OB28, selecionar o caminho de menu Visão de tabela > transporte. Criar uma
nova ordem de transporte. Selecionar a validação a ser transportada. Escolher o caminho de
menu Processar > Incluir na ordem. Escolher o caminho de menu Seleção > Tudo incl. na
ordem. Gravar.

Entrar novamente na transação OB28. Dar duplo clique na validação a ser transportada. Na
tela seguinte, escolher o caminho de menu Validação > Transporte. Na tela seguinte,
selecionar regras lógicas, transportar sets e mensagens. Clicar executar, criando uma nova
ordem para esse transporte. Esse transporte já levará todos os objetos relacionados à
validação, inclusive os sets e a mensagem criada.

CENÁRIO: VALIDAÇÕES ATIVAS COM ADIANTAMENTOS PARA PEDIDOS DE COMPRA


SEM CLASSIFICAÇÃO CONTÁBIL
Cenário

1. criado um pedido de compra com classificação contábil U (pedido ainda não tem
classificação contábil conhecida)
2. solicitado adiantamento a fornecedor com referência a esse pedido
> sistema apresenta mensagem de erro dizendo que classificação contábil U não pode
receber lançamentos
> apesar do sistema não efetuar lançamentos em CO no adiantamento (fornecedor x banco)
ele requer que o sistema já tenha feita a classificação contábil para um pedido para poder
permitir qualquer operação vinculada a este pedido (centro de custo, ordem ou projeto)
3. posteriormente o pedido receberia classificação contábil adequada e seus parâmetros de
rateio

Solução
Utilização de ordem interna / centro de custo / projeto "bobo" ao invés de classificação
contábil desconhecida (U) em pedidos de compra. Para isso, é preciso:

Alteração de procedimentos

1.criar um pedido com classificação contábil K ou F ou P colocando o objeto de custo "bobo"


(por exemplo, sempre um centro de custos “bobo”)
2. solicitar adiantamento, quando necessário
3. ao fazer medição serviço/recebimento alterar a classificação do pedido para CC ou OI ou
PS corretos com as devidas regras de rateio (se esta alteração não for feita o sistema emitirá
mensagem de erro impedindo o recebimento no pedido - devido à regra de validação)

Alteração de configurações

1. definir e criar centro de custo "bobo" XXXX


2. alterar regra de validação de CO

seguindo os passos:

a. Já existindo uma regra de validação (sem utilizar user-exit), que só permitisse o


lançamento em contas de custos industriais se fossem informados centros de custos
produtivos ou auxiliares de produção, por exemplo:

Validação VALIDCO Validações CO x Classif. Contábil


Etapa 001 Validações Centros de Custos
Se a conta contábil informada estiver no set de contas
Pressuposto de custos industriais (esse set deve estar construído e
COBL-HKONT IN 0000VALID_CC com os valores adequados

Verificação … então, para que o lançamento seja


permitido, é necessário que o centro de
COBL-KOSTL IN 0000Z_SET_PROD custo informado esteja no set de centros
produtivos ou auxiliares de produção

Serão substituídos posicionamente pelos campos de


saída HKONT (no conta) e KOSTL (no centro custo)

Tp. E Nº 000 Text U100 - A conta & não pode ser usada com o centro de custo &
Campos saída 1 COBL - HKONT 2 COBL - KOSTL
3 - 4 -
Teoricamente, teríamos apenas que alterar esse passo da regra de validação, com o
seguinte:

Pressuposto
COBL-HKONT IN 0000VALID_CC AND COBL-AUFNR = '' AND
COBL-PS_PSP_PNR = '' Se a conta contábil informada estiver no set de contas
de custos industriais e ordem interna não estiver
preenchida e numero projeto não estiver preenchido

Verificação
COBL-KOSTL IN 0000Z_SET_PROD OR COBL-KOSTL = 'centro de custo dummy'
… então, para que o lançamento seja
permitido, é necessário que o centro de
custo informado esteja no set de centros
produtivos ou auxiliares de produção ou ele
seja o cc dummy

Porém o acesso ao campo COBL-PS_PSP_PNR nem sempre é recuperado de forma


satisfatória (intermitentemente retorna a mensagem de erro GB311). Para que o acesso
sempre seja feito de forma correta, é preciso utilizar a função
'CONVERSION_EXIT_KONPR_OUTPUT' (verificar nota 77268). Então, é necessário mudar
a validação para que ela acesse uma exit, por exemplo U111, com o código:

FORM U111 USING B_RESULT.


DATA: AUX-PROJETO(24) TYPE C.
B_RESULT = B_FALSE.
CALL FUNCTION 'CONVERSION_EXIT_KONPR_OUTPUT'
EXPORTING
INPUT = COBL-PS_PSP_PNR
IMPORTING
OUTPUT = AUX-PROJETO.

IF COBL-HKONT IN 0000VALID_CC AND COBL-AUFNR = '' AND


AUX-PROJETO = '' .
IF COBL-KOSTL IN 0000Z_SET_TODOS OR COBL-KOSTL = 'centro de custo dummy'.
B_RESULT=B_TRUE.
ENDIF.
ELSE.
B_RESULT=B_TRUE.
ENDIF.
ENDFORM.

Além disso, é necessário criar uma outra etapa de validação, para que o sistema não permita
lançamento real no centro de custo 'bobo'. Para isso,

b. criar set de tipo de documento com todos os tipos de documentos

Set-básic Z_SET_DOC
Tabela COBK
Nome do campo BLART
Nº DE valor ATÉ valor Te
001 AA ZZ
002 01 99

c. criar mensagem: O objeto & não pode receber lançamentos

onde & irá corresponder a:


COBL-KOSTL
d. Criar nova etapa na regra de validação:

Pressuposto:
COBK-BLART IN 0000Z_SET_DOC

Verificação
COBL-KOSTL <> 'centro de custo dummy'

> por que tipo de documento? pois é uma informação que só aparece em CO nos
lançamentos reais e planejados, em compromisso não aparece, pois não tem
documento, só informação, e não haverá planejamento para estes objetos de custos

> verificar que a ordem interna e o projeto tenham um esquema de status que permita
lançamento de compromisso mesmo sem orçar
APROPRIAÇÃO DE ORDENS DE PRODUÇÃO – MELHORIA DE PERFORMANCE

Não existe opção de "server group" na transação CO88 para versões anteriores a 4.5 para
diminuirmos o tempo de processamento de apropriação de ordens de produção.

Existem outras duas sugestões:

1. rodar a execução por grupos de ordens, de forma a processar várias vezes o


processamento coletivo ao mesmo tempo, utilizando-se do report rkoco88. (conforme notas
OSS 64048 e nota 172325) > necessário criar grupos de ordens e disparar o reporting uma
vez para cada grupo de ordem.

2. do segundo mês em produção em diante, setar o flag de deleção (para posterior


archiving) via transação co78 nas ordens encerradas no mês anterior, de forma que estas
não sejam capturadas na apropriação coletiva do mês em questão. (conforme nota 38855,
parágrafo 3).

APROPRIAÇÃO DE ORDENS DE PRODUÇÃO X PRD GERADO

Os lançamentos a crédito por apropriação real da ordem de produção serão feitos da


seguinte forma :

1) Na entrada do material produzido no estoque de ordem de cliente:

O sistema toma o valor do custo estimado na ordem de venda, proporcionalizado à


quantidade da ordem de produção. Mesmo que a ordem de produção tenha diferenças no
roteiro ou na utilização de matérias-primas, o que é levado em conta são as especificações
da ordem de venda.

2) Na apropriação da ordem de produção

2.1) Se nenhuma remessa do material houver sido feita, o sistema ajusta o valor a crédito
lançado pelo roteiro e matérias primas efetivamente utilizadas (inclusive por diferenças de
quantidade). Ajusta também o valor do estoque da ordem de cliente. O sistema utilizará o
preço real da matéria-prima (no caso de estarmos utilizando o preço médio móvel do
material); e a tarifa planejada das atividades.

2.2) Se já houve remessa, parcial ou total, o sistema ajusta o valor a crédito lançado pelo
roteiro e matérias-primas efetivamente utilizadas, utilizando o preço real da matéria-prima e a
tarifa planejada das atividades. A diferença do ajuste será proporcionalizada pela quantidade
já remetida e a quantidade ainda em estoque. A parcela referente à quantidade já remetida
será lançada como PRD; a outra parcela será ajustada no estoque da ordem do cliente. Se
todo o estoque já houver sido remetido, tudo será lançado em PRD.

3) No cálculo das tarifas reais das atividades

O sistema ajusta o valor a crédito trocando os valores calculados pela tarifa planejada pela
tarifa real. Valem as mesmas observações de 2.1 e 2.2.

Efeitos da apropriação da ordem ao longo do mês x ao final do mês

Se for possível a apropriação ao longo do mês, antes das remessas serem feitas, o volume
de PRD gerado será menor (pelo efeito de 2.1). Como só teremos a tarifa real no final do
mês, e provavelmente todas as remessas devam ter sido efetuadas, independentemente da
apropriação ser feita ao longo ou no final do mês, a geração de PRD causada por 3 será do
mesmo volume.
GERAÇÃO DE PRD E UMB

1) A apropriação se dá num mês, e o mês seguinte ainda não está aberto para lançamentos
em MM

Nesse caso, se alguma quantidade de estoque já tiver sido remetida, a diferença entre
planejado e real vai gerar um PRD proporcional à quantidade remetida (se nada foi remetido,
nenhum PRD é gerado; se tudo foi remetido, é tudo PRD; senão, o PRD é proporcional à
quantidade ainda em estoque).

2) A apropriação se dá num mês, e o mês seguinte está aberto para lançamentos em MM

Nesse caso, são avaliadas as quantidades em estoque na data da apropriação (mês da


apropriação) e na data do mês seguinte (que na verdade é o mês corrente para
lançamentos), e podem ocorrer o seguinte:

Se alguma quantidade de estoque já tiver sido remetida no mês em que estiver sendo feita a
apropriação, a diferença entre planejado e real vai gerar um PRD proporcional a essa
quantidade remetida (e esse PRD será lançado com a data da apropriação); se,
adicionalmente, alguma quantidade de estoque tiver sido remetida no mês seguinte à
apropriação (que na verdade é o período corrente), vai também ser gerado uma UMB
proporcional a esse delta de quantidade remetida.

Exemplo UMB

Suponha que ao final do mês 06 eu tenha um estoque de 10 UNIDADES de um produto a R$


10, totalizando um estoque de R$ 100, mas ainda não fechei esse mês. No dia 03.07, vou
encerrar o mês 06, e meu estoque já foi movimentado e tem um estoque de 1 UNIDADE aos
mesmos R$ 10, totalizando um estoque de R$ 10.

Ao fazer a apropriação das ordens de produção, descubro que o preço de cada unidade do
produto ao final do mës é de R$ 11 ao invés de R$ 10, o que significa um acréscimo de R$
10,00 ao estoque final. Ora, o estoque do dia 03.07 também deve ser ajustado, mas não
somando R$ 10 (senão o preço unitário do produto ficaria por R$ 20). Ora, o sistema
ajustará mais R$ 1,00 ao preço unitário do produto, aumentando o estoque para R$ 11,00.
Os outros R$ 9,00 sáo lançados para a conta de UMB.

Se a localização estivesse ativa, depois o sistema buscaria esses lançamentos e acabaria


jogando a diferença para uma conta de CPV. Como ainda não temos a localização, isso vai
ter que ser um lançamento manual em FI, retirando da conta de UMB e lançando no CPV.

PRD E UMB LANÇADOS POR CENTRO – SEM UTILIZAR A DIVISÃO

1) Em lançamentos de apropriação de ordem, não adianta configurar OKB9 - não tem como

2) A única maneira de jogar PRD (e UMB) em diferentes centros de custos é:

Na transação OMWD, criar grupos de área de avaliação para cada uma das plantas
existentes:

Área aval. Empresa Nome da firma PlanoCtas Cód.agrup.aval.


0001 0001 SAP Brazil INT 0001
FA01 FAS1 FASAL S.A PDCS 0001
FA02 FAS1 FASAL S.A PDCS 0002
FA03 FAS1 FASAL S.A PDCS 0003

Na transação OBYC, escolher a operação PRD (e UMB se necessária), clicar no botão


Regras e marcar :

Plano de contas PDCS Pl.Contas Distrib./Centro Serviços (F


Operação PRD Diferenças de preços

Débito/Crédito 
Modif.cta 
CódAgrAval 
ClassAval 

Após, recadastrar as classificações. Para cada classe de avaliação / código de grupo de


avaliação deve ser criada uma conta contábil / classe de custos, ou seja, para cada filial vai
haver nessa solução uma classe de custos diferente (por exemplo, 34999030 para PRD da
filial 1, 34999031 para PRD da filial 2, 34999032 da filial 3). A cada uma dessas classes de
custos deve ser ligado um centro de custos (na OKB9).

CONTAS DE RECEITA / DEDUÇÕES DE VENDA LANÇADAS POR CENTRO – SEM


UTILIZAR A DIVISÃO

Pode-se utilizar a transação OVF3 para determinar um centro de custos para cada
combinação Organização de Vendas / Canal de Distribuição / Setor de Atividade / Motivo da
ordem.

ATUALIZAÇÃO SIMULTÂNEA DE RECEITAS / DEDUÇÕES DE VENDAS EM CO-PA E


CCA (OU OPA)

Para que os lançamentos originados por faturas de SD sejam lançados em CO-PA e CCA,
simultaneamente, é necessário proceder de acordo com a nota OSS 28068 (senão o
lançamento somente será feito em CO-PA), ativando a substituição padrão 0_SCO10
(através da transação OKC9) para as áreas de contabilidade de custos.
UTILIZAÇÃO DE MOEDAS INTERNAS ADICIONAIS – ASPECTOS NA CONVERSÃO DE
DOCUMENTOS DE FATURAMENTO X LANÇAMENTOS EM FI E CO-PA

Para evitar diferenças de taxas de conversão entre FI e CO-PA nos lançamentos de receitas /
deduções de vendas, a configuração de moedas internas adicionais (transação OB22) deve
estar:

Tipo moeda 10 Moeda da empresa Moeda BRL


Ctg.câmbio M Conversão standard com câmbio médio
Moeda base 1 Conversão a partir da moeda de transação
TpDtConv. 3 Data de conversão

Tipo moeda 40 Moeda forte Moeda USD


Ctg.câmbio M Conversão standard com câmbio médio
Moeda base 1 Conversão a partir da moeda de transação
TpDtConv. 3 Data de conversão

Tipo moeda 50 Moeda index. Moeda UMC


Ctg.câmbio M Conversão standard com câmbio médio
Moeda base 1 Conversão a partir da moeda de transação
TpDtConv. 3 Data de conversão

Se a Moeda base estiver 2 (Conversão a partir da moeda interna 1), o sistema converterá
primeiramente para BRL, e depois fará a conversão para dólares e UMC. Esses dois passos
na conversão podem gerar diferenças com os valores lançados em CO-PA (supondo que a
moeda da área de resultado seja USD e moeda da empresa = BRL).

Outra configuração em FI que afeta as conversões efetuadas é a da transação OB07:


CgCâ Utilização Moeda Base
FRF Conversão UME EUR
G Conversão standard com câ BRL
IEP Conversão UME EUR
ITL Conversão UME EUR
LUF Conversão UME EUR
M Conversão standard com câ BRL
NGL Conversão UME EUR
O Conversão standard p/ orç BRL
P Conversão standard p/plan BRL
PTE Conversão UME EUR
XEU Conversão UME EUR

A moeda base preenchida significa que o sistema fará todas as conversões passando por
ela, ou seja, se por exemplo, for necessária uma conversão da moeda Yen para USD pela
taxa M, não adianta estar cadastrada a cotação M Yen -> USD. O sistema sempre buscará a
taxa M Yen -> BRL, e a dividirá pela taxa M USD -> BRL para achar a cotação M Yen ->
USD.

Para que não haja confusões, é melhor que, se esta configuração indicar moeda base, seja
estabelecido um procedimento impedindo o cadastramento de taxas de uma outra moeda em
relação a outra que não seja a moeda base.

Outro fator a ser considerado é que, se a data de conversão (no documento FI) divergir da
data de lançamento, a conversão em CO-PA será feita pela data do lançamento. Para
corrigir, aplicar a nota OSS 134358.
Conversão dos campos de valor de cost estimate em CO-PA

For sales documents which pricing procedure uses a currency other than the company code
currency, there is a problem with the currency conversion of fields which are filled by means
of CO-PA valuation with product costing. Let me start by explaining the conversion logic as it
is currently implemented in the SAP standard:

1. During CO-PA valuation product cost data are read either in company code currency
( which is the standard ) or in controlling area currency ( special option ). The valuation
converts these data from company code currency ( or controlling area currency ) into
operating concern currency. Taking into account the valuation date the system uses an
exchange rate of type 'M' for this conversion.

2. Since CO-PA valuation is called up only once i.e. for the line item of currency type 'B0'
the fields filled by valuation with product costing are converted back from operating concern
currency into company code currency when the CO-PA line-item of currency type '10' is
created.

The problem is that the conversion rate used in this second conversion is sometimes not
identical with the exchange rate of type 'M' that was previously used in the valuation module
(it uses the exchange rate of the document; as the majority of the documents uses exchange
rate type G, it’s this rate that is used).

Example taken from sales order 1570:

Value Field ‘B0’ line item ‘10’ line item


Fixed Costs 942,37 USD 1884,74 BRL
Variable Costs 264,41 USD 528,82 BRL

The product cost estimate from sales order 1570 gives a total value of 2125,15 BRL with a
fixed amount of 1659,52 BRL and a variable amount of 465,63 BRL.

The system performs the following calculation:

a) 1659,52 BRL divided by 1,761 ( BRL/USD ) exchange rate type 'M' gives 942,37 USD ( -->
see 'B0' item );
942,37 USD times 2,000 ( BRL/USD ) exchange rate type ‘G’ gives 1884,74 BRL ( --> see
currency type '10' item )

b) 465,63 BRL divided by 1,761 ( BRL/USD ) exchange rate type 'M' gives 264,41 USD ( -->
see 'B0' item );
264,41 USD times 2,000 ( BRL/USD ) exchange rate type ‘G’ gives 528,82 BRL ( --> see
currency type '10' item )

The same problem applies to sales conditions EK02 and VPRS.

I am afraid that as of jet there is no fix available to change the logic that is used in CO-PA
currency conversion. While it is conceivable to implement a correction that changes the logic
for those value fields that are field by valuation with product costing in such a way that
exchange rate type 'M' is used when the conversion from operating concern currency ( 'B0'
line-item ) to company code currency ( '10' line-item ) is done there is certainly no chance to
create a standard fix such a to use different exchange rates for cost carrying conditions types
such as EK02, ZEK2, ZEK0, VPRS ... on the one side and conditions types carrying revenues
or revenue deductions on the other side.

What options are available at this point? Considering the transfer of billing documents I
suggest that you consider taking advantage of CO-PA enhancement COPA0005 ( Exit
'EXIT_SAPLKEII_002' ). In this exit you have access to all record type 'F' items just before
these items are posted ( i.e. after derivation and valuation ). At this point it would be possible
to:

1. change the value fields 'VVCSF' (fixed costs) and 'VVCSV' (variable costs) in the
currency type '10' line-item

2. change the value field VVCRP (total costs) in currency type 'B0' and '10' line-items such
as to use exchange rate type 'M' when converting from transaction currency to operating
concern currency and company code currency

Considering the transfer of sales orders there is no exit available in the SAP standard that
would allow you to access the 'B0' and '10' items just before they are being posted. However,
it is conceivable to implement such an exit with a very small modification in your system.
In this exit you would have to do the same changes as in CO-PA enhancement COPA0005
( Exit 'EXIT_SAPLKEII_002' ) for the billing documents; I suggest that you create an external
perform in template programm RKEVRK2S as shown below. 'ZZCOPAEXIT' is a user defined
program that contains a form called 'modify_order_items'.
Table gt_item_post_new contains the CO-PA line items that are to be posted.
Please note that program RKEVRK2S is merely a template program for generating the 'actual'
program RK2Sxxxx (xxxx = name of the operating concern) which is called during the update
of actual data. In order to create the 'actual' program use transaction 'SE37' and call up
function module 'RKE_GENERATE_INTERFACE_ACT' for the operating concerns in your
system.

Changes to program RKEVRK2S :


...
*-------------------------------------------------------------------*
* Verbuchung der Einzelposten in der Ergebnisrechnung
*-------------------------------------------------------------------*
* --> V_TKEBL Ledger/Waehrungstypen
*-------------------------------------------------------------------*
FORM POST_ACTUAL_ITEMS USING IT_V_TKEBL TYPE RKEA1_T_V_TKEBL.

* post reversed items


PERFORM POST_ITEMS TABLES GT_ITEM_POST_REV
USING IT_V_TKEBL
'X'.

*Start of insertion "<-- Insert


perform modify_order_items in program 'ZZCOPAEXIT' "<-- Insert
tables gt_item_post_new "<-- Insert
*End of insertion "<-- Insert

* post new items


PERFORM POST_ITEMS TABLES GT_ITEM_POST_NEW
USING IT_V_TKEBL
' '.
* initialize data for next posting
CLEAR: GT_ITEM_POST_REV[],
GT_ITEM_POST_NEW[].

ENDFORM.
...

I think the easiest way to solve the valuation problem for the ledger '02' line-items is to call the
standard CO-PA valuation function module for the ledger(s) separarely. I have written a little
function module that allows you to call the standard valuation function module from within
your user-exits.
All you need to do is to set up some standard CO-PA valuation customizing for record type 'A'.
The different ways to access product cost information can be realized by means of the
function 'Assign costing keys to other characteristics' ( see CO-PA IMG path 'master data -->
valuation --> product costing' ).

Accessing the material prices from the material master can be done by means of the
valuation with 'Conditions and costing sheets'.

In order to implement the function module listed below you have to create a function group via
'SE37 --> GoTo --> function groups create'.

In this function group you can create a function module

Z_COPA_VALUATION_XXXX

where XXXX is the name of your operating concern. When you create the function module
please make sure that you set the processing type to 'Remote function call supported'! You
call call up the function module in both the billing document exit and the sales order exit.
This way you avoid reading tables such as keko and keph directly. You also don't have to
worry about the problem how to read the sales order product costing estimate at the time
when the sales order is created ( provided you set up your valuation customizing for record
type 'A' ).

Please replace 'S001' by the name of your operating concern

FUNCTION Z_COPA_VALUATION_S001.
*"-------------------------------------------------------------------
*"*"Lokale Schnittstelle:
*" IMPORTING

*" VALUE(I_KURST) LIKE TKEVS-KURST


*" VALUE(I_COPA_ITEM) LIKE CE1S001 STRUCTURE CE1S001 <--!!
*" EXPORTING
*" VALUE(E_COPA_ITEM) LIKE CE1S001 STRUCTURE CE1S001 <--!!
*" EXCEPTIONS
*" VALUATION_ERROR
*"-------------------------------------------------------------------

CONSTANTS: C_ERKRS LIKE TKEB-ERKRS VALUE 'S001'. <--!!

DATA: BEGIN OF LT_FIELDTAB OCCURS 60.


INCLUDE STRUCTURE DD03P.
INCLUDE STRUCTURE CEFLD.
DATA: END OF LT_FIELDTAB.

CALL FUNCTION 'RKE_PRICING_INTERFACE_ACT'


EXPORTING
ERKRS = C_ERKRS
KURST = I_KURST
RKE_EINZELPOSTEN = I_COPA_ITEM
IMPORTING
BEWERTETER_EP = E_COPA_ITEM
TABLES
DBTAB = LT_FIELDTAB
EXCEPTIONS
OTHERS = 1.

IF SY-SUBRC <> 0.
MESSAGE ID SY-MSGID
TYPE SY-MSGTY
NUMBER SY-MSGNO
WITH SY-MSGV1
SY-MSGV2
SY-MSGV3
SY-MSGV4
RAISING VALUATION_ERROR.
ENDIF.

ENDFUNCTION.

Soluções implementadas:

Para ordens de venda: utilizando a modificação no programa RKEVRK2S, a função


ZCOPA_VALUATION_RCOS e o programa definido pelo usuário, chamado no programa
RKEVRK2S:

report zzcopaexit_mod_values .

form modify_order_items tables t_item structure ce1rcos.

*--> tabelas
TABLES: TCURR, " taxa de conversao
MBEW. " mestre de materiais

*--> variáveis
DATA: LINE_ITEM_RCOS LIKE CE1RCOS,
LINE_ITEM_RCOS_AT LIKE CE1RCOS,
TIPO_TAXA LIKE TKEVS-KURST VALUE 'M'.

DATA: TAXA LIKE TCURR-UKURS, " taxa cambio


estrang
AUX_VBELN LIKE CE1RCOS-KAUFN, " nº docto ref aux
AUX_KDPOS LIKE CE1RCOS-KDPOS, " nº item ordem
venda
AUX_MOEDA LIKE CE1RCOS-REC_WAERS, " taxa cambio aux
AUX_FIXO LIKE CE1RCOS-VVCSF,
AUX_VAR LIKE CE1RCOS-VVCSV,
AUX_TOTAL LIKE CE1RCOS-VVCSV,
NUM_CONDICAO LIKE VBRK-KNUMV,
OUTRA_MOEDA(4) TYPE C, " campo logico
AUX-TPPPROD(3) TYPE C.

*********************************************************************
* O objetivo dessa exit é acertar os valores dos campos de valor de
* custos em CO-PA para ordens de venda. Esses valores, quando o
* esquema de preços da ordem vem em moeda diferente de reais, são
* convertidos de forma errada: ao invés de utilizarem a taxa de
* câmbio M (que é a utilizada no lançamento de CPV), utilizam a taxa
* de câmbio G - a mesma do faturamento, o que faz com que os valores
* em reais fiquem incorretos
*
* A exit fará:
* No caso dos produtos Make-to-order, chamará a função padrão de
* avaliação CO-PA; a função já retornará os valores convertidos pela
* taxa média USD - BRL; o mesmo ocorrerá no caso dos produtos make-
* to-stock com roteiro e lista técnica (produtos de estoque e
* subprodutos)
*
* No caso dos produtos Make-to-stock simples, buscará o valor
* em reais no mestre de materiais, e ajustará à quantidade faturada
*
* Esta exit contem a mesma lógica do include ZXKKEU08 (que faz a
* mesma coisa para os documentos de faturamento), só mudando o ajuste
* para a quantidade da ordem, ao invés da quantidade da fatura, no
* caso dos produtos MTO
*********************************************************************
LOOP AT T_ITEM INTO LINE_ITEM_RCOS.

IF LINE_ITEM_RCOS-COPA_AWTYP = 'SD00' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDIN' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDOR' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'VBRK'.

* somente precisa ajustar se for lançamento; se for estorno não

IF LINE_ITEM_RCOS-STO_BELNR IS INITIAL.

* verifica se o esquema de precos do faturamento é em reais ou outra


* moeda. Só precisa ajustar no caso de outra moeda

IF AUX_VBELN <> LINE_ITEM_RCOS-KAUFN.


MOVE 'FALSE' TO OUTRA_MOEDA.
MOVE LINE_ITEM_RCOS-FRWAE TO AUX_MOEDA.
ENDIF.
IF AUX_MOEDA <> 'BRL'.
OUTRA_MOEDA = 'TRUE'.
ENDIF.
ENDIF.

IF OUTRA_MOEDA = 'TRUE'.
IF LINE_ITEM_RCOS-WWEQU = 'X'.
IF LINE_ITEM_RCOS-WWTVD = 'O'.
MOVE 'MTO' TO AUX-TPPPROD.
ELSE.
IF LINE_ITEM_RCOS-WWTVD = 'E' OR
LINE_ITEM_RCOS-WWTVD = 'B'.
MOVE 'MTL' TO AUX-TPPPROD.
ELSE.
MOVE 'MTS' TO AUX-TPPPROD.
ENDIF.
ENDIF.
ELSE.
MOVE 'MTS' TO AUX-TPPPROD.
ENDIF.

IF AUX_KDPOS <> LINE_ITEM_RCOS-KDPOS.


MOVE LINE_ITEM_RCOS-KDPOS TO AUX_KDPOS.

*** No caso dos produtos make to stock, buscará o preço médio móvel
*** ou o preco standard no mestre de materiais, dependendo do
*** controle de precos
***
*** A EXIT NAO SE PREOCUPA - NO CASO DE MTS SIMPLES EM
*** AJUSTAR A QUANTIDADE NO CASO DA UNIDADE DA QUANTIDADE NA ORDEM DE
*** VENDAS SER DIFERENTE DA UNIDADE DA QUANTIDADE NO CÁLCULO DE
*** CUSTOS:NUNCA SERÃO DIFERENTES
***
*** A EXIT INFORMA O CENTRO FIXO 'CS01' NO SELECT DA MBEW, POIS SÓ HÁ
*** UM CENTRO HOJE; SE HOUVER MAIS CENTROS, SERÁ NECESSÁRIO UTILIZAR
*** A CARACTERÍSTICA CENTRO EM CO-PA PARA FAZER ESSE SELECT
***
IF AUX-TPPPROD = 'MTS'.

SELECT VPRSV VERPR STPRS PEINH INTO


(MBEW-VPRSV, MBEW-VERPR, MBEW-STPRS, MBEW-PEINH)
FROM MBEW WHERE MATNR = LINE_ITEM_RCOS-ARTNR AND
BWKEY = 'CS01'.
ENDSELECT.

IF MBEW-VPRSV = 'S'.
COMPUTE AUX_TOTAL = ( MBEW-STPRS / MBEW-PEINH )
* LINE_ITEM_RCOS-VVQTO.
ELSE.
COMPUTE AUX_TOTAL = ( MBEW-VERPR / MBEW-PEINH )
* LINE_ITEM_RCOS-VVQTO.
ENDIF.
ENDIF.
ENDIF.

*--> Fará os acertos de conversão USD <> BRL se o esquema de preços


* não for BRL.

IF AUX-TPPPROD = 'MTO' OR
AUX-TPPPROD = 'MTL'.
CLEAR: LINE_ITEM_RCOS-VVCSF, LINE_ITEM_RCOS-VVCSV.
CALL FUNCTION 'Z_COPA_VALUATION_RCOS'
EXPORTING
I_KURST = TIPO_TAXA
I_COPA_ITEM = LINE_ITEM_RCOS
IMPORTING
E_COPA_ITEM = LINE_ITEM_RCOS_AT.

MOVE LINE_ITEM_RCOS_AT-VVCSF TO LINE_ITEM_RCOS-VVCSF.


MOVE LINE_ITEM_RCOS_AT-VVCSV TO LINE_ITEM_RCOS-VVCSV.
COMPUTE LINE_ITEM_RCOS-VVCRP = LINE_ITEM_RCOS-VVCSF +
LINE_ITEM_RCOS-VVCSV.
ELSE. " aux-tpprod = 'MTS'
IF LINE_ITEM_RCOS-PALEDGER = '02'.
MOVE AUX_TOTAL TO LINE_ITEM_RCOS-VVCRP.
ELSE.
*--> função converte esquema de preços: BRL -> USD
CALL FUNCTION 'READ_EXCHANGE_RATE'
EXPORTING
DATE = LINE_ITEM_RCOS-BUDAT
FOREIGN_CURRENCY = 'USD'
LOCAL_CURRENCY = 'BRL'
TYPE_OF_RATE = 'M'
IMPORTING
EXCHANGE_RATE = TAXA
EXCEPTIONS
OTHERS = 4.

COMPUTE LINE_ITEM_RCOS-VVCRP = AUX_TOTAL / TAXA.


ENDIF.
ENDIF.
MODIFY T_ITEM FROM LINE_ITEM_RCOS.
ENDIF.
ENDIF.
ENDLOOP.
ENDFORM.
Para documentos de faturamento : utilizando a exit padrão ZXKKEU08

Versão final chamando o módulo de função Z_COPA_VALUATION_RCOS:

*--------------------------------------------------------------------
* *
* INCLUDE ZXKKEU08 *
* *
*-------------------------------------------------------------------*

*--> tabelas
TABLES: TCURR, " taxa de conversao
MBEW. " mestre de materiais

*--> variáveis
DATA: LINE_ITEM_RCOS LIKE CE1RCOS,
LINE_ITEM_RCOS_AT LIKE CE1RCOS,
TIPO_TAXA LIKE TKEVS-KURST VALUE 'M'.

DATA: TAXA LIKE TCURR-UKURS, " taxa cambio estrang


AUX_VBELN LIKE CE1RCOS-KAUFN, " nº docto ref aux
AUX_KDPOS LIKE CE1RCOS-KDPOS, " nº item ordem venda
AUX_MOEDA LIKE CE1RCOS-REC_WAERS," taxa cambio aux
AUX_FIXO LIKE CE1RCOS-VVCSF,
AUX_VAR LIKE CE1RCOS-VVCSV,
AUX_TOTAL LIKE CE1RCOS-VVCSV,
NUM_CONDICAO LIKE VBRK-KNUMV,
OUTRA_MOEDA(4) TYPE C, " campo logico
AUX-TPPPROD(3) TYPE C.

*********************************************************************
* O objetivo dessa exit é acertar os valores dos campos de valor de
* custos em CO-PA. Esses valores, quando o esquema de preços do
* faturamento vem em moeda diferente de reais, são convertidos de
* forma errada: ao invés de utilizarem a taxa de câmbio M (que é a
* utilizada no lançamento de CPV), utilizam a taxa de câmbio G - a
* mesma do faturamento, o que faz com que os valores em reais fiquem
* incorretos
*
* A exit fará:
* No caso dos produtos Make-to-order, chamará a função padrão de
* avaliação CO-PA; a função já retornará os valores convertidos pela
* taxa média USD - BRL; o mesmo ocorrerá no caso dos produtos make-
* to-stock com roteiro e lista técnica (produtos de estoque
* e subprodutos)
*
* No caso dos produtos Make-to-stock simples, buscará o valor
* em reais no mestre de materiais, e ajustará à quantidade faturada
*
*********************************************************************
LOOP AT T_ITEM INTO LINE_ITEM_RCOS.

IF LINE_ITEM_RCOS-COPA_AWTYP = 'SD00' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDIN' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDOR' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'VBRK'.

* somente precisa ajustar se for lançamento; se for estorno não


IF LINE_ITEM_RCOS-STO_BELNR IS INITIAL.

* verifica se o esquema de precos do faturamento é em reais ou outra


* moeda. Só precisa ajustar no caso de outra moeda

IF AUX_VBELN <> LINE_ITEM_RCOS-KAUFN.


MOVE 'FALSE' TO OUTRA_MOEDA.
MOVE LINE_ITEM_RCOS-KAUFN TO AUX_VBELN.
SELECT WAERK INTO AUX_MOEDA FROM VBAK
WHERE VBELN = AUX_VBELN.
ENDSELECT.
ENDIF.
IF AUX_MOEDA <> 'BRL'.
OUTRA_MOEDA = 'TRUE'.
ENDIF.
ENDIF.

IF OUTRA_MOEDA = 'TRUE'.
IF LINE_ITEM_RCOS-WWEQU = 'X'.
IF LINE_ITEM_RCOS-WWTVD = 'O'.
MOVE 'MTO' TO AUX-TPPPROD.
ELSE.
IF LINE_ITEM_RCOS-WWTVD = 'E' OR
LINE_ITEM_RCOS-WWTVD = 'B'.
MOVE 'MTL' TO AUX-TPPPROD.
ELSE.
MOVE 'MTS' TO AUX-TPPPROD.
ENDIF.
ENDIF.
ELSE.
MOVE 'MTS' TO AUX-TPPPROD.
ENDIF.

IF AUX_KDPOS <> LINE_ITEM_RCOS-KDPOS.


MOVE LINE_ITEM_RCOS-KDPOS TO AUX_KDPOS.

*** No caso dos produtos make to stock, buscará o preço médio móvel
*** ou o preco standard no mestre de materiais, dependendo do
*** controle de precos
***
*** A EXIT NAO SE PREOCUPA - NO CASO DE MTS SIMPLES EM
*** AJUSTAR A QUANTIDADE NO CASO DA UNIDADE DA QUANTIDADE NA ORDEM DE
*** VENDAS SER DIFERENTE DA UNIDADE DA QUANTIDADE NO CÁLCULO DE
*** CUSTOS: NUNCA SERÃO DIFERENTES
***
*** A EXIT INFORMA O CENTRO FIXO 'CS01' NO SELECT DA MBEW, POIS SÓ HÁ
*** UM CENTRO HOJE; SE HOUVER MAIS CENTROS, SERÁ NECESSÁRIO UTILIZAR
*** A CARACTERÍSTICA CENTRO EM CO-PA PARA FAZER ESSE SELECT
***
IF AUX-TPPPROD = 'MTS'.

SELECT VPRSV VERPR STPRS PEINH INTO


(MBEW-VPRSV, MBEW-VERPR, MBEW-STPRS, MBEW-PEINH)
FROM MBEW WHERE MATNR = LINE_ITEM_RCOS-ARTNR AND
BWKEY = 'CS01'.
ENDSELECT.

IF MBEW-VPRSV = 'S'.
COMPUTE AUX_TOTAL = ( MBEW-STPRS / MBEW-PEINH )
* LINE_ITEM_RCOS-VVQTF.
ELSE.
COMPUTE AUX_TOTAL = ( MBEW-VERPR / MBEW-PEINH )
* LINE_ITEM_RCOS-VVQTF.
ENDIF.
ENDIF.
ENDIF.

*--> Fará os acertos de conversão USD <> BRL se o esquema de preços


* não for BRL.

IF AUX-TPPPROD = 'MTO' OR
AUX-TPPPROD = 'MTL'.
CLEAR: LINE_ITEM_RCOS-VVCSF, LINE_ITEM_RCOS-VVCSV.
CALL FUNCTION 'Z_COPA_VALUATION_RCOS'
EXPORTING
I_KURST = TIPO_TAXA
I_COPA_ITEM = LINE_ITEM_RCOS
IMPORTING
E_COPA_ITEM = LINE_ITEM_RCOS_AT.

MOVE LINE_ITEM_RCOS_AT-VVCSF TO LINE_ITEM_RCOS-VVCSF.


MOVE LINE_ITEM_RCOS_AT-VVCSV TO LINE_ITEM_RCOS-VVCSV.
COMPUTE LINE_ITEM_RCOS-VVCRP = LINE_ITEM_RCOS-VVCSF +
LINE_ITEM_RCOS-VVCSV.
ELSE. " aux-tpprod = 'MTS'
IF LINE_ITEM_RCOS-PALEDGER = '02'.
MOVE AUX_TOTAL TO LINE_ITEM_RCOS-VVCRP.
ELSE.
*--> função converte esquema de preços: BRL -> USD
CALL FUNCTION 'READ_EXCHANGE_RATE'
EXPORTING
DATE = LINE_ITEM_RCOS-BUDAT
FOREIGN_CURRENCY = 'USD'
LOCAL_CURRENCY = 'BRL'
TYPE_OF_RATE = 'M'
IMPORTING
EXCHANGE_RATE = TAXA
EXCEPTIONS
OTHERS = 4.

COMPUTE LINE_ITEM_RCOS-VVCRP = AUX_TOTAL / TAXA.


ENDIF.
ENDIF.
MODIFY T_ITEM FROM LINE_ITEM_RCOS.
ENDIF.
ENDIF.
ENDLOOP.

Versão ajustando também os campos de valor de receitas / deduções de receita – não


foi implementada pois a conversão desse tipo de campo de valor estava aceitável
(correta):

*-------------------------------------------------------------------*
*** INCLUDE ZXKKEU08 *
*-------------------------------------------------------------------*

*--> tabelas
TABLES: TCURR, " taxa de conversao
MBEW. " mestre de materiais
*--> variáveis
DATA: LINE_ITEM_RCOS LIKE CE1RCOS,
LINE_ITEM_RCOS_AT LIKE CE1RCOS,
TIPO_TAXA LIKE TKEVS-KURST VALUE 'M'.

DATA: TAXA LIKE TCURR-UKURS, " taxa cambio


estrang
AUX_VBELN LIKE CE1RCOS-KAUFN, " nº docto ref aux
AUX_KDPOS LIKE CE1RCOS-KDPOS, " nº item ordem
venda
AUX_MOEDA LIKE CE1RCOS-REC_WAERS, " taxa cambio aux
AUX_FIXO LIKE CE1RCOS-VVCSF,
AUX_VAR LIKE CE1RCOS-VVCSV,
AUX_TOTAL LIKE CE1RCOS-VVCSV,
NUM_CONDICAO LIKE VBRK-KNUMV,
OUTRA_MOEDA(4) TYPE C, " campo logico
AUX-TPPPROD(3) TYPE C.

*--> tabela interna


DATA: BEGIN OF TABINT OCCURS 200,
PALEDGER LIKE CE1RCOS-PALEDGER, " tipo moeda área
VVICM LIKE CE1RCOS-VVICM, " ICMS
VVISS LIKE CE1RCOS-VVISS, " ISS
VVIPI LIKE CE1RCOS-VVIPI, " IPI
VVFRS LIKE CE1RCOS-VVFRS, " Frete e Seguros
VVRCF LIKE CE1RCOS-VVRCF, " Receita Financeira
VVPIS LIKE CE1RCOS-VVPIS, " PIS
VVCOF LIKE CE1RCOS-VVCOF, " Cofins
VVRCB LIKE CE1RCOS-VVRCB, " Receita Bruta
VBELN LIKE CE1RCOS-KAUFN, " nº ordem cliente
KDPOS LIKE CE1RCOS-KDPOS. " item ordem cliente
DATA: END OF TABINT.

*********************************************************************
* O objetivo dessa exit é acertar os valores dos campos de valor
* em CO-PA. Esses valores, quando o esquema de preços do
* faturamento vem em moeda diferente de reais, são convertidos de
* forma errada:
*
* No caso das conversões de campos de valor de custos
* ao invés de utilizarem a taxa de câmbio M (que é a utilizada
* no lançamento de CPV), utilizam a taxa de câmbio G - a mesma do
* faturamento, o que faz com que os valores em reais fiquem
* incorretos
*
* No caso das conversões dos campos de valor de receitas / deduções
* de receita, ele utiliza a conversão direta da moeda para USD no
* caso da moeda da área de resultado, quando deveria utilizar o mesmo
* critério de conversão utilizado em FI: converter o valor da moeda
* estrangeira para BRL à taxa média; e depois converter o valor em
* BRL encontrado para USD pela taxa média.
*
* A exit fará:
*
* PARA OS CAMPOS DE VALOR DE CUSTOS
* No caso dos produtos Make-to-order, chamará a função padrão de
* avaliação CO-PA; a função já retornará os valores convertidos pela
* taxa média USD - BRL; o mesmo ocorrerá no caso dos produtos make-
* to-stock com roteiro e lista técnica (produtos de estoque e
* subprodutos)
*
* No caso dos produtos Make-to-stock simples, buscará o valor
* em reais no mestre de materiais, e ajustará à quantidade faturada
*
* PARA OS CAMPOS DE VALOR DE RECEITAS / DEDUÇÕES DE RECEITAS
* Como o valor em BRL está correto, armazenará todos os valores em
* tabela interna, e utilizará o valor em BRL para reconverter os
* valores em USD
*********************************************************************
*
* Preenche tabela interna que será depois utilizada para ajustar os
* valores de receita / deduções de receita
*
LOOP AT T_ITEM INTO LINE_ITEM_RCOS.

IF LINE_ITEM_RCOS-COPA_AWTYP = 'SD00' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDIN' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDOR' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'VBRK'.

* somente precisa ajustar se for lançamento; se for estorno não

IF LINE_ITEM_RCOS-STO_BELNR IS INITIAL.

MOVE: LINE_ITEM_RCOS-PALEDGER TO TABINT-PALEDGER,


LINE_ITEM_RCOS-VVICM TO TABINT-VVICM,
LINE_ITEM_RCOS-VVISS TO TABINT-VVISS,
LINE_ITEM_RCOS-VVIPI TO TABINT-VVIPI,
LINE_ITEM_RCOS-VVFRS TO TABINT-VVFRS,
LINE_ITEM_RCOS-VVRCF TO TABINT-VVRCF,
LINE_ITEM_RCOS-VVPIS TO TABINT-VVPIS,
LINE_ITEM_RCOS-VVCOF TO TABINT-VVCOF,
LINE_ITEM_RCOS-VVRCB TO TABINT-VVRCB,
LINE_ITEM_RCOS-KAUFN TO TABINT-KAUFN,
LINE_ITEM_RCOS-KDPOS TO TABINT-KDPOS.

APPEND TABINT.

ENDIF.
ENDIF.
ENDLOOP.

LOOP AT T_ITEM INTO LINE_ITEM_RCOS.

IF LINE_ITEM_RCOS-COPA_AWTYP = 'SD00' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDIN' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDOR' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'VBRK'.

* somente precisa ajustar se for lançamento; se for estorno não

IF LINE_ITEM_RCOS-STO_BELNR IS INITIAL.

* verifica se o esquema de precos do faturamento é em reais ou outra


* moeda. Só precisa ajustar no caso de outra moeda

IF AUX_VBELN <> LINE_ITEM_RCOS-KAUFN.


MOVE 'FALSE' TO OUTRA_MOEDA.
MOVE LINE_ITEM_RCOS-KAUFN TO AUX_VBELN.
SELECT WAERK INTO AUX_MOEDA FROM VBAK
WHERE VBELN = AUX_VBELN.
ENDSELECT.
ENDIF.
IF AUX_MOEDA <> 'BRL'.
OUTRA_MOEDA = 'TRUE'.
ENDIF.
ENDIF.

IF OUTRA_MOEDA = 'TRUE'.
IF LINE_ITEM_RCOS-WWEQU = 'X'.
IF LINE_ITEM_RCOS-WWTVD = 'O'.
MOVE 'MTO' TO AUX-TPPPROD.
ELSE.
IF LINE_ITEM_RCOS-WWTVD = 'E' OR
LINE_ITEM_RCOS-WWTVD = 'B'.
MOVE 'MTL' TO AUX-TPPPROD.
ELSE.
MOVE 'MTS' TO AUX-TPPPROD.
ENDIF.
ENDIF.
ELSE.
MOVE 'MTS' TO AUX-TPPPROD.
ENDIF.

IF AUX_KDPOS <> LINE_ITEM_RCOS-KDPOS.


MOVE LINE_ITEM_RCOS-KDPOS TO AUX_KDPOS.

*** No caso dos produtos make to stock, buscará o preço médio móvel
*** ou o preco standard no mestre de materiais, dependendo do
*** controle de precos
***
*** A EXIT NAO SE PREOCUPA - NO CASO DE MTS SIMPLES EM
*** AJUSTAR A QUANTIDADE NO CASO DA UNIDADE DA QUANTIDADE NA ORDEM DE
*** VENDAS SER DIFERENTE DA UNIDADE DA QUANTIDADE NO CÁLCULO DE
*** CUSTOS:NUNCA SERÃO DIFERENTES
***
*** A EXIT INFORMA O CENTRO FIXO 'CS01' NO SELECT DA MBEW, POIS SÓ HÁ
*** UM CENTRO HOJE; SE HOUVER MAIS CENTROS, SERÁ NECESSÁRIO UTILIZAR
*** A CARACTERÍSTICA CENTRO EM CO-PA PARA FAZER ESSE SELECT
***
IF AUX-TPPPROD = 'MTS'.

SELECT VPRSV VERPR STPRS PEINH INTO


(MBEW-VPRSV, MBEW-VERPR, MBEW-STPRS, MBEW-PEINH)
FROM MBEW WHERE MATNR = LINE_ITEM_RCOS-ARTNR AND
BWKEY = 'CS01'.
ENDSELECT.

IF MBEW-VPRSV = 'S'.
COMPUTE AUX_TOTAL = ( MBEW-STPRS / MBEW-PEINH )
* LINE_ITEM_RCOS-VVQTF.
ELSE.
COMPUTE AUX_TOTAL = ( MBEW-VERPR / MBEW-PEINH )
* LINE_ITEM_RCOS-VVQTF.
ENDIF.
ENDIF.
ENDIF.

*--> Fará os acertos de conversão USD <> BRL se o esquema de preços


* não for BRL.
IF AUX-TPPPROD = 'MTO' OR
AUX-TPPPROD = 'MTL'.

*** Acerto dos campos de valor de custos em make-to-order ou make-to-


*** stock com cost estimate calculado, através da função padrão de
*** avaliação CO-PA

CALL FUNCTION 'Z_COPA_VALUATION_RCOS'


EXPORTING
I_KURST = TIPO_TAXA
I_COPA_ITEM = LINE_ITEM_RCOS
IMPORTING
E_COPA_ITEM = LINE_ITEM_RCOS_AT.

MOVE LINE_ITEM_RCOS_AT-VVCSF TO LINE_ITEM_RCOS-VVCSF.


MOVE LINE_ITEM_RCOS_AT-VVCSV TO LINE_ITEM_RCOS-VVCSV.
COMPUTE LINE_ITEM_RCOS-VVCRP = LINE_ITEM_RCOS-VVCSF +
LINE_ITEM_RCOS-VVCSV.

*** Acerto dos de valor de receitas/deduções de receita em make-to-


*** order ou make-to-stock com cost estimate calculado, convertendo o
*** valor em reais para USD pela taxa média
IF LINE_ITEM_RCOS_PALEDGER = '01'.

LOOP AT TABINT WHERE


VBELN = LINE_ITEM_RCOS-KAUFN AND
KDPOS = LINE_ITEM_RCOS-KDPOS AND
PALEDGER = '02'.

CALL FUNCTION 'READ_EXCHANGE_RATE'


EXPORTING
DATE = LINE_ITEM_RCOS-BUDAT
FOREIGN_CURRENCY = 'USD'
LOCAL_CURRENCY = 'BRL'
TYPE_OF_RATE = 'M'
IMPORTING
EXCHANGE_RATE = TAXA
EXCEPTIONS
OTHERS = 4.

COMPUTE: LINE_ITEM_RCOS-VVICM = TABINT-VVICM / TAXA,


LINE_ITEM_RCOS-VVISS = TABINT-VVISS / TAXA,
LINE_ITEM_RCOS-VVIPI = TABINT-VVIPI / TAXA,
LINE_ITEM_RCOS-VVFRS = TABINT-VVFRS / TAXA,
LINE_ITEM_RCOS-VVRCF = TABINT-VVRCF / TAXA,
LINE_ITEM_RCOS-VVPIS = TABINT-VVPIS / TAXA,
LINE_ITEM_RCOS-VVCOF = TABINT-VVCOF / TAXA,
LINE_ITEM_RCOS-VVRCB = TABINT-VVRCB / TAXA.
ENDLOOP.
ENDIF.

ELSE. " aux-tpprod = 'MTS'

*** Acerto dos campos de valor em make-to-stock

IF LINE_ITEM_RCOS-PALEDGER = '02'.
MOVE AUX_TOTAL TO LINE_ITEM_RCOS-VVCRP.
ELSE.
*--> função converte esquema de preços: BRL -> USD
CALL FUNCTION 'READ_EXCHANGE_RATE'
EXPORTING
DATE = LINE_ITEM_RCOS-BUDAT
FOREIGN_CURRENCY = 'USD'
LOCAL_CURRENCY = 'BRL'
TYPE_OF_RATE = 'M'
IMPORTING
EXCHANGE_RATE = TAXA
EXCEPTIONS
OTHERS = 4.

COMPUTE LINE_ITEM_RCOS-VVCRP = AUX_TOTAL / TAXA.

LOOP AT TABINT WHERE


VBELN = LINE_ITEM_RCOS-KAUFN AND
KDPOS = LINE_ITEM_RCOS-KDPOS AND
PALEDGER = '02'.

COMPUTE: LINE_ITEM_RCOS-VVICM = TABINT-VVICM / TAXA,


LINE_ITEM_RCOS-VVISS = TABINT-VVISS / TAXA,
LINE_ITEM_RCOS-VVIPI = TABINT-VVIPI / TAXA,
LINE_ITEM_RCOS-VVFRS = TABINT-VVFRS / TAXA,
LINE_ITEM_RCOS-VVRCF = TABINT-VVRCF / TAXA,
LINE_ITEM_RCOS-VVPIS = TABINT-VVPIS / TAXA,
LINE_ITEM_RCOS-VVCOF = TABINT-VVCOF / TAXA,
LINE_ITEM_RCOS-VVRCB = TABINT-VVRCB / TAXA.
ENDLOOP.
ENDIF.
ENDIF.
MODIFY T_ITEM FROM LINE_ITEM_RCOS.
ENDIF.
ENDIF.
ENDLOOP.

Versão utilizando o acesso direto às tabelas KEKO-KEPH (sem utilizar a função


acessando a estratégia de avaliação CO-PA)

*-------------------------------------------------------------------*
*** INCLUDE ZXKKEU08 *
*-------------------------------------------------------------------*

*--> tabelas
TABLES: TCURR, " taxa de conversao
KEKO, " cabecalho calculo de custos
KEPH, " itens calculo de custo
MBEW. " mestre de materiais

*--> variáveis
DATA: LINE_ITEM_RCOS LIKE CE1RCOS,
LINE_ITEM_RCOS_AT LIKE CE1RCOS,
TIPO_TAXA LIKE TKEVS-KURST.

DATA: TAXA LIKE TCURR-UKURS, " taxa cambio


estrang
AUX_VBELN LIKE CE1RCOS-KAUFN, " nº docto ref aux
AUX_KDPOS LIKE CE1RCOS-KDPOS, " nº item ordem
venda
AUX_MOEDA LIKE CE1RCOS-REC_WAERS, " taxa cambio aux
AUX_FIXO LIKE CE1RCOS-VVCSF,
AUX_VAR LIKE CE1RCOS-VVCSV,
AUX_TOTAL LIKE CE1RCOS-VVCSV,
NUM_CONDICAO LIKE VBRK-KNUMV,
OUTRA_MOEDA(4) TYPE C, " campo logico
AUX-TPPPROD(3) TYPE C.

*********************************************************************
* O objetivo dessa exit é acertar os valores dos campos de valor de
* custos em CO-PA. Esses valores, quando o esquema de preços do
* faturamento vem em moeda diferente de reais, são convertidos de
* forma errada: ao invés de utilizarem a taxa de câmbio M (que é a
* utilizada no lançamento de CPV), utilizam a taxa de câmbio G - a
* mesma do faturamento, o que faz com que os valores em reais fiquem
* incorretos
*
* A exit fará:
* No caso dos produtos Make-to-order, buscará o valor em reais do
* cálculo de custos marcado, e converterá esses valores utilizando a
* taxa média USD - BRL; o mesmo ocorrerá no caso dos produtos make-
* to-stock com roteiro e lista técnica (produtos de estoque e
* subprodutos)
*
* No caso dos produtos Make-to-stock simples, buscará o valor
* em reais no mestre de materiais, e ajustará à quantidade faturada
*
*********************************************************************
LOOP AT T_ITEM INTO LINE_ITEM_RCOS.

IF LINE_ITEM_RCOS-COPA_AWTYP = 'SD00' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDIN' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'SDOR' OR
LINE_ITEM_RCOS-COPA_AWTYP = 'VBRK'.

* somente precisa ajustar se for lançamento; se for estorno não

IF LINE_ITEM_RCOS-STO_BELNR IS INITIAL.

* verifica se o esquema de precos do faturamento é em reais ou outra


* moeda. Só precisa ajustar no caso de outra moeda

IF AUX_VBELN <> LINE_ITEM_RCOS-KAUFN.


MOVE 'FALSE' TO OUTRA_MOEDA.
MOVE LINE_ITEM_RCOS-KAUFN TO AUX_VBELN.
SELECT WAERK INTO AUX_MOEDA FROM VBAK
WHERE VBELN = AUX_VBELN.
ENDSELECT.
ENDIF.
IF AUX_MOEDA <> 'BRL'.
OUTRA_MOEDA = 'TRUE'.
ENDIF.
ENDIF.

IF OUTRA_MOEDA = 'TRUE'.
IF LINE_ITEM_RCOS-WWEQU = 'X'.
IF LINE_ITEM_RCOS-WWTVD = 'O'.
MOVE 'MTO' TO AUX-TPPPROD.
ELSE.
IF LINE_ITEM_RCOS-WWTVD = 'E' OR
LINE_ITEM_RCOS-WWTVD = 'B'.
MOVE 'MTL' TO AUX-TPPPROD.
ELSE.
MOVE 'MTS' TO AUX-TPPPROD.
ENDIF.
ENDIF.
ELSE.
MOVE 'MTS' TO AUX-TPPPROD.
ENDIF.

IF AUX_KDPOS <> LINE_ITEM_RCOS-KDPOS.


MOVE LINE_ITEM_RCOS-KDPOS TO AUX_KDPOS.

*** No caso de produtos make to order, busca o número do cálculo de


*** custos gravado para a ordem de venda

IF AUX-TPPPROD = 'MTO' OR AUX-TPPPROD = 'MTL'.

IF AUX-TPPPROD = 'MTO'.
SELECT KALNR LOSGR INTO (KEKO-KALNR, KEKO-LOSGR)
FROM KEKO WHERE
MATNR = LINE_ITEM_RCOS-ARTNR AND
VBELN = AUX_VBELN AND
POSNR = AUX_KDPOS.
ENDSELECT.
ELSE.

*** A EXIT NÃO INFORMA O CENTRO NO SELECT DE KEKO, POIS SÓ HÁ UM


*** CENTRO:CS01 - SE HOUVER MAIS CENTROS, SERÁ NECESSÁRIO UTILIZAR A
*** CARACTERÍSTICA CENTRO EM CO-PA PARA FAZER ESSE SELECT

SELECT KALNR LOSGR INTO (KEKO-KALNR, KEKO-LOSGR)


FROM KEKO WHERE
MATNR = LINE_ITEM_RCOS-ARTNR.
ENDSELECT.
ENDIF.

*** Com o número do cálculo de custos, busca os valores calculados.


*** Os valores nos campos ksp ímpares correspondem ao custo total;
*** nos campos pares, ao custo fixo. Após obter esses valores, divide
*** pelo tamanho do cálculo de custos e multiplica pela quantidade
*** faturada
***
*** A EXIT NAO SE PREOCUPA - NO CASO DE MTS COM LISTA E ROTEIRO (MTL)
*** EM AJUSTAR A QUANTIDADE NO CASO DA UNIDADE DA QUANTIDADE NA ORDEM
*** DE VENDAS SER DIFERENTE DA UNIDADE DA QUANTIDADE NO CÁLCULO DE
*** CUSTOS:NUNCA SERÃO DIFERENTES

SELECT * FROM KEPH WHERE KALNR = KEKO-KALNR AND


KEART = 'H' AND
LOSFX = ' ' AND
KKZST = ' '.
ENDSELECT.

COMPUTE AUX_FIXO = KEPH-KST002 + KEPH-KST004 + KEPH-KST006 +


KEPH-KST008 + KEPH-KST010 + KEPH-KST012 +
KEPH-KST014 + KEPH-KST016 + KEPH-KST018 +
KEPH-KST020 + KEPH-KST022 + KEPH-KST024 +
KEPH-KST026 + KEPH-KST028 + KEPH-KST030 +
KEPH-KST032 + KEPH-KST034 + KEPH-KST036 +
KEPH-KST038 + KEPH-KST040.

COMPUTE AUX_VAR = KEPH-KST001 + KEPH-KST003 + KEPH-KST005 +


KEPH-KST007 + KEPH-KST009 + KEPH-KST011 +
KEPH-KST013 + KEPH-KST015 + KEPH-KST017 +
KEPH-KST019 + KEPH-KST021 + KEPH-KST023 +
KEPH-KST025 + KEPH-KST027 + KEPH-KST029 +
KEPH-KST031 + KEPH-KST033 + KEPH-KST035 +
KEPH-KST037 + KEPH-KST039 - AUX_FIXO.

*** Ajustar à quantidade faturada

COMPUTE AUX_VAR = ( AUX_VAR / KEKO-LOSGR )


* LINE_ITEM_RCOS-VVQTF.

COMPUTE AUX_FIXO = ( AUX_FIXO / KEKO-LOSGR )


* LINE_ITEM_RCOS-VVQTF.

COMPUTE AUX_TOTAL = AUX_VAR + AUX_FIXO.

ELSE.

*** No caso dos produtos make to stock, buscará o preço médio móvel
*** ou o preco standard no mestre de materiais, dependendo do
*** controle de precos
***
*** A EXIT NAO SE PREOCUPA - NO CASO DE MTS SIMPLES EM
*** AJUSTAR A QUANTIDADE NO CASO DA UNIDADE DA QUANTIDADE NA ORDEM DE
*** VENDAS SER DIFERENTE DA UNIDADE DA QUANTIDADE NO CÁLCULO DE
*** CUSTOS:NUNCA SERÃO DIFERENTES
***
*** A EXIT INFORMA O CENTRO FIXO 'CS01' NO SELECT DA MBEW, POIS SÓ HÁ
*** UM CENTRO HOJE; SE HOUVER MAIS CENTROS, SERÁ NECESSÁRIO UTILIZAR
*** A CARACTERÍSTICA CENTRO EM CO-PA PARA FAZER ESSE SELECT
***

SELECT VPRSV VERPR STPRS PEINH INTO


(MBEW-VPRSV, MBEW-VERPR, MBEW-STPRS, MBEW-PEINH)
FROM MBEW WHERE MATNR = LINE_ITEM_RCOS-ARTNR AND
BWKEY = 'CS01'.
ENDSELECT.

IF MBEW-VPRSV = 'S'.
COMPUTE AUX_TOTAL = ( MBEW-STPRS / MBEW-PEINH )
* LINE_ITEM_RCOS-VVQTF.
ELSE.
COMPUTE AUX_TOTAL = ( MBEW-VERPR / MBEW-PEINH )
* LINE_ITEM_RCOS-VVQTF.
ENDIF.
ENDIF.
ENDIF.

*--> Fará os acertos de conversão USD <> BRL se o esquema de preços


* não for BRL.

IF LINE_ITEM_RCOS-PALEDGER = '02'.

IF AUX-TPPPROD = 'MTO' OR AUX-TPPPROD = 'MTL'.

MOVE AUX_FIXO TO LINE_ITEM_RCOS-VVCSF.


MOVE AUX_VAR TO LINE_ITEM_RCOS-VVCSV.
MOVE AUX_TOTAL TO LINE_ITEM_RCOS-VVCRP.
ELSE.
MOVE AUX_TOTAL TO LINE_ITEM_RCOS-VVCRP.
ENDIF.
ELSE.
*--> função converte esquema de preços: BRL -> USD
CALL FUNCTION 'READ_EXCHANGE_RATE'
EXPORTING
DATE = LINE_ITEM_RCOS-BUDAT
FOREIGN_CURRENCY = 'USD'
LOCAL_CURRENCY = 'BRL'
TYPE_OF_RATE = 'M'
IMPORTING
EXCHANGE_RATE = TAXA
EXCEPTIONS
OTHERS = 4.

IF AUX-TPPPROD = 'MTO' OR AUX-TPPPROD = 'MTL'.

COMPUTE LINE_ITEM_RCOS-VVCSF = AUX_FIXO / TAXA.


COMPUTE LINE_ITEM_RCOS-VVCSV = AUX_VAR / TAXA.
COMPUTE LINE_ITEM_RCOS-VVCRP = LINE_ITEM_RCOS-VVCSF +
LINE_ITEM_RCOS-VVCSV.
ELSE.

COMPUTE LINE_ITEM_RCOS-VVCRP = AUX_TOTAL / TAXA.

ENDIF.
ENDIF.
MODIFY T_ITEM FROM LINE_ITEM_RCOS.
ENDIF.
ENDIF.
ENDLOOP.
PLANEJAMENTO CENTROS DE CUSTOS : ALTERAÇÃO COTAÇÃO USD PLANEJADO
APÓS PLANEJAMENTO REALIZADO

Cenário: Modificar cotações do dólar após o planejamento da versão 0 já realizado.


Preservar esse planejamento (com as cotações originais) numa versão COP, e ter o
planejamento com as novas cotações atualizadas na versão 0.

Para fazer isso mantendo a consistência e o histórico das cotações, proceder da seguinte
forma:

1) Criar uma nova taxa de câmbio para conversão dos valores planejados, utilizando a
transação OB07. Copie a taxa P para uma taxa P1, por exemplo.

2) Defina fatores de conversão para essa taxa, utilizando a transação OBBS (pode ser
copiando o mesmo fator de conversão da taxa P).

3) Copie as taxas de câmbio P para essa nova taxa de câmbio P1, utilizando a transação
OB08 (copiar todas as cotações USD -> BRL do tipo P).

4) Crie a versão COP de planejamento (só planejamento, sem dados reais), utilizando a
transação OKEQ, e a versão na área de contabilidade de custos para essa versão. Crie os
exercícios que irão ser copiados nessa versão. Nesses exercícios, informe que a taxa para
conversão do planejamento é a P1.
Crie também a versão na área de resultado, com o tipo de moeda = 10 (moeda da empresa)
e categoria de câmbio = P1.

4) Utilize a transação de cópia do planejamento (KP97) para copiar o planejamento da


versão 0 para a versão COP. Antes de executar a cópia, selecione o caminho de menu
Suplementos > Moedas Planejadas e certifique-se que Custos e Tarifas estejam sendo
copiados em MOEDA DO OBJETO.

Utilize a transação de cópia do planejamento em PA (KE1A) para copiar o planejamento da


versão 0 para a versão COP.

Após feitas as cópias, a versão 0 e a versão COP estarão iguais, em moeda do objeto e da
área de contabilidade de custos

5) Altere as cotações das taxas de câmbio P que devam ser alteradas na transação OB08.

6) Utilize a transação de cópia do planejamento (KP97) para copiar o planejamento da


versão COP para a versão 0. Antes de executar a cópia, selecione o caminho de menu
Suplementos > Moedas Planejadas e certifique-se que Custos e Tarifas estejam sendo
copiados em MOEDA DO OBJETO.

Se houver uma versão de planejamento em PA para moeda tipo B0 (moeda da área de


resultado, utilize a transação de cópia de planejamento em PA (KE1A) para copiar o
planejamento da versão 0 (já atualizada) para essa nova versão.

Após feitas essas cópias, a versão 0 estará com o planejamento em moeda da área de
contabilidade de custos convertida às novas taxas P, e a versão COP com o planejamento
em moeda da área de contabilidade de custos convertida à antiga taxa P (que agora é a taxa
P1).
MARCAÇÃO DO CÁLCULO DE CUSTOS

O cálculo de custos não estava ficando gravado na ordem de venda porque, ao pedir um
cálculo manual (CTRL + F7), devemos, antes de gravar, marcar esse cálculo (clicar no botão
MARCAR, no alto, à esquerda da tela).

CÁLCULO DE CUSTOS AUTOMÁTICO NA ORDEM DE VENDAS

O cálculo de custos deve estar automático para as ordens de vendas. Para verificar se ele
está automático, verificar qual o tipo de item na ordem (ZTAC, etc...). Com o tipo de item,
verificar a que tipo de necessidade esse tipo está ligado (transação OVZI); Com o tipo de
necessidade, verificar a que classe de necessidade esse tipo de item está ligado (transação
OVZH). Com a classe de necessidade, verificar se o cálculo de custos está automático
(transação OVZG).

O cálculo de custos automático só é feito no momento da geração da ordem de venda.


Qualquer alteração posterior (na quantidade , matéria-prima, roteiro), não causa um recálculo
desse custo.

Porém, uma alteração desse tipo muda o status do item da ordem de vendas de CALC ( para
verificar esse status, uma vez dentro da VA03, marque o item, e escolha o caminho de menu
Saltar > Item > Status, e verifique o status do sistema) para PCAL. O status PCAL impede a
remessa e o faturamento. Para voltar o status de PCAL para CALC, é preciso solicitar o
cálculo de custos, marcá-lo e gravá-lo.

Em inglês – PCAL = COST (to be costed)


CALC = CSTD (costed)

Problema com o recálculo não automático do custo na ordem de


vendas

The real problem is not that the sales order cost estimate is wrong - until at least the moment
when delivery is blocked and we have to manually recalculate it. It's the effect of this on the
settlement of the production order.

For example:

1)If I create a sales order for 200 ton of product 30000003 using raw material 10000077 (price
= 2,00 BRL per ton) and a combination of characteristics that give me a sum of activity prices
of 1,31 BRL, the estimated cost for the order will be 401,31 BRL.

2)If later on I change this sales order, replacing raw material 10000077 by raw material
10000078 (price = 1,00 BRL per ton) and the same previous combination of characteristics,
the estimated cost for the order would be 201,31 BRL. As I didn't recost the order, the
estimated cost is still 401,31 BRL, and the item status is changed to "COST".

3)When I create the production order (using transaction CO08), planned and actual debits will
use the correct raw material assigned to the order (10000078), and if I don't change the
quantities used, these debits will amount to 201,31 BRL.

Planned and actual credits will use the estimated cost of the sales order - which, at this point,
amount to 401,31 BRL.

4) When I effectivelly produce the item and deliver it to stock (using transaction MB1A,
movement type 261), the actual credit and the value posted to stock will be 401,31 BRL.
5) Now, if I try to deliver the item to my client, system will prevent the delivery because of the
order status (COST). I'll have to recost the item. The cost estimate in the sales order is then
correct, and the status is set to CSTD.

6) However, the production order credits are not affected, and no posting is made to adjust
the stock value (that should be 201,31 BRL instead of 401,31 BRL).

7) When the delivery is made, the stock is credited and cost of sales is debited for 401,31
BRL.

8) When I settle the order, the difference between 401,31 BRL and 201,31 BRL is posted as a
price difference (PRD).

In my point of view, this distorts in a significant way my cost analysis. Or the system should
recost the order automatically, or, when I recost it manually, it should adjust the credits made
to the production order (and make adjustment postings to stocks).

This problem only happens when the change is made to the sales characteristics that affect
raw materials and activities. When the change happens in the sales quantity, the credits in the
production order already reflect this change.

Resposta SAP a esse problema

The problem arises because the standard price of a material of the valuated sales order stock
is determined according to a predefined strategy (well described in our online documentation).
With this strategy the standard price for the valuated sales order stock is calculated from the
sales order cost estimate when the first goods are received for the sales order stock and
serves as the valuation basis from this point onwards. It can only be changed manually with
transaction MR21. This would revaluate the sales order stock but the credits of the production
order can't be changed afterwards.

A change in the sales order quantity doesn't affect the calculated price (calculated costs per
calculation lot size) so this doesn't cause any problems on the production orders.

The only way to prevent such problems is to take care that the sales order is recosted after
you made any changes. It is not possible to recalculate the order automatically if there exists
a marked sales order cost estimate. This has to be done manually and it has to be done right
after you did the changes.
Solução
I'm sorry but the system works as designed.

CÁLCULO DE CUSTOS PARA MATERIAIS SEM LISTA TÉCNICA

Para que um material sem lista técnica tenha seu custo (com estrutura quantitativa)
calculado, é preciso que na visão MRP2 do mestre de materiais o campo tipo de suprimento
seja preenchido com “E”. O sistema considera que, nesse caso, o material será sempre
produzido internamente, usando apenas mão-de-obra.
CÓPIA DE GRUPOS DE CLASSES DE CUSTO E DE CENTROS DE CUSTOS ENTRE
MANDANTES

Para exportar do mandante de origem, executar o programa RGSSTE00. Selecionar o tipo


de set Grupo de Classes de Custos e Grupos de Centros de Custos. Para importar no
mandante de destino, executar o programa RGSSTI00, informando o arquivo gerado na
exportação.

Se os sistemas do mandante origem e destino forem diferentes, marcar a opção


Export.p/servidor apresentação (copiará em um arquivo da rede ou da workstation).

MENSAGEM “MARGEM DE LUCRO É PEQUENA DEMAIS” EM ORDENS DE VENDA

Para desabilitar a mensagem, nos esquemas de preço em SD, alterar a fórmula de condição
para regra de cálculo da condição VPRS de 5 (diálogo preço interno) para 6 (preço inicial).

DEVOLUÇÃO DE MATERIAL CONFIGURÁVEL

> movimento 653 E no documento de remessa de SD, gerando estoque especial de cliente
na ordem de devolução e posterior movimento 411 E de material configurável ordem do
cliente para material configurado estoque livre (procedimento manual). São contabilizados
tanto o movimento 653E (crédito cta CPV x débito cta estoque de material configurável)
quanto o 411E (débito estoque de material configurado x crédito estoque material
configurável).

> foram basicamente alteradas configurações de SD (transação VOV6 trocando-se o


movimento associado a categoria de divisão de devolução) e associado cálculo de custos
automático para item category de devolução em CO (transação OVZI)

> O custo considerado para devolução é o custo estimado calculado na ordem de devolução
– ele não devolve pelo mesmo custo pelo qual o material foi remetido (ou seja, se houve
mudanças entre OV e OP anterior, isso não é levado em conta). Isso é um procedimento
contábil aceitável (desde que seja definido como regra, o fisco interpreta que, se não há
intenção de prejudicá-lo, está OK – as flutuações podem ser para mais e para menos).

> Para MTS é criada ordem de devolução com base no documento de faturamento de saída;
é feita remessa para registar entrada de mercadoria, com movimento 651, que devolve o
material para Estoque da Ordem de Devolução, e não contabiliza; é feito faturamento com
geração ou não de nota fiscal de entrada e posterior movimento 453, transferindo o material
do Estoque de Devolução para Livre Utilização, contabilizando

> Vale a mesma observação para o custo considerado para devolução.

TARIFAS PLANEJADAS – ESTRATÉGIAS DE AVALIAÇÃO

A lógica de funcionamento para a estratégia de avaliação 6 – Tarifa Planejada mais atual é a


seguinte:

O sistema tenta buscar a tarifa mais atual partindo da data de avaliação para trás, até o mês
imediatamente subsequente ao mês corrente, o que significa:

1) Com essa estratégia não consigo pegar a tarifa do mês corrente, ou tarifas anteriores ao
mês corrente
2) Para que ela funcione, preciso ter sempre tarifas planejadas para o mês subsequente ao
mês corrente, pelo menos
Por exemplo: Se minha data de avaliação é 10/2004, e o mês corrente é 08/1999, tenho que
ter tarifas planejadas calculadas pelo menos para 09/1999 para que a estratégia funcione.

Essa estratégia somente funciona após aplicada a nota 161596 (se ela não estiver incluida
em algum dos HOT PACKAGES aplicados no sistema).

TARIFAS REAIS – ITERAÇÃO INDEPENDENTE EM MOEDA DA ACC E DO OBJETO

No cálculo de tarifas reais, se a moeda da ACC for diferente da moeda do objeto, para que o
sistema calcule o valor da tarifa em moeda do objeto utilizando os custos a controlar em
moeda do objeto (ao invés de simplesmente calcular esse valor convertendo o valor
calculado em moeda da ACC para o valor em moeda do objeto utilizando a taxa corrente de
uma moeda para outra), é preciso selecionar a opção “Iterar montantes independentemente”
na transação OKET (Atualizar opções de determinação de tarifa).

Se essa opção não for selecionada, os valores da tarifa em moeda do objeto ficarão
incorretos.

Aplicar a nota OSS 143157 – sem ela, a iteração independente pode trocar os valores:
gravar os valores em moeda do objeto no lugar da moeda da ACC e vice-versa (problema
intermitente.

TAMANHO DO LOTE

“ este campo corresponde ao tamanho de lote que será sugerido no cálculo de custos do
material, deve ser um número que seja um lote "coerente", o quero dizer, se determinado
material ao produzir 100 kg dele, consome 1 unidade de qq coisa e se produzir 200 kg deste,
consome 2 unidades, se o lote fosse 150 kg estaria consumindo tambem 2 unidades de qq
coisa e distorcendo o custo planejado do material
no caso da Fasal e Rio Negro é pouco importante pois o lote na verdade é a quantidade da
OP ligada à ordem de cliente, não irá nunca capturar do cadastro do material... "

ESQUEMA DE ELEMENTOS DE CUSTOS

-> O que deve constar do esquema de elementos de custos : todas as classes de custos que
irão ser consumidas por uma ordem de produção.

Assim, devem constar:

 As classes de custos de matérias-primas (34120202 ? somente ?)


 Em embalagens, as classes de custos secundárias de alocação da atividade. Se as
embalagens (34120202) são apropriadas no centro de custos emissor da atividade e
saem por consumo da atividade, não devem constar do esquema de elementos. Se
forem consumidos diretamente para a ordem de produção, devem constar.
 Em materiais auxiliares, se há classes de custos consumidas diretamente na ordem de
produção, devem constar. Se o material for consumido por um centro de custos que
fornece uma atividade a ser consumida por ordem de produção, não deve constar.
 Em atividades, as classes de custos secundárias de alocação das demais atividades
 Em beneficiamento externo, as classes de custos primárias que serão consumidas pela
ordem de produção a serem classificadas nesse tipo
 idem para subprodutos

Se faltar alguma classe de custos que será consumida pela ordem de produção no esquema,
o sistema calcula o seu valor como zero - so beware !!!!
> Se alterar o esquema de elementos de custos (por exemplo, incluindo uma classe de
custos), as tarifas devem ser recalculadas, senão a alteração não será enxergada pelo
sistema.

GRUPOS DE ORIGEM

... para esclarecer o assunto "sem origem" na visualização dos custos de uma ordem
de produção...

VISÃO DE CÁLCULO DE CUSTOS


Grupo de origem

Quando os custos de um material são calculados, cada material está associado a uma conta
de consumo e, por consequência, a uma classe de custo primária. Se um material tiver no
cadastro um grupo de origem, a combinação grupo de origem e classe de custo é atualizada
no esquema de elementos. As funções associadas ao grupo de origem são:

 Elementos de custos podem ser dependentes de grupo de origem (além da classe


de custo)
 Cálculo de overhead pode ser definido por grupo de origem
 Regras de cálculo de estoque em porcesso podem ser definidas por grupo de origem

desta forma, com as nossas configurações, o grupo de origem serve para termos
maior abertura no esquema de elementos, maior número de elementos de custo,
baseados nas diferentes combinações classe de custos x grupo de origem

(lançamentos na ordem de produção de consumo de atividade e de apropriação de


ordem de produção NÃO TÊM grupo de origem, o que gera a descrição "sem origem",
o que não deve ser um problema, pois a análise deveria ser feita baseada nos
elementos de custos (para o que o grupo de origem foi necessário) e não análise
baseada em grupo de origem)

Origem de material

Se o flag de origem de material é selecionado no cadastro de material, quando este material


é consumido numa ordem de produção, o número do material estará gravado assim como as
informações de elementos de custo e classe de custo para este material.

INCLUSÃO DE CHAVE DE DESVIO EM MATERIAIS JÁ CADASTRADOS

1) Chamar a transação SE38, informando o programa SAPMKKS1 e clicando o botão


EXECUTAR.
2) Na tela de seleção, deixe MATERIAL em branco; informe CENTRO FA01 até RN03. Clique
na seta para seleção de TIPO DE MATERIAL, clique na opção de SELEÇÃO MÚLTIPLA e
informe todos os tipos de material que serão utilizados em ordens de produção.
3) Marcar as opções
Editar lista
Gravar registros
Sobregravar chave
Bloq.materiais individual
4) Clicar no botão EXECUTAR

5) Após rodar, a mensagem Nenhum doc.de modificação escrito para modificações no


mestre material é normal.
DESBUFFERIZAÇÃO DE NUMBER RANGES

Objetivo: evitar a criação de documentos com números "saltados" (p. ex. passando de
10000001 para 10000040). FI, usualmente desliga a do RF_BELEG e SD o RV_BELEG, por
imposição legal.

No caso do CO, pode-se desligar a bufferização do objeto AUFTRAG (ordens internas). Esse
desligamento afeta também as numerações das ordens de produção e os projetos.

Para desligar, aplicar nota OSS 62077.

MOTIVO DO INVESTIMENTO E OUTROS CAMPOS INFORMATIVOS EM ORDEM INTERNA


DE INVESTIMENTO

Escolher o caminho (no IMG) Administração de Investimentos > Ordens de Investimento >
Dados Mestres > Ordens > Modalidades dos campos registro mestre, e escolher a aplicação
desejada:

Motivos de Investimento (transação OAW1)


Código de Proteção ao Meio Ambiente
Escala para Medidas

CRIAÇÃO E PREENCHIMENTO AUTOMÁTICO DE CARACTERÍSTICAS DEFINIDAS PELO


USUÁRIO EM ORDENS DE PRODUÇÃO E ORDENS INTERNAS

Proceder conforme nota 88660. Como exemplo de uso, podemos querer criar uma hierarquia
de ordens que separe materiais semi-acabados de acabados. Não existe essa característica
disponível no sistema. Vamos criar uma característica que será preenchida com 1 – para
produtos acabados e 2 – para produtos semi-acabados – nas ordens de produção.

Passos a serem seguidos no menu path (IMG) Controlling > Controlling Custos do Produto >
Sistema Info > Contabilidade de Objetos de Custos > Opções para análise compacta /
seleção de ordens > Hierarquia e seleção de ordem:

1) Criação da característica

Definir caraterísticas livres (CT01): Entrar com nome, descrição, formato. Se o valor da
característica só puder ser obtido automaticamente (sem possibilidade de alteração),
escolher o caminho de menu Saltar > Ctrl. Interface gráf, e marcar “Não pronto para entrada”.

2) Criação da função para preenchimento automático da característica

No menu funcional, Logística > Funções Centrais > Config. Variantes > Ferramentas >
Funções > Criar (CU65). Entrar com nome e descrição. Clicar no botão Módulo de Função
(ou caminho de menu Ambiente > Módulo de Função). Na tela seguinte, clicar o botão Criar.
Informar a classe de desenvolvimento (alguma classe de usuário definida por basis, por
exemplo, ZDES). Após informar uma descrição para o módulo, clicar nas pastas abaixo,
informado:

Importação

Parâmetro importação Estr./cpo.referê


GLOBALS CUOV_00
Tabelas

Parâmetro da tabela Estrutura ref


QUERY CUOV_01
MATCH CUOV_01

Exceções

Exceção
FAIL
INTERNAL_ERROR

Gravar o módulo de função e clicar no botão Texto Fonte (caminho de menu Saltar > Módulo
de Função texto de origem). Inserir a lógica da função. No exemplo abaixo, estamos
utilizando a função para preencher a característica CO_TIPOORDEM. Essa característica
recebe o valor 1 (que significará materiais semi-acabados) se a característica número do
material começar por 5; e o valor 2 (que significará materiais acabados) nos outros casos.
Abaixo, o código fonte exemplo, comentado:

FUNCTION Z_CO_FILL_CHARAC.
*"-------------------------------------------------------------------
*"*"Interface local:
*" IMPORTING
*" VALUE(GLOBALS) LIKE CUOV_00 STRUCTURE CUOV_00
*" TABLES
*" QUERY STRUCTURE CUOV_01
*" MATCH STRUCTURE CUOV_01
*" EXCEPTIONS
*" FAIL
*" INTERNAL_ERROR
*"-------------------------------------------------------------------

*--------------------------------------------------------------------
* Definição das variáveis para receber os valores das características
* Devem ser definidas tantas variáveis quantas sejam as característi-
* cas a serem exportadas e importadas. Nesse exemplo, definimos
* 1_valueimp para receber o valor de número do material
* (SAP_KKR_ORMATNR) e 1_valueexp para exportar o valor da
* característica CO_TIPOORDEM.
*--------------------------------------------------------------------

DATA: 1_VALUEIMP LIKE CUOV_01-ATWRT, Like CUOV_01-ATWRT se variável importada /


exportada for alfa; like CUOV_01-ATFLV se for
1_VALUEEXP LIKE CUOV_01-ATWRT. numérica

*--------------------------------------------------------------------
* Chamada do módulo de função que recupera os valores de caracterís-
* ticas já preenchidas. O módulo deve ser chamado tantas vezes
* quantas sejam as características que devem ser recuperadas. No
* exemplo, só é chamada uma vez para recuperar o número do material
* (SAP_KKR_ORMATNR) em 1_VALUEIMP
*--------------------------------------------------------------------

CALL FUNCTION 'CUOV_GET_FUNCTION_ARGUMENT'


EXPORTING Característica a recuperar
ARGUMENT = 'SAP_KKR_ORMATNR'
IMPORTING
SYM_VAL = 1_VALUEIMP Variável que receberá a
TABLES característica a ser recuperada
QUERY = QUERY
EXCEPTIONS
SYM_VAL se a característica a ser
recuperada for alfa; NUM_VAL se for
numérica
ARG_NOT_FOUND = 1
OTHERS = 2.

*--------------------------------------------------------------------
* Tratamento do valor da característica recuperada: se o número do
* material estiver entre 50000000 e 59999999, o valor a ser exportado
* para a característica CO_TIPOORDEM é 1 (semi-acabados); nos outros
* casos, é 2 (acabados)
*--------------------------------------------------------------------
IF 1_VALUEIMP > '50000000 ' AND
1_VALUEIMP <= '59999999 '.
1_VALUEEXP = '1'.
ELSE.
1_VALUEEXP = '2'.
ENDIF.

*--------------------------------------------------------------------
* Chamada do módulo de função que preenche o valor das característi-
* cas a serem preenchidas automaticamente. O módulo deve ser chamado
* tantas vezes quantas as características a serem preenchidas. No
* exemplo, só é chamada uma vez para exportar o valor contido em
* 1_VALUEEXP para CO_TIPOORDEM
*--------------------------------------------------------------------
CALL FUNCTION 'CUOV_SET_FUNCTION_ARGUMENT' Característica cujo valor
EXPORTING será preenchido
ARGUMENT = 'CO_TIPOORDEM'
VTYPE = 'CHAR'
SYM_VAL = 1_VALUEEXP
Variável que contém o valor a ser
TABLES exportado
MATCH = MATCH
EXCEPTIONS
EXISTING_VALUE_REPLACED = 1
OTHERS = 2.

ENDFUNCTION.

Após salvar a função, voltar, e na transação de criação da função, clicar no botão


características (caminho de menu Saltar > Sintese Características). Incluir todas as
características de entrada (no exemplo acima SAP_KKR_ORMATNR) e as características de
saída – as que serão preenchidas automaticamente (no exemplo acima CO_TIPOORDEM);
nas características de entrada, selecionar o indicador Parâmetro de entrada. Voltar para
a tela de síntese, alterar o status da função para 1 – Liberado, e salvar.

3) Criação da dependência de objetos que chamará a função criada

Através do caminho de menu (funcional) Logística > Funções Centrais > Configuração de
variantes (transação CU01), criar uma dependência do tipo Ação. Clicar o botão Editor
relações (caminho de menu Saltar > Editor Relações). Escrever a seguinte relação (baseada
no exemplo anterior): Característica (s) de
Nome da função entrada para a função
criada anteriormente

FUNCTION Z_CO_FILL_CHARAC (SAP_KKR_ORMATNR = SAP_KKR_ORMATNR,


CO_TIPOORDEM = $SELF.CO_TIPOORDEM)
Característica (s) que serão
preenchidas pela função

Voltar. Na tela de síntese, alterar o status da dependência para 1 – Ativação, e salvar.

4) Ativação da dependência

Para que os valores passem a ser preenchidos automaticamente, é necessário que tanto a
característica quanto a dependência criada sejam atribuídas à classe de objetos
SAP_KKR_CLASS.

Utilizando o menu funcional Logística > Funções centrais > Sistema de classes > Classe >
Modificar (transação CL02). Escolher o tipo de classe Objetos de Controlling – classe 013, e
informar a classe SAP_KKR_CLASS. Uma vez na aplicação, escolher o caminho de menu
Saltar > Características. Incluir a característica criada. Salvar. Entrar novamente na aplicação
e escolher o caminho de menu Suplementos > Dependência de objetos > Atribuições. Clicar
em novas entradas e informar a dependência criada no passo anterior.

A partir desse momento, a(s) característica(s) passarão a ser preenchidas automaticamente.


Para verificar o valor da característica na ordem de produção, chamar a transação CO03,
escolher o caminho de menu Ordem > Funções > Classif. Controlling.

5) Exemplo para recuperação de característica numérica

No exemplo anterior, a função Z_CO_FILL_CHARAC recuperava uma característica


alfanumérica. Nesse exemplo, mostramos a codificação da função para a recuperação da
característica numérica SAP_KKR_ORIDAT2 (data de encerramento técnico) e a move para
uma variável alfa no formato AAAAMM:

FUNCTION Z_CO_REC_AAAAMM.
*"-------------------------------------------------------------------
*"*"Interface local:
*" IMPORTING
*" VALUE(GLOBALS) LIKE CUOV_00 STRUCTURE CUOV_00
*" TABLES
*" QUERY STRUCTURE CUOV_01
*" MATCH STRUCTURE CUOV_01
*" EXCEPTIONS
*" FAIL
*" INTERNAL_ERROR
*"-------------------------------------------------------------------
DATA: 1_VALUE1 LIKE CUOV_01-ATFLV,
1_VALUE2 LIKE CUOV_01-ATWRT,
1_VALUEAUX(8) TYPE N.

CALL FUNCTION 'CUOV_GET_FUNCTION_ARGUMENT'


EXPORTING
ARGUMENT = 'SAP_KKR_ORIDAT2'
IMPORTING
NUM_VAL = 1_VALUE1
TABLES
QUERY = QUERY
EXCEPTIONS
ARG_NOT_FOUND = 1
OTHERS = 2.
MOVE 1_VALUE1 TO 1_VALUEAUX.
MOVE 1_VALUEAUX(6) TO 1_VALUE2(6).

CALL FUNCTION 'CUOV_SET_FUNCTION_ARGUMENT'


EXPORTING
ARGUMENT = 'Z_CO_AAAAMM_ENCERRAMENTO'
VTYPE = 'CHAR'
SYM_VAL = 1_VALUE2
TABLES
MATCH = MATCH
EXCEPTIONS
EXISTING_VALUE_REPLACED = 1
OTHERS = 2.

ENDFUNCTION.

DOCUMENTO DE ORIGEM EM OUTRO SISTEMA LÓGICO

Às vezes, ao criar um novo mandante em um sistema como cópia de um mandante já


existente, o sistema assume que o sistema lógico dos lançamentos já efetuados (MM, SD, FI,
CO) é o mandante copiado. Com isso, torna-se impossível exibir lançamentos originais ou
estorná-los. Para consertar isso, é preciso atualizar o sistema lógico nos cabeçalhos de
todos os documentos.

Mensagens sintoma desse erro são : RW020 – O documento de origem está no sistema
lógico XXXXXXX ou KC028 – Este não é o sistema lógico da ACC USI1.

Para acertar os cabeçalhos dos documentos, proceder conforme a nota OSS 28958, criando
o relatório ZZLOGSYS, e rodando esse relatório. Na hora de rodar o relatório, informar como
parâmetro OLD_SYS o mandante de onde os dados foram copiados.

Abaixo, o código do relatório (só não possui as tabelas de AM; se esse módulo tiver sido
implementado, verificar a nota).

REPORT ZZLOGSYS .

TABLES: T000, MKPF, COBK, COEP, COVP, AUFK, CSKS, VBRK, ACCTHD,
BKPF, GLPCA, GLPCP, CEPC.
DATA: NEW_SYS LIKE BKPF-AWSYS.
PARAMETER: OLD_SYS LIKE BKPF-AWSYS.
SELECT SINGLE * FROM T000 WHERE MANDT EQ SY-MANDT.
NEW_SYS = T000-LOGSYS.
CHECK NOT NEW_SYS IS INITIAL.
UPDATE MKPF SET AWSYS = NEW_SYS
WHERE AWSYS = OLD_SYS.
UPDATE COBK SET LOGSYSTEM = NEW_SYS AWSYS = NEW_SYS
WHERE LOGSYSTEM = OLD_SYS.
UPDATE COEP SET LOGSYSO = NEW_SYS LOGSYSP = NEW_SYS
WHERE LOGSYSO = OLD_SYS.
UPDATE AUFK SET LOGSYSTEM = NEW_SYS
WHERE LOGSYSTEM = OLD_SYS.
UPDATE CSKS SET LOGSYSTEM = NEW_SYS
WHERE LOGSYSTEM = OLD_SYS.
UPDATE VBRK SET LOGSYS = NEW_SYS
WHERE LOGSYS = OLD_SYS.
UPDATE ACCTHD SET AWSYS = NEW_SYS
WHERE AWSYS = OLD_SYS.
UPDATE BKPF SET AWSYS = NEW_SYS
WHERE AWSYS = OLD_SYS.
UPDATE GLPCA SET LOGSYS = NEW_SYS
WHERE LOGSYS = OLD_SYS.
UPDATE GLPCP SET LOGSYS = NEW_SYS
WHERE LOGSYS = OLD_SYS.
UPDATE CEPC SET LOGSYSTEM = NEW_SYS
WHERE LOGSYSTEM = OLD_SYS.

WRITE:/ 'Number of updates: ', SY-DBCNT.

NOTAS OSS A SEREM CONSIDERADAS

67739 – Prioridades das OSS (nota informativa)

33968 – Características não preenchidas em CO-PA (configuração tabela TKEZU) – todas as


características que são derivadas da tabela de item de documento de vendas devem constar
da tabela TKEZU, pois no momento da criação da ordem de venda, os dados ainda não
estão atualizados naquela tabela (o insert ainda não foi feito), fazendo com que as
características não sejam preenchidas. A configuração é necessária para que o programa
pegue a característica de tabelas temporárias (KOMK ou KOMP); se não for feita, as
características só são preenchidas numa rederivação ou alteração da ordem de venda.
Tomar cuidado, pois a configuração na TKEZU se sobrepõe à estratégia de derivação.

20254, 129318, 105747 – Campos de valor de SD que não são transferidos para CO-PA

35288 – Informações técnicas para melhoria de performance (criação de índices, separação


de tabelas em diferentes tablespaces) de CO-PA

101579 – Otimização de performance na estratégia de derivação – versão 40B

159266 e 126375 – Otimização de performance no planejamento. O pré-requisito para essas


notas é a aplicação da nota 128538.

121015 – Otimização de performance na cópia do planejamento com reavaliação

174327 – Otimização de performance em lançamentos em massa (por exemplo, faturamento


coletivo) em CO-PA

127228 – Otimização de performance em lançamentos em massa em CO-PA e criação /


alteração de ordens de venda muito grandes (VA01 / VA02)

172740 – Informações técnicas sobre a estratégia de derivação – versões 4.X

154982 – Torna o número de condições para entrada em uma regra de derivação ilimitado.

157677 – Torna o número de campos recuperados num acesso à tabela (na estratégia de
derivação) ilimitado.

129267 – Acesso exclusivo a um dos cálculos de custos de materiais especificados na


avaliação CO-PA (ao invés do acesso cumulativo)

70981 – Avaliação planejada usando condições de SD

21207 – Deleção de características e campos de valor em área de resultado com valores.

128538 – Ciclo de rateio real com critério de rateio baseado numa versão de planejamento
em moeda da empresa apresenta mensagem GA733 – fator de rateio não encontrado.

159781 – Rateio de centros de custos para PA deixa resíduos em moeda da empresa


(apesar de distribuir totalmente o valor em moeda da área de controle).
149098 – Na aplicação de rateio de centros de custos para PA, a consulta F4 de grupos de
centros de custos e classes de custos traz registros demais. Essa nota restringe a seleção
aos grupos pertencentes à área de contabilidade de custos.

160023 – Dados incorretos em relatórios usando níveis de compactação CO-PA. Aplicar a


nota e posteriormente executar o módulo de função RKE_GENERATE_SELECT para cada
uma das áreas de resultado a serem alteradas.

131796, 141539, 153970 – Partidas individuais não são exibidas a partir de nós de uma
hierarquia nos relatórios CO-PA

140288 – O transporte da deleção de um nível de compactação gera erros no display de


relatórios que usem níveis de compactação. O problema é resolvido na 40B no
HOTPACKAGE 14. Há uma solução workaround na nota (rodar um relatório de ajuste após
esse tipo de transporte).

138760 – Alteração de textos de características / campos de valor não refletida no sistema de


informação.

113496 – Cópia de formulários (relatórios CO-PA) entre áreas de resultado

157444 – Ordens criadas a partir de cotações não tem todas as características CO-PA

139217 – Lançamento de PRD em PA

140996 – Lançamento de UMB em PA

112938, 160311 – Reconciliação entre CO-PA, SD e FI. As transações KEAT e KEAW podem
ser baixadas do server sapserv3 (A nota 176213 diz respeito a correções na 112938; a
178389 corrige a 160311; ambas podem ser baixadas do servidor, sem nenhuma correção
manual)

176398 – Na alteração de ordem de vendas, ao deletar um item, e criar outro com o mesmo
ID, duas partidas de estorno são criadas (o estorno é dobrado).

167156 – No relançamento de ordens de venda para CO-PA (KE4T), alguns itens são
lançados múltiplas vezes (sem o correspondente estorno).

106968 – Lógica de atribuição a objetos de custos (nota informativa)

106902 – Receitas em Centros de Custos (nota informativa)

155239 – Short dump insert duprec

133142, 122335, 142150 – KE549

157315 – Nota coletiva mais atual CK11

153040 – Ajustar a quantidade do cálculo de custos à produzida

142780, 144679, 154336 – Estoque fica negativo ao fazer movimento de materiais para
ordem de produção após apropriação da OP.

112659 - KI501 - na cópia de planejamento - usuário se loca a ele mesmo

146069 – No planejamento de centros de custos, quando o centro não é válido para todo o
período informado no planejamento (ou não era válido no período anterior – período de
comparação) – short dump NO_ENTRY_FOUND/IK528_GET_OWAER_FOR_GJ ocorre.
O problema posterior – após a aplicação da nota é:

1) My planning layout displays planned and actual figures for the previous fiscal year.

2) I have cost centers with validity starting from 01.06.1999, and planned values for these
cost centers in this period

3) When I try to plan periods 01 through 12/2000, these planned values are not displayed;
they're only displayed if I input period 06 through 12/2000.

A solução SAP para o problema:

“ the system works as designed, even if it doesn't produce the result you are rightfully
expecting. The logic is that the cost center must be valid in the whole time interval to be valid
for display or change.
Since L1104 is only valid from 6/1999 no values will be displayed for 1-12/1999. The easiest
way to solve this problem is to create the cost center L1104 from 01.01.1999 to 31.05.1999 as
a copy of L1104.
Since no actual bookings should be allowed for this period anymore it should be no problem.
After extending the cost center you should be able to plan it the way you expect it.”

155363 – Relatório de partidas individuais chamado a partir de um outro relatório (p.ex.


Centros de Custos – Real x Planejado) não mostra todas as partidas individuais. Além da
correção especificada na nota, abrimos uma OSS que tem outra correção que não saiu em
nota:

I have changed the coding from function module


'ROMU_OM_FILL_BELKZ' in the following way:
+++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

...
* if ( vrgng = 'COIN' or vrgng = 'RKU1' "<<< delete
if ( vrgng = 'COIN' or vrgng = 'RKU1' or vrgng = 'COIN'"<<< insert
or vrgng = 'RKU2' or vrgng = 'RKU3'
or vrgng = 'RKIB' or vrgng = 'RKPB' ) and
( beknz <> 'A' and beknz <> 'L' ).
belkz = 'S'.

elseif belkz = 'A' or belkz = 'L'.

180593 e 162678 – O drill down da transação KSB1 para a exibição de partidas individuais
de documentos gerados pela transação CK24 – Atualização de preço standard – dá erro: ao
invés de chamar a transação FB03, chama a MR03.
REGRAS DE EXCEÇÃO

Configuração

Todas as transações abaixo se encontram no caminho de menu IMG : Controlling Custos do


Produto > Sistema Info > Opções para análise compacta/seleção de ordem > Hierarquia e
seleção de ordem

>>Selecionar e gerar características (transação OKQ3) : características que serão buscadas


nas ordens para compactação de informações

>>Definir esquemas de seleção (transação BS42): quais ordens serão selecionadas


conforme status da ordem

>>Definir telas de seleção para a lista de ordens (transação OKKC) : campos que são
características da hierarquia e que poderão ser utilizados como filtro de forma a limitar a
compactação

>>Criar Hierarquias de Ordens (transação OKTO)

>>Definir regras de exceção (caminho de menu: Controlling Custos do Produto > Sistema
Info > Opções para análise compacta/seleção de ordem > Hierarquia e seleção de ordem
> Definir regras de exceção ) :

Caso ordens cumpram determinadas regras apareceriam com "semáforos" coloridos


conforme definição apontando que determinada regra foi atingida

PASSOS :

1. DEFINIR QUE TIPOS DE NORMAS PODERÃO SER UTILIZADAS


2. PARA CADA NORMA A SER UTILIZADA, DEFINIR QUAIS REGRAS PODERÃO SER
UTILIZADAS
3. PARA CADA NORMA/REGRA, DEFINIR VALORES LIMIARES PARA VERMELHO E
AMARELO
(POR PERCENTUAL OU ABSOLUTO CONFORME CADA NORMA)

EXEMPLOS:

Nº regra 01
Norma Desvio de custos com referência a valor planejado em porcentagem
Valor limiar vermelho Valor limiar amarelo Moeda
Percentual 50 30
Absoluto

Nº regra 02
Norma Desvio de quantidade com ref.a valor planejado em porcentagem
Valor limiar vermelho Valor limiar amarelo Moeda
Percentual 10 5
Absoluto

Utilização
Para utilizar regras de exceção, escolher o seguinte caminho de menu, na parte funcional :
Contabilidade > Controlling > Contabilidade de Objetos de Custo > Controlling de Custos por
Ordem > Sistema Info > Obtenção de Dados > Hierarquia de Ordens
SISTEMA INFOR > OBTENÇÃO DE DADOS > HIERARQUIA DE ORDENS

Selecionar a hierarquia desejada, o período, e para associar a regra de excessão a essa


hierarquia, escolher o caminho de menu Suplementos > Excessão > Definir Regra

Após a associação, rodar a compactação

Para visualizar os resultados, selecionar o relatório no caminho Contabilidade > Controlling >
Contabilidade de Objetos de Custo > Controlling de Custos por Ordem > Sistema Info >
Seleção de Relatório, que se encontra na árvore Lista de objetos / para hierarquias de ordem
/ selecionar hierarquia

Nesse relatório, serão destacados os níveis da hierarquia que "merecem" análise pois se
estão encaixando na regra de exceção (luz amarela ou luz vermelha)
INCLUSÃO DE NOVAS CARACTERÍSTICAS / CAMPOS DE VALOR CO-PA NUM
SISTEMA E TRANSPORTE PARA OUTRO

Depois que uma request onde é transferida uma nova característica / novo campo de valor /
ou qualquer alteração na estrutura da área de resultado é transportada, para que ela fique
válida no sistema destino, é necessário entrar na transação de atualização da área de
resultado (KEA0) e pedir a geração da área. Assim, as características/campos de valor novos
passam a ser "vistos".

Além disso, tratando-se de características geradas pelo usuário, com tabelas de verificação,
é necessário rodar o report RKEAGENV, para que os módulos de manutenção de visões
sejam gerados. Esses módulos são necessários para manter os valores permitidos dessas
características.

TRANSPORTE CONFIGURAÇÕES E DADOS MESTRE CO-PA

Consultar também a nota OSS 128862.

A transação KE3I transporta todos os objetos de configuração e dados mestre de CO-PA. Os


valores das condições utilizadas em esquemas de cálculos de custos, que estão cadastradas
nas tabelas criadas pelo usuários (tabelas A5XX), entretanto, não são transportados nessa
transação.

É preciso transportar esses valores através de ALE. Para isso, é preciso criar um modelo de
distribuição com o mandante/sistema origem e o mandante/sistema destino, tanto no
mandante de origem quanto no mandante de destino (BASIS configura). Depois desse
modelo criado, pode-se incluir a classe de mensagem COND_A no modelo para a
transferência (se ela ainda não tiver sido incluída). Para isso, executar os seguintes passos:

IMG no sistema/mandante de origem:

Componentes válidas para todas as aplicações > Distribuição (ALE) > Atualizar Modelo de
Distribuição.

Selecionar o modelo de distribuição e clicar o botão Anexar Tipo de Mensagem. Informar o


tipo de mensagem COND_A. Gravar.

Componentes válidas para todas as aplicações > Distribuição (ALE) > Comunicação > Gerar
protocolos de transmissão

Informar o modelo de distribuição e clicar Executar

Componentes válidas para todas as aplicações > Distribuição (ALE) > Atualizar Modelo de
Distribuição.

Selecionar o modelo de distribuição e escolher o caminho de menu Processar > Visão de


Modelo > Distribuir

IMG no sistema/mandante de destino:

Componentes válidas para todas as aplicações > Distribuição (ALE) > Comunicação > Gerar
protocolos de transmissão

Informar o modelo de distribuição e clicar Executar


Após configurado o modelo, no mandante de origem, escolher a transação para atualização
dos tipos de condição (KE47), visualizar os registros para acesso da condição a ser
exportada, selecionar os registros a exportar e clicar no botão Enviar Condição (caminho de
menu Processar > Enviar condição).

Para visualizar os resultados do transporte, entrar na transação BALE e escolher o caminho


de menu Monitorização > Síntese Idoc, no mandante origem e no mandante destino.

ESTORNO DE DOCUMENTOS DE FATURAMENTO EM CO-PA

A transação KE4S (Lançamento posterior de faturas em CO-PA) sem o flag de verificação de


lançamento em CO-PA não estorna o item lançado e o lança novamente. Só refaz o
lançamento, duplicando os valores.

Para fazer o estorno, é necessário rodar o programa RKECADL1 (ver documentação na nota
OSS 126937), e depois fazer o relançamento usando a transação KE4S (com o flag de
verificação do lançamento escolhido).

Para utilizar a transação KE4S, é preciso aplicar a nota 139474 (correção do programa).
Para que a transação KE4S redetermine sempre o segmento de rentabilidade (no caso de
uma alteração na estratégia de derivação), é necessário aplicar a nota 135647.

O estorno e relançamento das ordens de vendas incorretas pode ser feito diretamente pela
transação KE4T, com o flag de verificação de lançamentos em CO-PA desligado. Se o flag
“sem bloqueio de documentos de venda” está desativado, o programa prende a tabela de
ordens de venda (não é possível a criação ou alteração de ordens enquanto o programa
estiver rodando.

REINICIALIZAÇÃO DE CAMPOS DE VALOR EM ORDENS DE VENDA

A transação KE4W no sistema standard só reinicializa campos de valor de documentos de


faturamento. As ordens de venda continuam a ser lançadas, independentemente dessa
configuração. Para que também os campos de valor em ordens de venda sejam
reinicializados, é preciso proceder de acordo com a nota 65707:

1) Ativar a característica FKART para o tipo de demonstração de resultados utilizada


(baseada em cálculo de custos ou em contas) na transação KEQ3;
2) Implementar as correções em programas indicadas na nota;
3) Regerar o programa afetado, rodando o módulo de função
RKE_GENERATE_INTERFACE_ACT (transação SE37 – informar o nome do módulo e
pressionar o botão TST individual; Informar na próxima tela como parâmetro ERKRS o
código da área de resultado e clicar Executar) em todos os mandantes a serem afetados.

É pré-requisito que todos tipos de ordens de venda que devam ter os campos de valor
reinicializados estejam ligados a um tipo de faturamento (verificar na transação VOV8),
mesmo que essas ordens não gerem faturamento posterior. Se isso acontecer (ordem sem
faturamento posterior), SD deve fazer configuração de maneira a dar erro se o usuário tentar
faturar essa ordem.

A configuração da transação KE4W também deve estar feita.

Obviamente, o tipo de faturamento ao qual o tipo de ordem a ser excluído for associado não
pode ser associado a outro tipo de ordem que não será excluída.

Após a configuração ter sido realizada, se todos os campos de valor de um tipo de


faturamento tiverem sido excluídos, a ordem de venda nem será lançada em PA (se tentar
consultá-la através da KE24, não haverá nenhuma partida individual), diferentemente do
faturamento, que será lançado com todos os campos zerados.

OBS: A reinicialização de campos de quantidade (em áreas de resultado com duas moedas)
em ordens de venda pode ocasionar short dump, gerando a mensagem KE549. Para
resolver esse problema, implementar a nota 133142. Após a correção no programa, regerar o
programa afetado, como descrito em 3 (ou aplicar as notas juntas, e só depois regerar os
programas).

CARACTERÍSTICAS COM O MESMO NOME – SELEÇÃO EM RELATÓRIOS

Ao criar uma característica com base em um elemento de dados, o sistema automaticamente


busca a tabela de verificação de valores, o nome e descrição desse elemento. Se forem
criadas duas características com base no mesmo elemento de dados (por exemplo, cliente
efetivo e cliente de entrega da mercadoria), como a seleção de características na criação de
um relatório é feita pelo nome da característica (e não pela chave), para descobrir qual
característica estamos selecionando, clicar uma vez sobre o nome da característica. Com ele
selecionado, teclar F1 e selecionar o botão Informação Técnica. Na janela, aparecerá a
chave da característica selecionada.

AUMENTO DO NÚMERO DE POSIÇÕES DAS DESCRIÇÕES DE CARACTERÍSTICAS NOS


RELATÓRIOS CO-PA

De acordo com a nota 112805: por definição, as descrições de características nos relatórios
de CO-PA são apresentadas com 20 posições. Verificar na tabela TKEF qual a tabela (campo
RETAB) onde estão armazenados a descrição curta (REFIE) e a descrição longa (REFIL) da
característica (campo FIENM). A descrição longa pode ser exibida em até 60 posições
(campo REFLL – tamanho máximo exibido da descrição longa). Se essa descrição é
suficiente, basta, ao executar o relatório, fazer um drill-down para a característica a ser
exibida com descrição longa, posicionar o cursor num valor de característica e escolher o
caminho de menu Opções > Represent. Característica, escolhendo a representação, por
exemplo, chave e denominação (descritiva). Salvar o relatório.

Se a tabela onde estão armazenadas as descrições não for suficiente, pode-se alterar isso.
Precisávamos de uma descrição de material que tivesse mais do que as 40 posições da
tabela MAKT (que é a tabela default de descrição das características ARTNR e WWPRO –
uma característica criada a partir de ARTNR). Criamos a tabela ZMATERIAL, com os campos
MATNR e DESCR (100 posições de descrição) e a transação de atualização dessa tabela.

A seguir, alteramos a tabela TKEF através do seguinte report:

report zz_mod_tab_tkef .

tables: tkef.

update tkef set: retab = 'ZMATERIAL'


refie = 'DESCR'
refil = 'DESCR'
refll = 60
where fienm = 'ARTNR' or fienm = 'WWPRO'.

write: / 'UPDATE performed on table TKEF'.


Regeramos as rotinas de leitura de texto, executando o módulo de função
RKD_SHORT_TEXT_GENERATE_30 em com o botão Tst. Individual, informando a classe
de aplicação KE.

Executamos o report RKEAGENF depois, informando a área de resultado e o tipo de análise


de rentabilidade.

Finalmente, executamos os passos de execução do relatório e seleção da opção de


descrição detalhada, descrita no primeiro parágrafo deste tópico.

Especificamente para a alteração do tamanho da descrição da característica KNA1, verificar


a nota OSS 149781. Se essa nota for implementada, implementar também as notas 139331
e 151735.
CENÁRIO – PRODUÇÃO, EXPEDIÇÃO E FATURAMENTO – NEGÓCIO DCS

Criar OP - CO08
Jogar para estoque de cliente - movimento 101 na MB31
Consumir matéria-prima - movimento 261 da MB1A
Apontamentos de atividades - transação CO11 ou CO15 (quando é revenda)
-------------------------------------------------------------------------------------------------------------------
VL01 - Expedição (Entrar com o local de expedição (SL01) e no OP
LT03 - Entrar com sistema de depósito = 600 e no do fornecimento criado acima
VL02 - Registrar saida da mercadoria
VF01 - Faturar

CENÁRIO – PRODUÇÃO, EXPEDIÇÃO E FATURAMENTO – NEGÓCIO SID

Criar OP - CO08 – usar tipo de ordem ZP01 – não liberar a ordem – salvar direto
Jogar para estoque de cliente - movimento 101 na MB31 – usar depósito 4000
Consumir matéria-prima - movimento 261 da MB1A
Apontamentos de atividades - transação CO11 ou CO15 (quando é revenda)
-------------------------------------------------------------------------------------------------------------------
VL01 - Expedição (Entrar com o local de expedição (USI) e no OP (Para o mercado externo,
antes de entrar na transação, escolher o caminho Processar > Propor Tipo de remessa.
Escolher Tipo de remessa = ZEX; escolher organização de vendas = ME; canal de
distribuição = EX; setor de atividade = LP (p.ex, depende da ordem)
Selecionar o caminho de menu Item > Partição do lote.
Selecionar o caminho de menu Processar > Dados incompletos e preencher o que ele pedir
VL02 - Registrar saida da mercadoria
VF01 – Faturar (no mercado externo, clicar o botão Dados Default e escolher Tipo de
faturamento = ZF8)

Para estornar o faturamento, antes, imprimir a nota fiscal (J1B3 – informar o número da nota
fiscal (o número será dado se, ao tentar estornar, a impressão ainda não estiver feita) – e
escolher o caminho de menu Nota Fiscal -> Saída)

CENÁRIOS – FATURAMENTO SEM RECONHECIMENTO DA RECEITA – RECEITA SÓ


RECONHECIDA NA REMESSA

1) no faturamento tinha documento de venda (receita X cliente) sem expedição de


mercadoria e lançando provisão de custos
2) no embarque havia novo documento de venda (estornando provisão de custos) e
documento de expedição lançando baixa de estoque e custo)

aqui seria:
1) no faturamento doc de venda sem expediçao lançando cliente x provisão
2) no embarque haveria novo documento de venda (lançando provisão x receita) e
documento de expedição (lançando baixa de estoque e custo)

Em PA, no faturamento, excluir todos os campos de valor gerados por esse tipo de
faturamento (o documento de vendas deve ter esse tipo de faturamento específico) utilizando
a transação KE4W. Verificar tópico Reinicialização de Campos de Valor em Ordens de
Venda descrito anteriormente.

CENÁRIO – PROBLEMA EM LANÇAMENTO EM CONTA DE CUSTO ANTES DA CRIAÇÃO


DA CLASSE DE CUSTO

O que aconteceu:
1. Documento gerado antes da criação de classe de custo 1900003538

D fornecedor
C conta 34100108 (sem gerar lançamento em CO)

2. Criação de classe de custo 34100108

3. Lançamentos na conta 34100108 e por consequência em CO

Como resolver (como ajustar 34100108 em CO do primeiro lançamento?):

Proposta 1: rodar OKBA

> não funciona pois não tem centro de custo no documento original
>> deveria ter rodado OKBA antes de criar a classe de custo e fazer outros lançamentos na
conta 34100108

Proposta 2.

a.Criar conta 34100199 e não criar classe de custo

b.Lançar via FI:

D 34100108 no centro de custo adequado com valor igual ao documento original


C 34100199 sem centro de custo

c. SAP gerará apenas 1 lançamento em CO:

D 34100108 no centro de custo adequado

exemplo:

> documento 100000207


CL Div. Conta BRL Montante
001 40 0034100108 Servs.MANUT. 100,00
002 50 0034100199 Ajuste serv.manut. 100,00-

 correspondente documento CO

Nº doc. Data doc. Texto cabeçalho doc. CR Nº doc.ref
LiL TpO Objeto Denominação objeto Clas.custo Denom.classe custo
5 100002226 01.09.1999 R 100000207
1 CCS 341209 OXICORTE 34100108 Servs.MANUT.

d. gerar classe de custo para 34100199

e. lançar em FI:

C 34100108 no centro de custo adequado com valor igual ao documento anterior


D 34100199 no mesmo centro de custo com valor igual ao documento anterior
> de forma a ficar com saldo zero em 34100199 e ajustar saldo na conta 34100108

f. bloquear a conta 34100199 pois não poderá mais ser utilizada

Observações importantes:
Nunca pode haver lançamento em conta contábil de resultado antes que a classe de
custo seja criada
Deve haver um procedimento de criação de conta contábil
1. CRIAR ITEM FINANCEIRO
2. CRIAR CONTA (ASSOCIADA AO ITEM FINANCEIRO)
> pode-se até criar bloqueada até a criação da classe de custo
3. CRIAR CLASSE DE CUSTO
> desbloquear a conta para liberar sua utilização
Se for detectado um erro (lançamento em FI sem classe de custo) deve ser corrigido
(via OKBA) antes da criação da classe de custo

CENÁRIO – ELIMINAÇÃO DE CLASSES DE CUSTOS DE DESPESAS COM O MESMO


SIGNIFICADO DE CLASSES DE CUSTO INDUSTRIAL (DUPLICADAS)

Rio Negro e Fasal, não alteram nada e continuam com as contas do grupo 34 e 44 como
estão.

Cosipa, Usiminas e Usiminas Mecânica, mantém o grupo 34 integral e sumariza o grupo 44


em 12 contas para despesas administrativas e outras 12 contas de mesma natureza para
despesas de vendas.
Todos os centros de custo, independente de serem de produção, administrativos ou vendas
utilizarão sòmente as contas detalhadas do grupo 34.
“CO” criará ciclos de rateio que transferirão as contas do grupo 34 dos centros
administrativos e vendas para as novas contas de despesas, utilizando ordens internas como
elemnto de passagem de grupos de contas 34 para a respectiva conta do grupo 44.
Portanto, as contas 44 1xx só receberão lançamentos através de “CO”.
Esta solução não trará prejuizos nas consolidações das demonstrações das Empresas do
Sistema Usiminas.

ESTRATÉGIA PARA IMPLEMENTAÇÃO:


Fazer as alterações o mais rápido possível, visando fazer o fechamento da RP 5 com o novo
critério. Os lançamentos efetuados em contas 44 1xx para centros administrativos e vendas
serão estornadas para as contas 34 1xx.

PROVIDÊNCIAS A SEREM TOMADAS:


“CO” - Criar os ciclos de rateio, criar as ordens, deletar as classes de custo 441xx, alterar as
regras de validação de centros de custo, criar 2 contas no grupo 34 para liquidação das
ordens para despesas administrativas e vendas, Alterar as classes de custo no planejamento
dos centros de custo administrativos e de vendas, e outros que serão avaliados pela equipe.

“FI” - Criar novas contas 441xx, deletar determinação contábil, deletar contas do grupo
441xx, alterar os esquemas de contabilização, estornar contas 441xx nos centros
administrativos e vendas e outros que serão avaliados pela equipe.

“MM” - Cancelar movimentos em duplicidade criados para satisfazer a situação de


duplicidade de contas que existia e outros que serão avaliados pela equipe.

CENÁRIO: TESTE DE STRESS

“ Eu quero dividir o teste em três etapas. Na primeira, nós estaríamos trabalhando


com um número reduzido de usuários. A idéia aqui é avaliar a execução das
transações mais custosas tem termos de tempo. Vamos executar um trace destas
transações e com isso, nós vamos determinar parâmetros de banco de dados e
buffers do SAP que devem ser ajustados. Isso demanda que estas transações sejam
executadas várias vezes. Assim, executa, mede tempo, avalia trace, ajusta
parâmetros, tira SAP do ar, coloca SAP no ar, executa novamente.

A segunda etapa está associada aos desenvolvimentos. Assim, temos que testar
também isoladamente no produtivo todos os desenvolvimento construídos. O mesmo
processo de trace deve ser executado como no passo 1. Neste caso, além de
ajustes nos parâmetros do SAP também podemos fazer algum ajuste fino nos
programas. Criar um índice ou mudar um select.

A última etapa envolve o maior número de usuários possível. Vamos tentar rodar o
pior dia da empresa. Precisamos acompanhar os tempos envolvidos nos processos
mais críticos. Quanto tempo para criar / alterar ordens de venda e produção, quanto
tempo para movimentação de estoque, etc. Fazemos uma avaliação geral do
ambiente, ajustamos alguns parâmetros e rodamos mais uma vez. Além dos ajustes
em parâmetros, podemos tentar um redistribuição dos usuários pelos servidores de
aplicação para tentar melhorar a performance.

Meu plano:

1. Criar um mandante auxiliar na produção para o teste;


2. Mapear as transações mais críticas em termos de tempo;
3. Mapear todos os desenvolvimentos construídos;
4. Identificar que transações serão executadas no pior dia do mês;
5. Gerar um roteiro a ser seguido pelos usuários. Acho que algo semelhante a
simulação considerando o passo 4;
6. Agendar uns dois dias para o trabalho. Podemos fazer as etapas 1 e 2 em um dia
e a 3 no dia seguinte.”

Anna Thereza Albuquerque

Como transações críticas em CO, vamos rodar as seguintes:

1) Cálculo de tarifas planejadas


2) Execução de ciclos de rateio e distribuição reais
3) Cálculo de tarifas reais
4) Apropriação coletiva de ordens internas
5) Reavaliação de ordens de produção
6) Cálculo coletivo de WIP
7) Cálculo de desvio
8) Apropriação coletiva de ordens de produção
9) Rateios em PA
10) Sumariação das hierarquias de ordens
11) Atualização dos níveis de compactação em PA
12) Emissão de relatórios em PA

Não teremos preocupação com o "fechamento" das informações. Para execuções repetidas,
iremos executar os processos e depois estorná-los.

INSTALAÇÃO SAPGUI 4.5

It happens quite often that we work with our computer at a client. Software like
Netware Programs, SAPGUI, etc must be configured differently or has to be
installed. What happens is, that after these installations it is not possible anymore
to work with MS-Office programs. A message appears every moment saying that
"There is not enough memory available" to execute a specific function like saving
a document in Word.

The problem has been solved at Chilena Consolidada. The installation of SAPGUI
Release 4.5 overwrites the DLL "Windows\System\Riched20.dll". This is the cause
of the error messages in MS-Office. The problem is simple to solve: Copy the
mentioned DLL in a temporary library before installing SAPGUI 4.5. Copy it back
after the installation.
For more information please contact the OSS system at SAP. There is at least one
note related.
INICIALIZAÇÃO DE CLASSES DE CUSTO – EM CENTROS DE CUSTOS E ORDENS
INTERNAS

1) Centros de Custos:

As contas 34 (classes de custo industrial) serão inicializadas utilizando um centro de custos


"dummy" a débito e utilizando a conta 34999010 (Apropriação de Ordens de Produção) a
crédito.

2) Ordens Internas:

2.1) Se houver ordens internas de manutenção em andamento teremos que carregar o saldo
das 34 dividindo o saldo entre centros de custo e ordens e fazer a primeira apropriação da
ordem para o centro de custos "dummy".

2.2) Se há ordens internas de investimento cujo saldo corresponda ao Imobilizado em


Andamento, este não será inicializado diretamente por FI: os lançamentos serão feitos nas
classes de custos primárias para lançamentos de investimento (classes 7, por exemplo),
abrindo as classes de custos; também poderíamos lançar numa única classe, mas o histórico
dos custos seria perdido); e apropriados na conta do Imobilizado em Andamento.

INICIALIZAÇÃO DE SALDOS DE ESTOQUES - ALTERNATIVAS

 PARA MATERIAIS CADASTRADOS A PREÇO MÉDIA MÓVEL

1) configurações
a. GBB-BSA utilizado pelo movimento 561 com montante
b. UMB reavaliação de material

2) carga
a. 561 com MM com valor médio histórico ou de um mês anterior (custo do mês anterior
não foi fechado)
b. armazenar valores de carga de materiais
c. lançamento da diferença em 31.XX.XX em conta de estoque ajustado

3) ajuste após fechamento de custos


a.1. lançamento de débito ou crédito de material da diferença entre carga e fechamento -
não corrige movimentações, pode gerar PRD que não terão tratamento automático
a.2. lançamento de modificação de preço - não corrige movimentações, pode gerar
variações que não terão tratamento automático
b. lançamento em centros de custo de secundários a serem rateados/atividades ou
centros de produção proporcional às diferenças

 PARA MATERIAIS CADASTRADOS A PREÇO STANDARD

1) configurações
a. GBB-BSA utilizado pelo movimento 561 com montante e ajuste da carga no período
anterior - carga
b. UMB reavaliação de material
c. YSX localização de custos (período atual - primeiro mês operação) não
automáticas e sem obrigatoriedade de impostos
d. configurar empresa em CB - para ativar programa de carga
e. inicializar empresa em CB - para ativar programa de carga

2) carga em 31.XX.XX anterior à implementação SAP


a. 561 em MM com valor a standard ou cálculo de custos anterior (timing de carga de
materiais e planejamento de atividades)
b. armazenar valores de carga de materiais
c. lançamento da diferença em 31.XX.XX em conta de estoque ajustado

3) ajuste após fechamento de custos


a.1. lançamento de débito ou crédito de material da diferença entre carga e fechamento -
não corrige movimentações, pode gerar PRD que não terão tratamento automático
a.2. lançamento de modificação de preço - não corrige movimentações, pode gerar
variações que não terão tratamento automático
b. após fechamento, carga de custo standard em CO-PC-CB com valores a médio do
sistema anterior

CENÁRIO: PROCEDIMENTOS PARA CONVERSÃO DE ESTOQUES – NECESSIDADES

 Para implementação SAP entende-se como atividades a serem executadas antes


do go-live:
 encerramento das operações
 fechamento de custos
 conversão de saldos
 conferência dos saldos
 deve ser reservado tempo significativo para conferência pré-implementação

 Para fechamento de custos:


 devem ser encerradas as entradas de compras
 devem ser encerradas as vendas do mês
 deve parar a produção, analisar com PP
 para produção sugere-se encerramento das ordens de produção do mês e
reabertura no mês seguinte no SAP, de forma a não se computar estoque em
processo (voltar para estoque de matéria-prima ou apontar produção nos
sistemas legados)
 caso não seja possível zero de estoque em processo sugere-se 1) estoque de
produtos intermediários com criação de códigos de materiais intermediários que
serão consumidos em ordens de produção no SAP ou 2) estoque de matéria-
prima que na verdade é material em processo que também será consumida em
produção no SAP (ambas opções irão requerer controle paralelo)
 serão identificados as seguintes variações de posição de estoque:
 matéria-prima em livre utilização
 matéria-prima reservada para Ordem de Venda
 material en processo (tendendo a ZERO)
 outros materiais em livre utilização
 produto acabado em estoque de Ordem de Venda
 material nosso em poder de terceiros (não valorizado) >> sugerimos MM
validar/desenhar processamento posterior de retorno deste material em poder de
terceiros enviado pelos sistemas legados
 material de terceiros em nosso poder (não valorizado)>> sugerimos MM
validar/desenhar processamento posterior de envio deste material de terceiros
em nosso poder enviado pelos sistemas legados
 o processo de fechamento de custos deve levar cerca de 2 horas e irá gerar
saldo de estoque X valor de estoque
 para valorização de estoques de matéria-prima e produto acabado serão
utilizados os custos de matéria-prima (custo será ajustado após fechamento de
custos do primeiro mês de SAP em produção)
 distorções entre saldo valorizado de estoques de sistemas legados X saldo de
estoque valorizado no SAP por arredondamentos serão tratadas nos sistemas
legados
 Verificar se há necessidade de tabela DE:PARA para associar dados dos sistemas
legados com informações de custo por material com códigos de materiais no SAP
 identificada necessidade de minimizar possibilidade de devoluções de notas emitidas
no sistema legado (faturamento antecipado em 30/06 deve ser criterioso) e que
deverão ser processadas no SAP e preparar procedimento/tipo de documento de
venda que suporte a entrada destas devoluções quando ocorrer, analisar com SD

S-ar putea să vă placă și