academia co
TRANSCRIPT
CONTROLADORIA 1 de 325
1 SISTEMA R/3 – INTRODUÇÃO ...................................................................................................................................... 12
1.1 MANDANTE (CLIENT) .................................................................................................................................................... 12
1.2 IDIOMA DO SISTEMA ...................................................................................................................................................... 13
1.3 ACESSO DIRETO À TRANSAÇÃO (COMMAND FIELD) ....................................................................................................... 13
1.4 MASTER DATA – DADOS MESTRES ................................................................................................................................ 13
1.4.1 Cadastro de clientes .................................................................................................................................................. 13
1.4.2 Cadastro de materiais ............................................................................................................................................... 14
1.5 CONSULTAS E RELATÓRIOS ........................................................................................................................................... 14
2 MENU PRINCIPAL ........................................................................................................................................................... 15
2.1 MENU SISTEMA (SYSTEM) ............................................................................................................................................. 15
2.1.1 Abrir/ Fechar Janela (Create / End Session) ............................................................................................................ 15
2.1.2 Especificações do Usuário (User Profile) ................................................................................................................ 15 2.1.2.1 Manter, Definir e Eliminar Dados (Hold, Set and Delete Data) ........................................................................................... 15
2.1.2.2 Dados Próprios (Own Data) ................................................................................................................................................. 15
2.1.3 Serviços (Services) .................................................................................................................................................... 16 2.1.3.1 Reporting ............................................................................................................................................................................. 16
2.1.3.2 Quickviewer (Abap Query (Bc-Srv-Que)) ........................................................................................................................... 16
2.1.3.3 Controle de Saída (Output Controller) ................................................................................................................................. 16
2.1.3.4 Atualização de Tabelas (Table Maintanance) ...................................................................................................................... 16
2.1.3.5 Batch Input .......................................................................................................................................................................... 17
2.1.3.6 Entrada Rápida (Fast Entry) ?????????? .............................................................................................................................. 17
2.1.3.7 Entrada Direta (Direct Input) ............................................................................................................................................... 18
2.1.3.8 CATT (Computer Aided Test Tool (BC-CAT) ??????????? ............................................................................................... 18
2.1.3.9 Jobs ...................................................................................................................................................................................... 18
2.1.3.10 Filas ................................................................................................................................................................................. 18
2.1.3.11 Serviços SAP (SAP Services).......................................................................................................................................... 18
2.1.3.12 Agenda (Appointment calendar) ..................................................................................................................................... 18
2.1.3.13 Business Workplace ........................................................................................................................................................ 18
2.1.4 Utilitários .................................................................................................................................................................. 19 2.1.4.1 Depuração de Telas (Debug Screen) .................................................................................................................................... 19
2.1.4.2 Depuração ABAP/4 (Debug ABAP) .................................................................................................................................... 19
2.1.4.3 Depuração Sistema (Debug System) .................................................................................................................................... 19
2.1.4.4 Consumo de Recursos (Resource Usage) ............................................................................................................................. 19
2.1.4.5 Fila automática processamento síncrono(Autom.queue syncronous processing) ................................................................. 19
2.1.4.6 Exibição de performance (Performance display) ................................................................................................................. 19
2.1.4.7 Trace performance ............................................................................................................................................................... 20
2.1.4.8 Análise de tempo de execução (Runtime analisys) .............................................................................................................. 20
2.1.4.9 Exibir Verificação de Autorização (Display authorization check) ....................................................................................... 20
2.1.5 Lista (List) ................................................................................................................................................................. 20 2.1.5.1 Imprimir (Print) ................................................................................................................................................................... 20
2.1.5.2 Procurar(Find)...................................................................................................................................................................... 20
2.1.5.3 Gravar(Save) ........................................................................................................................................................................ 20
2.1.5.4 Enviar(Send) ........................................................................................................................................................................ 21
2.1.5.5 Título da Lista (List header) ................................................................................................................................................ 21
2.1.6 Serviços para objeto ................................................................................................................................................. 21
2.1.7 Histórico do objeto ................................................................................................................................................... 21
2.1.8 Ordens spool próprias (Own spool request) ............................................................................................................. 21
2.1.9 Jobs próprios (Own jobs).......................................................................................................................................... 21
2.1.10 Mensagem breve (Short message) ......................................................................................................................... 21
2.1.11 Status..................................................................................................................................................................... 21
2.1.12 Logoff .................................................................................................................................................................... 21
2.2 AJUDA (HELP) ............................................................................................................................................................... 21
3 BARRA DE FERRAMENTAS PADRÃO (STANDARD TOOL BAR) ........................................................................ 22
4 BARRA DE TÍTULOS (TITLE BAR) .............................................................................................................................. 23
5 BARRA DE STATUS ......................................................................................................................................................... 23
6 BARRA DE FERRAMENTAS DA APLICAÇÃO (APLICATION TOOL BAR) ....................................................... 23
CONTROLADORIA 2 de 325
7 CAMPOS DA TELA DO R/3 ............................................................................................................................................ 23
8 MENU PADRÃO SAP OU FAVORITOS ........................................................................................................................ 24
9 MÓDULOS (COMPONENTES) ....................................................................................................................................... 24
10 METODOLOGIA DE IMPLANTAÇÃO DO R/3 ....................................................................................................... 25
10.1 FASE 1 – ORGANIZAÇÃO E PROJETO CONCEITUAL ......................................................................................................... 25
10.2 FASE 2 – DETALHAMENTO DO PROJETO E IMPLANTAÇÃO .............................................................................................. 25
10.3 FASE 3 – PREPARAÇÃO DA PRODUÇÃO .......................................................................................................................... 26
10.4 FASE 4 – OPERAÇÃO PRODUTIVA .................................................................................................................................. 26
10.5 BUSINESS NAVIGATOR – REFERENCE MODEL ............................................................................................................... 26
11 CUSTOMIZING – GUIA DE IMPLANTAÇÃO DO SAP (IMG) ............................................................................. 26
11.1 OPÇÕES GERAIS (GENERAL SETTINGS) .......................................................................................................................... 26
11.1.1 Países (Countries) ................................................................................................................................................. 27
11.1.2 Geocoding ............................................................................................................................................................. 27
11.1.3 Moedas (Currencies) ............................................................................................................................................ 27
11.1.4 Unidade de Medida (Units of Mensurement) ........................................................................................................ 28
11.1.5 Calendário (Calendar).......................................................................................................................................... 28
11.1.6 Time Zones (Fusos Horários) ............................................................................................................................... 28
11.1.7 Características de exibição de campos (Field Display Characteristics) .............................................................. 28
11.1.8 Variants to ajust help (SAP Library) .................................................................................................................... 28
11.2 ESTRUTURA DO EMPREENDIMENTO (ENTERPRISE STRUCTURE) .................................................................................... 28
11.2.1 Configurações específicas do país (Country-specific settings) ............................................................................. 29
11.2.2 Contabilidade Financeira (Financial Accounting) ............................................................................................... 29 11.2.2.1 Sociedade (Company) ..................................................................................................................................................... 29
11.2.2.2 Área De Controle De Créditos (Credit Control Area) ..................................................................................................... 29
11.2.2.2.1 Dados relevantes para SD ........................................................................................................................................... 30
11.2.2.3 Empresa (Company Code) .............................................................................................................................................. 30
11.2.2.4 Divisão (Business Area) .................................................................................................................................................. 31
11.2.2.5 Divisão de Consolidação (Consolidation Business Area) ................................................................................................ 31
11.2.2.6 Área Funcional (Funcional Área) .................................................................................................................................... 31
11.2.2.7 Área de Administração Financeira (AAF – Financial Management Area) ...................................................................... 31
11.2.3 Controladoria – Controlling ................................................................................................................................. 32 11.2.3.1 Área de Contabilidade de Custo – Acc (Controllling Area) ............................................................................................ 32
11.2.3.2 Empresa x Área de Contabilidade de Custos ................................................................................................................... 32
11.2.3.3 Área de Contabilidade de Custos x Área de Administração Financeira .......................................................................... 32
11.2.3.4 Área de Resultado (Área de Resultado) ........................................................................................................................... 33
11.2.4 Logística ............................................................................................................................................................... 33 11.2.4.1 Nível de Avaliação (Valuation Level) ............................................................................................................................. 33
11.2.4.2 Centro (Plant) .................................................................................................................................................................. 33
11.2.4.3 Localização (Location) .................................................................................................................................................... 34
11.2.4.4 Setor de Atividade (Division) .......................................................................................................................................... 34
11.2.5 Vendas e Distribuição (Sales and Distribution) ................................................................................................... 35 11.2.5.1 Organização de Vendas (Sales Organization) .................................................................................................................. 35
11.2.5.2 Canal de Distribuição (Distribution Channel) ................................................................................................................. 35
11.2.5.3 Escritório De Vendas (Sales Office) ................................................................................................................................ 35
11.2.5.4 Grupo De Vendedores (Sales Group) .............................................................................................................................. 35
11.2.6 Administração de Materiais (Material Management) .......................................................................................... 35 11.2.6.1 Depósitos (Storage Location) .......................................................................................................................................... 35
11.2.6.2 Organização de Compras (Purchasing Organization) ...................................................................................................... 35
11.2.7 Logistics Execution (Expedição) ........................................................................................................................... 36 11.2.7.1 Sistema De Depósito (Warehouse Number) .................................................................................................................... 36
11.2.7.2 Local De Expedição (Shipping Point) ............................................................................................................................. 36
11.2.7.3 Carga (Loading Point) ..................................................................................................................................................... 36
11.2.7.4 Organização De Transporte (Transportation Planning Point) .......................................................................................... 36
11.2.8 Manutenção (Plant Maintenance) ........................................................................................................................ 36 11.2.8.1 Centro de Planejamento de Manutenção (Maintenance Planning Plant) ......................................................................... 36
11.2.9 Recursos Humanos ............................................................................................................................................... 36 11.2.9.1 Área de Recursos Humanos (Personnel Areas) ............................................................................................................... 36
11.2.9.2 Sub-Área de Recursos Humanos (Personnel Sub-Areas) ................................................................................................ 36
CONTROLADORIA 3 de 325
11.2.9.3 Grupo de Empregados (Employee Groups) ..................................................................................................................... 36
11.2.9.4 Sub-Grupo de Empregados (Employee Sub-Groups) ...................................................................................................... 36
11.3 COMPONENTES VÁLIDOS PARA TODAS AS APLICAÇÕES (CROSS-APLICATION COMPONENTS) ........................................ 36
11.3.1 Administração de Documentos – DMS (Document Management System)............................................................ 36
11.3.2 Sistema de Classificação (Classification System) ................................................................................................. 37
11.3.3 Folhas de Horas de Trabalho ............................................................................................................................... 37
11.3.4 Processos Empresariais ALE definidos ................................................................................................................ 37
11.3.5 Transferência Inicial de Dados............................................................................................................................. 38
11.3.6 Ferramenta CATT ................................................................................................................................................. 38 11.3.6.1 Integrar ferramenta de teste externa ................................................................................................................................ 38
11.3.7 Serviços Internet/Intranet ..................................................................................................................................... 39
11.4 PROCEDIMENTO PARA MELHOR PERFORMANCE ............................................................................................................. 39 11.4.1.1 Status ............................................................................................................................................................................... 39
11.4.1.2 Status do Usuário............................................................................................................................................................. 40
11.4.1.3 Perfil de status ................................................................................................................................................................. 41
11.4.2 Esquema de status ................................................................................................................................................. 41
11.4.3 Administração de status ........................................................................................................................................ 42 11.4.3.1 Grupos de transações contábeis ....................................................................................................................................... 42
11.4.3.2 Grupos de bloqueio ......................................................................................................................................................... 43
11.4.3.3 Conjunto de funções ........................................................................................................................................................ 45
11.4.3.4 Perfil de seleção de status para Administração de Investimentos .................................................................................... 45
12 INTRODUÇÃO A CONTROLADORIA ...................................................................................................................... 45
12.1 DIFERENÇA ENTRE CONTABILIDADE FINANCEIRA (GERAL) E DE CUSTOS ..................................................................... 45
12.2 CONCEITOS BÁSICOS GERAIS ......................................................................................................................................... 46
12.3 PRINCÍPIOS CONTÁBEIS ................................................................................................................................................. 46
12.3.1 Realização ............................................................................................................................................................. 46
12.3.2 Competência e Confrontação................................................................................................................................ 46
12.3.3 Custo básico como histórico de valor ................................................................................................................... 46
12.3.4 Consistência .......................................................................................................................................................... 46
12.3.5 Conservadorismo .................................................................................................................................................. 47
12.3.6 Materialidade........................................................................................................................................................ 47
12.4 CONTROLADORIA .......................................................................................................................................................... 47
12.5 ABORDAGENS DE CUSTO IMPLEMENTADAS EM PARALELO NO R/3 ................................................................................. 48
12.5.1 Custeio Padrão x Custeio Real ............................................................................................................................. 48
12.5.2 Custeio por Absorção x Custeio Marginal ............................................................................................................ 48
12.5.3 Custeio direto x Contribuição Marginal ............................................................................................................... 49
12.5.4 Custos de Vendas x Custeio Periódico ................................................................................................................. 49
12.6 PLANEJAMENTO / PROJEÇÃO / ORÇAMENTO .................................................................................................................. 49
12.7 MOEDAS EM CO ............................................................................................................................................................ 49
12.8 CONCEITOS GERAIS DE CO ............................................................................................................................................ 49
12.9 COMPONENTES DO R/3 .................................................................................................................................................. 51
12.9.1 FI – Contabilidade Financeira (Financial Accounting) ....................................................................................... 51
12.9.2 TR – Tesouraria (Treasury) .................................................................................................................................. 52
12.9.3 CO – Controlling .................................................................................................................................................. 52
12.9.4 EC – Controlling Empresarial (Enterprise Controlling) ...................................................................................... 53
12.9.5 FI-IM – Administração de Investimento (Investment Management) ..................................................................... 54
12.9.6 Administração de bens imobilizados (Real State Management) ........................................................................... 54
13 CONTABILIDADE DE CUSTOS INDIRETOS (OVERHEAD COST CONTROLLING) .................................... 54
13.1 CONTABILIDADE DE CLASSE DE CUSTO (COST & REVENUE ELEMENT ACCOUNTING) .................................................. 54
13.2 CONTABILIDADE DE CENTRO DE CUSTO (COST CENTER ACCOUNTING) ........................................................................ 54
13.3 ORDENS INTERNAS (INTERNAL ORDERS) ....................................................................................................................... 54
13.4 CUSTEIO BASEADO NA ATIVIDADE (ACTIVITY-BASED COSTING) ................................................................................. 55
14 CONTROLLING DE CUSTO DE PRODUTO (PRODUCT COST CONTROLLING) ......................................... 55
14.1 PLANEJAMENTO DE CUSTO DE PRODUTO (PRODUCT COST PLANNING) ......................................................................... 55
14.2 CONTABILIDADE DE OBJETOS DE CUSTO (COST OBJECT CONTROLLING) ...................................................................... 56
14.2.1 Controlling de Objeto por ordem (Product cost controlling by order) ................................................................. 56
14.2.2 Controlling periódico de objeto (Product cost controlling by period) ................................................................. 57
14.2.3 Controlling por ordem do cliente (Product cost controlling by sales order) ........................................................ 58
CONTROLADORIA 4 de 325
14.3 CÁLCULO DE CUSTO REAL / LEDGER DE MATERIAIS (ACTUAL COSTING / MATERIAL LEDGER) .................................... 58
15 ANÁLISE DE RESULTADOS (PROFITABILITY MANAGEMENT) .................................................................... 58
15.1 MÉTODOS DE ANÁLISE DE RESULTADOS ........................................................................................................................ 58
15.1.1 Periódico ............................................................................................................................................................... 59
15.1.2 Custo de Vendas .................................................................................................................................................... 59
15.2 DEMONSTRAÇÃO DE RESULTADOS (PROFITABILITY ANALYSIS) .................................................................................... 59
15.3 CONTABILIDADE DE CENTRO DE LUCRO ........................................................................................................................ 60
15.3.1 Métodos de cálculo de lucro ................................................................................................................................. 60
16 INTEGRAÇÃO ENTRE CO COM OUTROS COMPONENTES DO R/3 ............................................................... 60
16.1 VALORES PROPOSTOS NOS LANÇAMENTO DE FI ............................................................................................................. 62
16.2 REGRAS DE VALIDAÇÃO E SUBSTITUIÇÃO ..................................................................................................................... 62
16.3 CLASSIFICAÇÃO CONTÁBIL POR TIPO DE ATIVIDADE ...................................................................................................... 62
16.4 CONCILIAÇÃO DE CO COM FI ........................................................................................................................................ 63
16.5 TRANSFERÊNCIA DE VALORES NO PLANEJAMENTO DE CENTROS CUSTOS / ORDENS INTERNAS ..................................... 63
16.5.1 Transferência de Depreciação e Juros (S_ALR_87099918a46) ........................................................................... 64
16.5.2 Transferência de necessidades de atividades de PP ............................................................................................. 66
17 SISTEMAS DE INFORMAÇÃO .................................................................................................................................. 67
17.1 VISÃO GERAL ................................................................................................................................................................ 67
17.2 REPORT WRITER/ REPORT PAINTER............................................................................................................................... 68
17.2.1 Criar relatório ...................................................................................................................................................... 68
17.3 GRUPO DE RELATÓRIOS ................................................................................................................................................. 69
17.4 ABAP LIST VIEWER (ALV) .......................................................................................................................................... 69
17.5 CONFIGURAÇÕES DO USUÁRIO / GERENCIAMENTO DE EXTRATOS ................................................................................. 70
17.6 RELATÓRIOS DRILLDOWN ............................................................................................................................................. 70
17.7 LOGISTICS DATA WHAREHOUSE.................................................................................................................................... 71
17.7.1 Catálogo de Campos ............................................................................................................................................. 71
17.7.2 Estruturas de Informação ..................................................................................................................................... 72
17.7.3 Atualização das características e índices das várias operações comerciais ........................................................ 78
17.7.4 Condições – atualiza requisitos ............................................................................................................................ 86
17.7.5 Fórmulas ............................................................................................................................................................... 87
17.7.6 Aplicações definidas pelo usuário ........................................................................................................................ 71
17.7.7 Monitoração da atualização ................................................................................................................................. 89
17.8 RELATÓRIOS – ANÁLISE FLEXÍVEIS ................................................................................................................................ 89
18 CONFIGURAÇÕES DE FI ........................................................................................................................................... 89
18.1 VARIANTE DE ANO FISCAL ............................................................................................................................................ 89
18.2 GRUPO DE TOLERÂNCIA ................................................................................................................................................ 90
18.3 PLANO DE CONTAS ........................................................................................................................................................ 90
18.4 CONTAS CONTÁBEIS ...................................................................................................................................................... 91
18.5 GRUPO DE CONTAS (ACCOUNT GROUP) ........................................................................................................................ 92
18.6 CONFIGURAÇÕES DOS CAMPOS DAS TELAS (FIELD STATUS) .......................................................................................... 92
18.7 VARIAÇÃO CAMBIAL ..................................................................................................................................................... 93
18.8 FINANCIAL STATEMENT VERSION ................................................................................................................................. 93
18.9 RAZÃO AUXILIAR (SUBSIDIARY LEDGER) ..................................................................................................................... 93
18.9.1 Contas de Clientes e Fornecedores ...................................................................................................................... 94
19 PROCESSAMENTO DIÁRIO DE FI ........................................................................................................................... 94
19.1 POSTING KEY – CHAVE DE LANÇAMENTO ..................................................................................................................... 94
19.2 LANÇAMENTOS BÁSICOS DE FI ...................................................................................................................................... 95
20 CONFIGURAÇÕES BÁSICAS DE CO ....................................................................................................................... 96
20.1 PLANEJAMENTO INTEGRADO ......................................................................................................................................... 96
20.2 NUMERAÇÃO AOS DOCUMENTOS DE CO ........................................................................................................................ 97
20.3 VERSÕES........................................................................................................................................................................ 97
20.3.1 Indicadores a nível geral ...................................................................................................................................... 97
20.3.2 Indicadores a nível de planejamento .................................................................................................................... 97
CONTROLADORIA 5 de 325
20.3.3 Indicadores para Determinação de Tarifa ........................................................................................................... 98
20.3.4 Versão Delta ......................................................................................................................................................... 99
20.3.5 Versões para avaliações ....................................................................................................................................... 99
20.4 AVALIAÇÃO PARALELA / PREÇO DE TRANSFERÊNCIA .................................................................................................... 99
20.4.1 Perfil de avaliação e de moeda ........................................................................................................................... 100
20.4.2 Denominações p/prismas de avaliação ............................................................................................................... 100
20.4.3 Tipo de legder de materiais x tipo de moedas x área de avaliação .................................................................... 101
20.4.4 Contas de compensação de diferenças de avaliação .......................................................................................... 101
20.4.5 Configurações globais para determinação de preço .......................................................................................... 101 20.4.5.1 Tipo de Condição .......................................................................................................................................................... 103
20.4.5.1.1 Criar tipos de condição próprios ............................................................................................................................... 103
20.4.5.2 Esquema de cálculo de custos ....................................................................................................................................... 105
20.4.6 Variante de preço interno ................................................................................................................................... 106 20.4.6.1 Lista de Preços .............................................................................................................................................................. 106
21 CONTABILIDADE DE CENTRO DE CUSTO ......................................................................................................... 107
21.1 DADOS MESTRE ........................................................................................................................................................... 107
21.1.1 Grupos de Dados mestre ..................................................................................................................................... 108
21.1.2 Classe de Custo (Cost Elements) ........................................................................................................................ 109 21.1.2.1 Categoria de Classes de Custo ....................................................................................................................................... 110
21.1.3 Centros de Custo (Cost Centers) ........................................................................................................................ 111
21.1.4 Tipos de Atividade (Activity types) ...................................................................................................................... 113 21.1.4.1 CATEGORIAS DE TIPO DE ATIVIDADE ................................................................................................................. 113
21.1.5 Índices estatísticos (Statistical key figures) ........................................................................................................ 115
21.1.6 Recursos .............................................................................................................................................................. 116
21.2 LANÇAMENTOS BASEADO EM EVENTOS ....................................................................................................................... 116
21.2.1 Automatic Commitment and Funds Reservation ................................................................................................. 116
21.3 LANÇAMENTOS REAIS .................................................................................................................................................. 116
21.3.1 Transferência manual de custos e receitas (Reposting Cost And Revenues Manually) ...................................... 116
21.3.2 Transferência de partida individual (Reposting Line Items) .............................................................................. 117
21.3.3 Time de Trabalho (Time Sheet) .......................................................................................................................... 117 21.3.3.1 Alocação direta de atividade (Direct Activity Allocation) ............................................................................................ 117
21.3.4 Transferência de Alocação de Atividade (Activity Allocation Reposting) .......................................................... 118
21.3.5 Entrada de Quantidade / Preço Atividades nos Emissores (SENDER ACTIVITY / ACTUAL PRICE) .............. 118
21.3.6 Alocação Manual de Custos ............................................................................................................................... 119
21.4 FECHAMENTO DE PERÍODO .......................................................................................................................................... 119
21.4.1 Cálculo de Provisões (ACCRUAL CALCULATION) - Delimitação ................................................................... 119
21.4.2 Actual overhead .................................................................................................................................................. 120
21.4.3 Overhead Commitment ....................................................................................................................................... 120
21.4.4 Alocação Periódica ............................................................................................................................................. 120 21.4.4.1 Definição de Ciclos ....................................................................................................................................................... 123
21.4.4.1.1 Pasta Cabeçalho do Segmento ................................................................................................................................... 126
21.4.4.1.2 Pasta Emissor/Receptor ............................................................................................................................................. 129
21.4.4.1.3 Pasta Val. Emissor .................................................................................................................................................... 130
21.4.4.1.4 Pasta Base de Refer.Receptora .................................................................................................................................. 132
21.4.4.1.5 Pasta Fator ponderação rec. ....................................................................................................................................... 134
21.4.4.2 Transferência Periódica (Periodic Reposting) ............................................................................................................... 135
21.4.4.3 Distribuição (Distribution) ............................................................................................................................................ 135
21.4.4.4 Rateio (Assessment) ...................................................................................................................................................... 136
21.4.4.5 Alocação indireta de atividade (Indirect Activity Allocation) ....................................................................................... 137
21.4.4.6 Estorno e Reclassificação de Segmentos (Segment Adjustment) .................................................................................. 137
21.4.4.7 Alocação por modelos (Template Allocation) ............................................................................................................... 137
21.4.4.8 Pre-distribuição de custos fixos ..................................................................................................................................... 138
21.4.4.9 Decomposição de Custos em atividades e reavaliação da Tarifa (Splitting / Price Calculation) ................................... 139
21.4.5 Cálculo de Variações (Variances) ...................................................................................................................... 139
21.5 PLANEJAMENTO ........................................................................................................................................................... 140
21.5.1 Escopo e Métodos de Planejamento ................................................................................................................... 141
21.5.2 Layout e Perfil (Profile) ...................................................................................................................................... 142
21.5.3 Ajuda do planejamento (Plaining Aids) .............................................................................................................. 142 21.5.3.1 Copiar ............................................................................................................................................................................ 143
21.5.3.2 KSPU – Reavaliar ......................................................................................................................................................... 144
21.5.3.3 Eliminar ......................................................................................................................................................................... 144
CONTROLADORIA 6 de 325
21.5.3.4 Transferências ............................................................................................................................................................... 145
21.5.3.4.1 Transferência de Depreciação e Juros (S_ALR_87099918a46) ................................................................................ 145
21.5.3.4.2 Transferência de necessidades de atividades de PP ................................................................................................... 147
21.5.3.5 KPSI – Conciliação do Plano ........................................................................................................................................ 148
21.5.3.6 KSWB – Transferência Periódica .................................................................................................................................. 149
21.5.3.7 KSA8 – Delimitação de Custos ..................................................................................................................................... 149
21.5.3.8 Planejamento de Fórmula .............................................................................................................................................. 150
21.5.3.9 KP96 – Ativar integração .............................................................................................................................................. 150
21.5.3.10 KP95 – Reavaliar planejamento manual ........................................................................................................................ 150
21.5.4 Accrual - Provisões (Accrual Calculation) ......................................................................................................... 150
21.5.5 Índices estatísticos – (Statistical Key Figures) ................................................................................................... 151
21.5.6 Classe de custos (Cost Elements) ........................................................................................................................ 151
21.5.7 Tipo de Atividade (Activity Type) ........................................................................................................................ 153
21.5.8 Conciliação automática do planejamento .......................................................................................................... 154
21.6 ANÁLISE DE DESVIOS (VARIANCE) .............................................................................................................................. 154
22 ORDENS INTERNAS .................................................................................................................................................. 154
22.1 DADOS MESTRE ........................................................................................................................................................... 154
22.2 EVENT-BASED POSTINGS .............................................................................................................................................. 155
22.3 FECHAMENTO DO PERÍODO .......................................................................................................................................... 155
22.4 PLANEJAMENTO E ORÇAMENTO................................................................................................................................... 155
22.4.1 Planejamento Global (Overall Planning) ........................................................................................................... 155 22.4.1.1 Estrutura temporal ......................................................................................................................................................... 155
22.4.2 Sumarização da Ordem....................................................................................................................................... 155
23 SCHEDULE MANAGER ............................................................................................................................................ 155
23.1 COMPONENTES ............................................................................................................................................................ 156
23.2 BENEFÍCIOS ................................................................................................................................................................. 156
24 BASICS OF THE REPORT PAINTER ...................................................................................................................... 156
25 ASAP .............................................................................................................................................................................. 157
25.1 ASAP OVERVIEW: TOPICS .......................................................................................................................................... 157
25.2 IMPLEMENTATION ROADMAP: TOPICS ......................................................................................................................... 157
26 PRODUCT COST PLANNING ................................................................................................................................... 157
26.1 INTRODUÇÃO ............................................................................................................................................................... 157
26.1.1 Mestre de Materiais ............................................................................................................................................ 157
26.1.2 Informações básicas para o cálculo do custo ..................................................................................................... 158
26.1.3 Esquema de Elementos (Cost Component) ......................................................................................................... 158
26.2 BENS TANGÍVEIS E INTANGÍVEIS. ................................................................................................................................. 159
26.3 VARIANTE DE CÁLCULO DE CUSTO (COSTING VARIANT) ............................................................................................ 159
26.4 CÁLCULO DE CUSTOS STANDARD ................................................................................................................................ 161
26.4.1 CK40N - Processar a execução do cálculo de custos (Costing Run).................................................................. 161
26.5 PRODUÇÃO REPETITIVA ............................................................................................................................................... 161
26.6 CÁLCULO DE WIP E REFUGO ....................................................................................................................................... 164
26.6.1 Chave de Determinação de Resultados (Results Analysis Keys) ........................................................................ 164 26.6.1.1 Estoque especial não avaliado ....................................................................................................................................... 164
26.6.2 Versão de Determinação de Resultado ............................................................................................................... 165 26.6.2.1 Controle simplificado .................................................................................................................................................... 165
26.6.2.2 Controle ampliado ......................................................................................................................................................... 165
26.6.3 Classes de custo da determinação do resultado ................................................................................................. 168
26.6.4 Método de avaliação (custos teóricos) ............................................................................................................... 168 26.6.4.1 Material em processo para custos teóricos..................................................................................................................... 168
26.6.4.2 Material em processo para custos reais.......................................................................................................................... 169
26.6.4.3 Preços internos .............................................................................................................................................................. 169
26.6.5 Wip no custeio periódico .................................................................................................................................... 170
26.6.6 Capitalização do WIP ......................................................................................................................................... 171
26.6.7 Definir regras de lançamento para apropriação de material em processo ........................................................ 172 26.6.7.1 Por categoria de demonstração do resultado .................................................................................................................. 172
26.6.7.2 Por classe de custo de determinação do resultado ......................................................................................................... 172
CONTROLADORIA 7 de 325
26.6.7.3 Preços internos .............................................................................................................................................................. 173
26.6.7.4 Atividades ..................................................................................................................................................................... 173
26.6.8 Funções a serem executadas antes do WIP ........................................................................................................ 173
26.6.9 Exemplo de cálculo de WIP ................................................................................................................................ 173
26.6.10 Cálculo de Custos teóricos baseado na estimativa de custeio padrão ............................................................... 174
26.6.11 Atualização do WIP ............................................................................................................................................ 175 26.6.11.1 Restrições ...................................................................................................................................................................... 175
26.7 VARIANTES DE DESVIO ................................................................................................................................................ 175
26.7.1 Os desvios do lado de entrada: ................................................................................ Erro! Indicador não definido. 26.7.1.1 Desvios de refugo .......................................................................................................................................................... 177
26.7.1.2 Desvio de preço de input ............................................................................................................................................... 178
26.7.1.3 Desvio de quantidade de input ....................................................................................................................................... 178
26.7.1.4 Desvio de estrutura ........................................................................................................................................................ 178
26.7.1.5 desvio residual do input ................................................................................................................................................. 178
26.7.2 Desvios do lado de saída: ........................................................................................ Erro! Indicador não definido. 26.7.2.1 Desvio de tamanho de lote ............................................................................................................................................ 178
26.7.2.2 Desvios de preço interno ............................................................................................................................................... 178
26.7.2.3 Desvios de preço médio................................................................................................................................................. 178
26.7.2.4 Desvios residuais ........................................................................................................................................................... 179
26.8 DEFINIR DESVIOS DE PREÇOS DE DADOS PRIMÁRIOS (SYSTEM SETTINGS FOR VAIRANCE CALCULATIONS) ................... 179
26.8.1 Versão teórica ..................................................................................................................................................... 179
26.9 CÁLCULO DE CUSTO REAL ........................................................................................................................................... 179
26.9.1 CKMLCP – Processar o cálculo de custos reais ................................................................................................ 179 26.9.1.1 Determinação de tarifa multi-nível ................................................................................................................................ 181
26.9.1.2 Programa RMMMINIT – Inicialização períodos mestre de material ............................................................................ 182
Condição ............................................................................................................................................................................................. 183
Saída .................................................................................................................................................................................................... 183
26.9.1.3 LINHA DE NÃO DISTRIBUÍDO ................................................................................................................................ 183
26.9.1.4 Resultado do cálculo de custos ...................................................................................................................................... 184
26.9.2 MR21 - Alteração de preco de material .............................................................................................................. 184
26.9.3 Custos teóricos totais .......................................................................................................................................... 184
26.10 SISTEMAS DE INFORMAÇÃO DE CO-PC ................................................................................................................... 184
26.10.1 Pesquisa de Produtos (Drilldown Product) ........................................................................................................ 184
26.10.2 Sumarização e Seleção de Ordens ...................................................................................................................... 185 26.10.2.1 Seleção e Geração de Características ............................................................................................................................ 185
26.10.2.2 Definir esquemas de seleção (selection profiles) ........................................................................................................... 185
26.10.2.3 Definir telas de seleção para a lista de ordens ............................................................................................................... 186
26.10.2.4 Definir regras de exceção .............................................................................................................................................. 186
26.10.2.5 Criar hierarquia de ordens ............................................................................................................................................. 186
26.10.2.6 Coleta de dados para hierarquia de ordens .................................................................................................................... 186
27 CUSTEIO ABC ............................................................................................................................................................. 187
27.1 INTRODUÇÃO ............................................................................................................................................................... 187
27.1.1 Problemas com a Contabilidade de Custos ........................................................................................................ 187
27.1.2 Custeio Baseado em Atividade (Activity Based Costing) .................................................................................... 188
27.2 VERSÃO DELTA ........................................................................................................................................................... 189
27.2.1 Introdução ........................................................................................................................................................... 189
27.2.2 Business management transactions .................................................................................................................... 190 27.2.2.1 Primary costs: ................................................................................................................................................................ 190
27.2.2.2 Secondary costs: ............................................................................................................................................................ 190
27.2.2.3 Statistical key figures: ................................................................................................................................................... 191
27.2.3 Recommendation ................................................................................................................................................. 191
27.3 AMBIENTES (ENVIROMENTS) ....................................................................................................................................... 191
28 DEMONSTRAÇÃO DE RESULTADO (PROFITABILITY ANALYSIS) ............................................................. 192
28.1 PROFITALIBITY MANAGEMENT .................................................................................................................................... 192
28.2 STRUCTURES ............................................................................................................................................................... 193
28.2.1 Definição das características a nível de segmento ............................................................................................. 193
28.3 DADOS MESTRE ........................................................................................................................................................... 193
28.3.1 Derivação de Características ............................................................................................................................. 193
28.3.2 Valuation ............................................................................................................................................................. 194 28.3.2.1 Valorização usando condições específicas de CO-PA (Condition Technique e Costing Sheet) .................................... 195
28.3.2.2 Valorização através de estimativas de cálcuo de custos – Costing Key......................................................................... 197
CONTROLADORIA 8 de 325
28.3.2.3 Valorização através de rotinas definidas pelo usuário .................................................................................................. 198
28.4 CONFIGURAÇÃO DO FLUXO DE VALORES REAIS ........................................................................................................... 199
28.4.1 Intervalo de documentos ..................................................................................................................................... 199
28.4.2 Grupos de Características e de Campos de Valores........................................................................................... 199
28.4.3 Sumarização dos dados durante a atualização ................................................................................................... 200
28.4.4 Unidade de Medida padrão em CO-PA .............................................................................................................. 200
28.4.5 Geração de Lançamentos pelas Ordens de Vendas ............................................................................................ 200
28.4.6 Geração de Lançamentos de Faturamento ......................................................................................................... 201
28.5 LIQUIDAÇÃO DE ORDEM E PROJETOS ........................................................................................................................... 201
28.6 DADOS REAIS ............................................................................................................................................................... 202
28.7 PLANEJAMENTO ........................................................................................................................................................... 202
28.8 SISTEMA DE INFORMAÇÃO ........................................................................................................................................... 202
29 CONTABILIDADE DE CENTRO DE LUCRO ........................................................................................................ 202
29.1 MÉTODOS DE CÁLCULO DE LUCRO ............................................................................................................................... 202
29.2 INTEGRAÇÃO COM OUTROS OBJETOS ........................................................................................................................... 203
29.3 CONFIGURAÇÕES GERAIS ............................................................................................................................................ 203
29.3.1 Opções para a área de contabilidade de custos (0KE5) ..................................................................................... 203
29.3.2 Parâmetros de controle para lançamentos reais ................................................................................................ 204
29.3.3 Atualizar versões de planejamento ..................................................................................................................... 204
29.3.4 Ajustar saldos das partidas individuais e registros totais (KEE0) ..................................................................... 205
29.3.5 Analisar opções ................................................................................................................................................... 206
29.3.6 Atualizar opções ................................................................................................................................................. 208
29.3.7 Ativar ledger de estoque médio ........................................................................................................................... 209
29.3.8 Transporte de saldo inicial ................................................................................................................................. 209
29.4 ORGANIZAÇÃO EMPRESARIAL ..................................................................................................................................... 210
29.5 DADOS MESTRE ........................................................................................................................................................... 210
29.5.1 Centro de Lucro .................................................................................................................................................. 210
29.5.2 Materiais representativos ................................................................................................................................... 211 29.5.2.1 Ativar materiais representativos .................................................................................................................................... 211
29.5.2.2 Selecionar materiais representativos .............................................................................................................................. 212
29.5.2.3 Derivar materiais representativos .................................................................................................................................. 212
29.5.3 Síntese de atribuição de centro de lucros a outros objetos (Assignment Monitor) ............................................. 213
29.6 TRANSFERÊNCIA DE CONTAS PATRIMONIAIS ................................................................................................................ 213
29.6.1 Transferência periódica ...................................................................................................................................... 213
29.6.2 Transferência on-line .......................................................................................................................................... 214
29.7 SISTEMA DE INFORMAÇÃO ........................................................................................................................................... 215
29.7.1 Relatórios standard de Centro de Lucro ............................................................................................................. 216 29.7.1.1 Relatórios orientados por lista ....................................................................................................................................... 216
29.7.1.2 Partidas Individuais ....................................................................................................................................................... 216
29.7.1.3 Partidas em aberto ......................................................................................................................................................... 216
29.7.1.4 Contas patrimoniais transferidas periodicamente .......................................................................................................... 216
29.7.1.5 Funções especiais .......................................................................................................................................................... 216
29.7.1.6 Ledger de Saldos médios ............................................................................................................................................... 216
29.7.1.7 Cenário ALE descentralizado ........................................................................................................................................ 216
29.7.1.8 Preços Internos .............................................................................................................................................................. 217
29.7.1.9 Transferência de Dados a EIS ....................................................................................................................................... 217
29.7.2 Relatórios Drilldown standard de Centro de Lucro ........................................................................................... 217 29.7.2.1 Reporting interativo ....................................................................................................................................................... 217
29.7.2.2 Reporting interativo – índices estatísticos ..................................................................................................................... 217
29.7.2.3 Special Functions ® Decentralized ALE-Scenario ........................................................................................................ 217
30 TRANSPORTE DE DADOS DE CO ENTRE MANDANTES ................................................................................. 218
30.1 TRANSPORTAR OPÇÕES PARA DADOS MESTRE.............................................................................................................. 229
30.2 DESTINO CONSOLIDAÇÃO ............................................................................................................................................ 231
31 ARQUIVAMENTO (ARCHIVING) ........................................................................................................................... 232
31.1 INTRODUÇÃO ............................................................................................................................................................... 232
31.1.1 Porque fazer ........................................................................................................................................................ 232
31.1.2 Pré-requisitos considerados pelo Archiving ....................................................................................................... 232
31.1.3 Conceitos básicos ............................................................................................................................................... 233
CONTROLADORIA 9 de 325
31.2 CARACTERÍSTICAS ....................................................................................................................................................... 233
31.3 PROCEDIMENTO PARA EXECUÇÃO DE UMA SEÇÃO DE ARCHIVING ............................................................................... 234
31.3.1 Primeiro passo – Geração dos arquivos ............................................................................................................. 234
31.3.2 Segundo Passo – Gravação dos arquivos ........................................................................................................... 235
31.3.3 Terceiro Passo – Eliminação dos dados ............................................................................................................. 235
31.4 OBJETO DE ARCHIVING E OBJETO DE DADOS .............................................................................................................. 235
31.4.1 PCA_OBJECT – Registros de totais e partidas individuais no EC-PCA ........................................................... 236
31.4.2 CO_ML_BEL – Documentos ledger de material (MLHD/IT/PP/PPF/CR/CRF/CRP) ....................................... 237
31.4.3 CO_ORDER – Ordens c/dados de movimento .................................................................................................... 238
31.4.4 CO_KSTRG – Objeto de custo: dados mestre e dados movimento ..................................................................... 248
31.4.5 CO-COSTCTR .................................................................................................................................................... 250
31.4.6 COPA2_MANN – COPA contábil, área de resultado MANN............................................................................. 252
31.4.7 COPA1_MANN - COPA baseada em cálc. custos, área de resultados MANN .................................................. 252
31.4.8 CO_CCTR_ID – Centro de custo – dados reais ................................................................................................. 253
31.4.9 CO_CCTR_PL – Centro de .custo – dados planejados ...................................................................................... 254
31.4.10 CO_CCTR_EP – Centro de custo - partidas individuais .................................................................................... 254
31.4.11 CO_ITEM – Partidas individuais de CO ........................................................................................................... 255
31.4.12 CO_ALLO_ST – Doc. Completamente estornados de rateio, distribuição, ... .................................................... 255
31.5 ADMINISTRAÇÃO DO ARCHIVING ................................................................................................................................ 255
31.5.1 Archive Development Kit (ADK) ......................................................................................................................... 256
31.5.2 Autorizações........................................................................................................................................................ 257
31.5.3 Gráfico da Rede .................................................................................................................................................. 257
32 ARQUIVAMENTO DE CO - CONTROLLING ....................................................................................................... 258
32.1 OBJETOS DE CO ........................................................................................................................................................... 258
32.2 TABELAS DE CRESCIMENTO EXPRESSIVO EM CO ......................................................................................................... 259
32.3 BANCO DE DADOS LÓGICO DOS OBJETOS DE CO .......................................................................................................... 260
32.4 ANÁLISE DA TABELA DE PARTIDAS INDIVIDUAIS DE CO (COEP)................................................................................. 260
32.5 CONSIDERAÇÕES SOBRE A TABELA COFP ................................................................................................................... 261
32.6 CONSIDERAÇÕES SOBRE A TABELA COBK .................................................................................................................. 262
32.7 CONSIDERAÇÕES SOBRE COMPACTAÇÃO ..................................................................................................................... 262
32.8 OBJETOS DE ORDENS INTERNAS .................................................................................................................................. 263
32.8.1 Objeto: CO_ORDER - Ordens Internas ............................................................................................................. 263 32.8.1.1 Tabelas envolvidas ........................................................................................................................................................ 263
32.8.1.2 Critérios de seleção ....................................................................................................................................................... 264
32.8.1.3 Tempos de retenção ....................................................................................................................................................... 265
32.8.2 Objeto: CO_KABR - documentos de apropriação .............................................................................................. 266 32.8.2.1 Tabelas Envolvidas ........................................................................................................................................................ 266
32.8.2.2 Critérios de seleção ....................................................................................................................................................... 266
32.8.2.3 Tempos de retenção ....................................................................................................................................................... 267
32.8.3 Recuperação de dados ........................................................................................................................................ 267
32.9 OBJETOS DE ARQUIVAMENTO DE CENTROS DE CUSTOS .............................................................................................. 267
32.9.1 Tabelas envolvidas .............................................................................................................................................. 268
32.9.2 Critérios de seleção ............................................................................................................................................ 269
32.9.3 Recuperação de dados ........................................................................................................................................ 269
32.9.4 Objeto: CO_CCTR_EP - partidas individuais de centros de custos ................................................................... 270 32.9.4.1 Banco de Dados lógico: CEK (transação OKEM) ......................................................................................................... 270
32.9.4.2 Critérios de seleção ....................................................................................................................................................... 271
32.9.4.3 Recuperação dos dados.................................................................................................................................................. 271
32.9.5 Objeto: CO_CCTR_ID - dados reais de centros de custos ................................................................................. 271 32.9.5.1 Banco de Dados lógico: CIK ......................................................................................................................................... 272
32.9.5.2 Critérios de seleção ....................................................................................................................................................... 272
32.9.5.3 Recuperação dos dados.................................................................................................................................................. 272
32.9.6 Objeto: CO_CCTR_PL - dados planejados de centros de custos ....................................................................... 272 32.9.6.1 Banco de dados lógico: CPK ......................................................................................................................................... 273
32.9.6.2 Critérios de seleção ....................................................................................................................................................... 274
32.9.6.3 Recuperação dos dados.................................................................................................................................................. 274
32.9.7 Objeto: CO_COSTCTR - dados gerais de centros de custos .............................................................................. 274 32.9.7.1 Banco de dados lógico: CRK......................................................................................................................................... 274
32.9.7.2 Critérios de seleção ....................................................................................................................................................... 277
32.9.7.3 Recuperação dos dados.................................................................................................................................................. 277
32.10 OBJETO: CO_ALLO_ST - ALOCAÇÕES ESTORNADAS ............................................................................................. 277
CONTROLADORIA 10 de 325
32.10.1 Banco de dados lógico SAK ................................................................................................................................ 277
32.10.2 Critérios de Seleção ............................................................................................................................................ 279
32.10.3 Recuperação dos dados ...................................................................................................................................... 280
32.11 OBJETOS: CO_ITEM - PARTIDAS INDIVIDUAIS DE CO ............................................................................................. 280
32.11.1 Dependências ...................................................................................................................................................... 280
32.11.2 Tabelas envolvidas .............................................................................................................................................. 281
32.11.3 Preparação para o arquivamento ....................................................................................................................... 281 32.11.3.1 Critérios de seleção ....................................................................................................................................................... 282
32.12 CUSTO DE PRODUTOS .............................................................................................................................................. 282
32.12.1 Objeto: CO_COPC - Estimativa de custos de produto ....................................................................................... 282
32.12.2 Objeto: CO_KSTRG - Objetos de custo .............................................................................................................. 283
32.12.3 Objeto: CO_BASEOBJ - Componente ................................................................................................................ 283
32.13 OBJETOS DE ARQUIVAMENTO DO LEDGER DE MATERIAIS ....................................................................................... 283
32.13.1 Objeto CO_ML_DAT .......................................................................................................................................... 283 32.13.1.1 Tabelas envolvidas ........................................................................................................................................................ 283
32.13.1.2 Critérios de Seleção ....................................................................................................................................................... 284
32.13.1.3 Recuperação de dados ................................................................................................................................................... 284
32.13.2 Objeto CO_ML_BEL .......................................................................................................................................... 284 32.13.2.1 Tabelas envolvidas ........................................................................................................................................................ 284
32.13.2.2 Critérios de Seleção ....................................................................................................................................................... 284
32.13.2.3 Recuperação de dados ................................................................................................................................................... 284
32.13.3 Objeto: CO_ML_IDX - Docs.entrs.índice p/o material: ledger de material ...................................................... 285 32.13.3.1 Tabelas Envolvidas ........................................................................................................................................................ 285
32.13.3.2 Critérios de seleção ....................................................................................................................................................... 285
32.13.3.3 Recuperação de dados ................................................................................................................................................... 285
32.14 OBEJTOS DE ARQUIVAMENTO DE CLASSES DE CUSTO .............................................................................................. 285
32.14.1 Objeto: CO_CEL_RCL - Ledger de Reconciliação ............................................................................................ 285
32.15 OBJETOS DE ARQUIVAMENTO DE CENTROS DE LUCRO ............................................................................................ 286
32.15.1 Objeto: PCA_OBJECT - Centro de Lucro .......................................................................................................... 286
32.16 OBJETOS DE ARQUIVAMENTO DE COPA .................................................................................................................. 286
32.16.1 Objeto: COPA1_XXXX - Demonstração de Resultados baseado em custos....................................................... 286 32.16.1.1 Tabelas envolvidas ........................................................................................................................................................ 286
32.16.1.2 Critérios de seleção ....................................................................................................................................................... 286
32.16.1.3 Recuperação dos dados.................................................................................................................................................. 287
33 ARQUIVAMENTO DE PP: PRODUÇÃO ................................................................................................................. 287
33.1 OBJETO: PP_ORDER - ORDEM DE PRODUÇÃO ........................................................................................................... 287
33.1.1 Tabelas envolvidas .............................................................................................................................................. 287 33.1.1.1 Critério de seleção ......................................................................................................................................................... 291
33.1.2 Tempos de Retenção ........................................................................................................................................... 291
33.1.3 Recuperação de dados ........................................................................................................................................ 292 33.1.3.1 Perfil para sistema de apropriação de ordens ................................................................................................................. 292
33.1.3.2 Definir variantes de síntese para síntese de objetos ....................................................................................................... 293
33.1.3.3 Perfis para lista de efetuação do picking ....................................................................................................................... 293
34 ARQUIVAMENTO DE SD - VENDAS E DISTRIBUIÇÃO .................................................................................... 293
34.1 OBJETO SD_VBAK - DOCUMENTOS DE VENDAS ........................................................................................................ 294
34.1.1 Tabelas envolvidas .............................................................................................................................................. 294
34.1.2 Funções e relatórios disponíveis......................................................................................................................... 296
34.1.3 Objetos de autorização necessários .................................................................................................................... 296
34.1.4 Dependências ...................................................................................................................................................... 297
34.1.5 Recuperação de Dados de Custos ....................................................................................................................... 297
35 TABELAS DO BANCO DE DADOS .......................................................................................................................... 297
35.1 CATEGORIA DE UMA TABELA OU ESTRUTURA .............................................................................................................. 297
35.1.1 Tabela Transparente ........................................................................................................................................... 297
35.1.2 Estrutura ............................................................................................................................................................. 298
35.1.3 Categoria de tabela ............................................................................................................................................ 298
35.1.4 Estrutura Append ................................................................................................................................................ 298
35.1.5 Tabela Pool ......................................................................................................................................................... 299
35.1.6 Tabela Cluster..................................................................................................................................................... 299
CONTROLADORIA 11 de 325
35.1.7 Estrutura gerada de visão ................................................................................................................................... 299
35.2 CATEGORIAS DEFINIDAS PELO USUÁRIO NO ABAP DICTIONARY ................................................................................ 299
35.3 TIPOS DE DADOS E TIPOS DE OBJETOS .......................................................................................................................... 300
35.4 CLASSE DE ENTREGA ................................................................................................................................................... 300
35.4.1 Comportamento na cópia de mandante .............................................................................................................. 301
35.4.2 Comportamento no caso de instalação, mudança de release e importação de idioma ...................................... 301
35.4.3 Tabelas dependentes de mandante ...................................................................................................................... 301
35.4.4 Tabelas independentes de mandante ................................................................................................................... 301
35.4.5 Comportamento no caso de transporte entre sistemas de cliente ....................................................................... 301
35.4.6 Utilização da classe de entrega na atualização ampliada de tabela .................................................................. 301
36 TABELAS DO MÓDULO DE CO .............................................................................................................................. 302
36.1 TABELAS DE COMPACTAÇÃO DE ORDENS .................................................................................................................... 302
36.2 TABELAS DE COMPACTAÇÃO DE COPA ...................................................................................................................... 302
36.3 CONTROLLING DE CUSTOS INDIRETOS ......................................................................................................................... 302
36.3.1 Tabela BPTR - dados de objeto .......................................................................................................................... 303
36.3.2 Tabela ARCU_COIT1 Tempo de Retenção para partidas individuais de CO .................................................. 304
36.4 CONTABILIDADE DE CENTRO DE CUSTO ...................................................................................................................... 306
36.4.1 Contabilidade de custos Alocações RK-S ........................................................................................................... 306
36.5 TABELA DE DESVIOS - COSB ...................................................................................................................................... 307
36.5.1 Categorias de valores da tabela COSB .............................................................................................................. 307
36.5.2 Categorias de desvio/determ.resultados da tabela COSB .................................................................................. 310
36.6 DEMONSTRAÇÃO DE RESULTADOS .............................................................................................................................. 310
37 TABELAS DE MATERIAIS ....................................................................................................................................... 314
APÊNDICE A - TRANSAÇÕES DO R/3 ............................................................................................................................... 314
APÊNDICE B - NOTAS RELACIONADAS.......................................................................................................................... 315
NOTA 85708 - PERGUNTAS E RESPOSTAS SOBRE ARQUIVAMENTO DE CO_OM ....................................................................... 315
NOTA 200513 - CONSIDERAÇÕES SOBRE DELEÇÃO DA TABELA COBK - CABEÇALHO DE DOCUMENTOS DE CO. .................... 317
NOTA 32236 - QUANTIDADE OU VALOR DE ESTOQUE INCORRETO NO MESTRE DE MATERIAIS .................................................. 317
APÊNDICE A - TRADUÇÕES ............................................................................................................................................... 319
APÊNDICE B - CONCEITOS GERAIS DE GESTÃO DE NEGÓCIO .............................................................................. 320
APÊNDICE C - CONCEITOS GERAIS DO R/3 .................................................................................................................. 323
WORKBENCH (ABAP BC-DWB) ............................................................................................................................................ 323
VARIANT (VARIANTE) ............................................................................................................................................................. 323
BUSINESS SCENARIO (CENÁRIO DE NEGÓCIO) ......................................................................................................................... 323
UNIDADE ORGANIZACIONAL ................................................................................................................................................... 323
MASTER DATA (DADOS MESTRE) ............................................................................................................................................. 323
TRANSACTION (TRANSAÇÃO) .................................................................................................................................................. 323
DOCUMENTO ........................................................................................................................................................................... 324
TIPO DE DOCUMENTO .............................................................................................................................................................. 324
TIPO DE CONTA ....................................................................................................................................................................... 324
REPORTS .................................................................................................................................................................................. 325
ENJOY SAP ............................................................................................................................................................................. 325
CHANGE & TRANSPORT SYSTEM (BC-CTS) ............................................................................................................................ 325
CONTROLADORIA 12 de 325
1 Sistema R/3 – Introdução
SIGNIFICADO DA SIGLA R/3
R Real Time
3 3 tier (database, aplication system, frontend)
PRINCIPAIS PROCESSOS / NÍVEIS DE APOIO A GESTÃO. O Sistema R/3 atende aos quatro grandes principais
processos de uma empresa e o três níveis de apoio à gestão:
PRINCIPAIS PROCESSOS QUE ATENDE
AQUISIÇÃO DE MATERIAIS (Material Procurement)
VENDAS E EXPEDIÇÃO (Sales and Distribution)
PLANEJAMENTO E CONTROLE DA PRODUÇÃO
CONTABILIDADE, FINANÇAS E FISCAL
NÍVEIS DE APÓIO Á GESTÃO
CORPORATIVO – EIS (Executive Information System) – Lucros, ROI, Mercado, etc..
GERÊNCIA OPERACIONAL (NÍVEL TÁTICO) - Sistemas de Informações Específicos
de cada área – LIS (Logistics Information System), FIS (Financial Information System), HIS
(Human Resource Information System); Utiliza dados do sistema R/3 e de sistemas externos.
OPERACIONAL – Componentes do R/3 e sistemas não R/3.
O R/3 incorpora o conceito de WYSIWYG – (What You See Is What You Set) que permite configurar o front-end
individualmente para cada usuário personailizando leiautes de tela e menus. Para cada usuário, pode-se definir quais campos
serão exibidos, quais serão bloqueados e quais os obrigatórios e, ainda, estabelecer valores pre-definidos para determinados
campos. Podem ser criados novos menus específicos para cada usuário conforme o papel (role) que desempenha na empresa ou
mesmo alterar os menus existentes (Favorites). As interfaces com o usuário podem ser personalizadas através de elementos
organizacionais, perfis de usuário, regras de contabilização, calendários, tipos de materiais, faixas de numeração.
1.1 Mandante (Client)
O R/3 trabalha com o conceito de mandante (client) que permite agrupar, em um só ambiente operacional, operações de
diversas empresas independentes em termos de negócio. Um mandante é uma unidade independente para o R/3 tendo seus
próprio ambiente, dados, transações, parametrizações. Para entrar no sistema, o usuário deve informar em qual mandante irá
trabalhar. Conforme as necessidades da empresa podem ser criados um único mandante para todas as empresas (situação mais
comum), ou dividi-las em diversos mandantes.
O conceito de mandante também é bastante usado no processo de Implantação. Normalmente, para cada Implantação do R/3
são definidos pelo menos três mandantes:
Primeiro – para testes iniciais, durante as definições de parametrizações.
Segundo – para definir as configurações de produção onde serão efetuados os testes mais refinados, já bem mais próximo
do ambiente de produção.
Terceiro – é o ambiente de produção propriamente dito. Durante a Implantação, as alterações de configuração serão
efetuadas no ambiente de teste e validadas. Posteriormente, então, são transferidas para o ambiente de produção através de
funções específicas disponíveis no R/3. (Funções de transporte de dados).
CONTROLADORIA 13 de 325
1.2 Idioma do Sistema
O R/3 está disponível em diversas línguas, podendo o usuário informar o idioma que irá trabalhar ao entrar no sistema. O
usuário tem um idioma padrão definido no seu perfil. É possível um mesmo usuário se “logar” mais de uma vez no sistema.
Uma vez dentro do sistema, o usuário pode abrir até 6 sessões simultâneas (janelas ou modos), ou seja, pode estar trabalhando
em até seis transações diferentes ao mesmo tempo. Para abrir uma nova sessão pode ser usado o menu, a barra de tarefas e o
campo command field descritos posteriormente.
1.3 Acesso direto à transação (Command field)
É o campo localizado na barra de ferramentas padrão do R/3 que permite acessar diretamente uma transação (função) do
sistema sem a necessidade de navegação no menu informando o seu código. Para identificar o código de uma transação, o
usuário tem várias opções:
estando na aplicação, pode selecionar, na barra de menu, a opção System Status. Um dos campos exibidos na janela será
o código da transação.
o primeiro campo da barra de status (extremidade inferior da tela) pode apresentar diferentes informações conforme
parametrizado: System, Client, user, program, transaction, Response Time, Round trips/flushes. Teclando no ícone ao lado
do campo, pode se visualizar qualquer uma destas informações.
marcando a opção Opções Suplementos Exibir nomes técnicos (Settings Suplementos Show Technical Names).
Neste caso, no menu padrão (SAP Menu e no Favoritos), o código da transação aparecerá antes do nome da transação.
Além do código da transação, alguns comandos podem podem ser digitados neste campo com funções específicas:
/o antes do nome da transação – a transação solicitada será aberta em uma nova sessão e a sessão corrente permanece
com a transação corrente;
/n antes do nome da transação – a transação corrente será encerrada e a transação solicitada é aberta na mesma sessão;
/i – encerra a seção corrente.
1.4 Master Data – Dados mestres
Os registros de dados que permanecem no banco de dados por um longo período de tempo são chamados Master Data. São os
cadastros básicos e compreendem os fornecedores, os materiais, as contas contábeis, clientes, etc. São criados de forma
centralizada podendo ser usados por várias aplicações. Por exemplo, o cadastro de cliente é usado tanto por vendas quanto pelo
contas a receber. O cadastro de clientes e fornecedores são distintos. Isto significa que se uma empresa for cliente e fornecedora
ao mesmo tempo, deverá ser inserida nos dois cadastros. No entanto, é possível estabelecer um vínculo entre os dois cadastros
para permitir o encontro de contas do ponto de vista financeiro, no caso de uma permuta, por exemplo.
Os cadastro são subdivididos em segmentos de acordo com a área de utilização. Por exemplo, o cadastro de clientes se
subdivide e três: General Data (cross-enterprise) que possui informações genéricas para todas as empresas, Financial
Accounting Data que possui informações específicas para a empresa ligados principalmente a área financeira e Sales Data que
possui informações relevantes somente para a área de vendas.
1.4.1 Cadastro de clientes
O cadastro de clientes é por mandante. Cada filial de uma empresa representa um cliente para o R/3. Através das Partner
Functions é possível determinar diferentes filiais de uma empresa para faturamento, cobrança, entrega, etc. (SP – Sold-to-party;
BP – bill to party; PY – payer; SH – Ship-to-party).
Os clientes podem ser associados à empresa, organização de vendas, canal de distribuição e divisão (business area).
A nível de dados gerais de clientes estão as informações: código (número da conta do razão auxiliar), nome, endereço, telefone,
informações bancárias. A nível de empresa podem ser definidas a conta de conciliação (conta de saldo sintética do grupo de
clientes no razão geral), condições de pagamento, forma de classificação dos lançamentos dos clientes na tela de consulta de
lançamentos (item sorting), procedimento de cobrança, etc.
A nível de vendas estão as informações para controle do cliente para vendas. As informações de vendas podem ser acessadas
pela área financeira e vice-versa. Analogamente, o cadastro de fornecedores possui um parte genérica, uma parte por empresa
(contas a pagar) e uma área para compras.
CONTROLADORIA 14 de 325
Trading Partner – para controle de negociações entre empresas do grupo
1.4.2 Cadastro de materiais
O cadastro de materiais é usado por todos os módulos de logística (compras, engenharia, desenvolvimento de produtos,
planejamento de materiais, almoxarifado, contabilidade financeira, vendas, custos, programação da produção (work
scheduling), previsões (Forecasting), classificações (agrupamentos para facilitar pesquisas), warehouse management
(gerenciamento de estoques a nível de prateleira, estantes, etc.), etc.). Inclui todos os materiais usados na empresa: matérias-
primas, material de consumo, produtos acabados, intermediários, materiais de manutenção, etc. O Material Type é que irá
definir a característica do material, ou seja, determina as visões que o material pode ter. A existência de um único cadastro para
todas as áreas evita redundâncias. A estrutura lógica do cadastro de clientes e fornecedores também se aplica ao cadastro de
materiais.
Um ponto importante a se considerar no cadastro de materiais é a definição da unidade de medida. O cadastro trabalha com
uma unidade de medida do material e outras unidades alternativas que podem ser definidas para vendas, compras, produção,
requisição de material, etc.. Somente custo só aceita trabalhar com a unidade de medida básica. Portanto, a unidade de medida
básica deve ser definida de acordo com a necessidade da área de custos. Para as demais áreas pode ser definida uma unidade
medida específica.
1.5 Consultas e Relatórios
Uma vez que a informação foi alimentada no R/3 existem basicamente três formas de se extrair a informação. Através dos
Sistemas de Informação, através do EIS (Executive Information System) e através do BW (Business Information Warehouse).
Cada módulo do R/3 possui o seu sistema de informações com relatório já predefinidos e que podem ser customizados. A forma
de alimentação destes sistemas é PUSH, ou seja, a cada transação, os dados são automaticamente transferidos para os sistemas
de informação. Para os outros dois, o critério é PULL, significando que a atualização não é on-line a cada transação e, sim, um
processo batch que puxa as informações do R/3. O EIS trabalha com o conceito de ASPECTS (níveis de sumarização). O objeto
de negóico “Aspect” corresponde a um conjunto de informações de negócio sumarizadas para uma Empresa ou um Grupo para
fins de avaliação de cada uma das áreas da empresa. Uma tabela do banco de dados contendo características e key figures é
criada para cada Aspect. Pode conter, por exemplo, informações sobre posições financeiras, logística, pessoal, situações de
mercado.
As saídas do sistema podem ser arquivos, fax, e-mail, relatórios impressos ou consultas em tela permitindo, inclusive, gerar
planilhas Excel. Na versão 4.6 também é possível trabalhar com planilhas Excel dentro do próprio SAP através da opção do
menu Ambiente Opções Office Integration: selecionar Microsoft Excel. Algumas parametrizações de basis devem estar
configuradas para permitir este tipo de acesso.
Os relatórios do R/3 são processados on-line ao mesmo tempo em que as transações estão sendo efetuadas. Relatórios
freqüentemente usados pode ter suas parametrizações (opções de seleção) armazenadas na forma de Variantes facilitando sua
execução. Estas variantes tanto podem ser usadas na geração de relatórios on-line como podem ser vinculadas a jobs
especificando quando o relatório deve ser processado. Os dados de um relatório podem também serem exibidos graficamente.
O R/3 possui o conceito de pesquisa recursiva ou drill-down que permite que se desça a nível de detalhes a partir de um
relatório genérico até chegar na informação desejada. Esta alternativa facilita grandemente a análise dos dados em um relatório
de forma ágil e segura.
As informações nos sistemas de informação são armazenadas em estruturas de informações sumarizdas (aggregated
information structure). Alternativamente, os SI também podem receber informações de outros sistemas não-SAP. Os
relatórios mais freqüentemente usados podem ser executados a partir do Menu standard do SAP.
Basicamente, os relatórios se dividem em três tipos:
Padrão (standard reports): lista de documentos, de cadastros básicos (lista de clientes, fornecedores, plano de contas, etc.),
etc.;
Sistemas de Informação: análise padrões sobre logística (LIS), financeiro (FIS) e recursos humanos (HIS);
EIS e BW
CONTROLADORIA 15 de 325
2 Menu Principal
A barra de menu contém as opções do menu em cascata. Varia conforme a aplicação corrente. Em todas as aplicações, estarão
disponíveis as opções de Sistema e Ajuda (System e Help) descritos mais adiante.
2.1 Menu Sistema (System)
O menu Sistema aparece em todas as telas do R/3 e disponibiliza diversas funções:
2.1.1 Abrir/ Fechar Janela (Create / End Session)
Permite a criação e o encerramento de novas janelas (sessões ou modos). Como já foi dito, no R/3, o usuário pode trabalhar
com até seis janelas (sessões) simultâneas possibilitando que sejam processadas até 6 transações ao mesmo tempo. Isto facilita
que o usuário, estando cadastrando um ordem de vendas, por exemplo, possa fazer verificações no cadastro de materiais sem
abandonar o cadastramento da ordem. Relatórios que são constantemente acessados também podem ficar em aberto em uma
janela paralela.
2.1.2 Especificações do Usuário (User Profile)
2.1.2.1 Manter, Definir e Eliminar Dados (Hold, Set and Delete Data)
As funções de Manter e Definir dados permite criar grupo de objetos de dados similares ou iguais como, por exemplo, um
grupo de ordens de compra. As duas funções permitem definir valores propostos para os campos especificados só que a função
Manter permite alterar o valor do campo e a função Definir não.
Para Manter ou Definir dados, preencha o conteúdo do campo e “congele-o na tela” usando uma das funções. A partir daí,
sempre que for retornar a esta tela, especificamente, o sistema, automaticamente, preenche o campo ou os campos
“congelados”. Se for necessário alterar o valor, utilize a Função Manter. Caso contrário, utilize o Definir pois o sistema irá
saltar este campo agilizando a digitação. Podem ser congelados campos de várias telas. Os campos permanecerão congelados
até que sejam eliminados através da função Eliminar ou após a saída (logoff) do sistema.
Nem todas as telas tem esta função disponível. Assim como para todos os objetos do R/3 Repository, as telas tem atributos que
a descrevem e determinam seu funcionamento em tempo de execução. O atributo Hold Data determina se o usuário poderá ou
não congelar valores para esta tela. Somente valores realmente informados pelo usuário poderão ser congelados. Eles
sobrepõem o valor transferido pelo programa ABAP no evento PBO. No evento PBO, o atributo Hold Data pode ser alterado
dinamicamente (em tempo de execução).
2.1.2.2 Dados Próprios (Own Data)
Contém as configurações do usuário. As informações estão divididas em três grandes grupos:
Endereço (Address) – Em Endereço, são definidos o nome completo do usuário, a forma de tratamento, o endereço e telefone.
Valores Fixos (Defaults) – Em Valores Fixos, são definidos o formato de apresentação das informações ao usuário: notação
de decimais e de datas, impressora padrão, idioma padrão, menu inicial, etc.
Parâmetros (Parameters). Em Parâmetros, são definidos os valores propostos para preenchimentos de um determinado campo
de tela através do parameter ID deste campo de forma que, sempre que este usuário acesse uma tela que possua este campo, o
campo configurado já aparecerá preenchido com o valor proposto aqui definido. O objetivo da definição dos valores propostos
é agilizar e minimizar erros no preenchimento dos campos. Assim, por exemplo, podem ser definidos como valor propostos, o
código da empresa, o código do centro, da Área de Contabilidade de Custos, etc.. Em conjunto com as definições das variantes
de exibição, pode-se restringir a alteração destes campos para garantir uma entrada de dados correta. Cada vez que os dados
próprios do usuário forem alterados, será necessário reiniciar o menu para que as alterações sejam consideradas.
Para saber qual o o parameter ID de um campo, vá para uma tela que contenha o campo deseja, posicione o cursor no campo e
tecle F1. Será exibida a tela de help do campo. Em seguida, precione a opção Informações técnicas para ver o parameter ID do
campo.
CONTROLADORIA 16 de 325
2.1.3 Serviços (Services)
2.1.3.1 Reporting
Inicia o Reports (programas ABAP). Cada tipo de programa ABAP possui um comando inicial dos seguintes tipos:
Tipo Comando Inicial
1 REPORT
M PROGRAM
F FUNCTION-POOL
K CLASS-POOL
J CLASS-POOL
S PROGRAM
T TYPE-POOL
I -
Programas do tipo I (Include) não são compilados, são simplesmente modularizados sendo usados somente no contexto do
programa a que pertence. Por esta razão, não possuem um comando inicial. Os comandos REPORT e PROGRAM,
normalmente, têm a mesma função. Permite especificar a classe de mensagens do programa e as opções de formatação para sua
lista default. O tipo de programa é que define se ele é executável ou somente poderá ser iniciado por uma transação e não o
comando inicial. No entanto, programas executáveis poderiam sempre iniciar com um comando REPORT, e modules pools
sempre com o comando PROGRAM. Surtotinas (tipo S) deveriam iniciar com o comando PROGRAM.
2.1.3.2 Quickviewer (Abap Query (Bc-Srv-Que))
Ferramenta que permite contruir relatórios sem programação. Para definir um relatório com o QuickViewer, basta definir os
títulos, selecionar os campos e opções que definirão a estrutura do relatório. Uma seqüência específica de campos podem ser
associada através de numeração. Se necessário, as listas podem ser editadas através de “arrastar soltar” no modo WYSIWYG,
ou através das funções disponíveis nas barras de ferramentas. Os dados também poderão ser enviados para programas externos
tais como Excel ou Word.
2.1.3.3 Controle de Saída (Output Controller)
Permite gerenciar as solicitações de impressão do usuário. Existem duas formas de visualizar as solicitações de relátórios do
usuário:
Da tela de seleção do Controle de Saída (transação SP01). É possível navegar entre a tela de Outputs requests e spool
requests. É possível selecionar os campos a serem exibidos. Para selecionar os campos, pressione a opção “Outros critérios
de seleção...” e escolha uma das opções. Selecione as solicitações combinando os diversos critérios (por exemplo, usuário,
número da solicitação, dispositivo de saída, data da solicitação, etc.). Assim como em todas as telas do SAP, se um campo
for deixado em branco, todas as opções serão consideradas, ou seja, nenhuam restrição será considerada para aquele
campo.
Conforme o nível de autorização, os usuários poderão ver todas as solicitações ou somente as suas.
Da lista de solicitações: selecionar a lista de solicitações cujas solicitações de saída se deseja ver e escolha a opção
(Output requests). Várias outras opções estão disponíveis tais como, ver o conteúdo, eliminar, solicitar impressão, etc..
2.1.3.4 Atualização de Tabelas (Table Maintanance)
Manutenção da tabelas e visões de tabelas do R/3. Nem todas as tabelas poderão ser alteradas por esta função devendo ser
usada uma função específica para a tabela, disponível no Customizing (IMG). Um tabela (ABAB Dictionary (BC-DWB-DIC) é
um vetor de dados no dicionário ABAP. Um tabela consiste de colunas (valores de dados com o mesmo tipo) e linhas (registros
de dados). Cada registro deve ter uma identificação única determinada por um ou vários campos.
CONTROLADORIA 17 de 325
Tabelas internas são objetos de dados variáveis dinamicamente. Como todas as variáveis, são declaradas através de um
comando DATA. Tabela internas estáticas também podem ser declaradas em Procedures usando o comando STATICS e em
classes usando o comando CLASS-DATA.
Embora o controle de visão de tabelas do SAP possa ser usado independentemente, é preciso conectá-lo a uma coleção de
visões de tabelas para explorar seu utilização de forma completa. Uma vez que uma visão de tabela é conectada a uma tabela, a
alteração em outra automaticamente reflete na outra e vice-versa sem a necessidade de programação adicional.
2.1.3.5 Batch Input
– Gerencia as sessões de batch input para transferência de dados. Batch Input é uma interface do R/3 (Basis
Services/Communication Interfaces – BC-SRV) que facilita a entrada de um grande volume de dados no sistema podendo ser
usado para entrada periódica de dados externos e migração inicial de dados. Um programa ABAP lê os dados externos a serem
inseridos no R/3 e armazena em uma sessão de batch input. As ações necessárias para a transferência dos dados são gravadas
através de transações normais do SAP. Após a geração da sessão pelo programa, a sessão pode ser processada para executar as
transações SAP. Uma sessão de batch input entra na fila quando criada e permanece lá até ser iniciada explicitamente. Para
iniciar uma sessão pode ser usada esta opção ou, alternativamente, submeter um job em background (RSBDCSUB). Este job irá
inicializar todas as sessões com o nome indicado. No sistema de processamento background é possível coordenar a geração e
execução das sessões de batch input. Por exemplo, pode-se programar a execução (schedule) do programa de batch input e o
RSBDCSUB e definir que o programa deve ser executado antes do RSBDCSUB. O RSBDCSUB será executado,
automaticamente, somente se o job de batch input for processado com sucesso. Alternativamente, o programa de batch input e o
RSBDCSUB pode ser enfileirados como passos de um único job. Só que, neste caso, o RSBDCSUB será executado mesmo que
o programa anterior tenha abortado.
O batch input é apenas uma das forma de transferência de dados. Os dados também podem ser transferidos por Direct Input e
Call Transaction.
Outra forma de transferência de dados é o Call Transaction para execução de transações SAP. Os dados não precisam ser
armazenados em sessões para posterior processamento. Todo o processamento de batch input é feito on-line pelo programa.
Neste caso, o tempo de processamento é menor. No entanto, este processo, não suporta correções interativas e função de log
automáticos.
2.1.3.6 Entrada Rápida (Fast Entry) ??????????
Recorder – (Transaction Recorder) – transação SHDB – Esta transação pode ser usada pra gravar uma série de transações e suas
telas. Pode ser usada para criar programas de transferência de dados que usem o batch input ou o Call Transaction, para criar
sessões de batch input, para criar massa de teste ou para criar módulos de funções. A gravação pode ser executada várias vezes.
As telas serão executadas exatamente da mesma forma como foram processadas durante a gravação. As gravações podem ser
alteradas depois de gravadas. Esta é a mesma transação iniciada pela opção Batch Input (Recorder).
Observações:
As teclas F1 e F4, os comando dos menus Sistemas e Ajuda não são gravadas.
Mensagens de erro de de aviso não são gravadas. Isto significa que somente campos com o código OK e conteúdos que
conduzam a um processamento bem sucedido serão processados na tela corrente.
O comando COMMIT WORK no fluxo da transação indica processamento OK. A gravação também encerrou com
sucesso.
LEAVE TO TRANSACTION no decorrer da transação indica que não esta disponível batch input. A gravação é encerrada.
Nas telas de SCREEPAINTER, movimento da barra de rolagem são são gravados. Devem ser usadas as funções F21 e F24
para o posicionamento.
Processamento Visível
Exibir somente erros
Cancelar
CONTROLADORIA 18 de 325
2.1.3.7 Entrada Direta (Direct Input)
O Direct Input é uma otimização do bacth input usada, especialmente, para a transferência de grandes volumes de dados. Tem
uma performance melhor porque não trabalha com tela para consistência dos dados como ocorre com o bathc input. Também
não trabalha com sessões, armazenando os dados diretamente. A consistência dos dados é feita por módulos de funções do
SAP. Em caso de erro, o processo pode ser reiniciado somente se executado em background. Para manter e executar estes
programas, use o programa RBMVSHOW ou a transação BMV0. Exemplos de programa de Direct Input:
Programa Aplicação
RFBIBL00 FI
RMDATIND MM
RVAFSS00 SD
RAALTD11 AM
RKEVEXT0 CO-PA
2.1.3.8 CATT (Computer Aided Test Tool (BC-CAT) ???????????
Registrar
Cancelar
2.1.3.9 Jobs
Gerenciamento de jobs processados no servidor. Um Job corresponde a um conjunto de programas que são executados
cronologicamente um após o outro controlados por comandos específicos.
2.1.3.10 Filas
2.1.3.11 Serviços SAP (SAP Services)
Logon no SAPNet R/3 Frontend.
2.1.3.12 Agenda (Appointment calendar)
Um apontamento é um intervalo de tempo ou horário paraa o qual um usuário especificou uma atividade ou um evento
específico. Os apontamento são associados a uma intervalo de tempo em uma agenda. Este intervalo é então preenchido com
esta atividade. Mas de um apontamento pode ser associado a um intervalo de tempo. A agenda possui ferramentas para facilitar
a manutenção como apontamentos periódos. Apontamentos de grupo e atividades sem vinculação de dia, são atividades diárias.
Próprio (Onwer)
Empregado (Employee) – permite criar uma lista de tarefas que um empregado deve executar durante um determinado
período. As listas podem ser importadas e editadas. Para isto, devem ser usadas as funções d isponíveis no SAP List
Viewer.
2.1.3.13 Business Workplace
A Businnes workplace é uma área de trabalho integrada para o usuário contendo processamento de itens de trabalho,
mensagens enviadas e recebidas, documentos administrativos e processos de trabalho e distribuição e processamento de
informações para toda a empresa ou dentro de um grupo particular. É uma ferramenta do SAP Business Workflow (BC-BMT-
WFM).
CONTROLADORIA 19 de 325
2.1.4 Utilitários
2.1.4.1 Depuração de Telas (Debug Screen)
2.1.4.2 Depuração ABAP/4 (Debug ABAP)
2.1.4.3 Depuração Sistema (Debug System)
2.1.4.4 Consumo de Recursos (Resource Usage)
2.1.4.5 Fila automática processamento síncrono(Autom.queue syncronous processing)
2.1.4.6 Exibição de performance (Performance display)
Os dois aspectos relevantes de um sistema operacional são a disponibilidade e a performance.
Disponibilidade
Um serviço é dito disponível se for capaz de executar a tarefa para a qual foi destinado. É um conceito “sim-não”, estando o
serviço disponível ou não. Considerando um tempo ocioso não programado, este conceito sim-não é associado a uma modelo
de insucesso denominado “Crash failure”. Esta é uma aproximação das falas reais de sistema, que geralmente são mais
complexas.
CONTROLADORIA 20 de 325
Performance
A performance é medida pel abilidade de conhecimento de certos critérios pre-definidos, tais como, rendimento do sistema (por
exemplo, número de usuários suportados) e o tempo de resposta para cada usuário. Performance é considerada aceitável quando
um certo nível é atingido dentro de um dado período.
A performance, com certeza, depende da disponibilidade. No entanto, a disponibilidade nem sempre garante a performance. Por
exemplo o R/3 onde a utilização de CPU do servidor de banco de dados é alta tem baixa performance, mas pode ser
considerado como disponível. Na prática, a distinção entre estes dois aspectos frequentemente se misturam em casos extremos,
pois, uma performance muito ruim significa que o sistema pode ser considerado como não disponível. Por exemplo, uma
conecção de rede pode ser interrompida depois de um time-out ocorrido em função de uma performance baixa inaceitável.
Para aumentar a disponibilidade do sistema., é essencial minimizar o tempo de ociosidade. Os tempos de parada podem ser
planejados ou não planejados e, num nível mais baixo, podem ser separados em planejados e não planejados do R/3, do
gerenciador do banco de dados, da rede, do sistema operacional e mesmo do hardware.
2.1.4.7 Trace performance
2.1.4.8 Análise de tempo de execução (Runtime analisys)
Função para medição e análise de performance de todos os programas, transações e funções dos módulos. É usada para gerar
listas que idetificam comando com longo tempo de execução, acessos a tabelas sumarizadas e mostrar o fluxo hierarquico do
programa. Estas informações facilitam encontrar e analisar problemas causados por:
Uso excessivo ou desnecessário de comandos ABAP, de subrotinas e módulos de função.
Funções de progama de uso intensivo de CPU
Funções específicas do usuário que forma alteradas por comandos ABAP
Acessos ao banco desnecessários ou ineficientes.
Opções disponíveis:
Executar
Ativar
Desativar
2.1.4.9 Exibir Verificação de Autorização (Display authorization check)
2.1.5 Lista (List)
2.1.5.1 Imprimir (Print)
2.1.5.2 Procurar(Find)
2.1.5.3 Gravar(Save)
Arquivo Office
Arquivo Menu
CONTROLADORIA 21 de 325
File local
2.1.5.4 Enviar(Send)
2.1.5.5 Título da Lista (List header)
2.1.6 Serviços para objeto
2.1.7 Histórico do objeto
2.1.8 Ordens spool próprias (Own spool request)
2.1.9 Jobs próprios (Own jobs)
2.1.10 Mensagem breve (Short message)
2.1.11 Status
2.1.12 Logoff
2.2 Ajuda (Help)
O R/3 possui diversas formas de ajuda ao usuário:
Help de Campo (F1) – estando posicionado em um determinado campo da tela, o usuário pode teclar F1 para obter um
explicação do campo. Também pode acessar este help através do botão direito do mouse. Além do help de campo, a tecla F1
também permite acessar help de menu, funções e mensagens, dependendo de onde o usuário estiver posicionado. Na janela de
help de campo também está disponível o botão de “Informações técnicas” que exibe informações de formatação do campo,
nome da tabela, nome do campo, parameter ID, etc.. O parameter ID é importante para a construção de valores propostos para o
usuário.
Ajuda para a Aplicação. O help de aplicação pode ser acessado na tela de help de campo ou pela barra de menu Help
Aplication Help. Se o usuário estiver na tela inicial, será exibido a SAP Library posicionado no item Getting started with R/3.
Biblioteca SAP (SAP Library). Este é o manual on-line do sistema. Contém a explicação de todo o sistema podendo o usuário
navegar pelo índice ou por pesquisas para encontrar a informação desejada. O idioma é definido pela biblioteca disponibilizada
para consulta e não pelo idioma que o usuário esteja logado.
Info de Release (Release Notes) – informa as alterações que ocorreram nas mudanças de versão do R/3.
CONTROLADORIA 22 de 325
SAPNet. Permite logar no SAPNet. Se situações de erro ocorrerm no sistema, o SAPNet fornece uma ajuda efetiva e rápida.
If problem situations occur in the system, SAPNet provides fast, effective help. In SAPNet, you can enter your questions to
SAP directly and immediately receive an initial response. SAPNet provides you with the same information that SAP itself uses
for First Level Support.
When you save the message you entered, the terminology contained in the message is used for an automatic search in the notes
database. The system displays a list of notes, which contain detailed descriptions of how to solve the problem.
First and Second Level Support workers use incoming customer messages to write Notes. R/3 developers also create Notes if
they recognize any potential sources of problems or missing information.
Atividades
There are different ways to start a search for notes. Several are listed below:
Specify the number of the note
Enter the application area (for example BC-DB)
Enter values for the change date
Free text search: Enter an Oracle or SAP utility keyword
Feedback – permite enviar mensagens para a SAPNet R/3 Frontend, SAP’s service system.
Opções (Settings) – permite alterar a configuração do help, alterando, por exemplo, como serão exibidas informações no Zoom
do campo.
Matchcode – (Zoom) – Entradas Possíveis. O zoom do campo, ou seja, a lista da opções possíveis para preenchimento do
campo em que o usuário está posicionado pode ser obtido com a tecla F4 ou o botão direito do mouse. Esta alternativa é
bastante útil pois evita que o usuário tenha que decorar códigos. As opções que aparecerão na lista do campo são filtradas
conforme a aplicação. Assim, um mesmo campo pode ter uma lista de entradas possíveis diferente de uma tela para outra, ou
mesmo numa mesma tela quando o preenchimento dos demais campos forem diferentes. O zoom do campo também pode ser
obtido pelo botão imediatamente à direita da campo. Sempre que selecionar esta opção, antes da listagem será exibida uma tela
de seleção (filtro) para que o usuário possa restringir mais a pesquisa e encontrar o valor desejado mais rapidamente. Para
algumas funções, este matchcode pode ser alterado para que outros campos, ou combinação de campos possam ser usados para
pesquisa.
Help do IMG – IMG é o Guia de Implementação do R/3, contém todas as etapas que precisam ser seguidas para parametrização
do sistema antes da entrada em produção. Todas as atividades nele relacionadas possuem um help explicativo que pode ser
exibido tanto no formato html quanto em text script conforme parametrizado no menu Utilities. Este help é bastante útil na
Implantação do sistema.
3 Barra de Ferramentas padrão (Standard Tool Bar)
Esta barra está disponível em todas as aplicações tendo alguns de seus ícones inibidos quando não estiverem disponíveis. Os
ícones possuem um help explicando sua função e sua tecla de atalho bastando para isto permanecer com o cursor sobre ele por
um tempo. Possui o campo Command Field já descrito, os ícones de gravação, navegação, saída, criação de sessão (janela),
ajuda, opções de layout. Nas opções de layout é possível alterar a forma de apresentação das mensagens, formas de trabalhar
com o cursor, tamanho da fonte, cores, etc..
Botão Nome Função
Confirmar (Enter) Confirmar as informações digitadas ou selecionados. Não grava.
Campo de comando Permite digitar comando, como, por exemplo, o código da
transação.
Gravar Mesma função do Menu Edit Salvar
Voltar Retona para atela anterior sem salvar os dados. Obriga o prévio
preenchimento dos campos obrigatórios.
CONTROLADORIA 23 de 325
Sair Encerra a transação atual sem salvar os dados. Retorna para a tela
inicial ou a tela do menu principal.
Cancelar Abandona a transação atual sem salvar os dados. Corresponde à
função Edit Cancelar.
Imprimir Imprime os dados da tela atual.
Localizar Pesquisa por informações na tela atual.
Localizar próxima Procura a próxima ocorrência na tela atual.
Primeira página
(Ctrl+PgUp)
Retorna para a primeira página.
Página anterior
(PgUp)
Retorna uma página.
Próxima página
(PgDn)
Avança uma página.
Última página
(Ctrl+PgDn)
Avança para última página.
Abrir janela Abre uma nova janela. Mesma função System Abrir janela
(Create session).
Criar tecla de atalho Permite a criação de teclas de atalho para relatórios do SAP,
transações ou tarefas (válido para Win 32).
Ajuda (F1) Apresenta a descrição do campo onde o cursor estiver
posicionado.
Leiaute do Menu Permite personalizar as opções da tela (Opções, Gerar Gráfico,
Criar Ligação, Ativar GuiXT, Tamanho Standard, Hardcopy,
Cortar rapidamente_inserir, Sobre...
4 Barra de Títulos (Title bar)
A barra de títulos mostra uma descrição sucinta da aplicação em que o usuário está.
5 Barra de Status
Localizada na extremidade inferor da tela, possui um campo para apresentação de mensagens. As mensagens, no R/3, podem
ser de erro, aviso ou simples informação. Esta característica da mensagem pode ser alterada, ou seja, uma mensagem de aviso,
por exemplo, pode ser alterada para uma mensagem de erro. A configuração ara exibição das mensagens pode ser alterada
conforme as preferências do usuário. Assim, se preferir, o usuário pode solicitar que as mensagens de erro, por exemplo, sejam
exibidas em janelas de diálogo e não na barra de status.
6 Barra de Ferramentas da Aplicação (Aplication tool bar)
A barra de ferramentas específica da aplicação contém diversos ícones que variam de acordo com a aplicação complementando
as opções padrão disponíveis na barra de ferramentas padrão.
7 Campos da tela do R/3
Os campos de entrada de dados podem ser de três tipos diferentes: Radio Buttons, Check boxes, Input field (texto) funcionando
de forma semelhante aos aplicativos windows. Os campos que aparecem preenchidos com uma checkmark são os campos de
preenchimento obrigatório. Em versões anteriores, estes campos eram marcados com pontos de interrogação. Através de
“Variantes de exibição” o usuário poderá alterar os campos obrigatórios, opcionais e poderá até mesmo ocultar alguns campos.
CONTROLADORIA 24 de 325
Assim, por exemplo, é possível determinar quais os campos serão de preenchimento obrigatório conforme o grupo de contas
contábeis do plano de contas.
Algumas telas ainda possuem uma tabela com explicações.
8 Menu Padrão SAP ou Favoritos
Depois de informar seus dados para entrar no sistema (mandante, nome, senha e idioma), será apresentado ao usuário o menu
padrão do SAP (SAP Easy Access – Standard). Se desejar que seja apresentada outra tela, poderá ser parametrizada uma
transação inicial em Extras Set start transaction . Esta transação pode ser uma transação do próprio SAP para um usuário
que tenha acesso bem específico no sistema (pouco usado) ou, por exemplo, para criar um menu específico para a empresa.
Basicamente, o usuário tem três formas de navegar no SAP:
Através do Menu padrão que já vem montado com todas as transações disponíveis no menu;
Através do Command Field informando diretamente o código da transação;
Através de um menu customizável, o FAVORITES, onde o usuário poderá dependurar as transações de seu uso, conforme
suas preferências, inclusive podendo criar uma estrutura diferente da estrutura do menu padrão. Além de transações, o
usuário pode também incluir sites da internet, relatórios e arquivos. Para a manutenção do favorites, está disponível a
opção de dragging & dropping (arrastar e soltar o mouse).
Em Extras Settings, a tela inicial também pode ser alterada solicitando que seja apresentado somente o menu Favorites, ou
que o Favorite seja apresentado depois do Menu padrão e ainda se deseja que a imagem da tela principal seja ou não exibida.
Além do Menu Standard, a SAP também disponibiliza outros menus montados de acordo com a função específica do usuário.
Assim, por exemplo, existem menu para um usuário do contas a pagar, um para um usuário da contabilidade, etc. Nestes menu,
aparecem disponíveis somente as transações relacionadas à sua atividade ou cargo da empresa. Os usuários do sistema deverão
ser vinculados a um grupo de atividades (activity groups – user role). Na versão 4.6 do R/3 já existem user roles(função, cargo)
predefinidas para todas as áreas de aplicação. Estando o usuário vinculado a um grupo de atividade, poderá escolher entre
navegar pelo menu padrão ou pelo menu específico do usuário. Na aplication tool bar podem ser criados novos menus, pode-se
alternar entre um menu e outro, pode-se associar usuários.
9 Módulos (Componentes)
PP – PRODUCTION PLANNING (PRODUÇÃO)
SOP – Sales and Operation Planning
MPS – Master Production Scheduling
MRP – Material Resource Planning / Management Resource Planning
OS/OP – Ordem de Produção e de Processo
Chão de Fábrica
Custeio dos produtos
MM – MATERIAIS MANAGEMENT
SD – SALES AND DISTRIBUTION
FI – FINANCIAL ACCOUNTING
IM – INVESTIMENT MANAGEMENT
Planejamento e Controle de medições de Programas de Investimento de Capital
EC – ENTERPRISE CONTROLLING
Consolidação gerencial e Contabilidade por centro de lucro (Profit Center Accounting)
CO – CONTROLLING (CONTROLADORIA)
Contabilidade de Custos
Demonstração dos custos e receitas da empresa;
CONTROLADORIA 25 de 325
Permite a contabilização por centro de custo, centro de lucro ou produto;
Trabalha com o Custo ABC – Activity Based Costing (Custeio baseado em atividade)
Gera Análise de Rentabilidade / Demonstração de Resultados
Controle Corporativo
Controle de Orçamentos
Contabilidade Gerencial
AM – ASSET MANAGEMENT
QM – QUALITY MANAGEMENT
PM – PLANT MAINTANANCE
HR – HUMNA RESOURCES
Efetiva participação dos vários níveis de gerência.
PS – PROJECT SYSTEM
Planejamento, controle e monitoramento de projetos complexos de longa duração visando gerenciar fundos e
recursos, qualidade e tempo.
WF – WORKFLOW
Automatização de processos conforme regras e procedimentos pré-determinados.
IS – INDUSTRY SOLUTIONS
Combinação dos diversos módulos do R/3 com funcionalidades específicas da indústria: CPG / TELECON /
PETROQUÍMICA / QUÍMICA E FARMACÊUTICA / AUTOMOBILÍSTICA / ELETRO-ELETRÔNICA / SAÚDE.
10 Metodologia de Implantação do R/3
A referência para a Implantação de sistemas de Gestão Integrada (ERP) são os processos de negócio da empresa. Os Sistemas
mais avançados estruturam suas funções com base em processos de negócio e, muitas vezes, fornecem modelos de referência a
serem adotados pelas empresas que irão imcentror o sistema.
10.1 Fase 1 – Organização e Projeto Conceitual
Analisar necessidades
Organizar Projeto
Criar ambiente de teste
Treinar Equipe do Projeto
Definir Funções e Processos
Projetar Interfaces e extensões
PROJETO CONCEITUAL
10.2 Fase 2 – Detalhamento do Projeto e Implantação
Estabelecer:
Parâmetros globais
Estrutura da Organização
Dados básicos e mestres
Funções e Processos
Implementar Interfaces e extensões
Estabelecer
Processos e relatórios
Gerência de arquivamento
Gerência de autorizações
Executar TESTE FINAL
CONTROLADORIA 26 de 325
APLICAÇÃO
10.3 Fase 3 – Preparação da Produção
Preparar início da produção
Criar documentação para usuários (quem faz????)
Preparar ambiente de produção
Carga de dados
Treinar usuários
Estabelecer Administração do Sistema
Transferir dados para produção
Operação Assistida
PRODUÇÃO
10.4 Fase 4 – Operação Produtiva
Suportar Operação Produtiva
Otimizar o uso do sistema
10.5 Business Navigator – Reference Model
O Reference Model é uma ferramenta de implementação do R/3 de forma estruturada que descreve graficamente o escopo das
atividades dos componentes do R/3 e dos processos do negócio suportados por este sistema. O Business Navigator ensina como
implementar cada um dos métodos de Contabilidade de Custos.
11 Customizing – Guia de Implantação do SAP (IMG)
O guia de implementação para o Customizing do R/3 lista todas as atividades para a Implantação do R/3 bem como o controle e
a documentação de todo o projeto de Implantação.
O Customing pressupõe a criação de uma equipe (gerente e membros) para atuar no projeto. Os membros da equipe efetuam as
configurações do sistema e documentam os procedimentos de Implantação através da manutenção de notas e situações. O
gerente do projeto é responsável por:
Criar projetos de Customizing e visões do projeto
Definir o escopo do projeto
Especificar as datas de início e fim do projeto
Definir a equipe do projeto
Definir o idioma do projeto
Definir o status
Definir os tipos de documentação do projeto.
11.1 Opções Gerais (General Settings)
Nesta seção efetuam-se as configurações gerais do sistema válidas para todas as aplicações e necessárias para o processamento
das transações contábeis. Inclui as definições de países, codificação geográfica, moedas, unidade de medida, calendário, fuso
horário, definição de valores globais (invisível, ativo, inativo, etc.)
Dentro no módulo de CO podem ser definidos valores globais para:
Controladoria a nível de custos indiretos
Contabilidade de Classe de Custo
Tipos de Atividade
Índices Estatísticos
Contabilidade de Centro de Custo
Custeio baseado na atividade
CONTROLADORIA 27 de 325
Ordens de Custos indiretos
Processos de custos indiretos
Sistemas de Informação
Controladoria a nível custo de produto
Planejamento de Custo de Produto
Contabilidade de Objetos de custo
Cálculo de Custo real / Ledger (Razão) de Material
Sistema de Informação
Demonstração de resultados (Análise de Rentabilidade)
Estruturas
Dados mestre
Planejamento de Vendas e Resultado
Fluxo de valores reais
Sistema de Informação
Ferramentas
11.1.1 Países (Countries)
11.1.2 Geocoding
11.1.3 Moedas (Currencies)
Transação: OB08 – Entrar taxa de câmbio
Todas as moedas a serem usadas no sistema deverão estar cadastradas na tabela de moedas tendo um código e uma data de
validade atribuídos a ela. A maioria das moedas mundiais já estão cadastradas no R/3.
Para trabalhar com diferentes moedas, é preciso definir as taxas de câmbio (translation factors), ou seja, as cotações das moedas
para permitir a conversão dos valores. O R/3 permite o cadastramento de diferentes tipos de taxas (histórica, bank selling, bank
buying, média, etc.) usadas para valorização, conversão, tradução, planejamento, etc. O R/3 sempre irá tomar a cotação mas
recente para a conversão dos valores não exigindo que tenha sido cadastrada uma cotação para aquele dia especificamente. Isto
tanto podem ser benéfico do ponto de vista que não te obriga ter as cotações totalmente em dia. No entanto, caso a empresa
queira ou necessita trabalhar sempre com a cotação atualizada, terá de definir procedimentos manuais para garantir a correta
alimentações dos dados. As cotações atualizadas deverão ser informadas antes do início das movimentações do dia já que a
atualização de uma cotação só é considerada para os lançamentos efetuados após a lançamento da cotação.
Para garantir a coerência, é recomendado que se trabalhe sempre com a cotação defasada de um dia sendo que esta cotação
pode ser informada no final do dia anterior.
Não necessariamente será considerada a cotação da tabela para converter os lançamentos. No lançamento de um documento em
FI-AP, por exemplo, pode ser informada uma taxa de câmbio diferente da tabela para atender aos casos específicos de taxas
negociadas.
Num ambiente estável, as cotações seriam cadastradas uma só vez. O cadastramento de cotações dependente do tempo está
disponível a partir da versão 4.0A. Com regime de inflação, o cadastramento destas taxas pode ser bastante trabalhoso e o R/3
oferece ferramentas para minimizar estes lançamentos para cada tipo de taxa (uma por tipo):
Cotação inversa – definindo esta alternativa, sempre que for cadastrada a cotação da moeda 1 para a 2, o R/3 irá calcular a
cotação da moeda 2 para a moeda 1. É a ferramenta mais antiga é não está mais sendo muito usada.
Moeda base – associando uma moeda base a um tipo de taxa de câmibo (exchange rate type), será necessário apenas
cadastrar as cotações das outras moedas com a moeda base. O R/3 irá derivar as demais cotações a partir da base. A moeda
base somente pode ser usada em cotações médias. Até a versão 4.0A somente era possível definir uma moeda base por tipo
de taxa de câmbio. Se for necessário pode ser usado um derived exchange rate type para definir uma moeda base
diferente. Exemplo: um grupo de empresa tem como moeda base a moeda A. Mas para um determinada empresa, a moeda
base deve ser B. Assim, em todos os relacionamentos com a moeda B deve ser definido um derived exchange rate type que
tenha a moeda B como moeda base.
CONTROLADORIA 28 de 325
Exchange Rate Spreads – por spread entende-se a diferença entre a taxa média e as taxas de bank selling e bank buying.
Definindo esta variação, o sistema irá determinar as taxas a partir da média.
Cotação direta / indireta – A cotação direta é denominada price notation: quanto vale uma moeda estrangeira em relação à
moeda local. A cotação indireta é dita volume notation quantas unidades de moeda local por moeda estrangeira. O R/3 permite
trabalhar tanto com cotação direta quanto indireta. Para cada par de moeda é definido qual a notação padrão. O R/3 realça as
cotações que não estão seguindo o padrão. Como padrão, o R/3 define que uma cotação direta não tem nenhuma prefixo e uma
cotação indireta é precedida de uma barra “/”. Caso a empresa trabalhe com as duas cotações, recomenda-se definir um prefixo
para a cotação direta também “*” (asterisco) de forma a minimizar erros. Se a empresa trabalhar mais freqüentemente com
cotações indiretas, pode também definir um prefixo para a direta e excluir o prefixo para indireta.
A cotação é definida informando um valor e uma relação entre as moedas (ratio). O ratio é usada para moedas de baixo valor
aquisitivo. (exemplo: cruzeiro – dolar = cotação: 1,232 x 1000 ). Na parametrização da conta contábil em FI é definido o tipo
de taxa de câmbio a ser usado.
11.1.4 Unidade de Medida (Units of Mensurement)
11.1.5 Calendário (Calendar)
11.1.6 Time Zones (Fusos Horários)
11.1.7 Características de exibição de campos (Field Display Characteristics)
Os field display characteristic permite determinar preenchimentos padrões para alguns campos de forma a facilitar a entrada de
dados e minimizar erros. Pode ser definido a nível global ou de transação. Também pode ser definido se será ao não permitida a
alteração do valor e ainda se o valor será exibido. A nível global pode ser usado, por exemplo, quando só existe uma empresa.
O código é definido como padrão a nível geral. A nível global pode ser diferenciado também o domínio separando a empresa
“sender” da empresa “receiver” a nível de elemento de dados. A nível de transação, pode-se citar como exemplo a definição de
um único tipo de requisição de compra para a transação ME21. Também o campo pode ser suprimido ou bloqueado para
alterações. A nível de transação deve ser criada uma “Variante de transação”.
11.1.8 Variants to ajust help (SAP Library)
11.2 Estrutura do Empreendimento (Enterprise Structure)
A estrutura da empresa no R/3 é mapeada através de unidades organizacionais (Organizational Units). Ela pode ser definida de
forma bastante flexível permitindo, obter-se uma visão da empresa independentemente dos critérios legais. Na verdade, é
possível obter diferentes visões para um mesmo grupo empresarial: do ponto de vista fiscal, do ponto de vista de logística, do
ponto de venda de gerenciamento de custo ou de gerenciamento financeiro, etc.
Algumas unidades são específicas de uma determinada área, como é o caso da Organização de Vendas e outras são mais
genéricas como é o caso da Centro (Centro) que é válida tanto em MM como em PP (Logística). A centro corresponde a um
local físico, é uma unidade organizacional do ponto de vista de logística, sendo, portanto, usada em todos os módulos desta área
da empresa. Não tem uma vinculação direta com o CGC. É possível ter duas centros com o mesmo CGC e uma centro com
mais de um CGC. A divisão em centros pode ser usada para diferenciar preço médio (o material é valorizado por código e
centro), para separar material novos de recondicionados, para separar locais de produção de locais de distribuição. Outra
alternativa para cálculo separado de médio é pelo SPLIT VALUATION.
O nível mais alto da hierarquia são os Clients. Na verdade, o client corresponde a uma área de trabalho reservada que trabalho
de forma independente das outras, exceto por algumas poucas tabelas que são comuns a todos os clients (ex: tabela de idioma,
tabela de posting key, tabela de características de PA, tabela Access Sequence de SD). Resumindo, o client é uma separação
lógica da base de dados.
A relação entre Client e Company Codes, Company Codes e Plants e Plants e Storage Location (Depósito) é de 1:N. Assim,
uma centro só pode pertencer a uma empresa e uma storage location só pode pertencer a uma centro. O R/3 trabalha da seguinte
forma: primeiro cria-se as unidades e depois estabelece-se as associações entre elas. Isto permite a existência de
relacionamentos N:N, por exemplo, entre Organização de Vendas e Canais de Distribuição. O relacionamento entre empresas e
CONTROLADORIA 29 de 325
Unidades de Negócio (Business Area) também é N:N só que, neste caso, não existe nenhuma vinculação a nível cadastral. O
relacionamento é definido a cada transação. A associação só vai ser percebida na extração de informações. O controle de
estoque é separado por unidades de negócio.
A determinação das unidades organizacionais e o estabelecimento dos vínculos entre elas é uma etapa de trabalho essencial no
projeto. O número de unidades organizacionais não deve ser exagerado para não gerar problemas de performance, devendo ser
criadas somente as estruturas realmente necessária para o controle e extração de informações.
A escolha de uma estrutura de organização deve ser bem feita uma vez que alterá-la posteriormente exige um trabalho
exaustivo. Apenas alguns usuários devem ter autorização para atualizar os elementos organizacionais. Após encerrar o processo
de manutenção das unidades organizacionais, o acesso deve ser bloqueado para não serem efetuadas outras modificações.
As unidades organizacionais de cada área são:
11.2.1 Configurações específicas do país (Country-specific settings)
Esta função permite ativar as versões padrão do país liberadas pela SAP. (programa RSCICO02). A versão do país deve ser
instalada em uma cópia do client (mandante) 000 no sistema de teste. Somente após os testes as configurações devem ser
transportadas para o sistema de produção. Para isto, o client no qual a versão está sendo instalada deve ser configurado de
forma que as alterações do Customizing sejam gravadas automaticamente. Jamais instale a versão do país diretamente do
ambiente de produção. Para executar o programa, deve ser autorizado o objeto S_TABU_CLI.
Somente as unidades organizacionais padrões do SAP devem estar disponíveis no sistema e sem alterações. A empresa 0001
deve conter todas as configurações padrão de acordo com o plano de contas INT. As configurações para os diversões países
(que atendem as necessidades legais) estão contidas nos templates da empresa XX01 onde XX é o código da empresa. No
entanto, estes templates somente contêm algumas das configurações padrões para a empresa 0001, o que significa que não ela
não deve ser usada como uma empresa de produção. Ela deve ser usada única e exclusivamente com este programa. Algumas
das configurações do programa são: plano de contas, determinação de contas, esquema de cálculo de impostos, financial
statements, métodos de pagamento, plano de depreciação, classes de custos.
O programa integra as necessidades legais e de negócio dos templates sobrepondo os parâmetros específicos do país na empresa
0001, combinando a empresa com a Área de Contabilidade de Custos apropriada. Para países que usam o plano de contas INT,
a empresa 0001 e associada à Controlling Area 0001. Para os outros casos, a empresa 0001 é associada à Controlling Area
XX01.
11.2.2 Contabilidade Financeira (Financial Accounting)
11.2.2.1 Sociedade (Company)
Unidade organizacional para a qual é possível gerar demonstrativos contábeis de acordo com a legislação. Uma sociedade é
uma unidade organizacional que agrega as empresas de acordo com os requisitos da legislação comercial de cada país. No R/3,
todas as funções de consolidação da contabilidade financeira são efetuadas com base nas sociedades. Uma sociedade pode
abranger uma ou várias empresas.
Também é aceitável designar filiais juridicamente dependentes como “sociedades” e reuni-las na unidade jurídica com os meios
da consolidação.
É necessário que todas as empresas de uma sociedade trabalhem com o mesmo plano de contas e mesmos exercícios fiscais. As
moedas utilizadas podem ser diferentes.
O código tem 6 posições alfanuméricas.
11.2.2.2 Área De Controle De Créditos (Credit Control Area)
Unidade Organizacional que representa uma área de responsabilidade para monitorar e conceder crédito aos clientes. Ela pode
ser definida específica por empresa ou pode abranger várias empresas. Uma empresa, porém, só pode pertencer a uma área de
controle de crédito. As informações de crédito são disponibilizadas por cliente dentro de uma área de controle de crédito. O
SAP disponibiliza a área de controle de crédito padrão 0001.
CONTROLADORIA 30 de 325
11.2.2.2.1 Dados relevantes para SD
Atualização do crédito p/valor pendente ordem/remessa/DF
A atualização de crédito controla quando os valores da ordem pendente, da remessa em curso e do documento de faturamento
pendente devem ser atualizados. O valor da ordem pendente somente será atualizado para divisões de remessa que são
relevantes para o fornecimento.
O usuário poderá indicar os seguintes grupos de atualização a fim de atualizar as estatísticas relevantes para o crédito:
Atualização de crédito 000012
Ordem – aumenta o valor da ordem pendente com base em divisões de remessa relevantes para o fornecimento
Fornecimento – reduz o valor da ordem pendente com base em divisões de remessa relevantes para o fornecimento;
aumenta o valor de remessas em curso
Documento de faturamento – reduz o valor de remessas em curso; aumenta o valor do documento de faturamento
pendente
Documento FI – reduz o valor do documento de faturamento pendente; aumenta as partidas em aberto
Atualização de crédito 000015
Fornecimento – aumenta o valor de remessas em curso; aumenta o valor do docuemento de faturamento pendente
Documento FI – reduz o valor do documento de faturamento pendente; aumenta as partidas em aberto
Atualização de crédito 000018
Ordem – aumenta o valor de remessas em curso
Documento de faturamento – reduz o valor de remessas em curso; aumenta o valor do documento de faturamento
pendente
Documento FI – reduz o valor do documento de faturamento pendente; aumenta as partidas em aberto
Se uma operação não puder ser processada com a atualização de crédito desejada pelo usuário, o sitema determinará a
atualização de crédito seguinte. O usuário seleciona, por exemplo, a atualização de crédito 000012 que reduz o valor da ordem
pendente e aumenta o valor de remessas em curso no fornecimento. Se um item da ordem não for relevante para o
fornecimento, o sistema automaticamente determinará a atualização de crédito 000018 para este item. Esta atualização de
crédito aumenta o valor de remessas em curso a nível do item da ordem. O sistema utiliza a quantidade confirmada das divisões
de remessa relevantes para o fornecimento para atualizar o valor da ordem pendente.
11.2.2.3 Empresa (Company Code)
Menor unidade organizacional do ponto de vista da contabilidade financeira para emissão de relatórios externos (Balanço,
Apuração de Lucros e Perdas). Uma empresa deverá ser constituída de acordo com pontos de vista fiscais, comerciais e
contabilísticos. Regra geral, a empresa corresponde a uma sociedade juridicamente autônoma. A empresa também pode
representar um local de trabalho dependente no estrangeiro, quando for necessário à empresa se reportar ao exterior
(Reporting), na moeda do país.
Todos os lançamentos financeiros deverão, obrigatoriamente, estar vinculados a uma empresa. O código poderá ser derivado,
automaticamente, pelo sistema conforme parametrizações. A integração entre os módulos do R/3 e feita através da empresa
vinculando às unidades organizacionais dos outros módulos. Por exemplo, na entrada de um documento na contabilidade
financeira com uma classificação contábil da fatura de custos (centro de custo, ordem interna, etc.), o sistema utilizará o vínculo
definido pelo usuário para determinar uma Controlling Area (Área de Contabilidade de Custos – ACC) para a transferência de
dados para o CO (Controlling).
O usuário poderá instalar várias empresas em um mandante para poder administrar simultaneamente diferentes
“contabilidades”.
O código da empresa tem 4 posições alfanuméricas e deve ser único.
Na Implantação de uma empresa, o IMG (implementation Guide) sugere que seja feita uma cópia de uma das empresas padrões
que já vêem cadastradas e fazer as alterações necessárias, posteriormente. A cópia é recomendada mas não é obrigatória. Na
função de cópia de uma empresa são copiados:
CONTROLADORIA 31 de 325
A definição da empresa (código, nome ,cidade, país, moeda, idioma e endereço). O país define os procedimentos de
localização e também é importante nas transações de pagamentos e negociações. O R/3 suporta diferentes formatos para
endereços de correspondência no exterior. O idioma é importante para a criação dos textos automaticamente neste idioma
(exemplo: na emissão de cheques). As contas contábies são administradas na moeda da empresa (moeda local). As outras
moedas são consideradas externas (foreign). O sistema irá converter os lançamentos em moeda estrangeira para a moeda
da empresa;
Parâmetros globais (plano de contas, ano fiscal (definição), valores default para a empresa);
Tabelas do Customizing (approximadamente 315 tabelas);
Contas do Plano de Contas (opcional);
Determinação de contas – parametrizações contábeis para geração de lançamentos automáticos em FI pelo demais módulos
do R/3. De acordo com os diversos parâmetros de cada módulo, transações, são parametrizadas por FI. Em CO a
determinação de contas corresponde ao procedimento que determina as contas de ajuste para os lançamentos de conciliação
entre CO e FI manual ou automaticamente por meio de substituição.
No R/3 padrão está cadastrada a empresa 0001 com o plano de conta INT e sem especificações especiais de país. Para usar um
país que tenha country template, pode ser usado o programa de versão do país que copia as tabelas específicas do país na
empresa 0001. A cada cópia de empresa, o programa deve ser reprocessado. O programa customiza também as controlling
areas, plants, purchasing organizations, sales organizations, credit controls areas, financial management areas, etc..
A empresa 0001 não deve ser usada como a sua empresa produtiva porque ela é usada como a empresa destino no programa de
versão do país. Além disto, o programa só pode ser executado em uma nova instalação e não em uma instalação que já sofreu
um upgrade por que podem existir alterações de uma versão para outra.
11.2.2.4 Divisão (Business Area)
Agrupamento de empresas de uma sociedade de acordo com o negócio (segmento), tais como, linha de produto, subsidiária, etc.
para a qual pode ser efetuado um Balanço e uma Apuração de Lucros e Perdas. Normalmente, é classificada por
responsabilidade.
O usuário poderá estabelecer várias divisões em um mandante, que poderão ser classificadas contabilmente em todas as
empresas definidas nesse mandante. Ou seja, o relacionamento em divisão e empresa é N:N. Esta vinculação é feita a nível
transacional e não a nível cadastral como acontece na maior parte do relacionamentos entre as unidades organizacionais. Para
uma entrada consistente dos documentos é importante que as divisões tenham o mesmo significado em todas as empresas.
O código tem 4 posições alfanuméricas.
11.2.2.5 Divisão de Consolidação (Consolidation Business Area)
Além de permitir a consolidação de empresas, o R/3 também permite consolidar Business Area. Para isto, deve ser definida a
divisão que será usada para consolidar os dados das diversas divisões da empresa.
11.2.2.6 Área Funcional (Funcional Área)
Área dentro da sociedade que possui uma função específica (administrativa, comercial, distribuição, marketing, produto, etc.)
objetivando classificar o custo operacional por função.
11.2.2.7 Área de Administração Financeira (AAF – Financial Management Area)
Unidade Organizacional da Contabilidade Financeira que estrutura o empreendimento do ponto de vista da Fluxo de Caixa e da
Administração de Orçamento. O vínculo entre a AAF e as outras áreas é efetuada através da empresa. Por exemplo, se for
indicada uma classificação contábil da administração do orçamento ao editar um documento na contabilidade financeira (por
ex. item financeiro, centro financeiro), o sistema utiliza a empresa para determinar a AAF para a transferência de dados para a
administração do orçamento. As empresas de uma AAF devem trabalhar com a mesma moeda interna.
CONTROLADORIA 32 de 325
11.2.3 Controladoria – Controlling
11.2.3.1 Área de Contabilidade de Custo – Acc (Controllling Area)
É a mais alta unidade organizacional em CO. Agrupa diversos empresas (Company Code) de uma mesma sociedade ou de
várias sociedades para avaliar de forma mais sintética, a Contabilidade de Custos e Receitas. Todas os empresas de uma mesma
Área de Controle (ACC) devem usar o mesmo plano de contas, ter o mesmo número de períodos contábeis reais podendo variar
somente o número de períodos especiais. Podem trabalhar com moedas distintas. A moeda do grupo deve ser a moeda da ACC.
Obrigar que duas empresas trabalhem com o mesmo plano de contas não significa necessariamente que as duas empresas
tenham que trabalhar com as mesmas contas. As empresas deverão usar as mesmas contas operacionais, mas estas contas
podem ser vinculadas à contas específicas de cada país através da alternative account number field no cadastro de contas
contábeis.
Deve ser definido no cadastro da ACC, se ela terá somente uma empresa ou mais de uma (cross-company-code accounting).
Recomenda-se definir que será mais de uma mesmo que a ela só seja associada uma empresa para facilitar manutenções futuras.
No entanto, se definirmos cross-company-code-accounting, a moeda dos objetos de custo de CO obrigatoriamente será,
obrigatoriamente, igual à moeda da empresa.
Todas as transações de apropriação de custos internas referem-se somente a objetos pertencentes a uma mesma ACC, ou seja,
para alocar custos de um centro de custo para outro, os dois devem pertencer à mesma ACC. Note que estes centros de custo
podem pertencer a empresas distintas o que irá obrigar, posteriormente, a execução da reconciliação para acertar a
contabilidade financeira.
O código tem 4 posições alfanuméricas.
11.2.3.2 Empresa x Área de Contabilidade de Custos
Somente no caso de o usuário efetuar uma contabilidade de centro de custo abrangendo todas as empresas, é preciso atribuir as
empresas à área de contabilidade de custo explicitamente. Antes de poder efetuar a atribuição, porém, é preciso atualizar nos
dados mestre da ACC o código de controle de atribuição, o plano de contas e a variante de cálculo de custos bem como as
opções de moeda. O código do controle da atribuição influencia as demais opções. Através dele, é estipulada a atribuição de
empresa(s) para a ACC.
Código = "1" 1 Empresa 1 ACC – Esta opção se aplica aos casos em que cada empresa possui uma visão de
custos independente. A empresa, para a qual se pretende criar uma ACC análoga, já deve estar cadastrada com a
definição da moeda, plano de contas e variante de ano fiscal. O código da empresa deve ser igual ao da ACC. Neste
caso, a contabilidade financeira e a contabilidade de custos terão a mesma visão.
Código = "2" 1 Empresa N ACC – A Contabilidade de custos abrange várias empresas. Permite estipular, para a
ACC, uma moeda diferente da empresa. Todos os dados relevantes para a contabilidade de custos são agrupados em
uma ACC comum e encontram-se ali à disposição para apropriações e análises. A visão da contabilidade de custos e a
visão contábil financeira serão divergentes. Este processo apresenta vantagens quando, por exemplo, deve ser
executada uma contabilidade de custos comum para um empreendimento com diversas filiais que efetuam os seus
respectivos balanços independentemente. Neste caso, as variantes de ano fiscal das empresas deve ser o mesmo no que
ser refere ao número dos períodos contábeis e nos limites de períodos. Além disso, as empresas têm de utilizar o
mesmo plano de contas.
11.2.3.3 Área de Contabilidade de Custos x Área de Administração Financeira
Antes de Associar as Áreas da Contabilidade de Custos com a Área de Administração Financeira, primeiro, é preciso atribuir as
empresa ativas na Administração de Orçamento às Áreas de Administração Financeira e às Áreas de Contabilidade de Custos.
A atribuição só poderá ser modificada enquanto a Administração de Orçamento não estiver ativada.
Este vínculo pode gerar problemas de performance quando:
Houver vinculação entre Classificações Contábeis da Administração do Orçamento às Classificações Contábeis do
CO.
For trabalhar com Ordens e Projetos.
CONTROLADORIA 33 de 325
O controle de disponibilidade estiver ativo tanto na Administração de Orçamento como nas ordens e nos projetos. Para
a administração do orçamento é possível desativar o controle de disponibilidade na função: “Determinar parâmetros
dependentes do ano fiscal para a elaboração do orçamento”.
11.2.3.4 Área de Resultado (Área de Resultado)
Estruturação da organização de acordo com o mercado de vendas. Agrupa uma ou mais ACC para as quais se pretende executar
uma Demonstração de Resultados (Profitability Analysis). A moeda da Área de Resultado não precisa ser a mesma das ACC.
AR1 AR2
ACC1 ACC3ACC2 ACC4
EMP5EMP4EMP3EMP2EMP1 EMP6
Do ponto de vista técnico, a definição da Área de Resultado define a estrutura dos arquivos de segmentos e lançamentos (line
item) nos quais os sistema irá armazenar os dados já que serão criados um grupo distinto de tabelas para cada uma das Área de
Resultado definidas. O sistema automaticamente gera outros objetos relacionado com esta estrutura.
11.2.4 Logística
11.2.4.1 Nível de Avaliação (Valuation Level)
O nível de avaliação define o nível para o qual devem ser avaliados os estoques de material podendo ser a nível de Centro
(Centro) ou de Empresa. Se a empresa estiver trabalhando com Planejamento da produção (PP), Cálculo de custos de produto
(CO-PC) ou SAP Retail (sistema SAP para varejo) é obrigatório usar a nível de Centro. Para saber se o SAP Retail está ativo
em uma instalação, deve ser executado o programa GETSYSDEF que descreve a definição do sistema instalado.
O nível de avaliação definido aplica-se para todos os mandantes. Recomenda-se nível do centro. Uma vez definido, o nível de
avaliação não pode ser convertido de centro para empresa, ou vice-versa. Será necessária uma conversão de dados.
A seleção do nível de avaliação irá influenciar:
a atualização dos registros mestre de material - Visão da contabilidade financeira (principalmente do preço de
avaliação) no mestre de material por centro ou por empresa;
as contas do estoque do razão – Se a avaliação do material ocorrer a nível da empresa, todos os estoques do centro de
um material são administrados em uma conta de estoque conjunta para cada empresa. Caso contrário, os estoques de
material de cada centro podem ser administrados em uma conta própria. Caso vários centros desejem utilizar a
determinação de conta, eles poderão ser agrupados no customizing da Avaliação e classificação contábil na seção
Determinação de Contas.
as contas do Razão usadas nas transações de movimentação de materiais.
11.2.4.2 Centro (Plant)
É a unidade de controle central do ponto de vista de Planejamento e Controle da Produção e Adminitração de Materiais. Pode
representar um local de produção ou simplesmente um conjunto de depósitos de materiais em um mesmo local físico. Cada
plant pertence a uma única empresa.
CONTROLADORIA 34 de 325
11.2.4.3 Localização (Location)
No Componente IS-A-Rl (Returnable packging logistics) a localização representa o perceiro de negóciovinculado à troca de
emblagem retornável. A localização é sempre a localização vinculada à transação de retorno de embalagem que está sendo
gravada. Por exemplo, na entrada de material (goods receipt), a localização é o recipiente onde a mercadoria circula. Para PM, a
localização é o local dentro de um centro de manutenção no qual um objeto técnico está localizado fisicamente. Para APO
(Advanced Planner and Optimizer), a localização corresponde ao local físico ou lógico onde a quantidade de produtos ou
recursos são manuseados. Os tipos de localização existente são: centro, área de distribuição, depósito, cliente ou fornecedor.
As localizações são definidas dentro de um centro e permite classificá-las de acordo com um critério com a localização física.
Posteriormente as localizações serão associadas a ativos fixos (associação obrigatória), partes de equipamentos, localizações
funcionais, centros de trabalho e recursos/ferramentas de produção. Nenhum verificação é feita entre a localização do ativo em
AM e a localização do ativo em PM. O mesmo ocorre com os centros de trabalho em PP e PM.
As localizações são puramente informativas podendo ser usadas para estruturar um matchcode ou critério para emissão de
relatórios. Nenhuma funcionalidade pode ser obtida a partira das localizações em termos de hierarquia, etc.
11.2.4.4 Setor de Atividade (Division)
Para o IS-U-MD, o Setor de Atividade corresponde a uma chave interna da empresa para classificar os materiais. Um ou mais
setores podem ser associados a uma categoria de Setor de Atividade. Por exemplo, uma empresa utilitária pode dividir as
categorias de Setor de Atividade de água em água potável e água para lavar. Em SD, o Setor de Atividade corresponde a uma
unidade organizacional definida de acordo com as responsabilidades de vendas ou lucros para materiais e serviços
comercializáveis.
O Setor de Atividade é uma unidade organizacional de SD também requerida para a associação contábil com a Divisão para
transações de logística em FI. A divisão do material é determinada pelo Centro e Setor de Atividade (definidos no cadastro de
materiais). Para adaptar o escopo funcional de um Setor de Atividade das empresas, devem ser verificados os seguintes pontos:
Associar o Setor de Atividade para uma ou mais organização de vendas e um ou mais canais de distribuição;
Associar a divisão a um Setor de Atividade / Centro. Como na release 3.0, a divisão é determinada em MM a partir da
Setor de Atividade e área de avaliação.
O material é sempre associado a um único Setor de Atividade no mestre de materiais.
É possível informar dados para o material por Setor de Atividade para os clientes bem como condições e pricing.
Também podem ser criados vários cadastros de cliente e condições (elementos de precificação), que se aplicam a várias
Setores de Atividades, usando o Setor de Atividade Representativo.
Podem ser definidos escritórios de vendas por Setor de Atividade.
Podem ser definidos para cada tipo de documento de vendas que todos os itens irão pertencer a um mesmo Setor de
Atividade.
Os itens de uma remessa (delivery) ou de um documento de faturamento (biling document) podem pertencer a diferentes
setores de atividade.
O setor de atividade é usado como um critério de seleção para listar documentos de vendas e para worklist para remessas.
Pode ser definida uma impressora destino para mensagens diferentes para cada setor de atividade baseado no documento de
vendas.
Utilize o setor de atividade 01 como setor genérica se não for trabalhar com classifcação de setores.
CONTROLADORIA 35 de 325
11.2.5 Vendas e Distribuição (Sales and Distribution)
11.2.5.1 Organização de Vendas (Sales Organization)
É o elemento organizacional central que controla as condições de vendas para os clientes. Representa uma unidade de vendas
do ponto de vista legal. A Organização de Vendas pertence a uma empresa.
11.2.5.2 Canal de Distribuição (Distribution Channel)
É o elemento que descreve em qual canal as mercadorias e/ou serviços serão distribuídos para o cliente.
11.2.5.3 Escritório De Vendas (Sales Office)
11.2.5.4 Grupo De Vendedores (Sales Group)
11.2.6 Administração de Materiais (Material Management)
11.2.6.1 Depósitos (Storage Location)
Área de armazenamento de material de gerenciamento independente dentro de um centro (Administração de Estoques).
11.2.6.2 Organização de Compras (Purchasing Organization)
Responsável por todo o processo de compras (requisições de cotações, ordens de compras). Uma Organização de Compras
pode ser associada a uma empresa, a várias empresas ou a nenhuma empresa sendo o vínculo estabelecido através do Centro
(Plant) nas transações de aquisição para efeitos legais. Mantém informações relevantes dos fornecedores e dos preços
permitindo uma aquisição eficiente de materiais.
CONTROLADORIA 36 de 325
11.2.7 Logistics Execution (Expedição)
11.2.7.1 Sistema De Depósito (Warehouse Number)
11.2.7.2 Local De Expedição (Shipping Point)
11.2.7.3 Carga (Loading Point)
11.2.7.4 Organização De Transporte (Transportation Planning Point)
11.2.8 Manutenção (Plant Maintenance)
11.2.8.1 Centro de Planejamento de Manutenção (Maintenance Planning Plant)
11.2.9 Recursos Humanos
11.2.9.1 Área de Recursos Humanos (Personnel Areas)
11.2.9.2 Sub-Área de Recursos Humanos (Personnel Sub-Areas)
11.2.9.3 Grupo de Empregados (Employee Groups)
11.2.9.4 Sub-Grupo de Empregados (Employee Sub-Groups)
11.3 Componentes válidos para todas as aplicações (Cross-Aplication Components)
Corresponde à manutenção dos cadastros gerais (para todos os módulos), tais como, mensagem, administração dos documentos
(numeração, tipos, arquivos, transferências, etc.), administração de autorizações, ferramentas de importação de dados),
configurações dos subsistemas, folhas de horas de trabalho, nota fiscal, CFO, Filiais, Índices de bancos, parceiros de negócio,
transferência de dados externos, processos empresariais ALE (Aplication Link Enabling)
11.3.1 Administração de Documentos – DMS (Document Management System)
Definir os intervalos de numeração de documentos. Podem ser internos (numerados automaticamente pelo sistema) ou
externos (informado pelo usuário a cada lançamento). Não pode haver sobreposição de intervalos. Se for definido um
“número” alfanumérico, o sistema não irá verificar nenhum intervalo a menos que esteja sendo usado o USER EXIT.
User Exit – ferramenta do ABAP – Workbench (BC-DWB) que indica o ponto do programa SAP que irá chamar um
programa específico do cliente. Diferentemente das CUSTOMER EXIT, permite ao desenvolvedores acessar os
CONTROLADORIA 37 de 325
componentes de programas e objetos de dados do sistema padrão. As USER EXIT precisam ser revisadas nas mudanças
de versão. A User Exit pode usar includes ou tables (acessadas no Customazing).
Customer Exit são melhorias (enhancements) predefinidas no SAP para utilizações específicas. São módulos pré-
implementados no SAP (empty modification modules). O SAP gera as Customers Exit com a transaction SMOD. A partir
daí, os clientes podem usar a transaction CMOD para selecionar as otimizações desejadas e associá-las aos enhancement
projects, editar os componentes e ativar os projetos relevantes. A vantagem é que estas exits não precisam ser revisadas
em mudanças de versão.
Definir as configurações por tipo de documento (descrições por idioma, status dos documentos e sua descrição, links com
objetos e sua descrição), transporte da origem para o ALE (Aplication Link Enabling). O ALE é uma ferramenta de
integração (CA-BFA-ALE) que se refere à criação e operação de aplicações distribuídas de forma a garantir a integridade
dos dados via comunicações síncronas e assíncronas.
Maintain Key Fields – No SAP informações dos documentos estão vinculados com vários outros objetos do SAP cujos
campos chaves já foram definidos. Para criar novos vínculos é preciso dar manutenção nestes key fields.
11.3.2 Sistema de Classificação (Classification System)
11.3.3 Folhas de Horas de Trabalho
Com a folha de horas de trabalho é possível entrar as jornadas de trabalho pessoais válidas para vários componentes.
Uma condição para a entrada pessoal, é a de criar nºs pessoais para todos os empregados relacionados com o sistema SAP. Para
isso, recorrer às funções do componente administração de pessoal . Todas as ações necessárias neste quadro, são exibidas se
um IMG do projeto for criado para a folha de horas de trabalho.
Componentes essenciais para a atualização de dados mestre de pessoal são:
1. Entrada de um mini registro mestre de pessoal
Esta entrada é facilitada através da oferta de uma medida especial para a criação de nºs pessoais para a utilização da folha
de horas de trabalho.
Nesta medida são agrupados todos os dados relevantes para o mini registro mestre de pessoal.
2. Determinação da atribuição organizacional
Um nº pessoal em HR deve ser atribuído a determinadas unidadades organizacionais. Para atualização destas unidades
podem ser aceitas as opções standard, caso não existam outros requisitos para uma atribuição organizacional.
3. Determinação de autorizações
Por motivos de segurança, os dados pessoais devem ser protegidos. Assim, a folha de horas de trabalho utiliza à definição
do sistema de autorizações HR, que evita o acesso não autorizado a dados pessoais. Aqui pode ser definido em detalhe as
pessoas que obtêm autorizações para exibir, atualizar e aprovar dados.
Para mais informações relativas à atualização de autorizações, consultar a documentação on-line com a palavra
autorizações.
Para a atualização de autorizações pessoais, são necessárias verificações de autorização especiais. Assim, a definição do
sistema de autorizações da folha de horas de trabalho recorre à definição do sistema de autorizações do gerenciamento de
recursos humanos. Estas autorizações são então atualizadas no quadro da Administração de pessoal nas seguintes etapas:
Atualizar comutador principal de autorização
Atualizar perfis
Instalar autorizações para nºs pessoais
Na etapa seguinte Atualizar autorizações são atribuídos os grupos de autorização criados no quadro do customizing da
Administração de pessoal à folha de horas de trabalho.
11.3.4 Processos Empresariais ALE definidos
SAP fornece processos empresariais ALE predefinidos.
Estes podem ser aproveitados para os objetivos do usuário, que este terá de configurar.
Uma série destes processos empresariais ALE pode ser configurada através deste guia de implementação.
CONTROLADORIA 38 de 325
Na Biblioteca de processos empresariais ALE encontram-se todos os processos empresarias ALE com uma descrição
detalhada (Ajuda -> Biblioteca SAP -> Componentes válidos para várias aplicações -> Business Framework Architecture).
Pode ser utilizada a modelagem de um modelo SAP. Deste modo é atualizado automaticamente o modelo de distribuição.
Contudo, o modelo de distribuição só pode ser atualizado manualmente, sem utilizar um modelo SAP.
Nas descrições dos processos empresariais ALE são encontradas referências às ferramentas disponíveis.
Estas ferramentas podem ser encontradas no guia de implementação sob Base -> Distribuição (ALE).
Instalar administração de usuário central
Em uma associação R/3 existem vários sistemas com vários mandantes. Os mesmos registros mestre do usuário devem ser
sempre atualizados em cada mandante.
Para evitar uma atualização múltipla dos registros mestre de usuário, esta atualização é executada em um sistema central.
11.3.5 Transferência Inicial de Dados
O workbench de transferência de dados é uma transação centralizada para transferência de dados de um sistema anterior para o
sistema SAP. A transação disponibiliza as ferramentas necessárias e o acesso aos programas standard para execução da
transferência de dados.
11.3.6 Ferramenta CATT
11.3.6.1 Integrar ferramenta de teste externa
Esta ferramenta permite configurmar a utilização de qualquer ferramenta de teste externa de CATT do sistema SAP. A
ferramenta de teste tem de suportar a interface externa de CATT no sistema SAP.
Para utilização desta ferramenta é necessária a instalação de uma ferramenta de teste externa, a qual utiliza a interface standard
desktop CATT da SAP. As funções CATT do sistema SAP não são limitadas de forma alguma, à exceção da utilização da
ferramenta de teste externa. Para a atualização, é necessário o grupo de autorização STAT (objeto de autorização
S_TABU_DIS).
As opções de customizing dependem das indicações do fabricante da ferramenta de teste externa. É sempre necessário que
todos os campos da tabela de customizing sejam atualizados, caso a ferramenta de teste externa deva ser utilizada.
Exemplos:
O primeiro exemplo exibe uma opção de customizing por usuário para o usuário SAP "Modelo01". Se este executar um módulo
de teste CATT no formato da ferramenta de teste externa do fabricante "Company", o componente ActiveX é utilizado com a
ID de programa "Company.CompanyCtrl.1" como interface. O módulo de teste CATT externo tem a chave "CP" para distinguir
os formatos de diferentes fabricantes.
Nome do usuário "Modelo01"
Contole de usuário "Y"
ActiveX ProgID "Company.CompanyCtrl.1"
Nome do fabricante "Company"
Código do fabricante "CP"
O segundo exemplo exibe uma opção de customizing geral. Neste caso, é sempre utilizada, independentemente do usuário que
executa o módulo de teste CATT, a ferramenta de teste do fabricante "Company", caso exista um módulo de teste CATT
externo com o fabricante "CP". Tal se obtém através da entrada "N" no campo controle de usuário. A entrada para o nome do
usuário tem de ser um espaço em branco.
Nome do usuário " "
Controle de usuário "N"
ActiveX_ProgID "Company.CompanyCtrl.1"
CONTROLADORIA 39 de 325
Nome do fabricante "Company"
Código do fabricante "CP"
Recomendação: a instalação só é necessária caso os componentes, que decorrem dentro e fora do sistema SAP, devam ser
testados. A estes pertencem, por exemplo, os componentes de aplicação Internet da SAP.
Atividades
No diálogo de atualização do customizing, é necessário indicar o seguinte:
Nome do usuário: O usuário no sistema SAP que executa o teste, ou um espaço em branco e uma entrada "N" no campo
Controle de usuário.
Controle de usuário: indica se o nome do usuário SAP é relevante para o trabalho com uma determinada ferramenta de teste
externa (neste caso, inscrever no campo "Y"). Se for utilizada a mesma ferramenta de teste para todos os usuários SAP,
inscrever "N". Em qualquer dos casos, é necessário inscrever "Y" ou "N".
ActiveX ProgID: A ID de programa do componente ActiveX, a qual é utilizada pela interface desktop CATT no sistema SAP.
O componente ActiveX é sempre um elemento da instalação da ferramenta de teste externa.
Nome do fabricante: O nome do fabricante da ferramenta de teste externa. É assim possível modificar o nome do botão no
diálogo de atualização SAP para os módulos CATT do tipo X.
Código do fabricante: Um código de dois caracteres para o nome da ferramenta de teste externa, o qual é utilizado como chave
para a distinção de módulos de teste CATT. O código é exibido juntamente com o nome do módulo de teste externo na lista de
file interna no sistema SAP.
Outras observações
As opções de customizing são dependentes de mandante, de modo a garantir a utilização de ferramentas de teste externas de
diversos fabricantes em diferentes mandantes.
Caso as opções de customizing dependentes de usuário (em que o campo Controle de usuário tem a entrada "Y") e
independentes de usuário (em que o campo Controle de usuário tem a entrada "N") estejam atualizadas, as opções dependentes
de usuário estão sempre ativas ao se encontrarem ajustadas ao usuário que executa ou processa o módulo de teste CATT.
A tabela de customizing utilizada para este fim tem o nome "CATCU".
11.3.7 Serviços Internet/Intranet
11.4 Procedimento para melhor performance
A marcação para eliminação de uma ordem reduz o tempo de Reavaliação de ordens, Cálculo de WIP, Cálculo de Desvios e
Liquidação. Para reduzir o tempo de compactação (geração da sumarização de ordens) é preciso alterar o Esquema de Status de
seleção para desprezar as ordens com este status.
Para ativar a administração geral de status para ordens internas deve seratribuído o perfil de status a ser utilizado ao tipo de
ordem. Esse tipo de administração de status é recomendado se o usuário desejar obter um controle com o status de aplicação.
11.4.1.1 Status
O estado de processamento atual de um objeto é documentado por um ou mais status. Um status é um código que informa que
um determinado estado foi atingido (por exemplo, "A ordem foi liberada") e influencia o número de transações contábeis que
podem ser executadas para o objeto.
A execução de uma operação contábil pode, por sua vez, definir ou eliminar um ou mais status para o objeto especificado. A
interação entre o status e a operação pode ser ilustrada da seguinte maneira. É possível definir qualquer quantidade de status
para um objeto.
Um status pode ser exibido como um texto com 30 caracteres ou uma sigla com 4 caracteres. As duas variações de exibição
podem ser traduzidas para idiomas diferentes. O status ativo de um objeto pode ser exibido em forma de lista ou em uma linha
de status. A linha de status pode conter no máximo 8 status. O perfil de status é utilizado para definir a posição em que o status
da aplicação é exibido nessas linhas. Vários status podem ser emitidos na mesma posição. A coluna Prioridade do perfil do
CONTROLADORIA 40 de 325
status determina o status realmente exibido e a exibição em lista mostra todos os status ativos (dispostos de acordo com a
posição e a prioridade).
Um status pode estar ativo ou inativo. Ele está ativo quando está atualmente definido para um objeto. Ele está inativo quando
nunca foi ativado ou estava ativo, mas já foi desativado.
Um status pode permitir uma transação contábil, emitindo ou não um aviso ou proibir uma transação contábil. Quando uma
transação é permitida com um aviso para um determinado objeto, o sistema emite a mensagem de aviso durante a execução da
transação contábil. É possível ignorar o aviso e continuar a transação contábil. Se, por exemplo, um usuário deseja marcar uma
ordem liberada para eliminação. No entanto, a ordem ainda não atingiu o status Encerrada. Nesse caso, o sistema primeiro
emite um aviso de que a ordem ainda não foi encerrada.
Para executar uma operação contábil, pelo menos um status ativo deve permitir a transação contábil e nenhum dos status ativos
pode proibir a transação contábil.
A administração geral de status SAP distingue entre status do sistema e status do usuário.
Status do sistema O status do sistema é um status definido pelo sistema para informar o usuário sobre a execução de uma certa
função em um objeto. Só é possível influenciar esse status ao executar outra transação contábil que provoca a modificação do
status. Ao liberar uma ordem, por exemplo, o sistema define automaticamente o status do sistema Liberada.
Status do usuário É possível uma maior diferenciação do status do sistema existente através da criação dos status do usuário.
O status do usuário é definido em um perfil de status que é criado para cada tipo de ordem no Customizing. É possível definir e
ativar qualquer quantidade de status do usuário.
Em uma ordem de produção, é possível definir simultaneamente os status Liberado, Cálc.previs.custos efetuado, Imprimida e
Confirmada. O status do sistema e o status do usuário influenciam as transações contábeis da mesma maneira.
11.4.1.2 Status do Usuário
Com os status de usuário, o usuário pode restringir ainda mais as operações contábeis permitidas para o status do sistema atual.
É possível criar o status necessário de usuário dentro de sua divisão, ao utilizar a função adequada de customizing e entrá-lo nos
perfis de status. O perfil de status é atribuído ao(s) tipo(s) de ordem(ns) relevante(s).
O usuário pode definir e eliminar o status de usuário definido no sistema, desde que tenha autorização para fazê-lo. O usuário
descobre como exibir informações de status e as transações admitidas e proibidas em Exibição de informações de status e
operações admitidas..
O usuário descobre como exibir uma síntese de todos os status ativos em Exibição de uma síntese geral de status ativos.
O processo de modificação de um pedido de modificação e dos objetos relacionados a ele é controlado pelo status de
sistema definido internamente. Um status de usuário suplementar dá ao usuário mais controle sobre esse processo de
modificação. Esse status de usuário pode ser atualizado na estrutura do esquema de status definido (rede de status) através
do processamento do pedido ou objeto de modificação.
O usuário só pode atualizar um status de usuário a partir de um pedido ou ordem de modificação se um status de usuário estiver
definido para o tipo de modificação selecionado. O usuário pode definir status de usuários no Customizing de Controle de
Modificações sob Definir tipos de modificação.
O status de usuário para o registro mestre de modificação e para o objeto de modificação é atualizado em telas diferentes:
Para atualizar o status de usuário de um registro mestre de modificação, ir para a tela Modificar cabeçalho (Saltar ®
Modificar cabeçalho).
Para atualizar o status de usuário de um objeto de modificação, ir para a tela de detalhes do registro de administração de
objeto (Saltar ® Síntese de objetos ® <objeto de modificação> ® Tela de detalhes).
O usuário pode utilizar o status de usuário específico da empresa para controlar o fluxo do processo das modificações. Quando
o usuário processa um registro mestre de modificação, o sistema determina quais status de usuário são suportados na situação
atual.
O fluxo de processo é controlado separadamente para o cabeçalho de modificação e os objetos de modificação:
O status de usuário do cabeçalho de modificação controla as modificações do registro mestre de modificação (por exemplo,
CHG-01).
CONTROLADORIA 41 de 325
O status de usuário dos objetos de modificação controla as modificações dos registros de administração de objeto
individuais (por exemplo, Lista técnica do material MA-1, Centro 0001, Utilização 1).
OBS: Não há ligação entre os status de usuário de diferentes objetos de modificação para um registro mestre de modificação.
Também não há ligação entre esse status de usuário e o status de usuário do cabeçalho de modificação. O sistema não verifica o
status de outros objetos quando o usuário define um status de usuário.
Para usar o status de usuário a fim de controlar a modificação do cabeçalho ou objetos de modificação, atualizar um esquema
de status no mestre de modificação.
11.4.1.3 Perfil de status
Um perfil de status contém uma quantidade de status de usuários e de normas definidas pelo usuário. Os perfis de status são
definidos para cada tipo de ordem no Customizing. O perfil do status permite
definir o status do usuário, documentar as funções deste status (texto descritivo) e atribuir um número ao status
determinando a seqüência esperada do fluxo de status do usuário;
definir um status inicial (feito automaticamente quando um objeto é criado);
determinar a definição automática de um status do usuário ao executar uma transação contábil.
permitir ou proibir a execução de transações contábeis se um status estiver ativo.
Um status do usuário sem um número de status pode ser definido ou eliminado a qualquer momento, independentemente de já
haver outros status de usuário ativos. No entanto, somente um status do usuário com um número de status pode estar ativo em
um determinado momento. Ao ativar outro status do usuário com um número de status, o status do usuário anterior é anulado
automaticamente.
Ao atribuir um número a um status do usuário, é necessário especificar limite inferior e superior especificando o intervalo a
partir do qual os status do usuário posteriores podem ser selecionados.
Exemplo: O usuário deseja utilizar o status do usuário para supervisionar as etapas individuais durante a construção de um
edifício. Criar os seguintes status do usuário em um perfil de status:
Perfil de status
N.
status
Status Texto breve N. status
mínimo
N. status
máximo
10 PLAN Planejamento 10 20
20 APRV Aprovação do planejamento 10 30
30 CNST Construção 30 40
40 HDVR Entrega 30 50
50 CMPL Encerrado 50 50
Esses status são geralmente processados em seqüência de acordo com os números de status. Neste exemplo, seria impossível
passar diretamente do status PLAN para o status CNST pois a partir do número de status 10, só é possível passar para o número
de status 20 APRV. Da mesma forma, após atingir o status CNST, é impossível retornar aos status PLAN ou APRV.
11.4.2 Esquema de status
Customizing Produção Controle da Produção Ordens (BS02) Definir Esquema de Status
É possível utilizar um esquema de status específico da empresa para controlar o processo de modificação (registro mestre de
modificação ou objetos de modificação). O usuário define esquemas de status ao selecionar Definir esquemas de status no
Customizing de Controle de Modificações. O esquema de status é atribuído a um tipo de modificação no Customizing de
Controle de Modificações, etapa Definir tipos de modificação.
O esquema de status é atribuído a um tipo de objeto. Essa atribuição determina se o esquema é definido para registros mestre
de modificação ou objetos de modificação. Os seguintes tipos de objeto são relevantes para o Controle de Modificações:
Registro mestre de modificação. Com esse esquema de status, que é definido para o registro mestre de modificação, o
usuário pode processar apenas o cabeçalho de modificação.
CONTROLADORIA 42 de 325
Objetos. Com esse esquema de status, o usuário pode processar apenas objetos de modificação.
O usuário pode definir status de usuários para o esquema de status. É possível atribuir operações contábeis para cada status de
usuário e definir dependências para ele na forma de uma rede de status. Em qualquer situação de processamento, é possível
selecionar o status desejado entre os status permitidos atualmente. O usuário pode exibir os status permitidos usando a função
de entradas possíveis.
OBS: No Customizing, o usuário pode definir um esquema de status que seja válido para o cabeçalho de modificação e os
objetos de modificação.
O esquema de status representa uma rede de status. Nessa rede, diferentes status estão conectados entre si. Em qualquer
situação de processamento, o usuário só pode definir um status que seja permitido nessa situação. O usuário pode exibir o
último com a função de entradas possíveis.
11.4.3 Administração de status
O sistema disponibiliza administração de status para processamento de medidas de investimento (elementos PEP e ordens).
Através da administração de status, o usuário pode definir suas próprias opções de status além daquelas predefinidas no sistema
(tais como criado, solicitado e assim sucessivamente).
Na prática empresarial em geral, freqüentemente é necessária uma subdivisão detalhada do ciclo da ordem baseada nas
transações que ocorrem na ordem. Erro! Indicador não definido.Se tomarmos uma ordem de feira e exposição como
exemplo: as transações contábeis para essa ordem são exibidas abaixo.
Existem várias transações no status do sistema Liberado. O lançamento de custos de preparação (faturas externas) e o
lançamento de custos de execução. O lançamento dos custos pós-produção no status Concluída em termos técnicos também
consiste em faturas externas.
Status Transações contábeis
Criada Planejamento
Liberada Lançamento de custos de preparação
Aluguel do balcão
Taxas da feira
Liberada Lançamento de custos de execução
Emissões de material
Atividades internas
Serviços externos
Concluída em termos técnicos Lançamento de custos pós-produção
Contas de hotel
Despesas de viagem
Apropriação de custos
Encerrada Nenhuma
É provável que o usuário queira limitar as transações contábeis a um certo período. Por exemplo, o lançamento de faturas
externas somente seria possível antes que os custos da ordem sejam apropriados. Ou o usuário não permitiria quaisquer
atividades internas adicionais após a ordem estar concluída em termos técnicos.
É possível conseguir isto através da subdivisão do status Liberada e atribuição das transações ao local onde elas são permitidas.
É possível subdividir um status do sistema em mais de um status. As transações são em seguida, atribuídas ao status individual.
Ao contrário da administração geral de status SAP, os status do sistema na administração de status de ordem não são
modificados através de uma função. Os status do sistema estão intimamente ligados ao status da ordem e são automaticamente
atualizados durante uma modificação de status.
11.4.3.1 Grupos de transações contábeis
É possível definir grupos de transações contábeis no menu de configuração através da reunião de várias transações em um
grupo. As transações de uma feira, por exemplo, podem consistir nas seguintes ações:
CONTROLADORIA 43 de 325
Planejamento de custos primários
Planejamento de aplicação de sobretaxa de custos indiretos
Lançamento de faturas externas
Retiradas de material
Alocação de atividades internas
Lançamentos de sobretaxas de custos indiretos aplicadas
Apropriação de custos
É possível utilizar essas transações para formar grupos de transações, por exemplo:
Planejamento de custos
Lançamentos de custos de preparação (faturas externas)
Lançamento de custos de execução (atividades internas, saídas de material, sobretaxas de custos indiretos)
Lançamento de custos pós-produção (somente faturas externas)
Apropriação de custos
Em seguida, o usuário pode utilizar esses grupos para definir as operações permitidas e proibidas em períodos
determinados:
Se uma operação estiver contida em um grupo de transações atribuído a um status ativo, ela é permitida para a ordem. Se uma
transação não estiver atribuída a um status, ela é proibida nesse status.
11.4.3.2 Grupos de bloqueio
Para proibir transações para ordens individuais, também é preciso definir essas transações como um grupo que pode, em
seguida, ser gravado na ordem como um grupo de bloqueio.
Um grupo de bloqueio pode ser idêntico ao grupo de transações permitido atualmente. Ele pode consistir em apenas parte das
transações do grupo de transações permitido. O grupo de bloqueio limita as transações permitidas.
A administração de status de ordem determina, por exemplo:
Qual status é default do sistema ao abrir a ordem.
Quais transações são permitidas ou proibidas em um determinado status (uma operação somente é permitida quando
pertence ao grupo de transações do status da ordem e não é proibida pelo status do sistema).
Se e quando os documentos de planejamento são escritos.
Quais são os atributos dos campos da tela durante a atualização dos dados mestre no status determinado.
Quando é possível marcar a ordem para eliminação.
O gráfico a seguir mostra uma síntese de status para ordens de feiras. Neste exemplo, são definidos seis status (de 10 a 60) para
o tipo de ordem.
As colunas têm o seguinte conteúdo:
Status da ordem As primeiras duas colunas da esquerda para a direita contêm o número do status e uma
breve descrição.
LSt, Hst (status mais baixo, Essas duas colunas determinam como é possível modificar o status na ordem. O
CONTROLADORIA 44 de 325
status mais alto) próximo exemplo oferece uma descrição detalhada.
Crt, Rel, Cmp, Cls (criada,
liberada, concluída em termos
técnicos, encerrada)
Essas quatro colunas contêm campos de seleção para os vários status do sistema. Para
atribuir o status de ordem a um status do sistema, marcar a coluna apropriada. Ao fazer
isto, é necessário seguir a seqüência da esquerda para a direita. Também é necessário
manter a seqüência de status numericamente crescente.
TranGrp (grupo de
transações)
Essa coluna contém o grupo de transações permitido para cada status respectivo.
PlD (documentos de
planejamento)
Marcar aqui se deseja registrar modificações de planejamento nesse status. Então o
sistema escreve partidas individuais, que podem ser exibidas, para cada modificação no
planejamento da ordem. O grupo de transações permitidas também deve incluir ações de
planejamento. Caso contrário, não é possível planejar e o código não tem efeito.
Dst (status default) Marcar o status default nessa coluna. Esse é o status que as ordens desse tipo devem ter
quando criadas. Geralmente é o status com o número mais baixo. O status default é
apenas um valor default. É possível sobregravar esse status caso necessário.
O exemplo seguinte ilustra como a administração de status pode afetar uma ordem. Utilizamos o mesmo exemplo exibido
anteriormente.
O usuário planejou a ordem no status 10 e deseja agora liberá-la.
A coluna StM mostra que o usuário pode definir a ordem somente no status 20 (custos de preparação). Ele modifica o status
diretamente na ordem para 20.
Isso causa o seguinte:
O usuário modificou a fase para Liberada ao mesmo tempo
que a data Liberada foi definida automaticamente na ordem
Agora é possível lançar as faturas externas para os custos de preparação.
Se agora, por exemplo, desejar retornar ao status do planejamento, o que é permitido de acordo com o LSt (status mais baixo =
10), o sistema define a data Liberada.
Do status 20, é possível definir o status 30, onde todos os lançamentos reais são permitidos (grupo de transações TUDO). Se
fizer qualquer modificação no planejamento agora, ela será registrada nos documentos de planejamento de acordo com a coluna
PID.
Se o usuário não esperar por custos pós-produção, pode definir o status 50 a partir do status 30, sem passar pelo status 40. Ao
mesmo tempo, o usuário modificou novamente o status do sistema, o que também define a data concluída em termos técnicos.
Agora é possível apropriar a ordem.
Em seguida, o usuário percebe que um dos funcionários ainda não apresentou as despesas de viagem. Como isto não pode ser
lançado no status 50, porque este permite somente a apropriação de custos, é necessário anular o status na ordem novamente.
O status mais baixo (Lst) determina que só é possível voltar até o status 40 a partir do status de apropriação de custos. O
sistema registra o status mais alto que a ordem atingiu até esse ponto. O status mais baixo ao qual se pode retornar, portanto,
permanece sempre o mesmo. Assim, é impossível retornar do status 40 para o status 30, embora, de acordo com LSt , o status
40 normalmente permita esse retorno.
Após lançar os custos pós-produção, é possível passar ao status 50 de novo e apropriar a ordem.
Logo que os custos da ordem são completamente apropriados, é possível definir o código de eliminação, já que essa coluna está
marcada para o status 50.
Também é possível definir a ordem para o status 60 após a apropriação de custos. Conforme indicado nas colunas LSt e HSt ,
não é mais possível fazer qualquer modificação de status.
O usuário não pode mais lançar na ordem neste ponto. No entanto, ele ainda pode utilizá-la para avaliações no sistema de
informações.
CONTROLADORIA 45 de 325
11.4.3.3 Conjunto de funções
O usuário normalmente necessita de administração de status para controlar os aspectos organizacionais de planejamento e de
elaboração de orçamentos de programas de investimentos. Os itens do programa de investimentos, portanto, podem utilizar as
funções genéricas de administração de status do R/3 (vide o Guia de implementação: Programas de investimentos ® Dados
mestre). Com a definição dos status adequados dos usuários, é possível certificar-se de que determinadas ações (tais como a
elaboração do orçamento) só sejam executadas quando o item do programa apresentar um determinado status. É possível
também ligar a mudança de status a uma autorização. Dessa forma o usuário garante que as modificações de status só possam
ser feitas pelos responsáveis pela tomada de decisão no empreendimento.
11.4.3.4 Perfil de seleção de status para Administração de Investimentos
É possível também perfis de seleção de status em Customizing de IM definir (em Sistema de informação). Um perfil de seleção
de status descreve uma determinada condição do sistema e/ou do usuário. O usuário pode entrar um perfil de seleção de status
nas seguintes funções:
Mudança de exercício
Rollup de valores planejados de medidas de investimento
Nos relatórios standard no sistema de informação
O sistema seleciona apenas os itens do programa ou as medidas de investimento com status descrito no perfil de seleção de
status. O usuário pode, por exemplo, optar por fazer um relatório só das medidas de investimento já lançadas.
12 Introdução a Controladoria
12.1 Diferença entre Contabilidade Financeira (Geral) e de Custos
A Contabilidade Financeira é oriunda da era Mercantilista assim como a Demonstração de Resultados. Com o surgimento das
indústrias surge a necessidade de se mensurar monetariamente os estoques e o resultado. Com o distanciamento entre as
empresas e as entidades financeiras surge a necessidade de se padronizar os demonstrativos contábeis pela Auditoria Externa
dando origem aos princípios básicos da Contabilidade de Custos. Ao contrário da Contabilidade Financeira, a Contabilidade de
Custos necessita de quantificações físicas para todos os valores monetários.
A Contabilidade de Custos tem duas funções básicas:
Controle – fornecer dados para o estabelecimento de padrões, orçamentos e outras formas de previsão e, posteriormente,
acompanhar efetivamente o acontecido para comparação.
Tomada de Decisões – alimentação de informações sobre valores relevantes que dizem respeito às conseqüências de curto
e longo prazo sobre medidas de corte de produtos, fixação de preços, opções de compra ou fabricação, etc..
O R/3 faz uma distinção clara entre a Contabilidade Interna e Externa de acordo com a sua finalidade. A Contabilidade Externa
está voltada para o atendimento das necessidades de entidades fora da empresa como bancos, instituições governamentais,
companhias de seguro, etc. Em função disto, ela atende aos requisitos legais impostos pela legislação. Paralelamente, a empresa
tem a necessidade de obter informações para análises gerenciais sem a necessidades de estar “preso” às restrições legais.
Estamos falando, então, de uma contabilidade interna, voltada para atender as necessidades de informações gerencias da alta
administração, dos gerentes de departamentos, etc.
O módulo que atende às necessidades da contabilidade externa é FI e da contabilidade interna CO. Esta desvinculação torna o
módulo de CO uma excelente ferramenta para cálculo de custos e análises gerenciais.
Analogamente, existe uma diferença semelhante entre CO-PA (Análise de Resultados) e EC-PCA (Contabilidade de Centro de
Lucro). A Contabilidade de Centros de Lucro está voltada para análises internas, gerenciamento das diversas áreas geradoras de
receita dentro da empresa e a Demonstração de Resultados (Profitability Analisys) está voltada para análise de mercado,
acompanhamento dos resultados na empresa nos diversos segmentos de mercado que ela atua.
Em CO, não existe a necessidade de existir um débito fechando com um crédito. Os lançamentos oriundos de FI geram um
débito no objeto de custo especificado e nenhum crédito. Quando ocorre o lançamento de um custo primário em CO ele é
tratado como uma entrada unilateral diferentemente da contabilidade tradicional. No lançamento de custos secundários, ou seja,
CONTROLADORIA 46 de 325
quando ocorre o repasse de custo de um centro de custo para uma ordem, por exemplo, aí sim, haverá um crédito no centro de
custo gerador do custo (emissor) e um débito no centro de custo que recebeu o serviço (receptor).
12.2 Conceitos básicos gerais
Gastos: um gasto pode gerar um custo diretamente (pagamento conta energia elétrica), pode gerar um investimento que
posteriormente pode virar custo (compra de matéria-prima) ou um investimento que se transforma em custo em parcelas
(compra de maquinário) ou um investimento que não vira custo (compra de terreno).
Desembolso: pagamento resultante da aquisição de bens ou serviços podendo estar defasado ou não do gasto.
Investimentos: sacrifícios havidos pela aquisição de bens ou serviços (gastos) que são estocados nos ativos da empresa para
baixa ou amortização quando de sua venda, de seu consumo, de seu desaparecimento ou de sua desvalorização.
Custo: gasto relativo a bens ou serviço utilizado na produção de outros bens ou serviços. Um custo só vira despesa na venda do
produto produzido.
Despesas: bens ou serviços consumidos direta ou indiretamente para a obtenção de receitas. No resultado existem receitas e
despesas e, às vezes, ganhos e perdas, mas não existem custos. Toda despesa é ou foi um gasto mas nem todo gasto vira
despesa (compra de terreno)
“Custo de Produto Vendido: não é custo é despesa.”
Perda: bens ou serviços consumidos de formal anormal ou involuntária e que são vão diretamente para o resultado como
despesas. As “perdas” previsíveis do processo produtivo não deveriam ser chamadas de perdas já que incorporam o custo.
12.3 Princípios Contábeis
12.3.1 Realização
Reconhecimento contábil do resultado (lucro ou prejuízo) apenas na realização da receita; gera diferença entre os conceitos de
lucro da Economia e da Contabilidade.
12.3.2 Competência e Confrontação
Diz que a despesas representativas dos esforços para a consecução de uma receita deve ser reconhecida no momento do
reconhecimento desta receita. Existem dois grandes grupos de despesas:
DESPESAS P/ OBTENSÃO DAS RECEITAS - incorridas para a consecução daquelas receita qie estão sendo
reconhecidas
DESPESAS DE VINCULAÇÃO DIFÍCIL OU IMPOSSÍVEL - incorridas para obtenção de receitas genéricas e não
necessariamente daquelas que agora estão sendo contabilizadas.
12.3.3 Custo básico como histórico de valor
Os ativos são valorizados pelo valor histórico. Isto exige trabalhar com moeda constante (pouco influência de efeitos
inflacionários que deturpariam os valores de custos apurados).
A Contabilidade só admite para registro os fatos relativos a gastos efetivos da entidade representados por pagamentos ou
promessas de pagamentos pelos bens e/ou serviços recebidos. O sacrifício representada pelo que a empresa deixou de ganhar
por ter aplicados seus recursos na fabricação de um bem e não em outra atividade qualquer ou simplesmente o juro calculado
sobre o capital próprio, por não obrigarem a entrega de ativo, deixam de ser contabilizado e também de ser englobas no custo
dos produtos.
12.3.4 Consistência
A empresa deve ser coerente na adoção de seus critérios. No caso de uma alteração a empresa deve reportar o fato e o valor da
diferença no lucro com relação ao que seria obtido se não houvesse a quebra de consistência.
CONTROLADORIA 47 de 325
12.3.5 Conservadorismo
Se baseia no espírito de precaução. Se a empresa tiver a opção de definir um fato ocorrido como ativo ou redução do PL, deve
optar pela redução do PL (ex.: provisão para devedores duvidosos; se um estoque avaliado pelo custo de aquisição (mercadoria)
ou de fabricação (produto) estiver ativado por um valor que exceda o seu valor de venda, deve ser reduzido ao montante deste
último (custo ou mercado, dos dois o menor).
12.3.6 Materialidade
Não exige controle sobre os itens de valor monetário pouco significativo.
12.4 Controladoria
Controladoria em uma organização coordena, monitora e otimiza todos os processos da empresa. Para isto, a Controladoria
requer informações sobre o consumo dos recursos e atividade de produção. O planejamento também é uma atividade executada
pela Controladoria. A comparação entre o planejado e o real permite apontar variações que constituem a base para medições
corretivas. Inclui, ainda, as funções de contabilização de lucros e perdas, tais como margem de contribuição, rentabilidade de
áreas individuais e da empresa como um todo. Fornece informações críticas para tomada de decisões suportando tanto os
objetivos operacionais (curto prazo) e estratégicos (longo prazo).
A Controladoria é uma ferramenta gerencial para tomada de decisão englobando as etapas de previsão, controle, apresentação
de resultados, recomendações ou deliberações e informações. As etapas são analisadas individualmente por área Controladoria
Financeira (Aquisição), Controladoria de Investimentos (Produção) e Controladoria de Custos e Receitas (Vendas) e de forma
global cíclica.
O objetivo do módulo de CO é armazenar, conciliar e, se possível, alocar os gastos operacionais totais dentro de um período da
empresa, extraídos da Contabilidade Financeira (Contabilidade, Contas a Pagar, Contas a Receber), tendo o custo como base.
Informações não relevantes à Contabilidade Financeira serão tratadas em CO permitindo um efetivo gerenciamento do custo.
O CO possui todos os procedimentos comuns para a Contabilização dos custos. Pelo CO é possível documentar os fatores de
produção e as saídas geradas baseado em valores e quantidades, aumentar a eficiência do controle e suportar tomada de
decisões. Constitui-se de “objetos” para os quais serão atribuídos custos e/ou receitas dentro de um período.
Cada departamento pode selecionar diferentes tipos de planejamento e funções. O CO já contém relatórios disponíveis para
análises comuns mas também permite a criação de relatórios customizados.
A dificuldade na apuração dos custos está, basicamente, na obtenção correta das informações. Os apontamentos de produção,
que são a base para o cálculo dos custos, são efetuados por profissionais de nível cultural médio e sem interesse por serviços
burocráticos. Na Implantação de um sistema, o ideal é começar com rotinas e formulários mais simples fazendo-se uma
Implantação progressiva tanto a nível de escopo como de profundidade. É preciso avaliar bem a relação gasto-benefício de cada
informação.
Portanto, ao contrário de outras abordagens contábeis, o R/3 permite controlar o fluxo de quantidades entre os objetos e
valorizá-lo. Estas quantidades representam o vínculo entre os componentes de Logística e Contabilidade, permitindo conciliar
informações de planejamento entre os diversos componentes. Por exemplo, é possível transferir informações do planejamento
de vendas para o planejamento e controle da produção e, então, usá-lo para determinar as necessidades de quantidades de
atividades internas a serem executadas. A partir daí, apura-se o custo dos centros de custos que irão fornecer estas atividades.
Para usar o módulo de CO como um sistema de projeção, é preciso obter informações não contábeis, tais como os
compromissos resultantes de aquisições e ordens de compra (custos futuros) se considerando como redutores de verbas
disponíveis.
COMPONENTES DE CO
Pergunta Componente
Quais custos ocorrem dentro da organização? Cost and Revenue Element Accounting
Como manter os custos indiretos sobre controle? Overhead Management
As áreas onde os custos indiretos ocorrem estão trabalhando
eficientemente?
Cost Center Accounting
CONTROLADORIA 48 de 325
COMPONENTES DE CO
Pergunta Componente
Quão alto estão os custos das atividades da empresa? Estão seguindo
o orçamento?
Overhead Orders
Como associar custos indiretos considerando fontes reais de custos e
como otimizar processos internos?
Activity-Based Costing
Quanto custa fabricar um produto ou fornecer um serviço? Product Cost Controlling; Product Cost Planning; Cost
Object Controlling; Actual Costing/Material Ledger
Quais os segmentos da empresa são rentáveis? Profitability Analysis
Quão lucrativas são as unidades corporativas individuais? Profit Center Accounting
Internacionalmente, a contabilidade pode ser dividida em duas abordagens baseada em diferentes tradições e necessidades. As
empresas que seguem a contabilidade européia fazem uma distinção maior entre contabilidade financeira e contabilidade de
custos que as empresas anglo-saxissônicas. O US-GAAP (United States’ Generally Accepted Accounting Principles) enfatiza o
investidor mais que o credor; os princípios contábeis são mais voltados para uma apresentação de valores mais justa do que
conversadora. Além disto, o balanço comercial e fiscal são menos vinculados e a valorização externa consumo de recursos é
mais real que a usada na Alemanha, por exemplo. No entanto, para fins de análises internas, a maior parte das empresas
preferem usar valorizações distintas das necessidades externas.
No R/3 os lançamentos contábeis são gerados automaticamente pelos outros módulos de forma on-line e em tempo real.
12.5 Abordagens de custo implementadas em paralelo no R/3
12.5.1 Custeio Padrão x Custeio Real
Na valorização das atividades pode ser usado tanto as tarifas planejadas quanto reais. Na contabilidade de Custo real, os custos
são alocados na sua totalidade para o cálculo de componentes. Já na contabilidade de custo padrão, somente são alocados os
custos padrão sendo a diferença entre o custo real e o padrão alocada diretamente para lucros do período.
Os custos padrão são estabelecidos segundo estudos de engenharia e são cuidadosamente apurados, levando-se em conta o
presente e o passado. Assim, nem todos os custos pré-orçados podem ser classificados como tal. Para determinação dos custos
padrão, há necessidade de seguir alguns critérios:
Seleção minuciosa do material utilizado na produção;
Estudos de tempo e desempenho das operações produtivas;
Estudos de engenharia sobre equipamentos e operações fabris.
Para os produtos acabados e semi-acabados, o SAP exige trabalhar com custeio padrão. Já, a nível de materiais comprados,
pode-se trabalhar tanto com custeio padrão quando média móvel. A partir da versão 4.6, é interesante trabalhar com padrão para
todos os materiais uma vez que permite visulaizar melhor as variações no custo em função de quantiade e de preço também a
nível de matéri-prima.
12.5.2 Custeio por Absorção x Custeio Marginal
Os custos podem surgir em toda a cadeia de alocação em porções fixas e variáveis, possibilitando tanto uma análise de custo
marginal quanto de absorção. No custo por absorção, todos os custos (fixo e variável) são repassados aos objetos de custo. Já no
custo marginal, somente são considerados os custos variáveis, tanto na apuração preliminar quanto na final.
Custeio por absorção consiste na apropriação de todos os custos de produtos aos bens elaborados mas somente os de produção.
Apesar de não ser totalmente lógico e de, muitas vezes, falhar como instrumento gerencial, é aceito para fins de avaliação de
estoques (para apuração de resultado e para o próprio Balanço) e também para o Fisco (IR).
O SAP permite analisar os custos decompondo-o em várias visões diferentes podendo incluir alguns custos em um visão e não
incluí-los em outras.
CONTROLADORIA 49 de 325
12.5.3 Custeio direto x Contribuição Marginal
A abordagem pode ser alterada para desconsiderar, totalmente, as alocações de custos indiretos associando-os aos objetos de
decisão originalmente programados. Os princípios que norteiam a metodologia do Custo Direto não consideram os custos
indiretos como custos de produção. Se baseia no princípio do COST-BY-CAUSE. Estes custos são lançados como custos
inaplicáveis ao processo produtivo, qualquer que seja o volume da atividade. Ao contrário do método de Custo por Absorção
que agrega os custos indiretos ao custo de produção, o método do Custo Direto debita os custos indiretos diretamente da
Receita de Vendas, obviamente apresentando resultados distintos nos balancetes de receitas e despesas.
A Margem de Contribuição por produto corresponde à diferença entre o preço de venda e os custos variáveis. O resultado deve
ser suficiente para cobrir os custos fixos, assim como o lucro líquido desejado pela empresa. A maior vantagem de se fazer uma
avaliação da Margem de Contribuição está em estabelecer um comparativo entre os preços dos concorrentes e os preços
praticados pela empresa. Uma vez identificado, a empresa poderá verificar qual a capacidade dos seus produtos para gerar
lucro, já que conhece os limites dos seus custos variáveis. É, portanto, uma informação relevante para a administração de
marketing.
Uma análise da tendência, observando-se em particular o comportamento da margem média de cada produto por período, seja
em reais como em percentuais, permitirá identificar eventuais desvios maiores. Estes desvios podem estar relacionados com os
preços projetados ou com os custos ou despesas variáveis consideradas. Um exame da coerência dos números torna-se
importante.
12.5.4 Custos de Vendas x Custeio Periódico
O componente de CO-PA (Análise de Rentabilidade) suporta Custos de Vendas (cost-of-sales accounting) que compara as
receitas e custos de vendas do período. Também permite contabilização periódica que compara receitas do período com os
custos totais, as variações no estoque de semi-acabados e acabados, materiais em processo e ativos produzidos internamente.
12.6 Planejamento / Projeção / Orçamento
Planejamento - esta ligado ao que a empresa espera realizar em termos operacionais, pode trabalhar tanto monetariamente
quanto em termos de quantidades. O módulo de CO possui inúmeras funções para planejamento integrado apresentando
diversos cenários (diferentes versões) que podem ser revalorizadas e copiadas. Permite tanto o planejamento centralizado como
descentralizado podendo as telas de entrada de dados ser customizada conforme as necessidades de cada um. Para facilitar a
manutenção, o R/3 permite lançamento automático de informações oriundos de outros módulos, alocações automáticas,
fazendo, ainda, a conciliação;
Forecast - projeção dos dados com base no ocorrido com base em algum critério podendo ou não estar ligado ao plano de
contas;
Orçamento - monetário ligado ao definição e controle de verbas.
12.7 Moedas em CO
Moeda da Área de Contabilidade de Custos
Moeda da Empresa ou do Objeto - Se estiver trabalhando com mais de um empresa por Controlling Area, a moeda do
objeto obrigatoriamente deverá ser a moeda da empresa. Se a Controlling area for definida para trabalhar com uma única
empresa, os objetos poderão ter uma moeda diferente da moeda da empresa.
Moeda da transação
12.8 Conceitos gerais de CO
Receitas – Receita total considerando-se o preço de mercado. Unidades de atividade operacional (bem ou serviço) valorizada
em preços de mercado, expressa na unidade de medida e moeda de vendas (quantidade x preço de mercado = vendas).
Grupos de Alocação – combinação de ordens em uma mesma Área de Contabilidade de Custos que são apuradas em conjunto
podendo ser definida com base em deadlines (mensal, semanal,...), área de trabalho (manutenção, reparo, etc. ...) ou destinatário
de apuração (centro de custo, conta contábil).
CONTROLADORIA 50 de 325
Cálculo de Custos – Método de apropriação de custo; cálculo de custos de bens produziods e comprados para uma unidade
produtiva ou operacional (produto ou serviço).
Contas de variação de preço– contas contábeis que receberão os lançamentos mensais referentes às variações entre o custo
padrão e o custo real ou para lançamento de variações entre os valores constantes na nota fiscal e na ordem de compra
(divergências de preço).
Capacidade – taxa utilizada para separar o custo fixo referente à utilização da capacidade do custo referente a tempo ocioso.
Custos teóricos – corresponde ao custo planejado com base nas quantidades e tarifas planejadas ajustados para as quantidades
reais apuradas para estas atividades. Conforme mostra o gráfico. Ele permite uma comparação mais significativa entre o real e o
planejado.
previstoQUANTIDADE
Fixo
Total ajustado
Total previsto
CUSTOS
real
Custos Unitário – Ferramenta de custeio de produtos que não considera a lista de materiais (estrutura do produto) e o roteiro
(processo produtivo) usado para determinar o custo previsto dos componentes ou para detalhar a previsão de custos dos objetos
de custo (ordens ou centros de custo).
Classe de Custos (Cost Element) – conta contábil usada pela Controladoria para armazenar consumo de recursos de
produção. As classes podem ser primárias (que se referem aos materiais comprados, matérias-primas, fornecimentos
operacionais, folha de pagamento criados fora da Controladoria) e secundárias (referente a atividades operacionais internas
que somente são relevantes para a Contabilidade de Custos). É o ponto de partida para repassar os valores para outros
componentes de CO. As Classes de Custo secundárias mostram o fluxo dos valores internos, por exemplo, no caso da alocação
de atividade internas, cálculo de gastos gerais e apropriações (liquidações). O Conceito de classe de custos primária aqui não
coincide com o conceito normalmente aceito para os custos primários que os classifica como o somatório dos custos diretos de
matérias-primas e mão-de-obra.
Classe de Receita (Revenue Element) – conta contábil para armazenamento de venda de produtos e/ou serviços.
Centro de Lucro (Profit Center) – subdivisão da empresa para analisar separadamente os resultados, ou seja, definida para
fins de controle e gerenciamento interno. O lucro por centro de lucro pode ser calculado pelo método do custo de vendas (Cust-
of-sales) e/ou método contábil por período (period accounting). A contabilização por centro de lucro não é parte do processo de
apuração. Reflete a estrutura corporativa baseada em responsabilidades por lucratividades utilizando-se de todas as transações
de contabilização de lucros relevantes. O Balanço pode ser expresso por centro de lucro ou centro de investimento.
Centro de Investimento (Investiment Center) – Centro de Lucro associado a um ativo fixo ou em andamento.
Centro de Custos (Cost Center) – unidade contábil da empresa definida com base em áreas de responsabilidades, localização,
necessidades funcionais, critérios de alocação e/ou fornecimento de atividade ou serviços. Auxilia tanto no cálculo (alocação de
custos indiretos para as atividades de vendas) quanto no controle funcional do custo (detalhamento do custo incorrido dentro da
empresa). Para análises adicionais, um centro de custo pode ser vinculado também a um Centro de Lucro e/ou a uma Divisão.
Para garantir a conciliação envolvendo transações externas, todo centro de custo deve estar associado a um empresa.
Tipo de Atividade (Activity Type) – critério para alocação de quantidade de atividades operacionais entre centros de custo ou
centro de custo e ordens. Ferramenta para medir a saída de um centro de custo. (Ex: quantidade produzida, tempo de máquina,
tempo de produção, emergia em kwh, hora trabalhada). Os tipos de atividade devem ser definidos de forma a permitir fracionar
os custos para a execução de um serviço e calcular as quantidades de atividades de forma direta e retroativa. Os tipos de
atividades são valorizados de acordo com as tarifas definidas para cada centro de custo. Um determinado Centro de Custo pode
ter um, vários ou nenhum tipo de atividade relacionado. As atividades de um centro de custos com diferentes origens de custo
CONTROLADORIA 51 de 325
devem ser divididas em diferentes tipos de atividades. Pode-se entender o tipo de atividade como uma forma simplificada de
um cost-driver do Custeio ABC.
Dentro do planejamento de tipo de atividade, dados de controle podem determinar se a tarifa para a avaliação dos tipos de
atividade são definidos manualmente ou se são calculados interativamente através da determinação de tarifa.
Ordem (Order) – Instrumento de monitoramento de custos que descreve as atividades executadas internamente seja de
produção ou não permitindo o planejamento, monitoramento e alocação de custos as estas atividades dentro de uma Área de
Contabilidade de Custos. Podem existir diferentes ordens conforme necessário: CO: Ordnes de delimitação, ordens de custos
indiretos, , ordens de Investimento de Capital, Ordens de Receita, PM: Ordens de Manutenção, PP: Ordens de Produção, de
Montagem, Coletores e Ordens de Processo.
Projeto – Estrutura completa de tarefas de uma Área de Contabilidade de Custos. Pode-se controlar e monitorar, a nível de
projeto, cronograma, recursos, capacidades, custos, receitas e disponibilidades de fundos. Uma conta contábil não pode ser
vinculada a um projeto mas sim a uma tarefa de um projeto.
Elemento PEP (Plano de Estrutura de um Projeto) – item da Work breakdowm structure do projeto que descreve uma tarefa
concreta ou uma sub-tarefa que, por sua vez, também pode ser subdividida.
Objeto de Custo – Item para o qual se executa atividade e, consequentemente, atribui custos. Assim, um objeto de custo pode
ser um material (produto acabado), uma Ordem de Produção, de Montagem, de Produção Repetitiva ou de Processo, a uma
Network, a uma Ordem de Venda ou uma tarefa de projeto (item de WBS).
Processo Empresarial (Business Process) – agrupamento de tarefas executadas nos diversos centros de custo de uma empresa
com o objetivo de estruturar os processos da empresa por função.
Demonstração de Resultados (Profitability Analisys) – Mapeamento do custeio do período montado com base na
contabilidade de custo de vendas (cost-of-sales) ou contabilidade periódica (periodic accounting). É a última etapa do processo
de apuração relacionado as Classes de Custo. Com o gerenciamento das vendas, os custos são atribuídos a receitas por
segmento de mercado (market segment).
Objeto de Resultado (Profitability Segment) – objetos vinculados à Demonstração de Resultados definidos pela combinação
de várias características podendo se basear em informações já contidas no R/3 (ex: grupos de clientes, variação ou linha de
produtos, canais de distribuição, país) ou outras características definidas (classe e tamanho da ordem) contidas no R/3
Repository. É possível calcular um lucro operacional de um Objeto de Resultado comparando suas receitas e custos.
Tipo de Objeto (Object Class) – Agrupa os objetos e as unidades organizacionais de CO nas seguintes áreas de controle:
Gerenciamento de Custos Indiretos (Overhead Cost Management) / Centros de Custos
Gerenciamento de Investimento de Capital (Capital Investiment Management) / Ordens de Investimento de Capital
Gerenciamento de Vendas (Management Sales) / Objetos de Resultado
12.9 Componentes do R/3
A área contábil no R/3, se subdivide em cinco grandes módulos: Contabilidade Financeira, Contabilidade de Custos,
Controladoria Empresarial, Tesouraria e Controle de Investimentos.
12.9.1 FI – Contabilidade Financeira (Financial Accounting)
FI atende aos requisitos legais internacionais como o GAAP (padrão americano), IAS (International Accounting Standard) e
GOB (padrão alemão).
1. FI-GL – Razão Geral (General Ledger) – inclui as funções para manutenção do plano de contas, lançamentos contábeis,
etc. Para facilitar o entendimento, o R/3 trabalha com o conceito de Sub-ledger (subsidiary ledger), ou seja, razões
auxiliares, permitindo que as informações sejam armazenadas de forma sumarizada no Razão Geral. Em cada componente
do FI, existem razões auxiliares que detalham os lançamentos, por exemplo, para os clientes, em FI-AC, para os
fornecedores, em FI-AP. Informações de fornecedores também podem ser obtidas pelo registro das aquisições em MM
(Material Management). Também os módulos de FI-AM, (ativo fixo) FI-TM (Gerenciamento de viagens) e Bank possuem
sub-ledger.
2. FI-AR – Contas a Receber (Account Receivable) – controle das contas a receber integrado com a gestão de vendas,
análise de crédito.
3. FI-AP – Contas a Pagar (Account Payable) – gestão das contas de fornecedores integrada com a gestão de suprimentos.
CONTROLADORIA 52 de 325
4. FI-BL – Banks Accounting – gestão das contas de banco ligado ao sub-módulos de FI-AR e FI-AP.
5. FI-AA – Ativo Imobilizado (Fixed Assets – Assets Management) – gestão do ativo fixo desde a aquisição até a total
depreciação calculando valores de juros, depreciação, etc.
6. FI-LC – Consolidação (Legal Consolidation) – permite fazer a consolidação dos resultados das diversas empresas de um
grupo empresarial, fornecendo demonstrativos contábeis consolidados. Atualmente, está sendo recomendado a utilização
do EC-CS (Enterprise Controlling – Consolidation) que está sendo aperfeiçoado pela SAP. O FI-LC não está mais sendo
atualizado.
7. FI-SL – Special Purpose Ledger – possibilita ter uma outra “contabilidade” paralela à financeira visando atender
necessidades específicas como, balanço diário para Bancos, gerar relatórios para órgãos controladores (ex.: Elétricas),
FASB. Pode ser usado também para trabalhar com mais moedas quando se atinge o limite do FI-GL (no FI-GL pode-se
trabalhar, basicamente, com até 4 moedas: a local (do país), uma moeda indexada definada para a empresa, uma moeda
forte também definida para a empresa a moeda da transação (que, na verdade, pode ser qualquer uma). Vale observar que,
se no cadastro de contas contábeis for definida uma moeda diferente da moeda local, a moeda da transação para
lançamentos nesta conta contábil, obrigatoriamente deverá ser esta moeda.
8. FI-FM – Administração de Orçamento (Funds Management) – Controle e Verificações financeiras utilizando técnicas
de orçamentação.
9. FI-TM – Travel Management – Módulo para gerenciamento das viagens de funcionários ou prestadores de serviços
controlando desde o recebimento dos adiantamentos até o acerto das despesas. É usado internamente pela SAP.
12.9.2 TR – Tesouraria (Treasury)
1. TR-CM – Fluxo de Caixa (Cash Management) – acompanhamento diário do fluxo de caixa e projeções para curto e
médio prazo.
2. TR-CB – Cash Budget Management or Commitment Accounting – ferramenta de orçamentação de caixa. Pode ser
feita a nível de empresa ou a nível mais global por FM Area (Financial Management Area). Uma FM Área por ter um ou
mais de uma empresa. O Plano orçamentário normalmente é mais enxuto que o Contábil. Neste componente trabalha-se
com o conceito de Item financeiro que normalmente corresponde a mais de uma conta contábil.
3. TR-TM – Treasury Management – controle de aplicações e empréstimos, câmbio, derivatives e outros tipos de securities
(garantias) and hedging (restrições). Não está disponível na versão 4.0. Ainda está em processo piloto (passou por
localização).
4. TR-LO – Loans – Controle de empréstimos – Hipotética, Penhora
5. TR-MRM – Market risk Management
12.9.3 CO – Controlling
Ferramenta para fornecer informações operacionais para a alta administração referente a análise do negócio e tomada de
decisões. Os componentes de CO podem ser classificados em quatro grupos de acordo com o seu objetivo:
1. CO-OM – Controlling de Custos indiretos (Overhead Cost Controlling)
Permite avaliar possíveis reduções nos custos indiretos apontando onde estes custos realmente incorreram, avaliar a eficiência
de cada área de responsabilidade (Centros de Custo), analisar os custos das atividades realizadas pelos centros de custo, efetuar
comparações com orçamentos (Centros de Custos e Ordens Internas) e fornece recursos para otimização dos processos de
negócio internos da empresa (Custeio ABC).
1.1. CO-OM-CEL – Contabilidade de Classe de Custo (Cost and Revenue Element Accounting) – Fornece a
estrutura para lançamentos de dados de CO através da classificação dos lançamentos de acordo com a natureza do
custo ou da receita.
Permite avaliar qual a natureza dos custos e das receitas incorridas na empresa. Trabalha com o conceito de classe de
custo que nada mais é que um espelho do plano de contas no que diz respeito às contas de custo e receitas. Permite a
conciliação dos custos em CO com a Contabilidade Geral (FI).
1.2. CO-OM-CCA – Contabilidade de Centro de Custo (Cost Center Accounting) – indica “onde” os custos
ocorreram dentro da empresa.
CONTROLADORIA 53 de 325
1.3. CO-OM-OPA – Ordens Internas (Internal Orders – Overhead Order Accounting) – descreve os custos para
atividades individuais (Construção de um prédio, preparação para exposição em feira) ou atividades progressivas
(manutenção periódica do prédio administrativo, custos de manutenção e operação de veículos) dentro de uma área de
controle. Pode ser entendido como um controle simples de projetos.
1.4. CO-OM-ABC – Activity-based Costing – possibilita uma visão da empresa orientada a processos apresentando de
forma transparente as atividades realizadas na empresa e seus custos. Indica “porque” os custos ocorreram dentro da
empresa. Na versão 3.0 não tinha o custeio ABC para produto. Era uma ferramenta gerencial apenas. Somente na
versão 4.0 passou a levar o custeio dos processos para o produto. Não é necessário mapear a empresa inteira em
processos.
2. CO-PC – Controlling de Custos de Produto (Product Cost Controlling)
Permite fazer estimativas dos custos de produção para cada produto e controlar os custos de produção incorridos e
deterimnar o custo real para os produtos no final do período fornecendo diversas ferramentas para análise de custo.
2.1. CO-PC-PCP – Planejamento de Custo de Produto (Product Cost Planning) – ferramenta para geração de
estimativas de custos de produção de materiais e serviços.
2.2. CO-PC-OBJ – Contabilidade de Objeto de Custo (Cost Object Controlling) – apura o custo de produção
incorrido durante o período e executa funções de fechamento de período.
2.3. CO-PC-ACT – Cálculo de Custo real (Actual Costing / Material Ledger) (Razão Auxiliar de Estoque, “cardex”
valorizado) – calcula custos reais por material no final do período.
3. Análise de Rentalibilidade (Profitability Management)
3.1. CO-PA – Demonstração de Resultados (Profitability Analisys) – permite analisar lucros e margens de
contribuição por segmento de mercado fornecendo uma visão externa da perspectiva orientada ao mercado para
gerenciamento de produto, vendas, planejamento global e tomada de decisões.
3.2. EC-PCA – Contabilidade de Centro de Lucro (Profit Center Accounting) – permite analisar internamente a
rentabilidade das áreas da empresa (Centros de Lucro) que tenham a responsabilidade de atingir determinado lucro ou
objetivos de produtividade. A modelagem dos Centros de Lucro é bem flexível podendo descer até o nível de gerente
de contas, se necessário.
12.9.4 EC – Controlling Empresarial (Enterprise Controlling)
1. EC-EIS – Sistema de Informação Gerencial (Executive Information System)
2. Planejamento Empresarial (Business Planning)
3. EC-CS – Consolidação (Consolidation System) – faz consolidação legal e gerencial podendo ser de três tipos: centros de
lucros, unidades de negócio e empresas sendo criada uma visão para cada um. Para cada View, podem ser definidas várias
hierarquias. Dentro das hierarquias, são definidos os Consolidation Groups. Os grupos de consolidação podem ser
Subsgroups (company consolidation), business area (business area consolidation), profit center e nós da hierarquia (profit
center consolidation). O último nível que corresponde às Consolidation Units serão empresas, uma combinação de
empresas e business areas, ou uma combinação de empresa e centros de lucro dependendo do tipo de consolidação.
A IDES (Internation Demonstration and Education System) utiliza uma hierarquia para representação legal e uma outra para
representação regional. A IDES contem várias empresas de exemplo orientada a diversos processos de negócios. Contepm um
guia simples e váriás indformações cadastrais e transacionais visando representar diferentes cenários. É uma ferramenta
bastante útil para treinamento da equipe do projeto sendo também usado como ambiente de treinamentos minstrado pela própria
SAP e para demonstrações de pre-venda.
Pode ser usado para consolidação de orçamento.
Trabalha com o conceito de Group Company (Grupo Empresarial) que corresponde à COMPANY ou SOCIEDADE no R/3.
Tem a função de consolidação.
É possível emitir balanço patrimonial por profit center também, mas não é o seu objetivo. As contas patrimoniais para o Centro
de Lucro devem ser usadas mais para cálculo de índices (capital operacional, etc.).
4. EC-PCA – Contabilidade de Centro de Lucro (Profit Center Accounting)
CONTROLADORIA 54 de 325
12.9.5 FI-IM – Administração de Investimento (Investment Management)
Fornece funções para o controle e acompanhamento dos investimentos do capital, financiamentos, investimentos,
planejamentos.
1. Appropriation Requests
2. Programs
3. Internal Orders
4. Investments Projects
5. Fixed Assets
12.9.6 Administração de bens imobilizados (Real State Management)
Módulo para administração do ativo no que diz respeito a rentabilidade, aluguéis, etc. Integrado ao módulo de FI-AM.
13 Contabilidade de Custos Indiretos (Overhead Cost Controlling)
Custos indiretos são os custos que não podem ser atribuídos diretamente a objetos de custos como ordens produção, ordens de
processo, etc. A parcela dos custos indiretos sobre o custo total, nos últimos anos, tem aumentado significativamente tanto em
empresas de serviços como de manufatura o que tem tornado a correta apuração dos custos indiretos cada vez mais importante.
13.1 Contabilidade de Classe de Custo (Cost & Revenue Element Accounting)
Permite identificar a natureza da receita ou do custo em CO a partir da classificação contábil feita em FI sempre relacionando a
um objeto de custo. Objeto de custo são entidades coletoras de custo podendo ser um Centro de Custo, uma Ordem Interna, um
Processo Empresarial, uma Ordem de Produção, uma Ordem de Vendas, um Projeto, um objeto de resultado, etc.)
Recebe lançamentos de diversos módulos ou componentes do R/3 (FI, AA, MM, SD, HR).
Através do Razão de Conciliação, ferramenta do CO-OM-CEL é possível identificar as diferenças em custos entre FI e CO
podendo gerar os lançamentos de conciliação em FI. Esta reconciliação se refere a movimentações entre centros de custos de
empresas, divisões ou áreas funcionais diferentes que pertençam à mesma área de contabilidade de custos.
13.2 Contabilidade de Centro de Custo (Cost Center Accounting)
O Centro de Custos é uma unidade organizacional dentro de uma Área de Contabilidade de Custos podendo ser definido de
acordo que diversos critérios como, por exemplo, áreas de responsabilidade, áreas funcionais, localização geográfica. Qualquer
que seja o critério, deve existir uma consistência na definição dos centros de custo. No mestre de Centros de Custos deve ser
definido o nome do responsável pelo Centro de Custo. Os centros de custos são classificados em categorias (administrativo,
produtivo, etc.) A definição e atribuição dos custos aos centros de custos é importante tanto para o gerenciamento dos centros
de custos como é base para utilização dos outros componentes de CO, como, por exemplo, o custeio ABC.
Os centros de custo podem ser agrupados fornecendo informações sumarizadas. Cria-se uma hierarquia standard para a área de
contabilidade de custos contendo todos os centros de custos que corresponde ao organograma da empresa. Assim, o nó
principal da cadeia concentra todos os custos da área de contabilidade de custos.
13.3 Ordens Internas (Internal Orders)
A Ordem Interna é uma ferramenta de CO bastante flexível. Também se constitui num objeto acumulador de custo como o
centro de custo só que, é de natureza transitória. Os custos jamais “morrerão” dentro de uma ordem. Num determinado
momento, esta ordem será liquidada e os seus custos serão transferidos para outro objeto. Assim, para um centro de custo, o R/3
solicita um período de validade, já para a ordem interna, não. Resumindo, a Ordem Interna corresponde a uma estrutura
transitória criada para diferentes propósitos podendo ser agrupada em quatro grandes grupos:
Custos Indiretos (Overhead) – Ordens para controle de custos indiretos gerados para um objetivo específico como, por
exemplo, campanha de marketing, exposição em feira, etc.. Posteriormente, estes custos serão transferidos para outro ou
CONTROLADORIA 55 de 325
outros objetos de custo (Ordens Internas, segmentos de rentabilidade, centros de custos, projetos) podendo depender da
natureza do custo (classe de custos) ou não e o saldo da ordem será zerado.
Investimentos (Investments) – Ordens para controle de Investimentos da empresa como, por exemplo, a criação de uma
ativo fixo (construção de um prédio, desenvolvimento ou Implantação de um software). No caso de um ativo, a ordem será
encerrada contra um ativo fixo, ou seja, a ordem terá uma liquidação externa. Este tipo de ordem pode também ter seus
custos transferidos para centros de custos, projetos ou contas contábeis do razão (uma conta do ativo imobilizado, por
exemplo, para a qual não existe associação com objeto de custo).
Provisões (Accrual) – Ordens para realização de provisões gerenciais como, por exemplo, provisão de participação nos
lucros. Os centros de custo serão debitados com os valores provisionados e a ordem interna é creditada. Utiliza-se a
sobretaxa ou suplemento para a geração destes valores. Estes lançamentos são feitos apenas em CO. Na realização efetiva
da despesa, a ordem é debitada e os centros de custos creditado estornando a provisão como acontece com as provisões
legais efetuadas diretamente em FI.
Receitas (Revenue) – Ordens para controle de Receitas usada quando o componente de SD não está sendo usado para o
gerenciamento de ordens de vendas ou para monitorar receitas que não afetam o negócio principal da empresa (ex: receitas
de miscelâneas).
13.4 Custeio Baseado na Atividade (Activity-Based Costing)
Tradicionalmente, os custos indiretos são alocados dos centros de custo para os objetos de custo por vários métodos, tais como
sobretaxa e alocação de atividades. O Custeio ABC aloca os custos diretamente para os processos de negócio da empresa sem
considerar as unidades da organização envolvidas na geração destes custos. Um processo pode ser executado por vários centros
de custo dentro de uma área de contabilidade de custos.
No R/3, o Custeio ABC foi implementado de forma diferente. Os custos continuam sendo atribuídos aos centros de custo. Os
custos dos recursos usados pelo centro de custos na execução de um processo é alocado para o processo (ex: os custos da
cotação de preços do Centro de Custos de Compra é alocado ao processo de aquisição. Os processos são consumidos por
objetos de custo (ex: ordem de produção) e seus custos são atribuídos a estes objetos de custo. Os custos do processo não
alocados para nehum objeto de custo são transferidos diretamente para CO-PA para garantir que todos os custos indiretos
aparecem na demonstração de resultados. Estes custos normalmente, referem-se às despesas não produtivas associadas aos
processos mas que não poderão incorporar os custos dos produtos já que a legislação não permite.
14 Controlling de Custo de Produto (Product Cost Controlling)
Considera todos os aspectos para planejamento dos custos de produção ou serviços, apuração e análise de custos reais que
incorreram num processo produtivo. Os cadastros básicos deste módulo são: a BOM (Bill of Material), o Roteiro e o Centro de
Trabalho (local físico, grupo de máquinas ou pessoa que realiza uma dada operação de produção). O R/3 permite vincular o
consumo das matérias-primas às operações do roteiro de produção. O Centro de Trabalho deverá estar vinculado a um Centro
de Custo ou a um processo ABC para que seja possível calcular o custo monetário das atividades realizadas pelo Centro de
Trabalho. O R/3 permite que um mesmo centro de custo tenha vários centros de trabalho.
14.1 Planejamento de Custo de Produto (Product Cost Planning)
Ferramenta que auxilia na determinação de custos planejados dentro de um cenário ideal, um cenário real, uma visão mais
otimista e uma visão mais pessimista, permitindo analisar custos de produção x aquisição e definir qual a melhor alternativa.
Se o módulo de PP estiver disponível, o cálculo do custo planejado pode ser automatizado fazendo-se uma valorização da
estrutura quantitativa (roteiro e lista técnica) do produto determinando os preços do materiais, preço das atividades e custos
indiretos. Não tendo a estrutura quantitativa pode-se usar a ferramenta de custo unitário definindo manualmente os custos para
os produtos ou pode-se, ainda, importar estes valores de sistemas não-sap.
Além do custo de produção, é possível determinar o custo de produto vendido que incorpora, além dos custos de produção, as
despesas com vendas dentro do conceito do Sistema R/3. Também podem ser analisadas outras visões de custo. O planejamento
de custos de produto também permite a determinação de preços, medição de produtividade, efetuar comparações entre
alternativas de produção (tamanho do lote), melhoramento contínuo, comparação entre custos de duas diferentes fábricas
(centros), analisar a influência de custos primários no produto (energia elétrica, depreciação de máquina e gerar o custo
padrão), etc..
CONTROLADORIA 56 de 325
14.2 Contabilidade de Objetos de Custo (Cost Object Controlling)
No planejamento de custos de produtos são feitas estimativas de custo para um dado material / centro. Agora, serão feitos
cálculos preliminares de custos para as ordens de produção e os coletores de custo. O cálculo preliminar de custos para a ordem
pode ser gerado no momento da criação da ordem podendo ou não aproveitar uma estimativa de custo já criada. Na
contabilidade objetos de custos, a determinação de custos tem três etapas: cálculo preliminar dos custos, apuração dos custos de
produção incorridos (atuais) e o processo de fechamento do período (cálculos de custos reais com apuração de variações de
preço para standard – ledger de materiais).
O custeio preliminar determina os custos planejados para um objeto de custo (ordem de produção, ordem de processo ou coletor
de custo). Variações no planejamento podem ser determinadas comparando o resultado do custeio preliminar da ordem de
produção com o custo padrão. Obviamente, esta comparação só tem sentido se os critérios para os dois cálculos forem
diferentes. Se for definido, por exemplo, que a estratégia para o cálculo de custos preliminares será com base na estimativa de
custo padrão corrente, os valores serão os mesmos.
No processo de custeio simultâneo, os custos de produção incorridos (matéria-prima, mão-de-obra, etc.) são acumulados nos
objetos de custo (ordens de produção, ordens de vendas, ordens de processo ou coletores de custos para produção repetitiva) à
medida que são realizados permitindo efetuar comparações entre o planejado e o incorrido em cada fase do processo de
produção. Ou seja, a cada movimentação de material, seja requisição de matéria-prima para a ordem, seja entrega de produtção
para estoque, automaticamete, o sistema estará atribuindos os custos correspondente para a ordem. Os apontamentos de
operações também estarão gerando lançamentos de custos de atividades para a ordem.
O processo de fechamento do período inclui as funções de alocação dos custos indiretos, cálculo e lançamento do WIP (work in
process), cálculo dos desvios entre custo padrão e real, liquidação dos saldos das ordens para CO-PA, EC-PCA e FI e cálculo
dos custos de refugo. Oss desvios vão direto para o resultado retornando para estoque através da localização até a versão 4.0 e
através do ledger de materiais a ártir da 4.5.
Existem três diferentes formas para apuração dos custos: Por Ordem ou Por período ou Por Ordem de Vendas. É possível se
trabalhar com os três cenários diferentes conforme o material / centro.
A definição se o material é make-to-stock ou make-to-order é feita através do código de necessidades dependentes para
necessidade individual e coletiva. Este código determina se são permitidas as seguintes necessidades para a necessidade
dependente do material:
necessidade individual - as quantidades necessárias do material dependente são exibidas individualmente.
necessidade coletiva - as quantidades necessárias do material dependente são acumuladas.
O usuário pode atualizar este código no registro mestre de material ou para o controle de explosão do item da lista técnica. A
configuração para o controle de explosão deve ser efetuada antes da configuração no registro mestre de material.
Caso o material esteja atribuído a um tipo de material para o qual não seja permitida uma administração de estoques com base
na quantidade neste centro, o usuário poderá definir o código como "Apenas necessidade individual". Caso o estoque seja
administrado como estoque para ordem do cliente ou como estoque para projeto, o código pode ter uma das seguintes
configurações:
necessidade individual e necessidade coletiva
apenas necessidade individual
Caso um material, administrado como estoque de projeto, deva ser suprido por outro centro, mediante um pedido de
transferência válido para todas as empresas, o código terá que ser definido em 2 (necessidade coletiva), no centro de saída do
estoque, por neste caso particular não ser possível nenhuma administração de estoque único de projeto nos dois centros.
Quando se define que um material é COLETIVE REQUIRED significa que será produzido para estoque (make-to-stock), se o
material for definido como INDIVIDUAL REQUIRED, significa que será produzido com um destino específico, sob
encomenda (make-to-order).
14.2.1 Controlling de Objeto por ordem (Product cost controlling by order)
Produção por ordem é uma produção baseada em lote para estoque podendo ser adotado com ou sem o módulo de PP. Sem o
módulo de PP, as ordens de produção podem ser criadas diretamente em CO.
Controlling de objeto por ordem, significa que todos os custos serão acumulados nas ordens de produção, ou seja, a ordem de
produção funciona como um coletor de custo. Posteriormente, as ordens serão liquidadas contra estoque (apontamentos de
produção e liquidação da ordem). Este método é usado quando a produção é bastante flexível quanto ao que produzir,
CONTROLADORIA 57 de 325
quantidades de lote, etc.; quando o custos de setup é alto e quando existe a necessidade de rastreabilidade ou controle individual
do lote. Ex: Order-related production.
A quantidade da ordem é de extrema importância porque os custos planejados são calculados em função dela e os custos reais
somente serão calculados depois que toda a quantidade da ordem for reportada. Os custos reais para as atividades internas e
materiais são coletados para a ordem de produção e podem ser comparados com o custo preliminar da ordem.
Seqüencia do Processo de produção por ordem
Solicitação da Ordem – pode vir do SOP (Sales Operation Planning) e ser transferido para o plano de produção. Pode também
ser gerado de uma necessidade de negócio fora do sistema.
Criação da ordem – com a execução do MRP são analisadas as necessidades de matéria-prima e produtos intermediários. Se
não houver estoque disponível, o sistema irá gerar novas ordens de produção, requisição de compras ou ordens de compras.
Com a criação da ordem é calculado os custos planejados para a ordem (exceto para produção repetitiva – neste caso, será
usado o coletor de custos). Os custos planejados são recalculados se houver alteração na ordem.
Verificação de viabilidade – verificar se existe matéria-prima disponível para a execução da ordem e também se a fábrica tem
capacidade para produzir.
Liberação da Ordem – depois da liberação, os custos incorridos começam a ser atribuídos à ordem (requisições de material,
reporte de produção apontando o consumo de atividades). Alguns custos primários podem ser alocados diretamente para a
ordem a partir de outros componentes do R/3 como, por exemplo, na aquisição de um material alocado diretamente para a
ordem em FI.
Impressão da ordem (Shop Paper printing)
Requisição de Material
Confirmações de produção – apontamento de atividades
Alocação de atividades de processo empresarial para a ordem – custeio ABC
Reavaliação de tarifas – realizado no encerramento do período para considerar as tarifas reais das atividades recalculadas para
cada um dos centros de custos com base nos custos realmente incorridos durante o período.
Cálculo do WIP – cálculo do material em processo que corresponde ao somatório dos saldos das ordens de produção em aberto
no período. Neste cenário é importante salientar que, enquanto a ordem estiver em aberto, mesmo com produção parcial, todo o
saldo da ordem será considerado como WIP. Somente depois da finalização da ordem é que o sistema consegue calcular a
variação.
Entrega para estoque Após a finalização do processo produtivo, a mercadoria é entregue ao estoque.
Cálculo do desvio entre custo real e padrão. Corresponde ao somatório dos saldos das ordens de produção que já foram
encerradas. A diferença é lançada para uma conta de resultado e posteriormente será devolvida ao estoque pelo Ledger de
Materiais.
Apropriação da Ordem – encerramento para zerar o saldo contra resultado ou WIP.
Arquivamento/exclusão da ordem. – uma vez encerrada a ordem deve ser, sempre que possível, marcada para eliminação
(exclusão lógica) para que não seja mais considerada nos processamentos de encerramento de período. Ainda, periodicamente,
deve ser feito o procedimento de Arquivamento (Archiving) que corresponde à exclusão fisica da base de dados das ordems
marcadas para exclusão sendo as mesma armazenadas em outro local físico. O procedimento de Archiving é recomendado mais
por questões de performance e liberação de espaço em disco. Pode ser feito de forma global ou localizada através dos objetos
de archiving.
14.2.2 Controlling periódico de objeto (Product cost controlling by period)
O outro critério para apuração dos custos é por período. Neste método, os custos serão acumulados em coletores de custo que,
na prática, correspondem a uma ordem de produção para produção repetitiva. Os coletores de custos podem ser definidos a
nível de produto (umn coletor por material) ou a nível de versão de produção (um coletor para cada versão de produção do
material). O ambiente de produção repetitiva se aplica quando o volume de produção é alto, a produção é contínua e estável e
não há necessidade de controle por lote.
A produção repetitiva refere-se ao planejamento e controle da produção usando coletores (cujo período é definido pelo usuário
podendo durar toda a vida útil de um produto) que fornecem os produtos acabados e semi-acabados para estoque. A partir da
versão 4.6, os run schedule headers foram eliminados e os apontamentos de produção são feitos diretamente para o coletor de
custos. As necessidades de material são normalmente geradas pelo MRP mas podem ser geradas manualmente. O PCP usa as
ordens geradas para planejamento de capacidade e seqüenciamento.
CONTROLADORIA 58 de 325
O controlling período de objeto pode ser definido em CO mesmo que em PP trabalhe com produção por ordem, produção
repetitiva ou produção por processo. Para efeito de custos, a apuração é feita por coletores de cutos de forma mais sintetizada
dependendo da necessidade da empresa. Esta flexibilidade está disponível a partir da versão 4.6.
14.2.3 Controlling por ordem do cliente (Product cost controlling by sales order)
O Controlling por ordem de cliente se aplica a ambientes complexos de produção make-to-order onde os custos são
acumulados na própria ordem de vendas. Se aplica tanto no caso de revenda com compra direcionada para uma ordem de
vendas ou fornecimento de serviços ou produção de mercadorias destinadas especificamente para um ordem de vendas. As
ordens de vendas irão acumular tanto os custos quanto as receitas. Também as despesas com vendas (esforço de vendas,
comissões, etc.) poderão ser acumulados nas ordens de vendas. Neste cenário, é possível rastrear o que foi comprometido, ou
seja, na colocação de uma ordem de compra já é determinado para qual ordem de vendas ela se destina. O sistema considera
WIP e reservas da ordem de vendas para análise de resultados. A análise de resultados pode ser feita com base em diferentes
visões (só o que foi faturado, tudo que foi produzido, etc.)
14.3 Cálculo de custo real / Ledger de Materiais (Actual Costing / Material Ledger)
Esta sub-componente é processado no encerramento do período para apuração do custo real de cada material. Durante o
período, as movimentações dos materiais são feitas com base no custo padrão ou média móvel. As variações são coletadas no
recebimento de uma fatura (compra) ou no encerramento de uma ordem. No fechamento, estas variações são utilizadas para
cálculo do preço real para o material gerando um lançamento em FI de variação de preço. A partir da versão 4.5, o ledger de
materiais substitui a localização Brasil já que permite o cálculo das variações multi-nível, jogando as variações apuradas nos
níveis inferiores para os níveis superiores da lista técnica do material.
O Custeio real utiliza o Ledger de Material para armazenar os preços dos materiais em até três diferentes moedas e de acordo
com três diferentes estratégias de avaliação (grupo, legal e centro de lucro). No caso de utilizar a estartégia de avaliação por
centro de lucro, o sistema deve ser parametrizado para trabalhar com preço interno.
15 Análise de Resultados (Profitability Management)
15.1 Métodos de análise de resultados
O R/3 trabalha com dois métodos para apuração de resultados: custos de vendas ou periódico. A empresa pode optar por um
dos métodos de acordo com suas necessidades. Normalmente, baseia sua escolha em restrições legais específicas do país. No
entanto, os dois critérios podem ser usados simultaneamente conforme for definido para cada uma das áreas de resultados
(baseado em custos, baseado em contas ou ambas).
Trabalhar com o CO-PA baseado em contas, significa que os dados serão analisados conforme os lançamentos nas próprias
classes de custo/receita trabalhando somente com valores reais lançados. Já dentro do CO-PA baseado em custos, pode-se
trabalhar tanto com valores reais lançados como estimados. Em função disto, a visão de custos de vendas em CO-PA baseado
em custos podem refletir em um resultado diferente da visão periódica. Já CO-PA baseado em contas sempre apresenta um
resultado igual ao resultado obtido na Contabilidade de Centros de Lucro (periódico).
Exemplificando, no faturamento é feita a contabilização das receitas, dos custos, dos impostos sobre vendas, mas não são
contabilizadas as comissões, os fretes, pis, cofins, etc.. Em CO-PA baseado em custos, estes valores poderão ser estimados
(através da valorização) diretamente em CO-PA. Isto somente é possível em CO-PA baseado em custos.
Em função disto, as empresas trabalham mais com CO-PA baseado em custos, em função da sua flexibilidade embora CO-PA
baseado em contas seja mais simples de configurar.
Resumindo, CO-PA baseado em contas só tem uma visão do passado, do já ocorrido enquanto CO-PA baseado em custos pode
trabalhar também com uma visão estimatida. Observe que, o conceito de estimativa é diferente do conceito de planejado. Os
valores estimados funcionam como valores “reais” que ainda não foram contabilizados. A nível de planejamento, pode-se
trabalhar tanto em CO-PA baseado em custos como baseado em contas. Do ponto de vista de planejamento é possível visualizar
as informações pelo dois métodos.
Dentro da tabela de CO-PA que guarda as informações dos lançamentos reais individuais, existirão registros do tipo F (gerados
no momento do faturamento) e tipo B (gerados no momento da contabilização). No caso das comissões, por exemplo, podem
existir dois lançamentos: um do tipo F e um do tipo B. Pode ser definido, no entanto, que não se deseja enviar os lançamentos
CONTROLADORIA 59 de 325
do tipo B para CO-PA e, neste caso, somente as comissões estimadas serão consideradas. Em CO-PA não existe a
obrigatoriedade de ter um espelho da realidade.
15.1.1 Periódico
Na maior parte dos aplicativos do R/3, adota-se o conceito de contabilização periódica. É usado em FI e Centro de Lucro. Em
FI, os custos de produção vão direto para o resultado e volta para o estoque no encerramento do período. Existe algumas
exceções como a consideração de variações em certas categorias de ativo ao longo do período. Este método permite analisar a
receita do período e os custos/gastos também do período, mesmo que a receita se refira a um bem produzido em um período
anterior. Inclui também as variações do estoque, WIP e ativos fixos. É uma ferramenta útil para medir a produtividade de
Centro de Lucro.
Possui uma visão útil para a área de produção da empresa. Está, portanto, mais voltada para uma visão interna, sendo, assim,
usado na contabilidade de centro de lucro. Em Demonstração de Resultados (CO-PA) este conceito não é contemplado visto
que CO-PA está mais voltado para análise de mercado.
No R/3, as funções de baixa do estoque referente a uma venda pode ocorrer um período diferente da venda visto que são duas
funções distintas (Fornecimento – Delibery e Faturamento Billing) o que fere os princípios contábeis do Brasil.
15.1.2 Custo de Vendas
Somente na Demonstração de Resultados (seja baseado em custos, seja baseado em contas) e Contabilidade de Centro de Lucro
é possível se trabalhar com o conceito de custos de vendas. Neste método, as receitas incorridas com mercadorias e serviços são
amarradas com os custos/gastos para produção destes itens. Permite efetuar análises efetivas de margens de contribuição sendo
especialmente importante para vendas, marketing e áreas de gerenciamento de produtos.
Ao contrário do baseado em custos , que trabalha com campos de valores (value fields), pelo método baseado em contas,
trabalha-se com as próprias contas.
Baseado em contas Baseado em custos
Conta – descrição Campo de valor – descrição
800000 Receita Vendas
870000 Deduções de Vendas
850000 CPV
.
.
.
400000 Despesas
VV010 Receita de Vendas
VV031 Deduções Vendas
VV040 CPV
.
.
.
Despesas
Dentro do SD, por exemplo, através do esquema de cálculo de custos pode-se definir critérios para obter os campos de valores
da Demonstração de Resultados. A determinação dos valores de receitas não estão necessariamente vinculados à contas
contábeis. Já a nível de despesas, os valores estão nos centros de custos e serão alocados aos objetos de resultados.
15.2 Demonstração de Resultados (Profitability Analysis)
Em CO-PA trabalha-se com o conceito de características que corresponde a cada uma das dimensões do objeto de resultado que
correspondem aos segmentos de mercado. Para cada combinação de valores das características será definido um objeto de
resultado. Define-se também campos de valores que correspondem às medições de performance que se deseja analisar, como,
por exemplo, vendas, descontos, COGS (Cost of Good Sold). Os campos de valores são usados somente no Demonstração de
Resultados baseado em custos. Trabalhando baseado em contas, trabalha-se diretamento com as próprias contas contábeis.
Além disto, são definidas as key figures que correspondem aos esquemas de cálculo para geração de relatórios.
Não existe um registro mestre para os objetos de resultados. Os objetos de resultados são gravados em uma Fact Table (gerada
automaticamente a cada nova combinação de valores de características encontrado). Para vinculação a um centro de lucro uma
de suas características é sempre o centro de lucro.
CONTROLADORIA 60 de 325
Existem algumas características que são padrão interno do R/3 além do Centro de Lucro como a Empresa, ou seja, todo
segmento de rentabilidade terá, obrigatoriamente algumas características. No PA, um segmento pode ser até 69 características
sendo 19 fixas (internas do R/3) e 50 variáveis. Um número razoável seria, no máximo, 20 características além das fixas.
15.3 Contabilidade de Centro de Lucro
O componente Contabilidade de Centro de Lucro (EC-PCA) é um componente de Enterprise Controlling que permite
determinar lucros e perdas por Centro de Lucro na visão de periódica ou de estimativa de custos de vendas. Permite analisar
também ativos fixos e índices estatísticos (número de empregados, metros quadrados, etc.) por Centro Lucro.
Consequentemente, permite calcular todos os índices financeiros e contábeis comumente usados na contabilidade de custos
(ROI, fluxo de caixa, vendas por empregado, etc.)
15.3.1 Métodos de cálculo de lucro
O componente Entreprise Controlling possui três ferramentas de análise da empresa:
Nível Ferramenta
Tático EC-EIS – Sistema de Informação Empresarial
Estratégico EC-CS – Consolidação
Operacional EC_PCA – Contabilidade de Centros de Lucro
Os métodos para cálculo dos lucros podem variar de acordo com o tempo (periódico ou on-line), conteúdo (custo periódico ou
custo de vendas) e forma de representação e base de valorização (contabilização periódica ou baseada em custos). Em PCA, os
dados são apresentados por período e por contas seguindo o mesmo princípio organizacional de FI o que permite uma
conciliação entre as informações geradas pelos dois módulos. Como FI suporta tanto o método de contabilização periódica
como o método de custos de vendas, PCA também segue esta regra.
Na contabilização periódica, os resultados são representados de acordo com as classes de custos e receitas. Isto permite
visualizar quais os fatores de produção geraram custos. Os custos totais do período podem ser comparados com as receitas
ocorridas no mesmo período. Os custos correspondem aos custos de produção de todos os bens e serviços do período
independentemente se foram ou não vendidos somados aos custos dos bens e serviços produzidos em períodos anteriores e
vendidos neste período. O resultado total do período deriva deste total juntamente com as atividades internas capitalizadas e as
alterações no WIP.
A visão de custos de vendas, compara os custos correspondentes às receitas geradas. Os produtos vendidos que compõem estes
custos tanto podem ter sido fabricado no período como em períodos anteriores. Portanto, nenhum distinção é feita a nível de
classe de custos. Ao contrário, os recursos são divididos de acordo com a função, desenvolvimento de produtos, produção,
vendas e administração.
Os centros de lucro são estatísticos, ou seja, os lançamento reais de custos sempre serão atribuídos a outro objeto (centro de
custo, ordem interna, material, projeto, ordem de venda, ativo, objeto de custos, e segmentos de rentabilidade). A vinculação de
centro de custo, processos de negócio, ordens internas, projetos, ordens de produção e objetos de custo é feita a nível cadastral.
Para o lançamento da receita, normalmente, é verificado o Centro de Lucro no cadastro do material de cada item da ordem de
vendas. O CPV é lançado posteriormente ao mesmo Centro de Lucro. Os ativos são vinculados a centro de lucro através do
centro de custo.
16 Integração entre CO com outros componentes do R/3
O módulo de CO-CEL integra com FI já que é nele que estão as classes de custo primárias. A partir do FI também são geradas
informações para CO-OM (custos de overhead para os centros de custo), para CO-PC (custos de mão-de-obra ou consumo de
matéria-prima, por exemplo, para as ordens de produção) e para CO-PA (informações de receitas). FI, por sua vez, também
recebe informações de CO-PC (material em processo WIP e variações (desvios), produtos acabados).
Outros componentes do R/3 também integram com CO, Recursos Humanos, Logística.
Sempre que for feito um lançamento de receita ou despesa em FI para uma conta contábil do Razão que tenha uma classe de
custo primária associada em CO, o sistema irá exigir que seja informado um objeto de custos (centro de custo, ordem interna,
ordem de produção, processo, etc.). Com isto, além do documento gerado em FI, também será gerado um documento em CO. O
CONTROLADORIA 61 de 325
documento de CO tem a sua própria numeração e contém informações sobre a classe de custo, o objeto de custo e o montante
do custo. O R/3 irá criar um vínculo entre estes dois documentos de forma que com o drill-down possa encontrar um
documento a partir do outro. A partir da versão 4.6, pode ser determinado, além do centro de custo, também o tipo de atividade.
A numeração dos documentos de CO é parametrizável. Pode-se, portanto, definir os intervalos de forma a se identificar a
origem do lançamento pelo número do documento.
Existe também uma integração indireta entre AA (Ativo Fixo) e CO. As depreciações calculadas em AA geram lançamentos
em FI e o Centro de Custo proprietário do ativo (esta informação está armazenada no Master Data do Ativo) recebe o débito
referente em CO. Além disto, é possível gerar lançamentos planejados de depreciações em CO para os centros de custos ou
ordens intermas proprietárias dos ativos baseados nos cálculos feitos no AM.
No processamento da Folha de Pagamento são gerados lançamentos de despesas em FI e os centros de custos a serem
debitados serão os centros de custo onde os funcionários estão alocados. Opcionalmente, os custos poderão ser lançados em um
único centro de custo e distribuídos em CO. Distribuição é uma das formas de alocação de custos em CO que utiliza classe de
custo primária para “ratear” custos de um objeto de custos para diversos (dependendo das necessidades específicas da empresa).
Ao gerar uma movimentação de saída de material, é preciso informar em MM o objeto de custo (centro de custo, ordem) a ser
debitado para que após o lançamento contábil em FI, seja gerado o documento também em CO. Outra integração de MM com
CO é pela ordem de compra. Uma ordem de compra pode (se parametrizado na ACC) gerar um lançamento de “compromisso”
(commitment) diretamente em CO. Isto é especialmente válido quando falamos de orçamento. A geração de um compromisso
já reduz a total disponível da verba. Posteriormente, quando a ordem de compra for convertida em uma fatura, o lançamento de
compromisso se transforma em um lançamento real.
Em FI pode ser feito um lançamento com dupla atribuição, ou seja, serão informados dois objetos de custo que podem ser, por
exemplo, uma ordem e um centro de custo, ou um segmento de rentabilidade (profitability analysis) e um centro de custo. Neste
caso, um deles receberá o lançamento real e o outro receberá um lançamento puramente estatístico. Uma ordem interna pode
ser definida como real ou estatística. Se for estatística somente receberá lançamentos estatísticos e sempre o sistema irá solicitar
que um outro objeto de custo seja informado para obter o lançamento real. Em CO, somente são gerados lançamentos reais.
Um centro de custo não pode ser estatístico mas pode receber lançamentos estatísticos. No entanto, estes lançamentos não
poderão ser visualizados em todos os relatórios. Os lançamentos estatísticos do centro de custo podem ser visualizados no
relatório do Sistema de Informação: Centro de Custos: planejado/real/desvio
Um centro de lucro é sempre uma entidade estatística. A amarração com o centro de lucro é feito a nível cadastral (master data).
Um dos objetivos de um lançamento estatístico, por exemplo, é permitir visualizar no centro de custo os custos de uma ordem
que posteriormente será encerrada contra ele.
Se num lançamento, se for informado um centro de custo e uma ordem, o R/3 irá verificar a natureza da ordem (real ou
estatística defino no dados mestre). Se a ordem for estatística o lançamento real irá para o centro de custo. Se a ordem não for
estatística, o centro de custo irá receber um lançamento estatístico.
Note ainda que para cada lançamento só pode ser informado um objeto para cada tipo. Assim, se for informada uma ordem
estatística não poderá ser informada uma ordem real. Portanto, se uma ordem for estatística, ela só recebe lançamentos
estatísticos, e se for real, só recebe lançamentos reais.
No caso dos centros de lucro os lançamentos estatísticos são automáticos uma vez que sempre que for criado um centro de
custo, ele é vinculado a um centro de lucro no dados mestre. Centro de Lucro são sempre estatísticos. Também uma ordem
pode ser vinculado a um cento de custo. Neste caso, sempre que for gerado um lançamento para esta ordem, obrigatoriamente,
será gerado um lançamento para este centro de custo (estatístico ou real dependendo a natureza da ordem). Uma ordem também
pode ser vinculada a um centro de lucro.
Se estamos falando de um lançamento de receita em um objeto de resultado de CO-PA, pode ser gerado no centro de custo um
lançamento estatístico desta receita. No entanto, estes lançamentos não poderão ser transferídos através dos métodos de
alocação disponíveis em CO. Um centro de custo somente recebe lançamentos de receita estatísticos (nunca real). Os
lançamentos reais de uma receita somente podem ser efetuados contra um objeto de resultados, uma ordem de venda, um
projeto de cliente ou uma ordem interna de receita (que substitui uma ordem de vendas de SD).
O R/3 possui ferramenta para o processamento de ordens de vendas através de uma série de documentos amarrados de forma a
gerar um fluxo de trabalho (workflow) para SD. O processo se inicia com as cotações de vendas e termina no recebimento das
faturas. Inicia com a geração do documento de vendas (ordem de vendas), passa pela pesquisa de estoque determinando o
fornecedor (interno ou externo) do material, em seguida, é gerado o documento de entrega (Delivery), o documento de fatura
(Billing) e, no recebimento, um documento de FI.
É bom lembrar que a Ordem de Vendas pode ter integração com CO-PA da mesma forma de uma Ordem de Compra gerando
uma previsão de receita permitindo analisar os lucros antecipadamente e gerando relatório que, além das receitas e custos já
CONTROLADORIA 62 de 325
incorridos, também reflita lucros e margem de contribuição esperadas. No entanto, somente no caso de CO-PA baseado em
custos é que é possível esta integração (cost-of-sales).
O documento de entrega (Delivery) gera em FI os lançamentos de baixa do estoque (credita estoque e debita custo de produtos
vendidos). Esta despesa somente alimenta CO-PA baseado em custos e somente depois da emissão da fatura. Em CO-PA
baseado em contas este lançamento não é efetuado porque, neste caso, o custo aqui considerado será toda a produção do mês e
não o custo do que foi vendido.
Quando um documento de faturamento é gerado, SD calcula o total das receitas de vendas, as deduções de vendas, e outros
valores (tal como o custo padrão) usando procedimento de precificação (Princing Procedure) e armazena estes valores em
Tipos de condição. Associando estes tipos de condições aos campos de valores de CO-PA baseado em custos, os dados são
automaticamente transferidos para CO-PA. O valor do custo lançado para CO-PA é o custo padrão calculado através do CO-
PC. As variações da produção são transferidas para CO-PA durante a liquidação de uma ordem de produção.
16.1 Valores propostos nos lançamento de FI
Definições de valores propostos automáticos são obrigatórios na geração de lançamentos automáticos tais como variação de
preços, variações cambiais, descontos.
Os valores propostos podem ser definidos em diferentes níveis: Área de Contabilidade de Custos, contas e empresa; Área de
Contabilidade de Custos, empresa, unidade de negócio e/ou área de avaliação; ou centro de lucro. Podem ser definidos valores
padrão a nível mais geral e definir as somente as variações no nível mais baixo.
Para os lançamentos de receita, o objeto de custo real pode ser um objeto de resultado, uma ordem de vendas, um projeto de
vendas ou uma ordem interna.
16.2 Regras de Validação e Substituição
Para garantir que as informações cheguem corretas em CO podem ser definidas regras de validação e regras de substituição.
Estas regras podem ser definidas geral para a Área de Contabilidade de Custos ou para um evento particular. Evento é um ponto
específico dentro de uma transação. Os eventos definidos em CO são:
Line item (0001) event usa dados do cabeçalho do documento (COBK) e o CO coding block (COBL). Controla os
lançamentos gerados dentro e fora de CO.
O cabeçalho do documento (0100) usa dados do COBK e afeta somente os lançamentos manuais do CO.
Lançamento Interno de CO: emissor/receptor (0002) usado somente em CO para consistir relacionamentos em emissor e
receptor em alocações periódicas.
Ás regras de validação são atribuídas mensagens definidas pelo usuário que poderão ser de erro, aviso ou informativa ou pode
ser solicitada a interrupção imediata do lançamento.
As regras de substituição são usadas para alterar um valor informado pelo usuário sem que este seja notificado. Um outro
evento é definido para substituições (0010) usado somente para processamento coletivo de ordens. Se uma regra de substituição
estiver em conflito com uma de validação o sistema envia mensagem. Pode ser definido também que as validações tem
prioridade sobre as substituições.
16.3 Classificação contábil por tipo de atividade
A nível de Área de Contabilidade de Custos pode ser definido ser será permitido usar o tipo de atividade para efetuar
lançamentos reais como objeto de classificação contábil. Se o código estiver marcado, é possível classificar contabilmente os
custos primários sobre o tipo de atividade de um centro de custo. A utilização de um tipo de atividade como objeto de
classificação contábil foi concebida para as seguintes áreas de utilização:
Custos de pessoal no cálculo de folhas de pagamento – O tipo de atividade emissor informado na folha das horas de
trabalho ou no registro das horas, no gerenciamento de tempos, (PT) pode ser transmitido ao cálculo da folha de pagamento
(PY) para a classificação contábil dos custos de pessoal.
Lançamentos de depreciações sobre tipo de atividade na contabilidade do imobilizado – No lançamento periódico de
depreciações no Razão, é possível classificar contabilmente o tipo de atividade gravado nos dados mestre do imobilizado,
ao lado do centro de custo e da ordem.
CONTROLADORIA 63 de 325
Também é possível classificar contabilmente tipos de atividade, diretamente, em lançamentos na contabilidade financeira. No
controlling é possível executar transferências de partidas individuais para tipos de atividade. No entanot, os custos classificados
contabilmente em tipos de atividade não serão considerados em uma distribuição subsequente. A classificação contábil direta
de tipos de atividade reflete-se imediatamente sobre a decomposição de custos reais.
O sistema pressupõe que os custos classificados contabilmente diretamente sobre tipos de atividade estejam correta e
completamente atribuídos a tipos de atividade. Os tipos de atividade classificados contabilmente diretamente não tomam lugar
na 1ª etapa de decomposição. Efetua-se somente uma repartição nos custos fixos e variáveis. Na 2ª etapa de decomposição, os
custos independentes da atividade são também repartidos sobre os tipos de atividade da classificação contábil direta.
16.4 Conciliação de CO com FI
Este procedimento é usado para conciliar lançamentos entre empresas, área funcionais ou divisões em CO. Em CO, pode ser
gerado um débito em um centro de custo que pertença a uma empresa e o crédito corresponde pode ser gerado em um outro
centro de custo que pertença a uma outra empresa. Para efeito de FI, houve um lançamento unilateral nas duas empresas. Para
CO isto é totalmente possível, mas, para FI é necessário um lançamento de ajuste. Para isto, é executada a função de
conciliação que irá identificar estas situações e gerar os lançamentos de conciliação necessários.
A conciliação pode ser executada a qualquer momento dentro de um período e pode, inclusive, ser executada mais de uma vez.
No entanto, recomenda-se sua execução somente no final do período para garantir que todos os lançamentos foram feitos em
CO antes da conciliação. Se a conciliação for executada mais de uma vez, o sistema gera valores de diferença desde a última
conciliação.Se for reprocessada a conciliação dentro de um mesmo período, o R/3 irá atualizar somente as diferenças geradas
após a última conciliação, ou seja, não é refeito todo o processo e, a cada nova execução, gera novos lançamentos.
Se a empresa deseja tem balanços separados por divisão ou até mesmo por centros de lucro, é necessário que este mesmo
procedimento de conciliação seja feito também para estas unidades organizacionais. O sistema determina os montantes
alocados entre empresas, áreas funcionais e divisões através das alocações de atividades, distribuição e reclassificação de custos
para a conciliação. Estas informações são transferidas para FI porque possuem um efeito direto no balanço e lançamentos de
receitas.
Para possibilitar a conciliação, é necessário criar contas de ajuste em FI e a chave de lançamento (posting key). Na
Contabilidade de Classe de Custos, estas contas devem ser associadas às transações de negócio, classes de objetos ou um
combinação de ambos, especificando as contas para débito e crédito. (determinação de contas). As contas também podem ser
determinadas através de substituição. Assim como as contas, também é preciso definir as chaves de lançamento.
Por questões fiscais, um fluxo de custos, entre empresas, ocorrido em CO, somente pode ser transferido para FI se as empresas
constituírem um sociedade integrada sujeita a impostos de vendas. Se necessário, definir regras lógicas para os lançamento de
conciliação.
Lançamento de conciliação fora do período tem o período de lançamento em FI diferente do de CO. No sistema de informação,
pode ser verificado os saldos contábeis entre CO e FI para um período particular usando relatórios de conciliação. Neste
relatórios, o sistema mostra uma diferença para um lançamento de conciliação feito fora de um período. O relatório de fluxo de
custos é mais adequado para a conciliação em FI e CO.
Se a empresa estiver trabalhando com balanço patrimonial por divisão, é preciso determinar fluxo de valores entre divisões e
gerar o lançamento de conciliação correspondente. Se estiver usando áreas funcionais para analisar lucros e perdas usando
Contabilidade de Custos de Vendas, os lançamentos internos de CO que gerem uma alteração na área funcional também
precisam ser transferidos para CO.
Não existe substituição para a área funcional para lançamentos de conciliação. A substituição pode conduzir a um erro no fluxo
de valores de CO. O sistema, portanto, não seria capaz de considerar estes valores em FI.
Se estiver usando preços fixos para avaliações de Centro de lucro em PS, então os lançamento de preço fixo para receptores e
emissores ocorrem em classes de custos diferentes. Isto pode significar que seguindo o lançamento de conciliação, o saldo das
classes de custos, onde as alocações de preço fixo ocorreram, são diferente em FI e CO. Para verificar no Sistema de
Informação se alocações de preço fixo estão causando diferenças nos saldo, define suas próspria classes de custos para preços
fixos.
16.5 Transferência de valores no planejamento de Centros Custos / Ordens Internas
Esta funcionalidade permite trazer de outros componentes do R/3 informações para o planejamento de centros de custos ou
ordens. As informações disponíveis são:
CONTROLADORIA 64 de 325
KPHR – Custos de pessoal do HR (custos primários para os centros de custos calculado no HR conforme a alocação dos
funcionários nos diversos centros de custo);
S_ALR_87099918 – Depreciação / Juros AM (valor das depreciações e juros dos bens do ativo imobilizado definidos
conforme o objeto de custo do bem – centro de custo ou ordem – no período do planejamento). O valor da classe de custo
será sobreposto. Se o tipo de atividade estiver definido no cadastro do bem, o custo será importado como dependente da
atividade – custo variável. Caso contrário, é considerado custo fixo;
KSPP – Atividade alocada PP – somatório das necessidades de atividades calculadas com base nas ordens planejadas
pelo MRP. Para planejamento de longo prazo. Para transferir as necessidades de atividades de PP primeiro é preciso
efetuar o planejamento manual dos centros de custo/tipo de atividade para criar um registro com esta relação no
planejamento. Isso pode ser feito, por exemplo, copiando o planejamento de outra versão ou período. Caso não encontre
um registro com a relação, o sistema emite mensagem de erro. Após a transferência, com êxito, é preciso executar a função
de conciliação do plano para que os valores trazidos de PP sejam efetivamente atualizados em CO.;
KVA4 – Índice estatísticos independente da atividade – extraído do SIL (Sistema de Informação de logística conforme
parametrizado no registro mestre do índice estatístico);
KVD4 – Índice estatísticos dependente da atividade – extraído do SIL (Sistema de Informação de logística conforme
parametrizado no registro mestre do índice estatístico);
16.5.1 Transferência de Depreciação e Juros (S_ALR_87099918a46)
O R/3 permite que sejam importados, para o planejamento de custos primários para os centros de custos e/ou ordens, os valores
de depreciação e juros periódicos de qualquer área de depreciação real da Contabilidade do Ativo. O programa permite
parametrizar se os valores de depreciação de um ativo vinculado a uma ordem deve ser lançado na ordem ou no centro de custo
com o qual ela está vinculada.
As definições das classes de custo que irão receber os valores é definido em AM (transação AO90 – Atribuir contas do razão).
Mesmo para os grupo de contas que não tem cálculo de depreciação, as contas devem ser parametrizadas para que a importação
possa ser efetuada.
O procedimento para cálculo da depreciação planejada é semelhante ao cálculo da depreciação simulada. O cálculo é feito tanto
para ativos já capitalizados como para investimentos planejados seja em OS (projeto – elemento PEP), IM (programa de
investimento) ou no próprio CO (Ordens Internas). Para os investimentos planejados, podem ser definidos se deverão ser
considerados os valores planejados ou orçados. Os termos de depreciação considerado serão considerados os termos de
simulação da depreciação. No caso das ordens de investimento, os termos da depreciação simulada são informados no momento
do cadastramento da ordem. Para os elementos PEP e programas de investimentos os dados da simulação também estão no
registro mestre.
OBS: Os valores calculados sobrepõem os valores anteriores. Portanto, o programa pode ser reprocessados quantas vezes
necessário. No entanto, nenhum outro planejamento deverá ser efetuado manualmente nas contas atualizadas por esta função
uma vez que serão sempre sobrepostos.
Quando parte do valor do investimento já foi capitalizado (liquidado contra um ativo), o R/3 não ajuste a base de cálculo para a
simulação gerando duplicidade de valores. Para correção deste problema deve-se utilizar o parâmetro “Tratamento das
ativações do exercício atual” para ou desprezar os lançamentos de capitalização do ano corrente no ativo, ou subtrair os valores
referente às capitalizações da base de cálculo nas simulações.
Caso o sistema não encontre um centro de custo ou ordem para efetuar o lançamento, será gerada mensagem de erro e o
programa é interrompido. Este erro ocorre, particularmente, para ordens com regras explícitas de liquidação e o sistema não
consegue determinar um centro de custo já que não estará mais disponível no registro mestre.
Também é possível separar os valores em parte fixa e variável. Para isto é preciso que o planejamento seja dependente da
atividade (foi parametrizado para considerar o tipo de atividade e o registro mestre do ativo tem um tipo de atividade
informada) e seja informado o fator de turnos (informar 1quando não se aplica).
Parâmetro Descrição
Empresa Informar um intervalo de empresas para selecionar os ativos a serem considerados. Através do
botão de seleção múltipla podem ser definidas várias empresas independente de intervalo. (*)
CONTROLADORIA 65 de 325
Parâmetro Descrição
Investimentos planejados Investimentos planejados são Ordens de Investimento (CO), Projetos (OS) ou Programas de
Investimento (IM).
Versão do planejamento – informar a versão do planejamento para considerar os valores base de
cálculo das depreciações.
Exercício de aprovação – exercício em que foi aprovado o programa de investimento.
Seleções – Centro de
Custo
Informar um intervalo de centros de custos para os quais se deseja calcular os valores planejados
de depreciação. Opcionalmente, pode ser usada a seleção múltipla (*)
Opções – Área de
avalização
Uma área de avaliação representa a avaliação dos imobilizados para um determinado objetivo
(por ex., balanço comercial, balanço fiscal, balanço geral consolidado, avaliação de bens,
avaliação baseada em cálculo de custos, etc).
Informar a área de avaliação para determinação dos critérios.
OBS: Deve ser uma área de avaliação real
Período planejamento Informar o exercício para o qual devem ser calculadas as depreciações e o intervalo de períodos
dentro deste exercício.
Outras opções para o
planejamento
Versão – informar a versão do planejamento que deve ser atualizada.
Relatório de totais – se esta opção for selecionada será exibido o relatório resumido do
processamento.
Variante de exibição Selecionar a variante de exibição do realtório que irá ser gerado. A variante de exibição pode ser
criada ou alterada na tela de exibição do relatório. Ela define quais as colunas a serem impressas,
critérios para classificação dos dados, totais, etc..
Selecionar Imobilizado Permite importar a depreciação de apenas alguns ativos especificados.
Orçamento X
Planejamento
Definir se deseja que os dados dos investimentos planejados (ordens de investimento, projetos e
programas de investimentos) trabalhem com os dados orçados ou planejados.
Selecionar ordens Definir para quais as ordens de investimentos se deseja efetuar os cálculos
Tratamento das ativações
do exercício atual
Como o R/3 normalmente considera o valor total planejado para a ordem ou elemento PEP não
levando em consideração as depreciações efetuadas, é preciso selecionar uma das opções para
que:
1 – o valor já capitalizado não entre no cálculo da depreciação simulada ou
2 – o valor das capitalizações efetuadas no ano corrente sejam desprezadas permanecendo os
valores compondo a base de cálculo das depreciações simuladas.
Area de contabilidade de
custos
Definir as áreas de contabilidade de custos que irão receber valores
Chave de Distribuição Se a chave não for informada, o sistema irá calcular os valores período a período. Se a chave for
informada será efetuado o cálculo do total dos períodos definidos e distribuídos os valores
conforme a chave
Planejamento dependente
da atividade
Definir se deverá ser considerado o tipo de atividade definido no mestre de materiais para gerar o
planejamento dependente da atividade. Para os ativos sem tipo de atividade informado, o
planejamento será independente da atividade.
Planejamento
independente da
atividade
Neste caso, o tipo da atividade não será considerado e todos os planejamentos serão lançados
independente da atividade
Dicas
Em todas as funções de processamento onde precisam ser informados parâmetros para a execução de um programa, o R/3
permite que estes parâmetros sejam gravados em variantes de seleção de forma a minimizar digitação e erros.
Selecionar a opção de processamento background sempre que o volume de dados for grande para melhorar performance e
não sobrecarregar o sistema em horários de grande utilização. A execução através de jobs permite o processamento fora do
horário normal de trabalho e libera a estação para outras tarefas.
CONTROLADORIA 66 de 325
Sempre antes de executar o programa definitivamente, solicitar uma execução teste e verificar se o processamento foi
efetuado com sucesso para evitar necessidade de acertos e estornos que sobrecarregam o banco de dados.
16.5.2 Transferência de necessidades de atividades de PP
Esta funcionalidade permite que sejam importados para CO o consumo previsto de atividades pela produção com base no
planejamento efetuado em PP (Plano global, MRP ou Planejamento de Longo prazo). A transferência efetiva dos valores se dá,
na verdade, através da conciliação do plano. Portanto, o procedimento de transferência, na verdade, ocorre em três etapas:
O primeiro passo é a geração dos registros de planejamento para cada relação centro de custo/tipo de atividade para as quais PP
possa gerar necessidade de atividades. Isto pode ser feito manualmente através da transação KP26 – Planejamento de Prestação
de Serviços/Tarifas ou, também, através da função de copia de plano (KP97) copiando apenas estrutura sem valores . Caso o
sistema não encontre um registro, o programa gera uma mensagem de erro e nenhum valor é importado. Basta gerar o registro e
reprocessar.
O próximo passo seria execução desta transação para que o sistema gere a outra parte da relação que é o consumo de atividade.
Só que, neste caso, os receptores serão ordens de produção e não centros de custo. Este valores podem ser visualizados no
relatório gerado pelo processamento ou, posteriormente, pelos relatórios do planejamento (S_ALR_87013629 – Tipo de
Atividade: reconciliação). Nele são mostradas as quantidades de atividades alocadas para cada centro de custo / tipo de
atividade.
O último passo é a execução da Conciliação do Plano (KPSI) quando os valores irão, efetivamente, para o planejamento de
prestação de atividade dos centros de custos produtivos (localizados no final da cadeia dos ciclos de alocação).
O processamento é efetuado, individualmente, para cada centro (planta) de logística.
Controle de Transferência para versão / exercício
Parâmetro Descrição
Área de Contabilidade de
Custos
Informar CTS para Santanense e FTSH para Santa Helena
Versão Informe a versão para a qual os volumes deverão ser importados
Exercício Informe o exercício para o qual os volumes de atividades deverão ser importados.
Transferência da necessidade
de atividades de:
Define o critério a ser usado para o cálculo das necessidades de desempenho de cada
centro de custo.
Plano Global – as quantidades de produção criadas no planejamento global são
programadas e analisadas através dos roteiros ou perfis do planejamento global. Neste
caso, deve ser informado o número da versão do planejamento global a ser importada.
MRP – as ordens planejadas para produção interna, criadas no planejamento de longo
prazo ou no planejamento de necessidades, são programadas e analisadas através dos
roteiros.
Plan.Longo Prazo – as ordens planejadas criadas para produção interna, através de roteiros, são programadas
e analisadas, no âmbito do planejamento de longo prazo ou do planejamento de necessidades de material.
Neste caso, deve ser informado o Cenário de planejamento.
UltGrpProd Utiliza Grupo de Produtos
Indica se os dados do grupo de produtos ou do planejamento de material devem ser
transferidos do planejamento de vendas e operações (SOP-standard) para CO-CCA.
Cenário de planejamento Com o cenário de planejamento, são definidos os parâmetros de controle para o
planejamento de longo prazo. Isto significa, entre outros, o centro, no qual o
planejamento deverá ter lugar, o período de planejamento e as versões a ser planejadas,
das necessidades independentes previstas.
Informar o cenário de planejamento a ser extraído os dados.
CONTROLADORIA 67 de 325
Controle de Transferência para versão / exercício
Parâmetro Descrição
Nível Programação Informar qual a necessidade de capacidade a ser selecionada.
Planejamento detalhado
Planejamento de taxas de produção
Planejamento Global
Ultima transferência Data da última transferência de dados efetuada.
Principais parâ metros para execução da função:
Campo Ações do usuário / conteúdo
Efetuar adaptação de período Código que controla se as quantidades de atividade planejadas das ordens planejadas
ou SOP simuladas, situadas fora do período de transferência, serão transferidas ou não
como atividade alocada para a contabilidade de centros de custo.
Se este código estiver ativo, o sistema SAP R/3 transfere todas as quantidades de
atividade planejadas de todas as ordens planejadas ou SOP do cenário planejado
selecionado ou da versão de planejamento global selecionada, como quantidades de
atividade alocada para a contabilidade de centros de custo. Nisto, as datas situadas fora
do período de transferência serão de tal modo ajustadas, que todas as quantidades de
atividade alocada estarão no período de transferência.
Verificação relacionamento
com objeto
Controla se deve ser efetuadas algumas verificações nos dados básicos relacionados às
ordens planejadas ou as ordens de SOP.
Se este flag não estiver marcado as verificações não serão completadas e não serão
geradas mensagens de erros no log caso ocorram. Se as verificações forem efetuadas, o
tempo de processamento irá aumentar consideravelmente.
Nível de Detalhe listagem Centro de custo / tipo de atividade
Material / Centro
Ordem planejada / SOP
Exemplo de Execução de adaptação de período
No planejamento integrado para o exercício seguinte foi gerada no cenário planejado utilizado do planejamento a longo prazo
uma necessidade independente planejada de um produto acabado, no primeiro período do exercício seguinte. Os produtos semi-
acabados necessários à produção deste produto acabado, são gerados como necessidades dependentes, completa ou
parcialmente, no último período do exercício atual.
Da programação dos roteiros para a necessidade independente ou dependente resulta que algumas operações, completa ou
parcialmente, se encontram ainda no exercício atual.
Se o usuário tiver ativado o código, todas as quantidades de atividade destas operações são transferidas para o exercício
seguinte. Se o usuário não tiver ativado o código, então ,em operações, as quantidades de atividade que se encontram
parcialmente ou que não se encontram no exercício seguinte serão, respetivamente, transferidas parcialmente ou não serão
transferidas.
17 Sistemas de Informação
17.1 Visão Geral
No Sistema de Informação de CO estão disponíveis diversas ferramentas cada uma com características e aplicações
específicas:
CONTROLADORIA 68 de 325
Report Painter/ Report Writer – permite montar relatórios com dados de CO e de outros componentes do R/3. Vários
relatórios padrões já estão disponíveis mas o usuário poderá gerar seus relatórios de acordo com as suas necessidades
específicas. O Report Painter é uma ferramenta similar ao Report Writer, porém de uso mais fácil. Várias funções do
Report Writer também estão disponíveis no Report Painter mas o usuário não precisa estar familiarizado com os conceitos
do Report Writer para usar o Report Painter.
Drill down Reporting – usada em CO-PA e CO-PC. Utiliza características para classificar os dados transacionais
(empresa, cliente, área de contabilidade de custos, período, ano fiscal, etc.). Os key figures (índices calculados) são os
valores específicos dos dados classificados (custos diretos, vendas, etc.). Estes key figures podem ser usados em fórmulas
para geração de outros valores.
Reporting based on ABAP List Viewer (ALV) – ferramenta que gera relatórios detalhados em CO (a nível de partidas
individuais). Possui uma interface padrão e permite alteração através de variantes de exibição. Através destas variantes de
exibição podem ser substituídas colunas, incluídas novas colunas, alterado a largura ou a ordem das colunas, etc. Estas
variantes podem ser gravadas de maneira genérica (disponível para todos os usuários, neste caso, o nome da variante deve
ter uma barra na frente para indicar que não é padrão da SAP) ou específica (somente usada pelo usuário que a criou). Uma
variante de exibição, portanto, corresponde a novas formas de visualizar um relatório já montado alterando colunas,
tamanho de colunas, etc. Já uma variante de seleção corresponde ao conjunto dos parâmetros necessários para a geração do
relatório definidos quais os dados serão apresentados e não como serão exibidos.
Os relatórios são disponibilizados para execução por meio de uma estrutura hierárquica de árvore (menu na 4.6), uma para cada
aplicação dentro de CO. Os relatórios criados pelo usuário, podem ser incluídos nesta estrutura (menu na 4.6).
17.2 Report Writer/ Report Painter
Ferramentas para análise de dados sumarizados ou totalizados. No sistema de informação, os lançamentos podem ser avaliados
imediatamente após sua entrada no sistema permitindo chegar até o nível de documento. O Report Writer e o Report Painter
oferecem diversas opções de exibição, classificação, filtro e sumarização da dados.
Um relatório criado no Report Painter pode ser alterado no Report Writer. No entanto, após a alteração, não poderá ser mais
alterado no Report Painter.
No Report Painter, o usuário define a estrutura de linhas e colunas e a seleção geral dos dados. Report Painter pode acessar os
dados de um extrato, diretamente do banco de dados, ou de um arquivo. É possível criar relatórios individuais para cada
elemento de um grupo definido na seleção geral de dados. Por exemplo, é possível definir relatórios distintos para o nó de
sumarização total e cada um dos nós de grupo em uma estrutura hierárquica de centro de custo.
Todos os relatórios que estão disponível on-line também podem ser executados em background em horário predefinido. Esta é
uma ferramenta bastante útil para fechamentos mensais quando se precisa executar vários relatórios em diversas áreas da
empresa. Estes relatórios podem ser programados para execução num horário de menor utilização do sistema.
O Report Painter também pode ser usado para a definição de layouts de planejamento em Contabilidade de Custos Indiretos,
Demonstração de Resultados e Contabilidade de Centro de Lucro.
Em resumo, o Report Painter pode ser usado de três formas diferentes:
Definição de Relatórios em CO-OM, CO-PC e EC-PCA;
Definição de Layouts de planejamento em CO-OM, CO-PA e EC-PCA;
Definição de formulários para Relatórios Drill-down em CO-PC, CO-PA e EC-PCA.
17.2.1 Criar relatório
Biblioteca – Todo relatório pertence a uma biblioteca. A biblioteca define as características, índices de base e índices que
podem ser utilizadas em um relatório. Relatórios de um mesmo grupos devem estar numa mesma biblioteca. Os nomes de
relatórios só são unívocos em conjunto com o nome da biblioteca. Ao contrário, um grupo de relatórios pode ser identificado
univocamente através do respectivo nome.
As bibliotecas podem ser utilizadas, entre outros, para
a delimitação de relatórios de produção e de teste
a distinção entre relatórios de diferentes grupos de usuários
CONTROLADORIA 69 de 325
o agrupamento de relatórios SAP standard
a formação de classes de aplicação
Nome do Relatório – Um relatório corresponde à edição de dados de um banco de dados sob a forma de uma lista. A estrutura
de um relatório é determinada na definição do relatório. É possível definir:
a restrição global de características (por exemplo., empresa, ledger, etc.) para o relatório (seleções gerais);
as características (ou seja., campos como Conta, Período, etc.) que devem aparecer nas linhas e colunas;
os índices (ou seja, campos de valores como Custos na moeda de transação, etc.) que devem aparecer nas colunas;
os subtotais que devem ser criados nas linhas e colunas.
O layout de um relatório é definido por parâmetros de layout. Os valores propostos para os parâmetros podem ser retirados de
layouts standard que possam ser definidos de forma independente de um relatório.
Vários relatórios de uma biblioteca podem ser agrupados em um grupo de relatórios. Isto é útil, quando os relatórios agrupado
se baseiem nos mesmos dados ou dados semelhantes, já que a seleção de dados só terá de ser executada uma vez para cada um
dos grupos de relatórios.
O nome de um relatório próprio do usuário não deve iniciar com números ou com o “-“ pois estes caracteres são reservados
para os relatórios standard. O nome do relatório de usuário pode conter letras de A a Z, número de 0 a 9 e os caracteres
especiais “-“, “_” e branco. Possui no máximo oito caracteres.
17.3 Grupo de Relatórios
Para efetuar a saída relatórios, é necessário incluí-los em um grupo de relatórios. Um grupo de relatórios é um conjunto de
relatórios de uma biblioteca, que devem ser processados conjuntamente em uma execução. O agrupamento de vários relatórios
em um grupo de relatórios é conveniente, se os relatórios analisarem basicamente o mesmo conjunto de dados. Neste caso, os
dados são lidos apenas uma vez, sendo distribuídos pelos vários relatórios. Não é possível processar relatórios de bibliotecas
diferentes em um grupo de relatórios.
Quando é gerado um grupo de relatórios, são gerados vários programas ABAP (xxxx = grupo de relatórios; mm = mandante,
evtl. codificado):
Programa para o processamento da primeira tela
Programa para a seleção (leitura) dos dados
Programa para a saída dos dados selecionados
Programa para a seleção múltipla (seleção e saída múltiplas para vários dados de entrada; apenas no caso de estar marcado
o respectivo código)
Se, depois de gerado um grupo de relatórios, for modificada alguma definição de set ou relatório, na seleção seguinte o grupo
de relatórios será automaticamente gerado de novo, desde que esta função não tenha sido explicitamente desativada na
definição do grupo de relatórios. O nome de um grupo de relatórios deve ser formado por apenas 4 caracteres, sendo permitidos
somente os seguintes:
'A' a 'Z'
'0' a '9'
'-' e '_'
17.4 ABAP List Viewer (ALV)
Uma partida individual é gerada a cada transação executada. Para geração de relatórios, todos as partidas individuais são
armazenadas em registros de totais. Partindo de um relatório gerado no Report Painter ou Report Writer sobre os centros de
custos, o usuário pode querer analisar as classes de custos destes centros de custo chamando um relatório de partidas
individuais. Os relatórios de partidas individuais apresentam os custos reais, planejados ou compromissos como partidas
individuais e como documentos de lançamentos.
CONTROLADORIA 70 de 325
Relatório Resumido Partidas individuais Documento de Origem
Quando é feita uma inclusão de nova coluna, o R/3 irá selecionar automaticamente o texto breve e texto longo conforme a
largura da coluna. Se o idioma estiver disponível para o relatório, será usado o idioma do logon. Podem ser alteradas também a
ordem de classificação da colunas (crescente ou decrescente), estabelecer filtros. O filtro vale somente para exibir ou não das
linhas mas, mesmo ocultas, elas estarão incluídas nos totais. É possível, também, definir totais interativos selecionando a coluna
e seu total.
17.5 Configurações do Usuário / Gerenciamento de Extratos
No R/3 é possível definir valores propostos a nível geral ou a nível de usuário para os critérios de seleção de um relatório
(variantes de seleção) e para a moeda do relatório facilitando sua execução. As definições a nível de usuário sobrepõe as de
nível geral.
Os valores propostos que podem ser informados são: dados básicos (área de contabilidade de custos, centro de custo ou grupo
de centro de custo, classe de custo, etc.); configurações para gerenciamento de extratos, planning timeframe, reporting
timeframe, moeda do relatório e outras especificações, tal como a versão.
Os critérios de seleção definidos são válidos somente para os relatórios da árvore de relatórios e nos componentes de
Contabilidade de Custos Indiretos e Contabilidade de Centros de Lucro.
O usuário pode gravar extratos de relatórios o que permite consultar novamente o mesmo relatório sem a necessidade de
reprocessá-lo. Para criar um extrato, o usuário por selecionar Gerar Extrato antes de rodar o relatório ou no momento em que
for sair do relatório. As configurações para gerenciamento dos extratos possibilita a definição de três opções:
Nova seleção – o sistema será irá reprocessar o relatório
Extrato – se existir um extrato de acordo com o critérios de seleção definidos, o R/3 apresenta as opções de extrato para
seleção do usuário. Se não existir, gera novo relatório.
Exibição automática do relatório corrente – o R/3 automaticamente apresenta último extrato gerado.
É possível apresentar todos os extratos em um lista sintética, imprimir ou excluir ou alterar a sua data de expiração. A partir da
versão 4.5 já é possível lançar o planejamento no Excel integrado com R/3 conforme será detalhado nas funções de
planejamento.
17.6 Relatórios Drilldown
As funções da geração de relatórios drilldown são divididas em três níveis de forma a permitir fornecer para cada usuário
somente as funções que ele necessitar. O primeiro nível contém as funções básicas e mais a opção de envio de relatório pelo
SAPmail. O segundo nível contém o restante das funções do drilldown e mais a possibilidade de gerar gráficos e migrar dados
para Excel. O terceiro nível possui todas as funções do drilldown e mais a possibilidade de configuração de impressora e gravar
dados de relatórios e definir exceções. Este nível é atribuído aos usuários que necessitem imprimir e modificar relatórios.
O nível do usuário é definido no parâmetro RLV (0 = todas as funções, 1 = nível 1 e 2 = nível 2). É importante lembrar que os
níveis de função individual está sujeito a verificações de autorizações.
OBS: É possível parametrizar o SAP-mail para que suas mensagens sejam reencaminadas para um e-mail externo ao R/3.
Os relatórios de Drill-down também usam o Report Painter para definição de formulários usados em CO-PC, CO-PA e EC-
PCA. Um formulário define o conteúdo e a estrutura formal do relatório. Pode ser considerado como um relatório semi-acabado
que será completado com a definição das características e dos key figures. O conteúdo de um relatório normalmente é fixo e, se
alterado, afeta todos os relatórios que o utilizam.
FORMULÁRIOS
Ano Anterior Ano Corrente Variação
CONTROLADORIA 71 de 325
KEY FIGURES
Orçado Real
RELATÓRIO
Orçado Real
Ano Anterior Ano Corrente Variação Ano Anterior Ano Corrente Variação
17.7 Logistics Data Wharehouse
No Customizing de Logística geral estão disponíveis as seções Base de dados e Atualização que constituem o Logistics Data
Warehouse (até agora: banco de dados estatísticos).
17.7.1 Aplicações definidas pelo usuário
No sistema de informação de logística, diversas configurações devem ser efetuadas de acordo com a aplicação. O sistema
propõe geralmente as aplicações standard que fazem parte do sistema de informação para logística. Diversas considerações a
serem realizadas no SIL, no entanto, exigem funções válidas para todas as aplicações. Por exemplo, agrupar informações de
aplicações diferentes em conjunto (dados de compras e vendas e distribuição, dados de produção e vendas, etc.).
Para análises com dados de diversas aplicações, é preciso definir uma aplicação que possua características de várias aplicações
standard.
Primeiro são propostas todas as aplicações SAP que estão integradas no sistema de informação para logística. Nesta base é
possível organizar as "aplicações mistas" necessárias para a empresa.
A transação de manutenção de aplicações permite, é possível criar, modificar e exibir aplicações definidas pelo usuário.
Customizing Logísticia Geral Sistema de Informação para logística (SIL) Logistics Data Warehouse Base de
Dados Apliações Atualizar aplicações definidas pelo usuário (OMOA) Criar ; (OMOB) Modificar ; (OMOC) Exibir
Atividades
1. Selecionar a função Aplicação nova.
Passa-se para a tela de detalhes.
2. Entrar um número para a aplicação definida pelo usuário.
3. Entrar um texto para a aplicação definida pelo usuário.
4. Atribuir a esta aplicação definida pelo usuário as características de pelo menos uma das aplicações standard propostas.
5. Gravar a aplicação definida pelo usuário.
Informações adicionais
As aplicações definidas pelo usuário podem ser utilizadas nas áreas seguintes:
definição de catálogos de campos
definição de estruturas de informação
17.7.2 Catálogo de Campos
Geralmente, todas as informações utilizadas nas operações comerciais correspondentes podem ser a base para o agrupamento e
a compactação de dados de aplicação nas estruturas de informação. Muitas destas informações, porém, servem mais para o
controle interno de uma operação comercial do que para a atualização de dados estatísticos.
CONTROLADORIA 72 de 325
O usuário que pretende definir um sistema de informação individual através de estruturas de informações (InfoSet) definidas
pelo usuário, deve ter uma visão clara no que diz respeito às informações que podem ser utilizadas para o Logistics Data
Warehouse o que é possível através da definição de catálogos de campos.
Um catálogo de campos (no sentido da atualização das estatísticas) define um grupo de campos relevantes da aplicação. Podem
ser misturados campos provenientes de qualquer hierarquia de documentos. Por exemplo, é possível agrupar em um catálogo de
campos todos os campos que têm a ver com a organização comercial (canal de distribuição, região de vendas, hierarquia de
produtos etc.). Para o usuário, não faz diferença se estes campos são utilizados no cabeçalho do documento, no item de
documento ou a nível de divisão.
Um catálogo de campos determina a seleção das informações relevantes e o agrupamento lógico destas informações.
OBS: Nomes compridos não são suportados em SIL. O usuário só pode incluir no catálogo de campos os nomes de tabelas, de
estruturas e de campos que não sejam maiores do que 10 caracteres.
17.7.3 Estruturas de Informação
Em um sistema de informação, a compactação de dados é necessária para a transparência de relações importantes. Visto que as
exigências para a compactação de dados são determinadas por muitos diferentes grupos de usuários, uma especificação rígida
da compactação não é suficiente. A experiência mostra que diferentes grupos de usuários necessitam de visões diferentes da
compactação de dados.
Para representar estas diferentes visões, o sistema SAP oferece as estruturas de informação definidas pelo usuário.
Nestas estruturas de informação, o usuário define a visão individual, selecionando, da aplicação operativa, as informações
consideradas como relevantes para a compactação. As informações a serem definidas para uma estrutura de informação estão
relacionadas na tabela abaixo.
Informações Descrição
Características Para cada estrutura de informação, é possível definir no máximo nove características que compõem a
chave de tabela da tabela do banco de dados.
Índices Índices são valores significantes sob o ponto de vista empresarial que devem ser compactados com base
nas características (por exemplo faturamento, quantidade de entrada de ordem, quantidade do pedido,
tempo do ciclo de produção).
Matriz do período A acumulação periódica de dados é outro critério de compactação importante. Os índices são
compactados diariamente, semanalmente ou mensalmente, ou em função de uma matriz do período
variável que é determinada através da variante de exercício.
É possível classificar as estruturas de informação de acordo com certas características de estrutura. A maior parte das estruturas
de informação fornecidas no sistema standard é igual em sua estrutura básica (por exemplo contêm 4 campos de período). As
estruturas de informação com o mesmo código possuem a mesma estrutura.
Tipos de Estruturas de Informação em SIL
Código Nome Descrição
Standard Estrutura de informação com dados periódicos do movimento. Este tipo é o tipo normal.
C Sem período Estrutura de informação que não contém dados periódicos. Contém valores atuais do estoque
como, por exemplo, o índice “Estoque”.
D Sem atualização Esta estrutura de informação não contém dados reais (talvez dados planejados). Por isso, não é
possível criar para ela nenhuma atualização. É utilizada para garantir a exibição periódica de
valores de estoque. Os dados reais encontram-se em uma estrutura de informação atribuída do tipo
standard e do tipo sem período. A respectiva análise standard lê os dados das estruturas de
informação atribuídas e executa um cálculo retroativo do estoque.
E Standard (Com
valores do
estoque)
Estrutura de informação que contém também valores periódicos do estoque, além de outros
códigos periódicos. Estes valores do estoque precisam ser aceitos ao final do período (ou seja, em
um determinado momento) através de um programa batch.
CONTROLADORIA 73 de 325
Tipos de Estruturas de Informação em SIL
Código Nome Descrição
F Análise de
Documentos
Estrutura de informação utilizada para a exibição de dados do documento. Estas estruturas de
informação estão sujeitas a várias medidas de performance devido ao volume de dados esperado
(por exemplo: planejamento não permitido). Além disso, são possíveis outras funções na análise
standard (por exemplo: análise total de documentos). Área de implementação: análise do cesto de
compras - IS-R.
T Transferência
para SAP-BW
Estrutura de informação especial para a transferência ao Business Information Warehouse (BW)
que não pode ser utilizada no reporting. Estas estruturas de informação estão sujeitas a diversas
medidas de performance devido ao volume de dados esperado (por exemplo planejamento não
permitido).
A utilização dos tipos acima mencionados depende da aplicação nas quais elas devem ser criadas:
Tipo Aplicação
todas (standard)
C 01 – SD
03 – Controlling de estoques
40 – Administração de mercadorias
D 03 – Controlling de estoques
40 – Administração de mercadorias
E 03 – Controlling de estoques
40 – Administração de mercadorias
F 40 – Administração de mercadorias
Ao ser criada uma estrutura de informação própria do usuário através do atributo Planejamento possível , decidir se esta é
relevante para o planejamento SIL ou não. Um estrutura de informação do tipo 'C' ou do tipo 'F' não pode ser marcada como
relevante para o planejamento.
É importante considerar, porém, se a estrutura de informação a ser criada deve ser utilizada no planejamento, pois uma estrutura
de informação que não pode ser incluída no planejamento aumenta consideravelmente a velocidade da análise no momento do
reporting. No caso de uma estrutura de informação não relevante para o planejamento, ocorre na tabela uma conversão dos
campos de chave atuais, de modo que os campos não relevantes (SSOUR, campos de período não necessários) sejam
posicionados ao final dos campos de chave.
Isto agiliza a procura no banco de dados. Se a estrutura de dados definida pelo usuário deve ser preenchida com dados, o índice
primário verifica a respectiva chave de tabela. A versão 000 é sempre utilizada como critério de procura. O mandante é sempre
a primeira posição na chave de tabela; caso contrário, toda tabela no ABAP Dictionary será interpretada como independente do
mandante. As características são diretamente posicionadas na chave de tabela após os mandantes.
As seções da chave de tabela apresentam-se da seguinte maneira:
Mandante - Característica - Versão - ...
Ao ativar a atualização, a chave de tabela é novamente convertida, de modo que o período selecionado para a atualização
apareça primeiro.
Exemplo:
Mandante - Mês - Características - Versão - ...
A fim de evitar uma perda acidental dos dados, a conversão dos campos de chave de uma estrutura de informação não relevante
para o planejamento só deve ocorrer se a respectiva tabela do banco de dados não contiver nenhum dado.
Observar o seguinte:
Uma estrutura de informação relevante para o planejamento só pode ser definida e atualizada com um período (dia,
semana, mês ou período contábil) em todos os mandantes de um sistema.
A modificação do período leva a uma conversão dos campos de chave e só pode ser executada se nenhum dos clientes
não possuírem mais dados na tabela do banco de dados.
CONTROLADORIA 74 de 325
As estruturas de informação definidas pelo usuário e as standard representam a base para todas as funções subseqüentes no
sistema de informação (por exemplo análises, planejamento).
17.7.3.1 Manter as estruturas de informações
Customizing Logísticia Geral Sistema de Informação para logística (SIL) Logistics Data Warehouse Base de
Dados Estruturas de Informaçãos Atualizar estruturas de informação definidas pelo usuário (MC21) Criar ; (MC22)
Modificar ; (MC23) Exibir
Nesta etapa, o usuário pode criar, modificar, eliminar e exibir as estruturas de informação. As novas estruturas de informação
definidas pelo próprio usuário devem possuir um nome de 4 caracteres, que deve se situar entre S501 e S999. As estruturas de
informação que foram criadas com outros nomes antes do release 3.0, podem continuar a ser utilizadas.
Para criar uma estrutura de informação que deve conter campos de diferentes aplicações, uma aplicação definida pelo usuário
deve ter sido anteriormente definida.
Estruturas de informação só poderão ser modificadas ou eliminadas, se elas não contiverem nenhum dado. Se a estrutura de
informação em questão contém dados, ela deve ser eliminada em primeiro lugar. Ao eliminar uma estrutura de informação,
todas as regras de atualização a ela atribuídas serão eliminadas em todos os mandantes.
Atividades
1. No campo Estrutura info, indicar um nome e uma descrição para a estrutura de informação que se deseja criar.
2. Atribuir a estrutura de informação a uma aplicação.
3. Através do atributo, o usuário determina o tipo de uma estrutura de informação. É também possível determinar se esta
estrutura de informação pode ser planejada. Se uma estrutura info foi criada com determinados atributos, estes não
poderão mais ser modificados.
OBS: Para criar uma estrutura de informação com referência a uma estrutura de informação já existente, indicar no campo
Modelo estrutura info o nome da estrutura de informação referida. Os elementos da estrutura modelo serão automaticamente
copiados na nova estrutura de informação podendo ser alterada.
4. Se foi selecionado o tipo 'D' (sem atualização), indicar a estrutura de movimento (tipo ' ') e a estrutura de estoque (tipo 'C').
5. Selecionar Processar Características, para definir características à estrutura de informação. Serão exibidas 2 caixas de
diálogo para seleção das características. Na primeira caixa de diálogo (características selecionadas: seqüência), os campos
selecionados serão listados. Para a seleção de outros campos, selecionar a função Lista de seleção.
A segunda caixa de diálogo (lista de seleção) contém duas listas. Na lista à direita, encontram-se todos os catálogos de
campos, a partir dos quais as características poderão ser selecionadas. Para isso, somente serão exibidos os catálogos de
campos (catálogos de características) válidos para a aplicação selecionada. Para exibir características de um determinado
catálogo de campos, selecioná-las através de um clique duplo.
Na lista à esquerda da caixa, encontram-se as características do catálogo de campos selecionado. Para transferir uma
característica da lista à estrutura de informação, posicionar o cursor no nome da respectiva característica e selecionar a
função Transferir. A característica selecionada será marcada e transferida á lista das características selecionadas.
OBS: Na seleção dos catálogos de campos e características, as respectivas descrições serão exibidas. Com a função Trocar
exibição, serão exibidos os nomes técnicos (nomes dos catálogos de campos e nomes dos campos da característica do
Dictionary).
6. Para acessar a lista das características selecionadas, pressionar Enter. Esta lista poderá finalmente ser editada. Isto significa
que o usuário poderá modificar a seqüência das características, poderá eliminar as características da lista ou incluir novas
nos catálogos de campos. Para modificar a seqüência das características selecionadas, marcar a característica ou um bloco
de características que deve ser deslocado através do ícone Marcar/desmarcar. É exibido o ícone Deslocar. Então,
posicionar o cursor sobre uma outra característica e selecionar o ícone Deslocar. A primeira característica marcada, ou o
bloco de características, será incluída exatamente acima da segunda característica marcada.
OBS: Uma alternativa para a seleção das características a partir dos catálogos de campos é a cópia de características a partir de
uma estrutura de informação já existente. Para isso, selecionar a função Processar Características a partir de modelos . Em
uma caixa de diálogo, indicar o nome da estrutura de informação, da qual as características devem ser copiadas. Note que, se as
características já foram selecionadas, e a função de cópia de um modelo é uitlizado, as características já selecionadas serão
sobregravadas, e não completadas.
CONTROLADORIA 75 de 325
7. Para definir índices para a estrutura de informação, selecionar Processar Índices. O sistema exibe os catálogos de
campos para índices e os catálogos para os campos de datas que se referem à aplicação. Na definição de índices, proceder
da mesma maneira que na definição para características.
Às vezes, é necessário definir índices semelhantes às características, na área de índices. Isto é importante, por exemplo, em caso
de uma estrutura de informação relativamente específica a um documento. Os catálogos de índices fornecidos pelo sistema
standard contêm somente índices calculáveis. Para definir índices semelhantes às características, os catálogos de índices
próprios do usuário devem ter sido definidos.
Ao definir um índice, indicar uma unidade (moeda para valor ou unidade de medida para quantidade). Com isso, especifica-se
em qual unidade o índice deve ser executado na estrutura de informação (por exemplo, moeda do documento, moeda interna,
unidade de medida de pedido, unidade de venda). Assim, a unidade do campo fonte será proposta a partir da aplicação.
A unidade do índice pode ser diferente desta proposta. Por exemplo, se em uma estrutura de informação forem utilizados
índices semelhantes, cujos campos fonte possuem diferentes unidades (p.ex. moeda interna e moeda do documento), estes
índices não serão diretamente comparáveis em caso de moeda interna e moeda de documento diferentes.
Neste caso, pode-se atribuir a unidade Moeda interna ao índice, cujo campo fonte se encontra na moeda de documento, para
fins de estatística. Se as unidades do campo fonte e índice forem diferentes, elas serão automaticamente convertidas no
momento da atualização das estatísticas da aplicação. O uso de conversão de moedas deve ser evitado.
Para a atualização das estatísticas, somente um determinado número de conversões é permitido. Trata-se em geral das
conversões de unidades, cujos fatores de conversão encontram-se armazenados no documento da aplicação. Isto é importante
para a consistência das atualizações de estatísticas, em caso de modificações de documentos. Com isso, evitam-se as diferenças
entre a criação de um documento e sua modificação posterior. Em ambos os casos, será utilizada a mesma taxa de câmbio para
a conversão de unidades.
Na geração da estrutura de informação, será criado automaticamente um respectivo campo de unidade em função da unidade
selecionada. No momento da atualização, este campo de unidade será automaticamente suprido por esta unidade que
corresponde ao índice. A geração automática de um campo de unidade não ocorre em caso de índices sem unidade e em caso
de contadores. Existe a possibilidade de utilizar unidades definidas pelo usuário para os índices também definidos pelo usuário.
Se no log forem exibidas as entradas em falta da tabela TMC6 e TMC24 para índices definidos após a verificação ou geração,
executar Atualizar unidades.
Para a definição de um índice, sua utilização também é importante nos casos de análises standard.
Ao utilizar índices qualitativos, não é adequado apresentá-los de modo percentual.
Por exemplo, se o valor do índice 1,5 a ser avaliado for maior que o valor do índice 3,5, não faz sentido a apresentação de
ambos os índices como percentual de uma soma de 5,0.
Com o código "SKz" (código de totalização), indica-se se os valores dos índices podem ser acumulados de forma adequada.
Esta informação é necessária para as análises standard durante a formação de totais, durante a execução das funções das
análises ABC, classificação e segmentação, assim como para o copy management.
Atenção
Este código não afeta a apresentação de totais em caso de análises flexíveis.
Nas estruturas de informação, para as quais foi definido o atributo Planejamento possível , é possível marcar com o código
"FKz" (código fixo), de modo que os valores deste índice sejam fixados no quadro de planejamento do planejamento
flexível.
Durante a geração, é gerado um campo adicional com o prefixo "F".
Exemplo: se o nome do campo for AETNETWR, será gerado um campo com o nome FAETNETWR na tabela dictionary e
na tabela do banco de dados. Na estrutura de informação, porém, este campo não é exibido.
Nas estruturas de informação do tipo 'D' (sem atualização) ou do tipo 'E' (standard com valores de estoque), os valores de
estoque são marcados através do código "BWt" (valor de estoque).
Para os valores de estoque com uma estrutura de informação do tipo 'D' (sem atualização), o usuário tem que definir o
valor do estoque na estrutura de informação de estoque do tipo 'C' (sem período), assim como os valores de entrada e saída
na estrutura de informação de movimento do tipo ' ' (standard). Isto é efetuado através de Processar -> Índices de
entrada/saída.
8. Gravar a estrutura de informação.
CONTROLADORIA 76 de 325
9. Para gerar a estrutura de informação, selecionar Estrutura info Gerar. Durante a geração, é criada a tabela dictionary e
a respectiva tabela do banco de dados para a estrutura de informação Snnn e a tabela para a hierarquia de planejamento
SnnnE (nnn é o número da estrutura de informação).
As etapas importantes para esta geração serão listadas em um log, que exibe a geração bem sucedida de cada etapa, assim como
eventuais erros que possam surgir. Primeiramente, obtém-se uma síntese das etapas mais importantes da geração (resumo do
log de geração). Posicionar o cursor sobre uma linha no log e selecionar Saltar Detalhe log , a fim de obter uma síntese
geral do objeto criado; ou selecionar função Saltar Log completo , para ver todo o log. Com Saltar -> Documentação, o
usuário obtém o número da mensagem e o texto descritivo, caso exista, para a mensagem, o que é importante para a correção de
um erro. Para imprimir o log, selecionar a função Log -> Imprimir.
10. Exibir objetos gerados. - Posicionar para isso o cursor na respectiva linha do log e selecionar Saltar -> Objeto gerado.
Acessa-se o Dictionary, para exibição da tebela gerada.
Funções adicionais
Para maiores informações sobre as características selecionadas e índices, encontram-se à disposição as seguintes funções:
Exibição de informações técnicas dos campos
Exibição da documentação de campos
Exibição de atributos gerais
Caso o usuário necessite de informações técnicas exatas sobre as características ou índices, selecionar a função Processar
Informações técnicas dos campos.
Em uma caixa de diálogo, serão apresentadas as seguintes informações:
o nome do campo da característica ou do índice, como ele será criado na estrutura de informação e na tabela Dictionary
correspondente. O nome deste campo é um valor proposto a partir do nome do campo de referência, e pode ser
sobregravado.
o nome da tabela de referência e do campo de referência, a partir dos quais os atributos técnicos para os campos serão
copiados na estrutura de informação. Estes campos também poderão ser sobregravados.
o nome do elemento de dados correspondentes e o domínio do campo de referência
o nome do campo fonte auxilia aqui somente a documentação. Ele será proposto na definição das regras de atualização
como campo fonte.
Para os atributos técnicos do índice, é importante a exibição da unidade do campo fonte. Dependendo desta unidade fonte,
são permitidas somente algumas conversões de unidades na unidade do índice.
Para exibir a documentação do campo, posicionar o cursor em uma característica ou índice e selecionar Processar Exibir
documentação campo. É exibida a documentação do respectivo campo de referência.
Através de Processar Atributos gerais, será exibido o nome da tabela Dictionary, que pertence à estrutura de informação.
Esta exibição só ocorrerá se a estrutura de informação tiver sido gravada ou gerada.
Através de Utilitários Atributos de transporte, existe a possibilidade de modificar os atributos de transporte (classe de
desenvolvimento) de um objeto.
Com Ambiente, pode-se acessar qualquer definição de atualização de uma estrutura de informação, ou ainda a exibição do log
de geração de uma estrutura de informação.
17.7.3.2 Classe de desenvolvimento para transport organizer
Os objetos relacionados do ABAP Workbench são agrupados em uma classe de desenvolvimento. A atribuição de um objeto a
uma classe de desenvolvimento é anotada no catálogo de objetos (TADIR). A classe de desenvolvimento define, através do
nível de transporte, as características de transporte do objeto.
No Change & Transport System é possível a distribuição do desenvolvimento de projetos grandes por vários sistemas R/3. As
classes de desenvolvimento de cada um dos sistemas de desenvolvimento são agrupadas a um nível de transporte. O nível de
transporte determina se os objetos são atribuídos a um change request local ou a um transportável.
CONTROLADORIA 77 de 325
A cada um dos sistemas de desenvolvimento R/3 é atribuído um nível de transporte como nível de transporte standard. Ao
utilizar o controle ampliado de transporte, é possível atribuir níveis de transporte standard divergentes aos mandantes
individuais. Para cada sistema R/3 e nível de transporte é possível definir, no máximo, um destino de consolidação.
Ao criar uma classe de desenvolvimento, a esta é atribuído o nível de transporte standard do sistema R/3. Porém, se se
pretender atribuir a uma classe de desenvolvimento um nível de transporte diferente do nível de transporte standard, é
necessária a autorização de administração na área Change and Transport System.
Os objetos de uma classe de desenvolvimento transferem as características de transporte determinadas para o nível de
transporte atribuído:
Se para o nível de transporte estiver definido um caminho de consolidação em saída do sistema R/3 atual, os objetos são
atribuídos a uma ordem transportável e, após a sua liberação, transportados para o destino de consolidação.
Se não estiver definido nenhum caminho de consolidação, os objetos são atribuídos a uma ordem local e não são
transportados.
Opções customizing não estão atribuídas a nenhuma classe de desenvolvimento. Por isso, o usuário transfere as características
de transporte do nível de transporte standard do sistema/mandante atual. Assim, geralmente, é adequado atribuir um nível de
transporte standard a um sistema de desenvolvimento, etapa essa para a qual está definido um caminho de consolidação em
saída do sistema de desenvolvimento.
Para exibir e modificar os níveis e caminhos de transporte, há que utilizar o Transport Management System (transação STMS)
As modificações só podem ser executadas pela administração de sistema.
As tabelas TSYST, DEVL, TWSYS, TASYS já não são produtivas a partir do release 40A e já não podem ser atualizadas.
A descrição das classes de desenvolvimento está anotada na tabela TDEVC. È possível atualizar as classes de desenvolvimento
através das seguintes transações:
Transação SE80 - inscrever classe de desenvolvimento - clique duplo na classe de desenvolvimento
Transação SM30 - tabela/visão V_TDEVC
As próprias classes de desenvolvimento são objetos do ABAP Workbench e são sempre tidas como classes de
desenvolvimento.
Ao criar um novo objeto do ABAP Workbench, é enviada uma janela de entrada, na qual é necessário atribuir o objeto a uma
classe de desenvolvimento existente. A classe de desenvolvimento deve descrever a área funcional à qual o objeto pertence. A
classe de desenvolvimento serve também como critério de navegação na representação da árvore de objetos no ABAP
Workbench (transação SE80).
Se existirem muitos objetos de uma categoria de objeto (por exemplo, programas ABAP) em uma classe de desenvolvimento, a
representação da árvore de objetos é confusa e a utilização do ABAP Workbench é dificultada. Aqui, a SAP recomenda criar
novas classes de desenvolvimento no mesmo nível de transporte, e distribuir os objetos pelas novas classes segundo critérios
temáticos.
Existem as seguintes convenções de nomes para classes de desenvolvimento que definem características funcionais da classe de
desenvolvimento:
A classe de desenvolvimento começa por A-S ou U-X: Estas classes estão reservadas para os objetos do standard
SAP. Os objetos definidos pelo usuário não podem ser criados em uma classe destas. As modificações de objetos desta
classe são registradas pelo Transport Organizer. É possível transportar os objetos para outros sistemas SAP.
A classe de desenvolvimento começa por Y ou por Z: Em uma classe destas, é possível criar objetos definidos pelo
usuário. As modificações de objetos desta classe são registradas pelo Transport Organizer. É possível transportar os
objetos para outros sistemas SAP
A classe de desenvolvimento começa por T (classe de teste privada: Ao criar esta classe, é possível determinar se o
registro de modificação é ativado. Se tal for pretendido, os objetos são registrados em solicitações locais no
processamento do Transport Organizer. Esta classe não pertence a qualquer nível de transporte. Os objetos só podem
ser transportados para outros sistemas SAP através da criação de uma solicitação de transporte.
A classe de desenvolvimento começa por $ (classe local): As modificações de objetos desta classe não são
registradas pelo Transport Organizer. A classe não pertence a qualquer nível de transporte. Não é possível transportar
os objetos.
CONTROLADORIA 78 de 325
A classe de desenvolvimento começa por um prefixo de conjunto de nomes: Caso o usuário tenha reservado para si
um conjunto de nomes, então é possível criar classes de desenvolvimento (e também outros objetos) neste conjunto de
nomes, classes essas cujos nomes começam pelo prefixo do conjunto de nomes. (Exemplo de um prefixo de conjunto
de nomes /COMPANY/, exemplo de uma classe de desenvolvimento correspondente /COMPANY/DEVCLASS)
As modificações de objetos desta classe de desenvolvimento são registradas pelo Transport Organizer e podem ser
transportadas.
17.7.3.3 Executar atualizações em massa
Nesta etapa é possível gerar estruturas de informação e atualizações simultaneamente em grandes quantidades.
Ao contrário da possibilidade da marcação para geração nova, na geração em massa a geração é efetuada imediatamente, quer
dizer não só na altura do próximo acesso. Além disso, nesta etapa não só podem ser gerados elementos dependentes, como por
exemplo análises standard e programas de planejamento, mas também tabelas de banco de dados para estruturas de informação.
A geração em massa de estruturas de informação oferece a possibilidade de restringir a seleção das estruturas de informação de
forma que, por um lado, estruturas de informação são geradas segundo versões revisadas já existentes, ou, por outro lado, que
só se efetua a geração posterior das versões já geradas, quer dizer versões revisadas não são consideradas.
O usuário pode diferenciar a geração em massa ainda mais selecionando para a geração as tabelas de banco de dados
pertencentes às estruturas de informação indicadas ou componentes dependentes das estruturas de informação (por exemplo
estruturas de análise, telas de planejamento).
A geração em massa de atualizações efetua-se em dependência da estrutura de informação e do grupo de atualização.
Quando se pretende executar este programa em background é preciso indicar uma variante.
Atividades
1. Para gerar estruturas de informação procede-se da maneira seguinte:
a) Entrar nos campos De e Até os limites de intervalo para a seleção das estruturas de informação.
b) Marcar as opções de seleção conforme as exigências do usuário.
2. Para gerar atualizações procede-se da maneira seguinte:
a) Entrar nos campos De e Até os limites de intervalo para a seleção das estruturas de informação.
b) Entrar nos campos De e Até os limites de intervalo para a seleção dos grupos de atualização.
3. Gravar as entradas.
4. Selecionar Programa -> Executar.
17.7.4 Atualização das características e índices das várias operações comerciais
Com a definição das estruturas de informação, o usuário cria a base para um sistema de informação individual. Através da
definição da atualização é determinado o fluxo de informações dos dados estatísticos da aplicação para o sistema de
informação.
Existem dois tipos diferentes do controle de atualização:
17.7.4.1 Controle Geral através da aplicação via Grupo de Atualização
Muitas vezes, é necessário que as várias transações comerciais influenciem a atualização das estatísticas. Isto em geral significa
que certos elementos organizacionais (por exemplo organização de vendas, tipo de documento, grupo de clientes) na aplicação
podem contribuir com a atualização. Visto que os elementos influenciadores nas várias aplicações são diferentes, é necessário
um elemento de controle standard. O grupo de atualização representa este elemento de controle.
Na aplicação, atribui-se um grupo de atualização a uma determinada transação comercial ou a um grupo de transações
comerciais. O tipo de atribuição e os elementos organizacionais determinantes variam de aplicação para aplicação.
Atualmente, a influência da aplicação sobre a atualização das estatísticas através do grupo de atualização é possível nos
seguintes sistemas de informação:
CONTROLADORIA 79 de 325
Compras – A descrição das opções específicas da aplicação para o grupo de atualização encontra-se na seção "Opções:
compras".
Manutenção – A descrição das opções específicas da aplicação para o grupo de atualização encontra-se na seção "opções:
Manutenção".
Administração de qualidade – A descrição das opções específicas da aplicação para o grupo de atualização encontra-se
na seção "Opções: administração de qualidade".
Transporte – A descrição das opções específicas da aplicação para o grupo de atualização encontra-se na seção "Opções:
transporte".
Vendas e distribuição – A descrição das opções específicas da aplicação para o grupo de atualização encontra-se na seção
"Opções: vendas e distribuição".
Para todos os outros sistemas de informação, admite-se apenas um grupo de atualização fixo.
Esta etapa oferece a possibilidade de criar, modificar, exibir, copiar ou eliminar grupos de atualização para a atualização das
estatísticas. A definição da atualização é uma função central no sistema de informação para logística enquanto que a atribuição
das transações comerciais específicas das aplicações é efetuada através dos elementos organizacionais correspondentes nas
respectivas aplicações. Na configuração standard, todos os grupos de atualização que começam com números ou com "S"
situam-se no conjunto de nomes SAP.
17.7.4.2 Controle Detalhado via Regras de Atualização
Ao definir a atualização, o usuário deve definir, tanto as regras de atualização para os índices, como também as regras de
atualização para as características. As regras de atualização são divididas em regras gerais e regras de atualização ampliadas.
Devem ser especificadas as seguintes regras de atualização:
17.7.4.2.1 Regras de atualização para índices
Tipo de atualização
Com o tipo de atualização, especifica-se como os dados a serem atualizados se relacionarão com os dados já atualizados na
estrutura de informação.
Caso o usuário se decida pela atualização de acumulação. os novos valores serão sempre adicionados aos antigos, ou
subtraídos dos antigos.
O tipo de atualização "Contador" é uma forma especial de atualização de acumulação. O valor "1" é adicionado aos valores
antigos, ou subtraído dos antigos.
Se o valor já atualizado deve ser sobregravado pelo novo valor, selecionar o tipo de atualização "somente transporte de
dados". O valor antigo na estrutura de informação é eliminado e substituído pelo novo valor. Com este tipo de atualização,
por exemplo, pode-se atualizar informações, tais como "último preço",
Evento
Com o evento, especificar qual ação a atualização deste índice deve acionar na aplicação operativa.
Uma vez que esta regra de atualização é diretamente atribuída a um índice, pode-se acionar a atualização de uma estrutura
de informação a partir de diferentes transações de aplicação. Isto permite ao usuário misturar, por exemplo, em uma
estrutura de informação, índices da ordem do cliente, do fornecimento e do documento de faturamento
Para se utilizar estruturas de informação "misturadas", deve-se criar uma aplicação definida pelo próprio usuário . Na
definição da regra de atualização, pode-se utilizar grupos de atualização de diferentes aplicações.
Nota
Existe também a possibilidade de misturar índices para todas as aplicações (p.ex. dados do processamento de ordem do
cliente e do pedido).
Neste caso, deve-se utilizar na estrutura de informação características existentes em ambas as aplicações.
Unidade
CONTROLADORIA 80 de 325
Neste campo, é exibida a unidade do índice (p.ex. moeda interna, moeda de estatística), que foi indicada na definição da
estrutura de informação.
Atenção
Esta regra de atualização não pode mais ser modificada, uma vez que um campo de unidade especial foi gerado durante a
criação da estrutura de informação para a unidade indicada.
Tabela de origem/Nome do campo de origem/Unidade de origem
Nos campos tabela de origem e nome do campo de origem, são propostas informações, indicadas na definição do índice
quando uma estrutura de informação é criada, ou informações obtidas automaticamente quando é selecionado um índice a
partir de um catálogo de campos.
A unidade de origem é determinada automaticamente a partir do campo de origem indicado.
Neste ponto, existe a possibilidade de modificar o campo de origem.
Nota
Ao utilizar o tipo de atualização "Contador", ou ao indicar uma fórmula ou uma rotina externa como fonte, não é
necessário indicar uma tabela de origem ou de um campo de origem.
Neste caso, deve-se indicar a unidade de origem, uma vez que ela não poderá mais ser determinada automaticamente.
Além disso, deve-se indicar uma hierarquia.
Campo de data para a determinação do período
Na atualização de um índice, será determinado o período, no qual o índice é acumulado.
Para a determinação do período, deve-se indicar um campo de data a partir da aplicação. O conteúdo deste campo
especificará o período.
A seleção da data correta para a determinação do período possui efeitos significantes sobre o valor informativo das
informações armazenadas.
Por exemplo, se a quantidade da ordem do cliente for atualizada para o evento "ordem do cliente", utilizando para isso a
data da ordem entrada no sistema, o usuário obterá uma informação sobre a entrada da ordem, uma vez que a data atual
vale como data de entrada.
Ao utilizar a data de expedição ao invés da data de entrada, a quantidade da ordem será acumulada em um outro período,
uma vez que a data de expedição encontra-se em geral no futuro. A atualização contém agora informações sobre a
capacidade de expedição a ser planejada nos períodos seguintes.
Nota
Durante a definição, uma entrada de ordens por período pode ser interpretada de 2 maneiras, que podem variar com a ajuda
do campo de data.
As diferentes interpretações podem ser explicadas nos exemplos a seguir:
A base é uma ordem do cliente com um item de 100 unidades que foram incluídas em janeiro. Em fevereiro, a quantidade
da ordem deste item é reduzida para 50 unidades, porque a quantidade total não foi produzida, por exemplo, ou porque não
pode ser fornecida; ou ainda porque o cliente de-repente não mais necessita da quantidade total de peças.
Como esta modificação deve ser atualizada por período na estrutura de informação?
Caso A:
O usuário é da opinião, que a entrada da ordem para o item foi em janeiro e por isso a modificação do item deve ser
atualizada também em janeiro.
Na estrutura de informação, reduz-se a quantidade de 100 para 50 no período de janeiro.
Neste caso, utiliza-se a data de entrada do item (MCVBAP-ERDAT) para a determinação do período.
Caso B:
O usuário é da opinião, que a entrada da ordem em janeiro não deve ser modificada pela entrada da ordem em fevereiro,
uma vez que a entrada da ordem de 100 unidades realmente ocorreu em janeiro.
Deseja registrar a modificação da ordem no período atual (fevereiro).
CONTROLADORIA 81 de 325
A entrada da ordem de 100 unidades em janeiro deve permanecer inalterada na estrutura de informação, e em fevereiro
deve ser atualizada com menos 50 unidades.
As modificações serão então creditadas no período que causa as modificações (atual), não no período original.
Neste caso, selecionar o campo de data especial (MCVBAP-VDATU), que sempre contém a data atual.
Fórmula
Utilizar uma fórumula, se a indicação de um único campo de origem não for suficiente para o índice selecionado, porque o
índice deve ser determinado através da ligação com vários campos de origem,
Para definir uma fórmula, acessar a respectiva transação de atualização.
Atenção
Se o usuário indicar uma fórmula, não poderá indicar um campo de origem.
Neste caso, indicar uma unidade de origem manualmente.
Ao indicar um campo de origem, determina-se automaticamente uma unidade de origem. Isto não é possível ao se utilizar
uma fórmula.
Condições
A atualização de um índice depende em geral de uma determinada combinação de fatores em uma transação comercial.
Por exemplo, se o usuário deseja que a quantidade fornecida seja somente atualizada quando o item de fornecimento for
completamente fornecido, deve-se definir uma condição que verifique se o campo de status correspondente no documento
de fornecimento foi definido como "fornecido completamente".
Ao definir uma condição, acessa-se a respectiva transação de atualização.
Nota
Para utilizar condições, existe a possibilidade de verificar anteriormente se elas podem ser reproduzidas utilizando-se o
controle geral através de grupos de atualização (p.ex. se um índice só deve ser atualizado para determinadas unidades
organizacionais ou tipos de documento).
Na cadeia de atividades de atualização, esta verificação ocorre antes da verificação de condições das regras de atualização,
e por isso é mais favorável aos niveis de performance.
Atenção
Se o usuário indicar uma condição, não deverá indicar nenhum campo de origem.
Neste caso, deve indicar uma unidade de origem manualmente.
Ao indicar um campo de origem, uma unidade de origem é automaticamente determinada. Isto não é possível ao se utilizar
uma condição.
Nome do programa/Rotina FORM
Caso o usuário necessite de uma definição complexa da atualização que não pode ser representada através da definição de
regras gerais de atualização, poderá gravar regras próprias de atualização em um programa externo.
Este processamento é acionado automaticamente no momento da atualização.
Para isso, indicar no campo Nome do programa o nome do programa externo, e no campo Rotina FORM , o nome da rotina
FORM, que contém o processamento especial do usuário.
Nota
A definição de rotinas externas de atualização está sujeita a convenções.
Dependendo do evento ao qual o usuário se refere, pode-se utilizar, por exemplo, somente determinadas informações de
origem da aplicação. Estas informações são transferidas à rotina de atualização como parâmetro USING.
O seguinte método fornece uma possibilidade simples de reconhecer os parâmetros importantes:
a) No campo Rotina FORM, indicar o nome da rotina a ser utilizada para a atualização.
b) Gerar a atualização.
CONTROLADORIA 82 de 325
No protocolo, é exibido o nome do programa de atualização gerado.
c) Posicionar o cursor no nome do programa e selecionar a função Exibir objeto.
O programa de atualização gerado é exibido.
A parte que descreve a atualização para o índice também contém a chamada gerada da rotina externa de
atualização.
Os parâmetros de transferência necessários foram também gerados. Utilizá-los para a definição da rotina externa
de atualização.
Exemplo
Chamada gerada de uma rotina externa de atualização:
* programa externo
PERFORM MENGE_BESTIMMEN(RMCV0101)
USING
XMCKONV
XMCVBAK
XMCVBAP
XMCVBEP
XMCVBKD
XMCVBPA
XMCVBUK
XMCVBUP
XMCVBAPF
CHANGING FU_KWMENG.
Hierarquia
A hierarquia de documentos especifica quais informações da aplicação devem se encontrar à disposição para a atualização.
Em geral, esta informação é automaticamente determinada com a indicação de um campo de origem.
Ao utilizar o tipo de atualização "contador" ou fórmulas, condições e programas externos de atualização, não é necessário
indicar um campo de origem.
Neste caso, indicar manualmente até qual nível de hierarquia do processamento de documento são necessárias as
informações para a atualização.
A indicação de uma hierarquia é importante para o controle de processo interno da atualização.
17.7.4.2.2 Regras de atualização para características
Tabela de origem/Campo de origem
No campo Campo de origem, indicar o campo de origem a partir da aplicação, cujas informações devem ser transferidas na
atualização.
Os campos de origem serão propostos a partir da definição da estrutura de informação.
Ao utilizar diferentes eventos para os índices, deve-se ajustar os valores propostos, uma vez que os campos de origem
propostos não se encontram à disposição para todos os eventos.
Offset/Comprimento
Se o conteúdo total do campo de origem para a atualização não deve ser empregado, utilizar offset e comprimento para a
determinação específica do segmento desejado do campo. Não é possível indicar o offset e o comprimento juntamente com
uma fórmula.
CONTROLADORIA 83 de 325
Exemplo
Offset e comprimento são geralmente utilizados para a interpretação de campos de hierarquia.
A hierarquia é geralmente representada por um campo de 18 caracteres, a partir do processamento de vendas e distribuição;
por exemplo, os 5 primeiros caracteres representam em geral um grupo principal, os 5 seguintes um subgrupo e os últimos
8 caracteres um outro subgrupo.
Para atualizar e avaliar dados de acordo com estes componentes lógicos, proceder da seguinte maneira:
a) Definir 3 novos campos.
b) Gravá-los na tabela Dictionary, na qual os outros campos de referência também foram gravados.
c) Os 3 novos campos são P1, P2, P3 e comprimento 5, 5 e 8, respectivamente.
d) Incluir os novos campos em um dos catálogos de campo.
e) Criar uma nova estrutura de informação que contenha estes 3 novos campos como características.
f) Definir as regras de atualização para esta nova estrutura de informação.
As regras de atualização para as novas características são as seguintes:
- P1 : Origem MCVBAP-PRODH Offset 00 Comprimento 05
- P2 : Origem MCVBAP-PRODH Offset 05 Comprimento 05
- P3 : Origem MCVBAP-PRODH Offset 10 Comprimento 08
As novas características P1, P2 e P3 são utilizadas no reporting e no planejamento como qualquer outra
característica.
Condição inicial
Se o campo de origem indicado no documento não estiver preenchido (inicial) e se não deve ocorrer nenhuma atualização,
a condição inicial poderá ser ativada.
Com isso, evita-se, por exemplo, a atualização da estatística, caso nenhum substituto tenha sido indicado na ordem do
cliente.
Se a condição inicial não for ativada, todos os valores dos documentos serão acumulados naqueles, nos quais nenhum
substituto foi indicado.
Assim, existe a possibilidade de acumular todos estes valores em "Outros".
Fórmula
Se a atualização para uma característica não puder ser determinada claramente a partir de um campo de origem, poderá ser
indicada uma fórmula, com a qual a informação de origem será determinada.
Este é o caso, por exemplo, quando a característica deve ser composta por vários campos de origem.
Caso contrário, proceder na definição de fórmulas para características da mesma maneira que na definição de fórmulas
para índices.
Ao contrário de fórmulas para índices, utilizar o campo "FORMULA_VALUE_OBJECT", e não o campo
"FORMULA_VALUE" para as fórmulas para características, para a transferência do resultado da determinação de
fórmulas.
Hierarquia
A hierarquia de documentos especifica quais informações da aplicação devem estar à disposição para a atualização.
Em geral, esta informação é automaticamente determinada através da indicação de um campo de origem.
Ao utilizar o tipo de atualização "contador" ou fórmulas, condições e programa externo de atualização, não é necessária a
indicação de um campo de origem.
Neste caso, o usuário deve indicar até qual nível de hierarquia do processamento de documentos as informações são
necessárias para atualização.
a indicação de uma hierarquia é importante para o controle do processo interno da atualização.
CONTROLADORIA 84 de 325
17.7.4.2.3 Definição detalhada da atualização
A definição detalhada da atualização ocorre com a ajuda das regras de atualização. As regras de atualização dependem da
estrutura de informação e do grupo de atualização. São compostas, por exemplo, pelo campo de origem, pelo resultado do
acionamento da atualização, pelas condições e fórmulas. Após a especificação das regras de atualização, os programas de
atualização serão automaticamente gerados. Após a definição das regras de atualização, deve-se ativar explicitamente a
atualização. A criação das regras de atualização, a geração dos programas de atualização e a ativação definitiva da atualização
são etapas que foram separadas por questões de segurança.
Atividades
1. No campo "Estrutura info", indicar o nome da estrutura de informação, para a qual se deseja atualizar as regras de
atualização.
2. Atribuir um grupo de atualização à estrutura de informação, a fim de estabelecer uma referência específica à aplicação.
3. Para criar a atualização para a estrutura de informação com referência a uma atualização já existente, indicar o nome da
estrutura info no campo Modelo da estrutura info e, no campo Modelo do grupo de atualização, o nome do grupo de
atualização.
4. Pressionar ENTER.
Acessa-se a tela de atualização das regras de atualização.
Na tela de atualização, encontram-se listados todos os índices da estrutura de informação, para os quais as regras de
atualização poderão ser definidas.
Se, na criação da atualização, nenhuma regra de atualização ainda foi definida, serão propostas todas as informações
existentes para a definição da estrutura de informação.
5. Para acessar o detalhe da definição da atualização, posicionar o cursor no índice desejado e selecionar a função Regras
para índice.
6. Especificar cada regra de atualização.
7. Após a especificação de todas as regras de atualização para o índice, selecionar a função Aceitar.
As especificações efetuadas foram transferidas e apresentadas na tela de atualização.
8. Proceder com os outros índices da mesma maneira.
9. Além das regras de atualização para os índices, definem-se também as regras de atualização para as características.
Para isso, posicionar o cursor no índice desejado e selecionar a função Regras para característica.
Acessa-se o detalhe para a atualização das regras de atualização da característica.
Nota
Deve-se definir as regras de avaliação da característica para cada índice, para que os índices de diferentes eventos possam
ser atualizados.
As regras de atualização das características podem ser diferentes para cada índice.
10. Definir cada regra de atualização.
11. Após ter definido as regras de atualização para todos os índices e características, gravar estas regras.
12. Gerar a atualização a partir das regras de atualização.
Antes da geração, todas as regras de atualização serão verificadas quanto às suas consistências. Possíveis inconsistências
serão registradas em log, e a geração será cancelada.
Pode-se executar a verificação também separadamente, selecionando-se a função Atualização -> Verificar.
Se não ocorrer nenhum erro durante a verificação, a atualização será gerada.
Após a geração, será efetuada a saída de um log.
Informações adicionais.
Durante a definição das regras de atualização, encontram-se à disposição as seguintes funções:
Eliminar regra
CONTROLADORIA 85 de 325
Para se excluir índices da atualização (por exemplo um dependente do grupo de atualização), posicionar o cursor no
respectivo índice e selecionar a função Processar -> Eliminar regra.
As regras de atualização para o índice selecionado e as características pertencentes serão eliminadas.
Recuperar
A função "Recuperar" está ligada diretamente à função de eliminação.
Caso as regras de atualização para um índice tenham sido eliminadas por engano, pode-se ativar novamente este índice,
selecionando-o a partir da lista de índices não utilizados.
Para isso, selecionar a função Processar -> Recuperar.
Em uma janela de diálogo, será apresentada a lista com todos os índices, já criada na estrutura de informação, porém não
utilizada na definição da atualização.
Selecionar os índices que ainda não foram considerados na atualização.
Com Enter, o usuário transfere todos os índices selecionados.
Porém, isto não recupera todas as regras de atualização que foram possivelmente definidas.
Serão copiadas somente as informações do campo de origem que foram especificadas durante a definição da estrutura de
informação.
Copiar regra
Esta função é necessária quando se deseja definir várias atualizações para um índice.
Esta importância será explicada através de um exemplo:
Exemplo
O usuário deseja atualizar a quantidade da ordem em aberto.
A quantidade da ordem em aberto é definida como quantidade da ordem que ainda não foi fornecida.
O processamento de ordem do cliente atualiza o campo "Quantidade da ordem em aberto".
Quando um fornecimento é entrado, a quantidade da ordem em aberto deve ser reduzida.
Na definição da atualização deste processamento, o usuário necessita de 2 regras de atualização para o índice "quantidade
da ordem em aberto".
A primeira regra descreve a atualização para o evento "Ordem do cliente". Com isso, o índice será atualizado a partir de
uma informação fonte especial do documento (MCVBAP-OAUME), colocada à disposição especificamente para este
objetivo.
A segunda regra de atualização descreve a redução da quantidade da ordem em aberto através da quantidade fornecida para
o evento "Fornecimento".
Para isso, copiar a primeira regra de atualização já existente e modificar o evento e a informação de origem.
Também aqui a quantidade fornecida será colocada à disposição para atualização em um campo especial (MCLIPS-
APOAUME).
Uma vez que a quantidade da ordem em aberto e a quantidade fornecida devem ser reduzidas, a informação será
apresentada como um valor negativo.
A quantidade da ordem em aberto estruturada através da primeira regra de verificação será então reduzida através da
segunda regra de verificação.
Nota
Trata-se de um caso especial, no qual a quantidade fornecida será apresentada como valor negativo para a redução da
quantidade da ordem em aberto.
Para expressar outras diferenças, cujo valor anteriormente atualizado deve ser reduzido pela segunda atualização, utilizar
uma fórmula para inverter o processo.
CONTROLADORIA 86 de 325
17.7.5 Condições – atualiza requisitos
Para a atualização de índices, muitas vezes é necessário definir regras de atualização complexas. Isto implica na definição de
condições que permitem ou não permitem a atualização. Visto que a determinação de condições está sujeita a exigências muito
diversas, precisa-se de um meio flexível para a definição. A atualização das condições subdivide-se conforme as aplicações.
Atividades
Selecionar a aplicação para a qual as condições devem ser atualizadas.
É exibida a síntese de todas as condições já existentes para a aplicação selecionada.
Criar
1. Para definir uma condição nova, entrar no campo Rotina FORM um número novo para a condição.
Nota
Para as condições standard oferecidas pela SAP, está reservado um determinado conjunto de nomes.
Por isso, utilizar para as suas condições números de 600 a 999.
2. Entrar um texto explicativo para a condição.
3. Para gravar um texto descritivo para a condição proceder da seguinte maneira:
a) Posicionar o cursor sobre a condição.
b) Selecionar a função Documentação.
Passa-se para o editor de textos SAP.
c) Entrar o texto.
d) Gravar o texto.
e) Voltar à tela de síntese.
Criar/modificar
1. Para modificar uma condição, posicionar o cursor na respectiva linha.
2. Selecionar a função Texto de origem.
O sistema passa para o editor de programas.
Atenção
Durante a definição da condição, é atribuído automaticamente um nome para a rotina FORM.
Este nome não pode ser modificado.
3. Definir a condição com a ajuda dos elementos de idioma ABAP.
É possível utilizar todos os campos de origem válidos para o evento que foi selecionado para a respectiva regra de
atualização e para o qual a condição deve ser válida.
Nota
Quando se analisa a visão V_QUTAB com a transação SM30, obtém-se uma síntese das tabelas de origem admitidas por
evento.
4. Na definição de condições, o resultado da verificação tem que ser atribuído ao campo Código de retorno.
Considerar:
Código de retorno = 0 condição preenchida
Código de retorno = 0 condição não preenchida
O campo Código de retorno já está definido em um conjunto de dados comum.
5. Gravar a definição da condição.
6. Voltar à tela de síntese das condições.
CONTROLADORIA 87 de 325
Exemplo da definição de uma condição.
Os dados do processamento de ordens de cliente só devem ser atualizados se o documento foi processado por completo.
Através de um campo de status no documento, é possível ver se o processamento do documento foi completado.
FORM MCV1_600.
IF MCVBUK-UVALL = 'C'.
RETURNCODE = 0.
ELSE.
RETURNCODE = 4.
ENDIF.
ENDFORM.
Ativar
Uma definição de condição só pode ser utilizada durante a atualização se estiver ativa.
Para ativar uma condição, proceder da seguinte maneira:
1. Posicionar o cursor sobre a respectiva linha.
2. Selecionar a função Processar -> Ativar.
Eliminar
Uma condição só pode ser eliminada se não estiver ativa.
Para eliminar uma condição, proceder da seguinte maneira:
1. Posicionar o cursor sobre a respectiva linha
2. Selecionar a função Processar -> Desativar.
3. Selecionar a função Processar -> Eliminar linha.
A condição é eliminada.
17.7.6 Fórmulas
Para a atualização de índices, muitas vezes é necessário definir regras de atualização complexas. Isto implica na definição de
fórmulas para determinar os índices. Como a criação de fórmulas está sujeita a exigências muito diversas, é necessário um meio
flexível para a definição. A atualização de fórmulas subdivide-se conforme as aplicações.
Atividades
Selecionar a aplicação para a qual as fórmulas devem ser atualizadas.
É exibida uma síntese de todas as fórmulas já existentes para a aplicação selecionada.
1. Para definir uma fórmula nova, entrar no campo rotina FORM um número novo para a fórmula.
Nota
Para as fórmulas standard oferecidas pela SAP, está reservado um determinado conjunto de nomes.
Por isso, utilizar para as fórmulas só números de 600 a 999.
2. Entrar um texto explicativo para a fórmula.
3. Para gravar um texto descritivo para a fórmula, proceder da seguinte maneira:
a) Posicionar o cursor sobre a fórmula.
b) Selecionar a função Documentação.
Passa-se para o editor de textos SAP.
c) Entrar o texto.
CONTROLADORIA 88 de 325
d) Gravar o texto.
e) Voltar à síntese.
Criar/modificar
1. Para modificar uma fórmula, posicionar o cursor sobre a linha correspondente.
2. Selecionar a função Texto de origem.
O sistema passa para o editor de programas.
Atenção
Durante a definição da fórmula, é atribuído automaticamente um nome para a rotina FORM.
Este nome não pode ser modificado.
3. Definir a fórmula com a ajuda dos elementos de idioma ABAP.
É possível utilizar todos os campos de origem válidos para o evento que foi selecionado para a respectiva regra de
atualização e para o qual a fórmula deve ser válida.
Nota
Ao analisar a visão V_QUTAB através da transação SM30, o usuário obtém uma síntese das tabelas de origem admitidas
por evento.
4. Ao definir fórmulas para índices com categoria de dados numérica (categoria F, N, P ou X), o usuário tem que atribuir o
resultado da determinação da fórmula ao campo Formula_Value.
Ao definir fórmulas para características ou índices com categoria de dados alfanumérica, utilizar o campo
Formula_Value_Object.
Através do campo Código de retorno, é possível determinar a validade da determinação de valores por meio da fórmula.
Convém sempre utilizar a especificação do código de retorno (por exemplo CLEAR RETURNCODE).
Os campos Formula_Value, Formula_Value_Object e Código de retorno já estão definidos em um conjunto de dados
comum.
5. Gravar a definição da fórmula.
6. Voltar à síntese das fórmulas.
Exemplo da definição de uma fórmula
O usuário pretende determinar a contribuição marginal I para o evento "documento de faturamento".
A contribuição marginal I é constituída com base na diferença entre o valor líquido de fatura e o valor de compensação
correspondente.
FORM MCV2_600.
FORMULA_VALUE = MCVBRP-NETWR - MCVBRP-WAVWR.
RETURNCODE = 0.
ENDFORM.
Ativar
Uma definição de fórmula só pode ser utilizada durante a atualização se estiver ativa.
Para ativar uma fórmula, procede-se da seguinte maneira:
1. Posicionar o cursor sobre a linha correspondente.
2. Selecionar a função Processar -> Ativar.
Eliminar
Uma fórmula só pode ser eliminada se não estiver ativa.
Para eliminar uma fórmula, procede-se da seguinte maneira:
CONTROLADORIA 89 de 325
1. Posicionar o cursor sobre a linha correspondente.
2. Selecionar a função Processar -> Desativar.
3. Selecionar a função Processar -> Eliminar linha.
A fórmula é eliminada.
17.7.7 Monitoração da atualização
Existe a possibilidade de monitorizar a atualização de dados estatísticos através do protocolo de atualização. Este protocolo é
registrado em função do usuário e da operação.
O protocolo de atualização é um utilitário para a verificação posterior da atualização, da geração de estruturas de informação e
das regras de atualização definidas para este fim.
Encontra-se à disposição a simulação da atualização para a monitorização da atualização. Através da simulação da atualização,
é possível elaborar um de atualização também para documentos que não causaram nenhuma atualização.
17.8 Relatórios – análise flexíveis
As análises flexíveis possibilitam a representação de características em hierarquias multi-nível definidas pelo usuário e a
acumulação dos respectivos índices. É possível combinar índices de estruturas de informação diferentes.
Com as análises flexíveis o usuário pode criar relatórios Report Writer com um layout variável muito facilmente.
As estruturas de análise representam a interface com o Report Writer. Estas estruturas são constituídas por características e
índices.
Com base nas estruturas de análise é possível uma definição individual de análises. As características e os índices pretendidos
são selecionados por meio da técnica Pick-Up.
Para cada estrutura de informação contida no sistema standard da SAP existe uma estrutura de análise. A estrutura de
informação e a estrutura de análise correspondente têm o mesmo nome.
Também se gera uma estrutura de análise para cada estrutura de informação definida pelo usuário.
Visto que para cada estrutura de informação está disponível uma estrutura de análise com o mesmo nome, é possível analisar
facilmente as estruturas de informação através das análises flexíveis.
17.9 Consultar conteúdo de Variantes de seleção de relatórios
Para consultar o conteúdo de uma variantes de seleção de relatório, ou seja, visualizar os parâmetros definidos para executar um
determinado relatório, usar a função SE38 (Editor ABAP).
18 Configurações de FI
18.1 Variante de Ano Fiscal
A variante ou tipo de ano fiscal pode ser definida como dependente ou independente do ano. Dependente do ano significa que a
cada ano podem ocorrer alterações nos períodos. Se for independente significa que, ano a ano, os períodos são iguais. Se o tipo
de ano fiscal por dependente do ano, a cada ano, os períodos devem ser definidos. O ano fiscal independente do ano também
pode ser definido com vinculado ao ano calendário ou não. Vinculado ao ano calendário significa que os períodos de
lançamento são iguais aos meses do ano (12 períodos reais). Se não for vinculado ao ano calendário, o ano fiscal pode ter de 1 a
16 períodos e, caso, o período não se inicie em primeiro de janeiro, deverá ser usado o annual displacement indicator para
indicar que um determinado mês deste ano calendário pertence ao ano fiscal anterior.
Um ano fiscal pode ter tanto períodos de lançamentos reais como períodos especiais. Os períodos especiais são períodos criados
além do último período real para efetuar lançamentos de ajuste ainda dentro do ano fiscal de forma que não impacte
diretamente os resultados do último período. Os períodos especiais somente estarão disponíveis para lançamento quando o
penúltimo período real estiver fechado. Não é muito usado pelas empresas. No total, podem ser usados 16 períodos (12 reais e 4
especiais). Para usar mais de 12 períodos, é preciso usar o Extended General Ledger. Os lançamentos efetuados nos períodos
CONTROLADORIA 90 de 325
especiais, para efeito de balanço, aparecem no último período real. Para efetuar um lançamento contábil em um período
especial, a data do lançamento deve estar dentro do último período e deve ser informado o período especial.
Caso o ano fiscal seja não vinculado ao ano calendário, deverá ser definido o mês de fevereiro com 29 dias para não ter
problemas com o ano bissexto.
Normalmente o ano fiscal é independente do ano.
Para evitar erros de lançamento os períodos podem ser fechados. Normalmente, só o período corrente fica aberto. No entanto,
se necessário, vários períodos poderão ficar em aberto.
Durante a rotina de fechamento, dois period ranges devem estar aberto ao mesmo tempo (o atual e o anterior). Portanto, dois
period ranges podem ser lançados na tabela de períodos de lançamento.
Várias empresas podem ser associadas a uma mesma variante de período. Assim, a abertura e fechamento poderá ser feita de
forma centralizada. O fechamento e abertura de período pode ser feito a nível geral, a nível de tipo de conta ou por intervalo de
contas.
Em conjunto com o Autorization Group (Grupo de Autorização), pode-se aumentar as restrições para lançamentos.
18.2 Grupo de Tolerância
A nível de empresa, pode ser definido o grupo de tolerância atribuindo limites de valores por documento, por lançamentos em
aberto (open item account item), ou limites de valores de descontos financeiros (gerados automaticamente) por lançamento.
Esta ferramenta minimiza erros. O grupo de tolerância é obrigatório. Assim, define-se um grupo com a chave “branco” que
será válida para todos os usuários e cria-se grupos com características especificas para associar aos usuários com maior
permissão. Pode ser informado percentual ou valor absoluto. O sistema considera o que for menor.
18.3 Plano de Contas
Uma empresa pode trabalhar, basicamente, com até três planos de conta:
Operacional – é o plano de contas oficial da empresa e que será usado nas transações do R/3. Todos os lançamentos
efetuados no sistema estarão vinculados diretamente às contas deste plano de contas.
Do Grupo – corresponde ao plano de contas do grupo de empresas (consolidação). Os lançamentos neste plano serão
derivados com base na associação definida no cadastro de contas contábeis do plano operacional.
Do País – usando o alernative account number, pode-se, ainda, definir um outro plano de contas que atenda às
necessidades do país. Também tem seus lançamentos derivados a partir da associação definida no cadastro de contas
contábeis.
A definição do plano de contas do grupo é válida, por exemplo, quando se deseja trabalhar, dentro de um mesmo grupo de
empresas cujos resultados serão consolidados, com planos de contas diferentes. Outra alternativa é definir o mesmo plano
operacional para todos as empresas e diferenciá-las no plano de contas no país. A desvantagem, neste caso, é que o usuário, que
normalmente está habituado com o plano de contas do país, terá que trabalhar com o plano de contas operacional.
O plano de contas do R/3 somente contempla as contas analíticas. As contas sintéticas serão “definidas” somente a nível de
relatórios. No entanto, é desejável manter a mesma estrutura na definição dos códigos das contas para facilitar manutenção e
extração de relatórios (1 – Ativo, 1.1 – Ativo Circulante, 1.1.1 – Disponível, etc.). A criação do plano de contas possui três
etapas:
Definição do Plano – O plano de contas é uma entidade que contém a estrutura e as informações básicas das contas do
G/L (Razão Geral). A chave tem 4 posições alfanuméricas.
Definição das caraterísticas – Além da chave, serão definidos a descrição, idioma padrão, tamanho da conta (no máximo
10 posições alfanuméricas), se a integração com CO será manual ou automática. Integração automática significa que a cada
conta cadastrada para este plano de contas, será gerada uma classe de custo primária em CO conforme parametrizações (a
partir da versão 4.6). Define-se também qual será o plano de contas do grupo e o status (ativo ou inativo).
Vinculação com as empresas – quando uma empresa é vinculada a um plano de contas, automaticamente também é
definido o plano de contas do grupo ao qual ela pertence. A definição do plano de contas do grupo é feita a nível de plano
de contas. Mais de um plano de contas, porém, pode ser referenciar a um mesmo plano de contas do grupo. Assim, duas
empresas com plano de contas diferentes poderão ser conciliadas em um mesmo grupo. Posteriormente, serão definidas as
CONTROLADORIA 91 de 325
contas específicas de cada empresa e para cada conta, deverá ser definida a conta correspondente do plano de contas do
grupo (group account number).
18.4 Contas Contábeis
O cadastro de contas contábeis se subdivide em dois níveis: geral (chart-of-accounts segment) e por empresa (company-code-
sgments). A nível geral estão as definições do código da conta, campos de controle (o tipo da conta (patrimonial (balance sheet)
ou de resultado (P&L statement)) e informações para consolidação (conta do grupo correspondente), a descrição da conta nos
diversos idiomas (a descrição da conta será apresentada no idioma do logon), a área funcional, palavras chaves, etc.
As contas de resultados serão zeradas no final do ano fiscal para determinadas contas (retained earnings account – lucros
acumulados). As contas são definidas a nível de plano de contas mas podem ser definidas mais de uma conta. Também devem
ser definidas as posting key (chave que define os critérios necessários para efetuar um lançamento) para gerar estes
lançamentos. (Define Retained earnings account). Na versão 4.0 não gerava os lançamentos automaticamente.
A nível de empresa, são definidos a moeda, os critérios para conversão de moeda, a conta correspondente do plano de contas do
país, sort key (forma padrão de classificação dos lançamentos nas telas de consulta), accounting clerk (funcionário responsável
pela manutenção da conta), filed status group (configuração de campos obrigatórios, opcionais, suprimidos, etc. a nível de
conta), informações pertinentes a impostos, bancos, cálculo de juros, line item display (indica se será possível ou não consultar
os lançamentos para esta conta em tela de consulta ou somente em relatórios).
Se for informada uma moeda diferente da moeda da empresa, somente será permitido efetuar lançamentos nesta conta nesta
moeda (exceto no caso de diferenças de taxas de câmbio resultante da valorização de balanço de contas). Se for informada a
moeda da empresa, o usuário poderá efetuar lançamentos em qualquer moeda definida no momento do lançamento. Se o
lançamento for efetuado em outra moeda, o montante será convertido para a moeda local (da empresa). O Arquivo de
Transações (Transation figures) é mantido por moeda, ou seja, a moeda faz parte da chave na identificação de cada registro:
local currency (somatório de todos os montantes convertidos para a moeda local , moeda 1, (somatórios dos lançamentos na
moeda 1, que pode ser a local), moeda 2 (somatório dos lançamentos efetuados na moeda 2) e assim, por diante. Isto é valido
independentemente do line item display.
Se o campo only balances in local currency for selecionado, somente serão gerenciados os valores na moeda local. Isto é
bastante válido para contas transitórias, por exemplo, que precisam ter o seu saldo zerado apenas na moeda local não
necessitando acertar saldos residuais em funções de possíveis variações cambiais entre a data do lançamento de entrada e o
lançamento de saída correspondente.
A sort key é a classificação default definida para a tela de apresentação dos lançamentos contábeis da conta. Accounting clerk
é a definição do funcionário responsável pela manutenção das contas. Não é feita nenhuma amarração pelo R/3 entre o
accounting clerk e o usuário. É apenas uma informação para controle pessoal da empresa. O field status group define o layout
da tela de entrada de dados (quais campos serão apresentados, de preenchimento obrigatório e os suprimidos).
Sem a definição da conta a nível de empresa, não será possível gerar lançamentos nesta conta para esta empresa. O R/3
disponibiliza uma função para manutenção do arquivo de contas somente dos dados gerais, somente dos dados da empresa e
com todos os dados. Depende dos níveis de autorização permitidos.
A opção line item display determina se será possível efetuar consulta dos lançamentos de uma determinada conta ou não. É
interessante restringir esta opção às contas realmente necessárias por questões de performance uma vez que, se for selecionada,
o R/3 irá gerar uma tabela de índice adicional. A nível de relatórios, podem ser listados os lançamentos para qualquer conta
independentemente deste parâmetro. Por exemplo, este campo não deve ser marcado para contas de conciliação (sub-ledger),
contas de receitas de vendas (gerenciadas em SD), contas de estoque de materiais (gerenciadas em MM), contas de impostos
ja´que só faz sentido analisar a partir da origem estas informações a partir da origem e não em FI. Estas contas só recebem
lançamentos automáticos do sistema.
Outra campo importante é o Open Item Management que determina se deseja fazer o controle de partidas em aberto como é o
caso dos clientes. Assim, quando é feito um lançamento de pagamento de uma duplicata, o R/3 “fecha” o lançamento de
emissão da duplicata. As partidas em aberto, portanto, corresponderão aos documentos em aberto. Obviamente, para marcar
este campo, o line item display também deve estar marcado. A nível de G/L, é importante para contas de compensação (contas
de movimentação bancária, conta transitória GR/IR (Goods receipt / invoice receipt – conta usada para dividir o momento do
recebimento de mercadoria em dois: físico e fiscal), salários.
Assim como no caso das empresas, a geração do plano de contas pode ser manual, digitada uma a uma, pode ser automática
(copiando de outro plano de contas) ou através de transferência de dados (Data Transfer – programa RFBISA00) a partir de
sistemas externos. O programa pode ser customizado.
CONTROLADORIA 92 de 325
Sempre que for efetuado um lançamento em FI numa conta contábil para a qual tenha associado uma classe de custo primária
em CO, o R/3 irá obrigar que seja informado o objeto de custo que será o coletor do custo. Da mesma forma, as receitas que
também terão reflexo em CO (Profitability Analysis ou Profit Center) terão classes de custos associadas. Um centro de custo
somente pode receber lançamentos de receita estatísticos.
18.5 Grupo de Contas (Account Group)
As contas contábeis são classificadas em grupos que definem, entre outras coisas, o intervalo de numeração válido (ativos fixo,
materiais, caixa, lucros e perdas, etc.). A definição dos grupos é feita pelo usuário. Na definição dos intervalos de numeração é
importante reservar um intervalo para as classes de custos secundários que nada mais são do que “contas contábeis” válidas
apenas em CO para análises de custos e que, portanto, não são cadastradas em FI. A nível real, as contas contábeis que têm
reflexo em CO são as contas de despesas e receitas. Todas as contas, inclusive patrimoniais, poderão ter reflexo em Profit
Center Accounting. Só que, neste caso, os lançamentos são meramente estatísticos pela própria natureza dos centros de lucro.
Embora o sistema permita que haja sobreposição dos intervalos entre os diversos grupos, isto não é recomendado, para facilitar
a identificação de uma conta pelo seu código (identificar o grupo da conta: ativo, passiov, etc.). E ainda, por questões de
geração de relatórios (criar estruturação das contas).
O grupo também determina o layout da tela de cadastramento da conta na empresa (field status group) portanto, deve ser
definido a nível geral do cadastro de plano de contas. Existem grupos padrões predefinidos no R/3.
18.6 Configurações dos campos das telas (Field Status)
Dentro do R/3 existem vários lugares onde se pode definir os layouts das telas conforme as necessidades específicas da empresa
variando os campos que serão exibidos e os campos que poderão ser alterados opcional ou obrigatoriamente. Para cada um dos
campos que foram predefinidos para exibição em uma tela o usuário poderá dizer se deseja suprimir (supress), permitir
alteração (optional entry), obrigar o preenchimento (required entry) ou apenas exibir (display). Definir um campo apenas como
display só tem sentido se a ele estiver definido uma valor default., o que pode ser feito de diversas formas dentro do SAP (por
exemplo: na profile do usuário). No entanto, mesmo estando suprimido um campo pode ter valores default associados a ele e
estes valores serão considerados como válidos nas telas de entrada de dados independentemente de sua exibição ou não.
Em algumas situações, estes parâmetros devem ser definidos a nível de grupo de campos (exemplo: interest calculation
indicator, interest cycle, interest calculation key date).
Assim como o status field pode ser definido a nível de grupo de contas, também pode ser definido a nível de transação. O R/3
irá verificar ambas as configurações respeitando a seguinte prioridade: Supress, Display, Requered Entry, Optional Entry). A
definição de supress e required entry para um mesmo campo gerar conflito e, portanto, uma mensagem de erro.
A nível de transação, as características dos campos são definidas no IMG / General Settings / Field Display Characteristics.
Em FI, a entrada dos documentos (lançamento contábil) é controlada por (válido somente para as entrada padrões, não vale para
as fast entrys), inicialmente, a nível de tipo de conta, em seguida, pela Posting key e, por fim, pela própria Conta.
Há exceções na definição das restrições e obrigatoriedades dos campos. Por exemplo, se for definido no cadastro da empresa
que ela permite a emissão de balanço por divisão, a business area poderá ser atribuída no lançamento. Portanto, o campo será
disponibilizado para lançamento podendo o usuário optar apenas entre obrigatório ou opcional, mas nunca suprimido. Outra
exceção são os campos de impostos que somente serão disponibilizados se a conta do G/L for definida como relevante para
impostos (tax-relevant).
Na cadastro de contas contábeis é atribuído um field status group. Um field status group é um conjunto de regras dos campos
agrupadas. Os field status group são agrupados em um field status variant que é vinculado à empresa. Normalmente, a mesma
variante é vinculada a todas as empresas para que todas trabalhem da mesma forma. Para os documentos dos razões auxiliares
(Sub-ledger), serão usada as definições atribuídas à conta de conciliação do razão geral.
Posting key Padrão
Clientes Fornecedores G/L Ativo Materiais
D C D C D C D C D C
01 11 21 31 40 50 70 75 89 99
02 12 22 32 80 90
CONTROLADORIA 93 de 325
Posting key Padrão
Clientes Fornecedores G/L Ativo Materiais
D C D C D C D C D C
03 13 23 33 81 91
04 14 24 34 82 92
05 15 25 35 83 93
06 16 26 36 84 94
07 17 27 37 85 95
08 18 28 38 86 96
09 19 29 39
A SAP recomenda o uso da posting key padrão. As posting key de 80 a 86 e 90 a 96 são para lançamentos do G/L fora de MM.
18.7 Variação cambial
A partir da versão 4.6 é possível executar mais de uma versão (release) de variação atribuindo a variação a contas contábeis
diferentes ou às mesmas contas. Pode ser atribuído um método de cálculo diferente para cada tipo de taxa.
18.8 Financial Statement Version
Para consolidação de informações, podem ser definidas diferentes versões de forma a armazenar dados em paralelo aos dados
reais para fins de simulação, planejamento, melhorias, etc. As versões de Consolidação são constituídas pela combinação de
diversas versões de diversas áreas: entrada de dados, taxas de impostos, métodos de translation.
Usando diferentes versões, é possível gerar diferentes financial statement consolidados para as mesmas empresas e sub-grupos.
Estes statements podem ser diferentes no que diz respeito aos seus relatórios e o uso de métodos opcionais, mas podem
simultaneamente ser baseados em definições comuns em sub-areas. Para evitar redundâncias nas definições comuns, alguns
dados (particularmente dados de tabelas de relatórios e parâmetros de controle) são armazenados em versões específicas (tais
como versões de taxa de câmbio e versões de métodos de translation). As versões específicas a serem usadas são associadas
durante a manutenção da versão de consolidação.
A Financial statement version define as estruturas do Balancete, ou seja, a estrutura tradicional do plano de contas para o Brasil.
Esta estrutura pode estar vinculada a um plano de contas especial, ao plano de contas do grupo de empresa ou simplesmente
sem uma associação específica.
Após a seleção da versão, o sistema irá exibir uma janela popup onde poderá ser selecionada a tradução para uma conta
individual patrimonial ou de resultado ou para uma worklist do todas as contas.
Para cada versão, são definidos os financial statement item que corresponde a cada uma das subdivisições na estrutura do
lancete. O último nivel desta estrutura terão os grupos de contas ou determinar, diretamente, quais contas deverão ser exibidas
segundo determiandos critérios.
Alternativamente, ao último nível também podem ser definidos intervalo de áreas funcionais
Essa estrutura do balanço / L/P poderá então ser também utilizada pelos relatórios do balanço do sistema de informação das
contas do Razão.
O financial statement item é fundamental para o sistema de consolidação (entrada de dados, lançamentos e relatórios). Um
financial statement item pode ser usado em diversas consolidações de plano de contas. É usado tanto para contas patrimoniais,
lançamentos de receita e lucro, metrics e ratios (fins estatísticos: número de empregados).
18.9 Razão Auxiliar (Subsidiary Ledger)
O R/3 trabalha com o conceito de sub-ledger (subsidiary ledger) para clientes, fornecedores e ativo fixo. Para conciliação com o
G/L (Razão Geral) é preciso definir contas de conciliação que correspondem aos saldos acumulados das contas de clientes,
fornecedores e ativos fixos no G/L. Um conta de conciliação (Reconciliation Account) pode ser do tipo (D) clientes e (K)
CONTROLADORIA 94 de 325
fornecedores e (A) ativo. O Material Ledger não é considerado conceitualmente como um Sub-Ledger para o R/3, mas tem a
mesma característica. No entanto, todos os lançamentos referentes a materiais serão efetuados diretamente em conta no G/L.
18.9.1 Contas de Clientes e Fornecedores
As contas de clientes e fornecedores correspondem, na verdade, ao cadastro de clientes e fornecedores. Assim como o cadastro
de contas, o cadastro de clientes e fornecedores também é dividido em segmentos. O de clientes tem : nível geral, nível de
empresa (dados financeiros) e nível de vendas. O Cadastro de fornecedores, analogamente, tem: nível geral, nível de empresa
(dados financeiros) e nível de compras. A manutenção destes cadastros pode ser feita de forma centralizada atualizando os
dados de todos os segmentos de uma só vez ou distribuída por segmentos. Esta definição irá depender da necessidade da
empresa. Normalmente funciona de forma descentralizada visto que uma mesma pessoa dificilmente terá conhecimento das
informações referente a todas as áreas.
O importante é definir um procedimento para que as diversas áreas atuem de forma sincronizada. No cadastramento de uma
ordem de vendas não é obrigatório a cadastramento do cliente no segmento empresa. No entanto, no faturamento, os dois
segmentos são obrigatórios. Existe uma programa que aponta os clientes que não foram cadastrados em todos os níveis
(segments). Analogamente, se aplica ao fornecedor.
O cliente pode atuar em mais de uma área de vendas dentro da empresa, portanto, seus dados devem ser específicos para cada
área. Por área de vendas entende-se a definição da Organização de Vendas, do canal de distribuição e da divisão (linha de
produto). O mesmo acontece com fornecedor (área de compras = organização de compras).
Da mesma forma que para as contas do G/L, podem ser definidos grupos de contas para as contas do S/L. Além do intervalo de
numeração e do status field, o grupo de contas do S/L também irá definir se o cliente/fornecedor é “one-time”, ou seja, se
corresponde a um cliente/fornecedor que irá efetuar uma negociação única com o cliente. Neste caso, o sistema irá exigir um
mínimo de informações para o cadastramento destes clientes / fornecedores. Os demais dados serão informados na emissão do
documento. No entanto, não pode ser usado um código genérico, é preciso criar uma conta para cada um individualmente.
A forma de definição do intervalo, porém é diferente. Primeiro são criados os intervalos de contas (sem permissão de
sobreposição) e posteriormente estes intervalos são associados aos grupos. Os intervalos também podem ser internos (gerado
automaticamente) ou externos (informado no cadastramento). Números externos podem ser alfanuméricos. Mais de um grupo
poderá ser vinculado a um mesmo intervalo.
Da mesma forma que na conta, o status field pode ser definido a nível de empresa, grupos de contas e ainda, transações. O
sistema irá seguir a mesma regra de prioridade.
No cadastro de fornecedores e clientes também podem ser definidos o funcionário responsável pelo cadastro, campos sensíveis
a mudanças necessitando de uma auditoria e posterior autorização.
19 Processamento Diário de FI
19.1 Posting Key – Chave de Lançamento
As Posting Key são as chaves de lançamento definidas a nível de Client sendo válida para todas as empresas. A chave de
lançamento controla os tipos de contas permitidos para o lançamento, se é um lançamento de débito ou de crédito e o field
status para detalhes adicionais. O field status aqui, pode ser usado para as contas dos sub-ledger ou para diferenciar o layout em
uma mesma conta quando o lançamento for a débito ao a crédito.
Além disto, a posting key define se o pagamento será lançado item a item ou não. Esta informação é importante na análise de
história de pagamentos e na criação de notificações de pagamento e se as números (figures) de vendas da conta deverão ser
atualizadas por transação, por exemplo, no lançamento de uma fatura de cliente.
Nas versões anteriores (até 4.5) era informada a Posting Key na tela de entrada de lançamentos do G/L. A partir da 4.6, a a tela
fi modificada e o usuário só informa se é débito ou crédito. É o sistema de define internamente a posting com base na transação
que está sendo utilizada pelo usuário.
CONTROLADORIA 95 de 325
19.2 Lançamentos básicos de FI
O FI usa uma transação para efetuar uma série de lançamentos: razão geral, faturas do contas a receber, notas de crédito do
contas a receber, faturas de fornecedores e notas de crédito dos fornecedores. Existe uma pequena diferença entre a tela de
lançamento de G/L e AP e AR.
Alguns valores já vêem preenchidos podendo ser default do sistema (data do lançamento = data corrente, document principle) e
outras definidos pela conta (tipo de documento e posting key, definições de débito e crédito da posting key – definido no
Customizing, ano fiscal, data do fluxo de caixa (value data – calculada pelo R/3 considerando a critério definido mas não trata
fim de semana), máxima variação permitida entre a taxa de câmbio calculada e a informada – definida na empresa). Num
lançamento contábil são definidas três datas: a data do lançamento, a data do documento e a data da entrada. A data do
documento e a data do lançamento podem ser alterados pelo usuário. A data da entrada do lançamento será definido sempre
igual à data do sistema operacional.
Um lançamento pode, antes de ser atualizado, ser “estacionado”, ou seja, é gravado com a situação pendente significando que
ainda não é um documento válido. Posteriormente, este documento deverá atualizado realmente. Esta ferramenta é bastante útil
quando ainda existe dúvida sobre alguma informação sobre o lançamento (impostos, por exemplo) que ainda se quer confirmar
antes da atualização definitiva ou mesmo para auditoria usado em conjunto com o Workflow. O usuário que lança sempre deixa
o documento pendente e um outro usuário irá liberá-lo após avaliação.
Uma vez atualizado, poucos campos poderão ser alterados. A nível de cabeçalho, somente o texto e a Referência. O sistema
grava um log das alterações informando os campos que foram alterados, o valor antigo e o atual, o usuário que fez a alteração e
a data/hora da alteração.
Uma vez atualizado, o documento não poderá mais ser excluído. Será necessário reverter (estornar) o documento gerando
lançamentos de estorno e lançar novamente o documento de forma correta. Também não é permitido gerar um lançamento a
partir do lançamento revertido. Deve ser digitado novamente. No entanto, o sistema possui uma série de ferramentas para
minimizar erros e evitar a necessidade de estornnos. Ao reverter um documento deve ser informado o motivo do estorno que
define se a data da estorno deverá ou não ser igual à data do lançamento original. Mesmo os lançamentos gerados
automaticamente por outros componentes do R/3, se necessário, serão atumoticamente estornados pelo sistema para gerar os
lançamentos corretos.
Lançamentos de documentos que já tenham sido liquidados (usado o open line item) não poderão ser estornados. É preciso
estornar as liquidações primeiro. Assim, por exemplo, se foi lançada uma fatura para o cliente e também já foi lançado um
recebimento para esta fatura, para estornar a fatura, primeiro será preciso estornar o recebimento.
O estorno pode ser padrão ou negativo. Esta definição é feita a nível de empresa e a nível de motivo de estorno. O padrão gera
um lançamento de crédito para cada débito errado e vice-versa gerando um registro adicional no Transation figures. No
lançamento negativo, o procedimento é o mesmo só que o valor creditado não é adicionado aos créditos mas subtraído dos
débitos e vice-versa. Normalmente é usado o padrão.
Lançamentos negativos também podem ser usados para transferência de lançamentos de itens errados, o item é removido da
conta errada e transferido para a conta certa. Isto só é possível para um tipo de documento que aceite lançamentos negativos.
CONTROLADORIA 96 de 325
20 Configurações básicas de CO
20.1 Planejamento Integrado
Planejamento
Estratégico
SOP
MPS
Análise de
recursos críticos
Análise da carga
bruta
MRP
CRP
Programação
e Controle de
Fábrica
Programação
e Controle de
Compras
Contabilização
Custeio
Fluxo de Caixa Previsto X
realizado
NÍVEL
ESTRATÉGICO
NÍVEL
TÁTICO
NÍVEL
OPERACIONAL
PLANO ESTRATÉGICO
Mercado
Recursos
Objetivos
P & D
PLANO OPERACIONAL (SOP)
Previsão de Vendas
Carteira
Promessa de Entrega
PLANO MESTRE DE PRODUÇÃO (MPS)
CONTROLADORIA 97 de 325
Estrutura de planejamento
Roteiros representativos
Recursos com restrição de capacidade
PLANEJAMENTO DAS NECESSIDADES DE MATERIAL (MRP)
Controle do Estoque
Parâmetros de planejamento
Estrutura da produto
PLANEJAMENTO DAS NECESSIDADES DE CAPACIDADES (CRP)
Roteiros de fabricação
Capacidades dos centros
20.2 Numeração aos documentos de CO
Assim como em FI, em CO também é necessário definir um intervalo de número de documentos para cada tipo de transação do
R/3 (business transaction). Primeiramente são definidos os grupos de transações que irão usar o mesmo intervalo. Se desejar um
intervalo para cada transação, deve ser criado um grupo para cada transação. Em seguida devem ser feitas as associações entre
os grupos e os intervalos de numeração. Os intervalos de numeração em CO são independentes do ano fiscal. A numeração
pode ser decrescente. É recomendado utilizar-se intervalos de numeração distintos para as transações de planejamento e
alocações reais de forma a permitir que o programa de reorganização reinicialize os intervalos em separado para cada um dos
grupos.
20.3 Versões
Um versão em CO é um conjunto de indicadores dependentes do ano fiscal usado para planejamento e lançamentos reais dentro
de uma Área de Contabilidade de Custos.
20.3.1 Indicadores a nível geral
Versão Bloqueada (Lock version) – define o status da versão: liberada ou não. Este flag permite bloquear a alteração dos
valores planejados para esta versão, ou seja, o plano fica congelado. Este flag só influencia no planejamento de ordens internas
e projetos se o planejamento integrado com centro de custo estiver ativado (indicador ativo para esta mesma versão) e as ordens
e projetos afetados forem integrados. Não tem nenhum efeito para o planejamento global (overall) de ordens internas e projetos
mesmo se o planejamento integrado estiver ativo.
Integração Planejamento (Plan data integration/line item update) – determina se o planejamento de Centros de Custos ou
Processos Empresariais deve ser transferido para outros componentes (tais como Special Purpose Ledger ou Centro de Lucro) e
se devem ser gravadas partidas individuaispara cada alteração nos dados planejados. Este flag somente pode ser alterado antes
de iniciar o planejamento. Se já existirem dados planejados, a alteração somente pode ser feita através da função Ativar
Integração no menu de planejamento. Esta função faz com que todos os registros de planejamento disponíveis para uma Área
de Contabilidade de Custos/Versão/Ano fiscal sejam lançados como partidas individuais para a AC interface. Todos as partidas
individuais existentes em uma transação de alocação planejada (rateio, distribuição, etc.) são lançados para a AC interface e
torna disponível para outros componentes. Não é permitido armazenar dados reais para a versão 001.
Permitido Copiar (Copying allowed) – especifica se esta versão pode ser usada para gerar outras versões do planejamento.
Este flag é relevante somente para ordens internas e projetos quando o planejamento integrado estiver ativo e as ordens e
projetos afetados são planejados de forma integrada.
20.3.2 Indicadores a nível de planejamento
Categoria de Taxa de Câmbio (Exchange rate type) – chaves sobre a qual se deseja armazenar as taxas no sistema. Pode ser
usada para definir a taxa de compra bancária, a taxa de venda bancária ou a taxa média para conversão de valores em moeda
estrangeira. A taxa média pode ser usada para conversão, e as taxas de compra e venda para valorização de montante em moeda
estrangeira.
CONTROLADORIA 98 de 325
Planejamento de ordens e projetos integrado com Centro de Custo – indica se o planejamento das ordens internas e dos
elementos PEP nesta versão será integrado com o planejamento de centros de custo ou processos ABC. Isto significa que no
planejamento de entrada de atividades para uma ordem interna ou elemento PEP integrado, as atividades programadas são
lançadas no centro de custo ou processo emissor. É permitido planejar liquidações e transferências periódicas de ordens e
elementos PEP para os centros de custo ou processos empresariais e alocações indiretas de atividade, rateios e distribuição dos
centros de custos / processos empresarias para ordens e elementos PEP integrados.
Todas as configurações válidas para o planejamento dos centros de custo / processos empresariais são válidas também para as
ordens internas e elementos PEP integrados. Se esta opção for selecionada, os dados planejados também estarão disponíveis
para Centro de Lucro e Special Ledger. Esta integração se aplica somente às ordens internas e a nenhum outro tipo de ordem.
Para ativar a integração, selecionar a opção “Planejamento Integrado” no cadastro do tipo de ordem ou no perfil do projeto.
Não é permitido executar o custeio unitário para ordens internas ou elementos PEP integrados.
Data Valor (Value date) – determina a taxa diária de câmbio a aplicar para a conversão de moedas. Se for informada uma
data, o sistema usa a taxa deste dia para todos os períodos. Caso contrário, a conversão será feita período a período. O sistema
assume a data do primeiro dia do período considerando as flutuações da taxa de câmbio dentro de um ano fiscal.
Versão para AIA (Alocação Indireta de Atividade) (Version for indirect activity allocation for non-integrated
order/project planning) – versão da qual os preços das atividades definidos para os tipos de atividades serão considerados na
avaliação das entradas de atividades para as ordens e elementos PEP, se o planejamento destes não forem integrados. O valor
padrão é a versão 000.
20.3.3 Indicadores para Determinação de Tarifa
Tarifa Puramente Interativa (Purely iterative activity price) - controla se serão gravadas tarifas paralelas. O indicador
ATIVO só é váldio para tarifas internas determinadas manualmente. Neste caso, é calculada uma tarifa puramente iterativa
além da tarifa resultado do planejamento (por exemplo, através da mistura entre tarifas internas iterativas e manualmente
definidas). Na determinação desta tarifa, o sistema desconsidera as tarifas definidas manualmente. Esta funcionalidade é
interessante para analisar a influência da determinadção manual de tarifas antes do cálculo automático.
Para a valorização das quantidades de atividade das alocações reais serão sempre utilizadas as tarifas resultante do
planejamento, desde que não tenha sido ativada a reavaliação das atividades reais.
Processo de Determinação das tarifas (Methods for calculating planned/atual activity prices) – o processo para a
determinação de tarifas planejadas e reais é definido separadamente sendo o real definido somente para a versão 0. Opções
disponíveis:
Periódica – cálculo efetuado período a período. No caso de produtos com sazonalidade, pode resultar em grandes
oscilações nos valores das tarifas ao longo do exercício.
Média – divide os custos totais de todos os períodos pelo total das atividades de todos os períodos para cada tipo de
atividade encontrando um valor médio assumido para todos os períodos considerados no cálculo.
Acumulada – só é possível para o cálculo da tarifa real. Semelhante à média só que considera do ínicios do exercícios até
o período corrente e não todo o exercício. O sistema credita todos os objeots envolvidos para efetuar nova avaliação. Neste
caso, todos os períodos precisam ficar desbloqueados para receber lançamentos.
Variante de avaliação para planejamento de recursos – esquema de cálculo de custos para determinação do preço dos
recursos.
Reavaliação com tarifas reais (Revaluation indicator (for revaluating actual activities with an actual activity price)) –
somente para a versão 0 – real. Opções disponíveis:
0 – nenhuma reavaliação será efetuada permanecendo o valor da tarifa planejada.
1 – reavaliação com operação própria. O sistema mantém as alocações originais com tarifas planejadas e lança a diferença
como uma operação própria. A autorização de reavaliação também é feita a nível de tipo de atividade. A Reavaliação de
medidas efetuas-se sempre com operação própria.
2 – Revaliação em operação original – o sistema modifica a alocação original escondendo o desvio real/planejado.
Esquema de elementos (Custos de Produção + Custos administrativos + Custos de vendas) (Cost component layout for cost
component splitting)
A versão permite criar um agrupamento independente de dados reais e planejados. Os dados da versão mais provável do
planejamento normalmente são gravados na versão 000. Os dados aqui informados constituem a base para cálculo de preços
CONTROLADORIA 99 de 325
planejados para tipos de atividades e determina tarifas pelos quais as atividades serão alocadas a nível real. A versão também
armazena os lançamentos reais e portanto são usadas nas comparações de real/planejado e em análise de desvios.
O R/3 permite armazenar dados reais e planejados nas versões. No planejamento, é necessário definir parâmetros dependentes
do ano fiscal. No custeio ABC, os dados podem ser armazenados em diferentes versões delta. Se estiver trabalhando com preço
de transferência (transfer price), devem ser definidas versões reais paralelas ao lado das versão operacional 000 para as
diferentes valorizações. A versão operacional é aquela que representa a versão principal em CO, que representa visão principal
de controladoria e é a única versão onde as transações envolvendo alocações de atividades são armazenadas. Permite a
definição de até duas versões adicionais para armazenamento de valorizações em paralelo.
As versões podem ser associadas a grupo de autorização registringo quais os usuários que poderão fazer que tipos de
planejamentos.
A definição de versão é genérica para CO permitindo a integridade dos dados quando se trabalha com diferentes aplicações
(Overhead Cost Controlling e CO-PA) – planejamento integrado. No entanto, a configuração da versão é específica para cada
componente, PA, PCA, OCC, para cada Área de Resultado, Área de Contabilidade de Custos e ano fiscal. O número de versões
é, praticamente, ilimitado. (campo com 3 posições alfanuméricas).
A versão 000 é automaticamente criada na criação de uma Área de Contabilidade de Custos e vale por cinco anos fiscais. Para
lançamento dos dados reais, o R/3 usa a versão 000. Portanto, para fazer análises entre o real e o planejado, é preciso usar a
versão 000. Na prática, o que as empresas costumam fazer é sempre trabalhar com a versão 000. Sempre que se deseja guardar
um planejamento, copia-se da versão 0 para uma outras versão e continua trabalhando com a versão 000.
20.3.4 Versão Delta
Quando estiver trabalhando com o ABC estatístico, obrigatoriamente deverá ser criada uma versão delta para armazenar os
lançamentos estatísticos. Trabalhando com o ABC integrado, as versões delta podem ser definidas mas os dados poderão ser
gravados na versão operacional e copiados para a versão delta. Esta configuração é definida para a versão. Para cada transação
deve ser informado se os dados serão gravados primeiramente na versão operacional e depois repassados para a delta ou se
somente serão gravados na versão delta. A versão delta será melhor detalhada no custeio ABC.
20.3.5 Versões para avaliações
Devem ser criadas versões adicionais para as avaliações paralelas em CO definindo a visão de avaliação por área de
contabilidade de custos. Se os preços internos não estivrem ativos usa-se a versão "000" em avaliação legal. Se o usuário utiliza
preços internos e os prismas de avaliação do centro de lucro se tornam determinantes para o controlling, é possível:
executar versões reais paralelas em várias avaliações,
deterimnar, para a versão real operativa "000", que avaliação obterá um papel determinante para CO, ou seja, que o
planejamento, a determinação das tarifas para atividades bem como comparações plano - real e análises de desvio se
baseiam nesta avaliação.
As opções devem ser efetuadas de forma consistente em relação às opções no perfil de moeda e avaliação. No âmbito da
ativação, verifica-se esta consistência. É necessário executar a avaliação legal ou na versão operativa ou em uma outra versão
real.
20.4 Avaliação Paralela / Preço de transferência
Usando preço interno (Transfer Price), é possível transferir e compensar fornecimentos de mercadorias entre as unidades
organizacionais (empresas, centros ou centros de lucro) através de métodos de avaliações em paralelo dentro de um grupo
corporativo. Através do Preço preço intermo é possível valorizar as transferências entre unidades organizacionais de acordo
com três diferentes critérios:
Critérios legais – avaliação, do ponto de vista jurídico, dos fornecimentos efetuados entre empresas filiadas com autonomia
jurídica, de acordo com as obrigações legais de prestação de contas.
Custo de produção – compensar paralelamente estes fornecimentos dentro do grupo de empresas em custos de produção do
grupo, evitando que dêem origem a lucros entre as empresas.
Perfil de Avaliação compensar adicionalmente estes fornecimentos com avaliações gerenciais do ponto de vista da
contabilidade de centro de custo. Um perfil de avaliação é uma combinação da defnição da moeda (que pode ser a do grupo, a
da empresa, ou outra) e da definição do método de valorização (por grupo, centro de lucro ou valorização legal).
CONTROLADORIA 100 de 325
Para trabalhar com Preços Interno, portanto, é preciso especificar, nos perfis de avaliação / moeda, quais as avalizações deverão
ser usadas para gerenciamento em paralelo dentro de CO e associar estes perfis à ACC fazendo as configurações necessárias a
cada aplicação.
Do ponto de vista de centro de lucro, os preços internos são, automaticamente, selecionados para movimentações de material
entre centros de lucro e aparecem como receitas internas e custos internos em PCA. Neste caso, uma requisição de material
entre centros de lucro diferentes é vista como uma venda em PCA, enquanto é um lançamento de consumo do ponto de vista da
empresa. Por exemplo, quando um ordem de produção vinculada a um centro de lucro A requisita um material que está
vinculado a um centro de custos B, o sistema irá gerar uma receita para o centro de lucro B e gerar um custo no centro de lucro
A no mesmo valor. Contabilimente, esta movimentação corresponde a um consumo creditando o estoque de debitando uma
conta de despesas pré-parametrizada.
Se desejado, as três visões (empresa, grupo e centro de lucro) podem ser gravadas no Ledger de Materiais. Este decisão define
como deverão ser configuradas os lançamentos dos valores em FI. Por exemplo, for definido que serão utilizadas três visões,
todas as transações (principalmente em CO) que geram lançamentos em FI, precisam gerar e gravar os valores nestas outras
visões.
Na Contabilidade de Centro de Custos, podem ser gravadas qualquer uma destas visões de forma que se possa analisar os
resultados operacionais dos centros de lucro de acordo com as três visões. Em FI, todos os lançamentos serão valorizados pelos
critérios legais. Opcionalmente, podem ser gravadas as outras duas visões. Em CO, é preciso definir qual das visões será a
principal (versão 0) e pode-se, opcionalmente, definir outras versões para gravar as outras visões.
20.4.1 Perfil de avaliação e de moeda
No perfil de moeda e avaliação determina-se que prismas de avaliação devem ser executados. O perfil de moeda e avaliação só
é necessário caso se pretenda executar paralelamente diversas avaliações no sistema. O perfil define as combinações desejadas
de moedas e avaliações que se deseja executar. Como exemplo executar-se-iam os seguintes prismas de avaliação:
Moeda da empresa (10) em avaliação legal (0)
Moeda do grupo de empresas (30) em avaliação do grupo de empresas (1)
Moeda da empresa (10) em avaliação de centro de lucro (2)
As regras seguintes devem ser consideradas na atualização do perfil de moeda e avaliação e são verificadas na ativação de cada
perfil na área de contabilidade de custo:
São dermitidos até três prismas de avaliação sendo que a execução da moeda da empresa em avaliação legal é obrigatória.
Duas destas avaliações devem usar a mesma moeda. Quanto às demais, relativamente à avaliação, é possível selecionar
entre avaliação do grupo de empresas (1) e avaliação do centro de lucro (2) e, relativamente à moeda, existe a seleção entre
moeda da empresa (10) e (10) moeda do grupo de empresas (30).
Todos os prismas de avaliação devem ser também executados, respetivamente, no ledger de material.
Só é possível executar uma avaliação de centro de lucro quando a contabilidade de centro de custo estiver em
funcionamento.
O perfil de moeda e avaliação só pode ser alterado se ainda não tiver sido atribuido, nem esteja ativo, na área de contabilidade
de custo.
Peril M & A : PCA
N. Moeda Avaliação
0 Empresa legal
1 Empresa centro de lucro
20.4.2 Denominações p/prismas de avaliação
Podem ser denominações próprias para os prismas de avaliação. Estas denominações aparecem, nas aplicações, por exemplo,
no sistema de informação ou em os dados do ledger de materiais. No standard, o prisma de avaliação 11 é denominado moeda
de contabilização, avaliação do grupo de empresas ou, em campos mais pequenos, Empr.(K). Esta denominação deve ser
ajustada em função de cada empresa. No caso de não atualizar qualquer denominação própria, o sistema utiliza as
denominações standard SAP. As denominações para outros idiomas podem ser atualizadas nos respetivos idiomas de acesso.
CONTROLADORIA 101 de 325
20.4.3 Tipo de legder de materiais x tipo de moedas x área de avaliação
Para cada tiop de ledger de materiais definido devem ser especificados os tipos de moedas que serão usadas no ledger de
materiais. Pode ser definido que serão usadas as moedas definidas para a contabilidade financeira, as moedas definidas para CO
ou uma outra definição especificada manualemente. Definir as moedas na modalidade individual.
Antes da conversão dos dados para o entrada em produção, certificar-se de que as opções de moeda na contabilidade financeira
ou perfil de moeda e de avaliação e no ledger de materiais estão corretas. Depois da entrada em produção, não será possível
nenhuma modificação das moedas, dos tipos de moedas e dos tipos de ledger de materiais.
No perfil de moeda e de avaliação, pode-se exibir tipos de moedas que pertencem a uma determinada área de contabilidade de
custos. Para assegurar o acesso direto às informações sobre os componentes Administração de materiais, Contabilidade
financeira e Controlling, especificar a moeda do grupo de empresas como moeda da área de contabilidade de custos.
Posteriormente, os tipos de ledger são vinculados às áreas de avaliação que correspondem ao centros.
20.4.4 Contas de compensação de diferenças de avaliação
Devem ser definidas as contas de resultado para o lançamento de diferenças de avaliação em transações contábeis entre
empresas filiadas. Ao utilizar prismas de avaliação paralelos/preços internos apenas são lançados os créditos e os débitos na
perspectiva de avaliação legal, uma vez que o pagamento é efetuado neste montante. Caso sejam administradas outras
avaliações para a conta de contrapartida, deve ser lançada a diferença em contas de compensação do prisma de avaliação, para
que sejam especificados na demonstração contábil do grupo de empresas. O sistema atribui a diferença de avaliação para cada
item individual ao centro de lucro pertencente.
Através desta função é possível determinar contas de compensação do prisma de avaliação por empresa e sociedade parceira de
negócios, nas quais as diferenças de avaliação devem ser lançadas. Para cada sociedade parceira de negócios são determinadas
as contas de débito e de crédito para as diferenças de avaliação entre as empresas filiadas.
20.4.5 Configurações globais para determinação de preço
O termo preço interno é usado para descrever o cálculo de preços para movimentações internas de mercadorias entre centros de
lucro. Condições são os passos individuais para determinação do preço interno. Quando ocorre uma movimentação entre dois
centros, o preço pode depender de um número de fatores, tais como o material envolvido, o centro emissor, o centro de lucro, o
centro de lucro parceiro, etc. A informações destes fatores variáveis é gravada no registro mestre na forma de registros de
condições. No registro de condição, o preço interno pode ser definido como um valor fixo ou um percentual de acréscimo ou
redução.
A seguir serão definidos os passos necessários para definir preços internos. A definição dos preço é feita no Customizing.
1. Tabela de Condições Definir as tabelas de condições a serem usadas para armazenas os registros de condições para cada
tipo de condição.
2. Seqüências de Acesso Definir as seqüências de acesso a ser usada para pesquisar os registros válidos (estratégia de
pesquisa).
3. Tipos de Condições Definir os tipos de condição para todos os elementos de precificação (montantes fixos, markups e
markdowns) que ocorrem nas suas negociações diárias.
Na contabilidade de centro de lucro, uma tipo de condição representa um componente de um preço interno. Podem ser
definidos tipos de condições para todos os tipos de preço fixo, markup ou markdown que ocorrem nas movimentações de
mercadorias internas. Se for definido um percentual de markup ou markdown como um tipo de condição, é preciso definir
outro tipo de condição para servir como a base de cálculo para este percentual. Este pode ser um preço do mestre de
materiais. O relacionamento entre estes dois tipos de condição serão definidos no procedimento de precificação.
Em alguns tipos de condição é preciso especificar uma seqüência de acesso. Neste modo são determinados quais os campos
o sistema deve usar para pesquisas para registros de condições válidos.
4. Registros de Condições Definir os registros de condições que determinam o montante ou o percentual a ser aplicado para
cada série de valores na tabela de condição (tais como preço fixado de 100,00 dólares por material 01, centro de lucro ABC
e centro 0001).
Os registros de condição podem ser atualizados diretamente de dentro da definição do tipo de condição ou a partir do
menu: Dados mestre Preço Interno Condições. Também é possível copiar registros existentes. Esta alternativa é
muito útil quando se deseja alterar a moeda do registro de condição.
CONTROLADORIA 102 de 325
5. Esquema de cálculo de custos Definir um procedimento de precificação para agrupar tipos de condição e determinar
como se relacionam. Além disto, o procedimento define quais os subtotais devem ser calculados, quais os valores de base
devem ser usados para aplicar percentuais e quais condições devem ser encontradas para que certos tipos de condição
sejam calculados. A base de cálculo tanto pode ser um valor fixo como um valor do mestre de materiais.
Nível – Número que determina a sequência das condições dentro do esquema.
Número – Número sequencia das condições dentro de um nível. A sequência indicada pelo numerador será
automaticamente transferida para a determinação de preço.
Nível desde /até - Níveis de condição cujos valores são a base para os acréscimos percentuais. Se mais de um nível até for
indicado ao mesmo tempo como referência, os valores de condição dos dois os níveis indicados pelo usuário e os valores
de condição dos níveis situados entre estes níveis serão somados. Neste caso, o total será a base para os descontos
percentuais. Se o usuário entrar um valor nos campos 'nível de' e 'até nível' simultaneamente, o sistema adicionará os
valores de condição dos níveis indicados aos valores de condição dos níveis intermediários.
Fórmula base – Fórmula que difere da fórmula definida no standard para determinar a base da condição. No sitema
standard, um desconto a nível do cabeçalho é distribuído de acordo com o valor acumulado dos itens. Todavia, se o
desconto absoluto a nível do cabeçalho for distribuído de acordo com o volume ao invés de ser distribuído da maneira
standard, os seguintes descontos serão calculados para um desconto a nível do cabeçalho no valor de $30:
Item Valor Volume Desconto standard por volume
1 $1000 2 m³ $20 $10
2 $500 4 m³ $10 $20
Esquema Nível Número Tipo condição Nível desde Nível ate Fórmula base Descrição
TP0001 010 00 TP01 000 000 000 Preço transf.(fixo)
TP0002 010 00 TPB1 000 000 000 Preço material (ML)
TP0002 020 00 TP02 010 010 000 Majoração percentual
TP0003 010 00 TPB2 000 000 000 Base do cálculo
TP0003 020 00 TP02 010 010 000 Majoração percentual
ZP0009 010 00 TPB1 000 000 000 Preço material (ML)
ZP0009 020 00 TP01 010 010 000 Preço transf.(fixo)
6. Excluções de condições Definir exclusões de condições, que permite determinar quais tipos de condição devem ser usados
em condições de exceção.
Na determinação de preço interno é muito comum encontrar diferentes registros válidos. Através da exclusões pode-se
compare condições e usar, por exemplo, a mais favorável para o centro de lucro parceiro. Diversos métodos estão
disponíveis:
Condição mais favorável em um grupo de exclusão
Registro de Condição mais favorável para um tipo de condição
Codiçõa mais favorável entre diferentes grupos de exclusão
Exclu~soes destes condições no grupo de exclusão quando um tipo de condição que pertence a outnro grupo de
exclusão aparece.
7. Variantes de preço interno Definir variantes de preço interno que especifica quais os procedimentos de precificação são
relevantes para dados reais e quais são relevantes para dados planejados. Na determinação dos preços internos, somente
dados reais são valorizados (variante 000). No entanto, podem ser criadas variantes adicionais para calcular preços
planejados baseado nos dados de precificação.
Variante 000 – Cálculo Preço Interno Fixo Produto
Esquema Denominação Seqüência
ZP0009 Esquema de Cálculo Custos PI 00
CONTROLADORIA 103 de 325
8. Definir Listas de preço determinando a estrutura da lista de condições. A lista permite analisar os registros de condições
de acordo com certos critérios. Podem ser definidas no customizing ou no Dados mestre da Contabilidade de Centros de
Lucro.
Preço interno: exib.análise de condições de preços internos
Se este código for ativado, uma análise de condições será chamada para cada transação que determina um preço
interno. Em uma análise de condições, são repartidos os componentes individuais da determinação do preço interno.
Se este código for definido, surgem etapas de diálogo que não são desejadas no funcionamento normal do sitema (por
ex., em movimentos de mercadorias, execuções do cálculo de custos, etc.). Por este motivo, a análise de condições só
deve ser ativada para fins de teste, de modo a verificar a determinação correta de preços internos, segundo as opções
no customizing da contabilidade de centros de lucro.
A análise de condições é chamada para todos os usuários, por variante de preço interno. Mas é possível controlar esta
análise individualmente: com a definição do parâmetro set-get 'DIA' no valor 'X', no registro mestre de usuários, o
usuário pode acionar a análise de condições para todas as variantes de preço interno.
Todas as modificações efetuadas nas configurações globais serão registradas automaticamente. Durante a gravação será
possível indicar se estas modificações devem ser transportadas ou não.
20.4.5.1 Tipo de Condição
Os registros de condição são atualizados de acordo com um tipo de condição. Os registros de condição serão usados para a
determinação do preço interno e conseqüente análise de resutlados dos centros de lucro.
Os registros de condição, nos quais estão arquivados os valores concretos para a determinação de um preço interno, podem ser
matidos a partir da atualização de tipos de condição ou através do menu de operacional em Contabilidade de Centros de Lucro
Dados mestre ->Preços internos Preços.
As seqüências de acesso também podem ser atualizadas a partir da atualização de tipos de condição. No entanto, deve ser
primeiramente criada no customizing da contabilidade de centros de lucro em controle detalhado da determinação do preço.
20.4.5.1.1 Criar tipos de condição próprios
Para criar um novo tipo de condição, clicando em criar na área de tela superior esquerda devem ser especificado:
Uma chave alfanumérica que pode ter até 4 caracteres e deve começar com a letra Z (estes conjuntos de nomes são
deixados livre no sistema standard do SAP).
Uma descrição (opcional)
Uma seqüência de acesso para os tipos de condição (se necessário) que controla o acesso aos registros de condição. A
seqüência de acesso deve estar pre- definida.
Marcar uma das opções no quadro de grupo definição tipo de cálculo de custos.
3. Selecionar saltar -> vista detalhada.
Os dados de controle lógicos apropriados já estão propostos para os tipos de condição condição básica de ledger de materiais,
condição básica de cálculo de custos, preço fixo e sobretaxa percentual. No entanto, podem ser adicionadasopções adicionais.
Para outros tipos de condição não existem quaisquer especificações. O usuário deve ter em atenção de efetuar opções que
correspondam de forma lógica.
Existem as seguintes possibilidades de entrada:
a) Categoria de condição – A categoria de condição classifica condições segundo categorias predefinidas. Na contabilidade de
centros de lucro são suportadas as seguintes categorias de condição:
Categoria Utilização
' ' (outras categorias de condição)
tipos de condição que não necessitam nenhuma categoria de condição especial como, por exemplo, sobretaxas e
deduções ou preços internos fixos.
K Preço interno – Avaliação da Empresa – Montante básico excluindo imposto
CONTROLADORIA 104 de 325
Tipos de condição de valor base para informar um sobretaxa baseada em cálculo de custos. Por motivos técnicos
estes tipos de condição têm de ser criados com a categoria de condição 'K', regra de cálculo 'C' e classe de
condição 'B'.
Para este tipo de condição não é necessária nenhuma seqüência de acesso.
B
Preço interno avaliação de grupo
Semelhante a anterior só que aqui, como montante base utiliza-se a avaliação do grupo de empresas do ledger de
materiais. Por motivos técnicos estes tipos de condição têm de ser criados com a categoria de condição 'b', regra
de cálculo 'C' e classe de condição 'B'.
Para este tipo de condição não é necessária nenhuma seqüência de acesso.
H
Preço Interno avaliação de Centro de Lucro
Semelhante a anterior só que aqui, como montante base utiliza-se a avaliação de centro de lucro do ledger de
materiais. Por motivos técnicos, estes tipos de condição têm de ser criados com a categoria de condição 'H', regra
de cálculo 'C' e classe de condição 'B'.
Para este tipo de condição não é necessária nenhuma seqüência de acesso.
As seguintes categorias de condição apenas são aplicáveis para condições básicas da perspectiva legal:
Categoria Utilização
G
Preço Interno – (de acordo com o controle de preços)
Tipos de condição, nos quais o preço-padrão (controle de preço 'S' ) ou preço médio móvel (controle de preço 'V')
são determinados a partir do mestre de materiais de acordo com o controle de preço.
Para este tipo de condição não é necessária nenhuma seqüência de acesso.
S
Preço interno – Standard
tipos de condição, nos quais o preço-padrão é determinado a partir do mestre de materiais independentemente do
controle de preço.
Para este tipo de condição não é necessária nenhuma seqüência de acesso.
T
Preço interno - Média móvel
Tipos de condição, nos quais o preço médio móvel é determinado a partir do mestre de materiais
independentemente do controle de preço.
Para este tipo de condição não é necessária nenhuma seqüência de acesso.
b) Regra de cálculo – A regra de cálculo determina o modo como o sistema calcula preços e sobretaxas ou deduções para um
tipo de condição. Este cálculo pode ser efetuado na contabilidade de centros de lucro de forma percentual (Regra de cálculo A),
quantidade (C) ou montante fixo (B).
c) Classe de condição – A classe de condição determina se o tipo de condição será usado para o cálculo de um acréscimo
(sobretaxas) e deduções (A) ou preços (B).
d) Fator de referência – O fator de referência determina o modo como o sistema interpreta a escala de um tipo de condição
podendo ser uma escala de valores (B ) ou de quantidade (C) ou além da configuração global (' ').
e) sinal +/- - determina se o valor deve ser positivo (acréscimo) ou negativo (deduções).
f) verificação escala –controla se os montantes escalonados que devem ser indicados de forma crescente ou decrescente.
g) regra de arredondamento Regra segundo a qual o sistema arredonda o valor de condição durante a determinação do preço.
Neste caso, o último dígito será arredondado. As opções padrões disponíveis são Comercial (acima de 5 arredonda para cima e
abaixo de 5 arrendonda para baixo), Arrrendondamente sempre para cima ou sempre para baixo.
h) conversão de moeda O campo controla a conversão de moedas se a moeda de condição divergir da moeda do documento. O
sistema multiplica o montante proveniente do registro de condição pela quantidade do item para calcular o valor da condição de
um documento. Este código controla se o sistema efetua a conversão de moedas antes ou depois da multiplicação. Se o usuário
marcar este campo, o sistema converterá o valor da condição para a moeda do documento depois da multiplicação. Se este
campo não for preenchido, o sistema converterá o valor da condição para moeda do documento antes da multiplicação.
Sistemas standard – Como standard são fornecidos vários tipos de condição, que podem ser utilizados também para a
definição de esquemas de cálculo. Normalmente os requisitos de uma determinação do preço interno podem ser satisfeitos
mediante os sistemas standard.
Mediante clique duplo na área de tela superior esquerda as opções para cada tipo de condição são exibidas na área direita da
tela. Mediante saltar -> vista detalhada é possível visualizar os respectivos dados de controle e opções adicionais.
São fornecidos os seguintes tipos de condição:
CONTROLADORIA 105 de 325
Tipo DESCRIÇÃO CATEG
ORIA
REG
RA
CLASS
E
TP01 Preço interno (fixo)
Este é um tipo de condição para um preço fixo. “ “
C
Qtde
B
Preço
TPB1
Base do ledger de materiais
Este é um tipo de condição de base que utiliza o preço de centro de lucro do
ledger de materiais. No esquema de cálculo podem, então, ser calculadas
sobretaxas ou deduções com base nesta condição básica.
H
Preço
C.Lucro
C
Qtde
B
Preço
TPB2
Base de cálculo de custos
Este é um tipo de condição de base que utiliza o preço do cálculo de custos.
No esquema de cálculo podem, então, ser calculadas sobretaxas ou deduções
com base nesta condição básica.
K
Preço
legal
C
Qtde
B
Preço
TP02 Sobretaxa percentual
Este é um tipo de condição para uma majoração percentual. “ “
A
Qtde
A
Acresc
20.4.5.2 Esquema de cálculo de custos
No esquema de cálculo determina-se quais tipos de condição devem ser considerados e em que seqüência. Mediante a variante
de preço interno é determinado a qual dos esquemas de cálculo existentes o sistema acede na determinação de preço interno.
Exemplo
Nível Tipo Condição Denominação Nível de
10 TP01 Preço interno Fixo
20 TPBA Preço do material Ledger materiais
30 TP0 Acréscimo Percentual 20
No exemplo acima é primeiro procurado um preço fixo. Se este não for encontrado, o preço de centro de lucro é determinado a
partir do ledger de materiais. Com base no preço de centro de lucro é calculada uma sobretaxa.
Também é possível, por exemplo, calcular sobretaxas de sobretaxas, criando uma linha de subtotal sem tipo de condição mas
com níveis 'de' e 'até' e utilizando em seguida esta linha para outros cálculos.
Se o usuário definir um esquema de cálculo próprio, este deve conter apenas os tipos de condição que forem utilizados. Caso
contrário, o sistema acede desnecessariamente às condições.
Standard
Como standard são fornecidos vários esquemas de cálculo, que podem ser atribuídos às variantes de preço interno.
Normalmente, os requisitos de uma determinação de preço interno podem ser cobertos por meio dos sistemas standard.
TP0001 PREÇO INTERNO FIXO
Nível Tipo de condição Denominação
010 TP01 Preço interno fixo
TP0002 Preços internos – porcentagem
Nível Tipo de condição Denominação de até
010 TP01 Preço do material
020 TP02 Acréscimo Percentual 010 010
OBS: É efetuada um acréscimo percentual no preço de centro de lucro do ledger de materiais.
.
CONTROLADORIA 106 de 325
TP0003 Esquema de plano cálculo de custos
Nível Tipo de condição Denominação de até
010 TPB2 Preço de cálculo de custos
020 TP02 Acréscimo percentual 010 010
OBS: É efetuada um acréscimo percentual no preço do cálculo de custos do material
20.4.6 Variante de preço interno
A variante de preço interno determina, se devem ser avaliados dados reais ou dados planejados. Na determinação de preço
interno para movimentos de mercadorias ou materiais são avaliados apenas dados reais. Neste caso necessita-se apenas da
variante fixa 000. Se, no entanto, o usuário pretender determinar preços planejados com base em dados de cálculo de custos,
pode criar várias variantes para a determinação de preço interno.
Criar variantes de preço interno próprias
1. Clicar na área de tela inferior esquerda em criar.
2. Atribuir um número com 3 caracteres e uma descrição sob a forma de texto.
3. Indicar os esquemas de cálculo, que devem ser executados na variante de preço interno. A seqüência do processamento
pode ser controlada através do campo RF .
4. Se o código análise de condição estiver ativado, a análise de condição é chamada em cada transação, que determina um
preço interno.
O código só deve ser definido para motivos de teste, para verificar a determinação correta de preços internos de acordo
com as configurações no customizing da contabilidade de centros de lucro.
Se não existirem outras configurações, a análise de condição por variante de preço interno é válida para todos os usuários.
Em alternativa, a análise de condição por variante de preço interno também pode ser controlada especificamente para o usuário.
Definir, para isso, o parâmetro set-get DIA no valor X, no mestre de usuário. O usuário afetado pode depois ativar a análise de
condição para todas as variantes de preço interno existentes.
5. Gravar a variante.
Sistemas standard
000 variante real
Número Esquema de cálculo Denominação Seqüência
10 TP0001 Preço interno fixo 01
20 TP0002 Preço interno porcentual 02
Primeiro o sistema processa o esquema de cálculo de custos TP0001. Se for encontrado aqui um preço interno, este é utilizado.
Se não for encontrado nenhum preço interno, é processado o esquema de cálculo de custos TP0002.
001 Variante de planificação 1
Número Esquema de cálculo Denominação Seqüência
10 TP0001 Preço interno fixo 01
20 TP0003 Preço de cálculo planejado 02
Primeiro o sistema processa o esquema de cálculo de custos TP0001. Se for encontrado aqui um preço interno, este é utilizado.
Se não for encontrado nenhum preço interno, é processado o esquema de cálculo de custos TP0003.
20.4.6.1 Lista de Preços
É possível definir uma estrutura da tela para listas de preços. Através de listas de preços, é possível analisar registros de
condição, de acordo com diferentes critérios. Tecnicamente, as listas preços representam programas ABAP.
CONTROLADORIA 107 de 325
Atividades
1. Entrar o título da lista de preços, que se pretenda criar. O código da lista é um suplemento composto por duas letras que é
automaticamente incluído ao report pelo sistema quando o report é gerado.
2. Na tela de dados subseqüente surgem todos os campos-chave, utilizados na área das condições, por ordem alfabética.
Selecionar todos os campos-chave, que devem ser tidos em consideração, na lista de preços.
3. Selecionar 'processar -> selecionar tabelas'. Surge uma caixa de diálogo, em que é possível especificar a seleção das tabelas
de condição. Caso seja selecionado "sim", apenas são avaliadas as tabelas de condição, que contêm todos os campos-chave
selecionados. Caso seja selecionado "não", são avaliadas todas as tabelas de condição, que contêm, no mínimo, um dos
campos-chave selecionados.
As tabelas de condições são as combinações de determinados campos que constitui a chave de um registro de condição.
Em um esquema de cálculo, o usuário especifica a sequência dos tipos de condição. Uma sequência de acesso poderá ser
atribuída ao respectivo tipo de condição. Esta sequência de acesso indica onde o sistema deve procurar os registros de
condição que são relevantes para um determinado tipo de condição (por exemplo, um bônus para um cliente). Cada acesso
na sequência de acesso está relacionado a uma tabela de condições. Os campos (ou seja, as chaves) definidos na tabela
possibilitam o sistema encontrar os registros de condição válidos. O usuário deverá definir um ou vários campos de destino
como chave de tabela durante a criação de uma tabela de condições. Além disso, será preciso informar o sistema onde o
valor para o campo de destino pode ser encontrado. Com este objetivo, o usuário deverá indicar um campo de origem. O
campo de origem e o campo de destino são geralmente idênticos, mas os dois também poderão ser diferentes.
Se o campo de destino "Cliente" fizer parte da chave, o usuário poderá determinar que o sistema utilize o campo
"Recebedor de mercadorias" como campo de origem e copie o valor existente neste campo.
4.
5. Marcar, na caixa de diálogo seguinte, todas as tabelas de condição, que devem ser avaliadas.
6. Selecionar "posicionar campos", de modo a determinar a estrutura da tela da lista de preços. Deve ter-se em atenção, que
surjam todos os campos-chave das tabelas selecionadas na tela de dados subseqüente. Os campos, que devem ser utilizados
na exibição posterior da lista como critérios de seleção, podem ser ocultados através da anulação da marcação na coluna
"seleção".
7. Selecionar "forma", de modo a determinar a exibição de escalas ou de períodos de validade para a lista de preços.
21 Contabilidade de Centro de Custo
Dentro de Contabilidade de Centro de Custo (CCA), assim como em todo o R/3, existe uma diferença entre dados cadastrais
(dados mestre) e dados transacionais (transation data). Os dados cadastrais (classes de custo, centros de custo, tipos de
atividades, índices estatísticos, Organização Empresarial e hierarquia standard) permanecem inalterados por um longo período
de tempo. Já os dados transacionais (lançamentos – line items, registros de totais – total records) são usados no curto prazo e
são associados aos dados cadastrais.
A partir da versão 4.6 foi disponibilizada em função em CO, Organização Empresarial que permite visualizar todas as
unidades organizacionais em uma só tela (empresas, centros de custos, centros de lucro, Área de Contabilidade de Custos, etc.)
de forma gráfica facilitando a compreensão da estrutura organizacional implementada.
21.1 Dados mestre
A manutenção dos cadastros básicos pode ser feita de forma individual ou coletiva. De forma coletiva podem ser definidos
intervalos de valores, grupos ou variantes de seleção (definidas no IMG). As variantes de seleção podem ser alteradas durante
o processamento. Para as variantes de seleção podem ser definidas classificações e filtros assim como em uma ABAP list
viewer (list variants – definem os campos a serem apresentados).
A variante de seleção permite acumular os registros de acordo de diversas características (por exemplo: agrupar os centros de
custo por categoria de centros de custo. Deste ponto de vista, podemos considerar a variante de seleção como um agrupamento
dinâmico visto que, se um novo centro de custo for cadastrado com esta categoria, automaticamente, passa a fazer parte deste
grupo.).
Dados mestre dependente do tempo – O R/3 permite a manutenção dos cadastros básicos também em função do tempo.
Assim, por exemplo, pode ser definido que durante o ano de 2000, o responsável pelo centro de custo de manutenção será o Sr.
Alberto e no ano de 2001 passará a ser o Sr. José. Será gerado um registro para cada intervalo de validade desejado. Nas
CONTROLADORIA 108 de 325
consultas e relatórios, será verificado o intervalo de validade. Este critério de dependência do tempo pode ser definido no
Customizing a nível de campo, ou seja, pode-se definir para quais campos se deseja guardar informações diferentes ao longo do
tempo. Então, só será possível definir dois responsáveis para um mesmo centro de custo conforme o período se o campo
responsável tiver sido definido como dependente do tempo. Sempre que for alterado um campo no cadastro de centro de custo
ou em outros cadastros do R/3 com a mesma característica, o sistema irá informar que o campo é dependendo do tempo e
solicitará que se deseja gerar um novo intervalo de validade ou alterar a informação no intervalo de dados atual.
No entanto, nem todas as informações podem ser definidas como dependentes do tempo. A vinculação do Centro de Custo à
hierarquia padrão é um exemplo.
21.1.1 Grupos de Dados mestre
Para todos os cadastros básicos podem ser definidos agrupamentos. Os grupos são usados para manutenção do cadastro, para
definir critérios de alocação, para análises e planejamentos a nível sintético. O uso do grupo agiliza o processo de planejamento
ou geração de relatórios. Pode ser criada uma hierarquia de grupos.
Os grupos de centros de custos podem ser criados independentemente da hierarquia padrão. Os grupos podem conter um ou
mais intervalos de numeração. No entanto, em alguns casos, não é possível selecionar os valores necessários através de
intervalos de numeração. Para selecionar, por exemplo, os centros de custos de produção ou as classes de custos de uma
determinada categoria, ou as ordens de um determinado tipo, pode-se definir uma variante de seleção e incluir a variante de
seleção no grupo. Opcionalmente, pode-se usar a própria variante de seleção no campo de grupo colocando um ponto antes do
nome para que o sistem reconheça que é uma variante e não um grupo. Transações para criar uma variante de seleção:
Transação Dados mestre
OKOV Ordens
KM1V Centros de Custos
KM7V Tipos de Atividades
KM5V Classes de Centros de Custos
É possível definir “Opções para relatório” para um determinado grupo. Uma destas opções é o valor representativo, que
permite definir definir um centro de custos para representar vários outros centros de custos. O valor representativo é um
substituto de um grupo de valores. Ele é utilizado, por exemplo, em textos de relatório.
Utilizando a seleção, é executado um relatório sobre um grupo de centros de custo, e deseja-se exibir o responsável pelos
centros de custo no cabeçalho do relatório. O responsável pelo centro de custo está somente gravado nos dados mestre dos
centros de custo. Por este motivo deve ser entrado um centro de custo como centro de custo representativo. Na execução do
relatório, é exibido o responsável pelo centro de custo representativo.
No controlling dos custos indiretos, o valor representativo é principalmente utilizado em grupos de centros de custo.
No sistema de informações:
Para a seleção da impressora do departamento, caso se deseje imprimir uma hierarquia, na qual a área de
responsabilidade difere para cada nível hierárquico, e por esta razão deve ser respetivamente selecionada uma
impressora diferente.
Para a exibição de dados mestre para características das linhas e colunas de um relatório, por exemplo no cabeçalho do
relatório, é utilizado o valor representativo em substituição de variáveis de texto.
Em rollups hierárquicos:
O valor representativo substitui, por exemplo, o centro de custo, no qual devem ser condensados os dados de todos os
centros de custo no set.
No planejamento (somente para CO: Contabilidade de centro de custo e FI: Ledgers especiais):
Se um set de parâmetros de set inclui um valor representativo, por exemplo um centro de custo, então pode ser entrado
um valor para este centro de custo no planejamento, em substituição de todos os centros de custo do set.
CONTROLADORIA 109 de 325
21.1.2 Classe de Custo (Cost Elements)
As classes de custo de subdividem em classe de custos primária, classe de custos secundária e classe de receitas. As classes de
custos são as “contas contábeis” para CO. É através destas classes que todos os lançamentos serão gerados em CO, seja
lançamentos oriundos de FI, seja lançamentos diretos em CO em qualquer um de seus componentes.
CLASSES DE CUSTOS PRIMÁRIAS (PRIMARY COST ELEMENTS)
Primary cost element - são as classes de custo primárias propriamente ditas;
Imputed cost element – são as contas para lançamento das provisões gerenciais (accrual orders), precisa ser definida no plano
de contas mas não precisa existir no segmento da empresa. Um exemplo de accrual orders podem ser uma depreciação
gerencial que não vem de FI. Neste caso, ou define-se um procedimento para converter as depreciações gerenciais efetuadas em
CO para as depreciações reais em FI e, num dado momento, a ordem será encerrada ou, define-se que as depreciações reais não
serão lançadas em CO. Neste caso, a ordem de provisão ficará sempre em aberto ou deverá ser liquidada manualmente em CO.
O motivo para que esta classe de custo seja primária é para a conciliação com FI.
External order settlement – conta para liquidação das ordens internas para fora de CO, por exemplo, no caso de se criar uma
ordem interna para controle da construção de um prédio. Ao final da construção, o prédio será convertido em um ativo
imobilizado e a ordem interna precisará ser liquidada contra uma conta contábil do ativo. Observe que , neste caso, a conta não
será uma conta de resultado e sim uma conta patrimonial. Este é um dos poucos exemplos de utilização de contas patrimoniais
em CO.
CLASSES DE CUSTOS SECUNDÁRIAS (SECONDARY COST ELEMENTS)
As classes de custo secundárias se subdividem de acordo com o método de alocação de custos para a qual ela será definida
dentro de CO.
Internal activity alocation – classe de custo associada a um tipo de atividade a nível cadastral usada para alocação de
atividades em CO seja direta ou indiretamente.
Assessment – classe de custo usada para efetuar rateio em CO. Cada segmento do ciclo de rateio pode ter uma classe de custo
diferente. No entanto, pode ser definida a mesma classe de custo para mais de um segmento.
Overheads – classe de custo usada para efetuar os lançamentos de sobretaxa conforme o esquema de cálculo de custos definido
na Costing Sheet.
Internal order settlement – classe de custo usada para efetuar a liquidação de uma ordem interna contra um objeto de custo
dentro de CO. Estas classes são definidas na Estrutura da Alocação (Alocation Structure) que será vinculada a um perfil de
liquidação (Settlement Profile) que, por sua vez estára vinculada ao tipo da ordem interna a ser liquidada. Assim, o processo de
liquidação da ordem pode usar várias classes de custo e pode, inclusive ser a classe de custo primária original do lançamento.
CLASSE DE RECEITAS (REVENUE ELEMENTS)
As classes de receitas são válidas somente para CO-PA e EC-PCA. Em CCA somente para lançamentos estatísticos.
Revenue element – recebe os lançamentos referentes a receitas.
Sales deduction – recebem os lançamentos referente a deduções de vendas.
Nem todas as contas de despesas terão uma classe de custo em CO. Por exemplo, a conta de custo de produtos vendidos.
Através do Default settings podem ser definidos critérios para geração automática das classes de custos primárias e
secundárias. As classes primárias serão definidas como espelho da conta contábil e a categoria será definida no default setting.
As classes secundárias terão a mesma descrição da categoria já que não existem em FI. Posteriormente pode ser alterado o
nome tanto da classe primária quanto da secundária. As classes podem ser geradas on-line ou através de batch input.
Como já foi dito anteriormente, é preciso reservar um intervalo de contas para as classes secundárias na definição do plano de
contas contábeis para FI visto que, embora CO não permita o cadastramento de uma classe secundária se já existir uma conta
contábil com este número no razão geral em FI, FI não verifica a existência de uma classe secundária para bloquear o
cadastramento de uma conta contábil no razão geral.
CONTROLADORIA 110 de 325
O R/3 permite o processamento coletivo para consulta e exclusão de classes de custo.
Para cada classe de custo pode ser definida uma Attribute Mix (Mix de Características) contendo até oito atributos que podem
ser definidos para a classe de custos para melhor descrevê-la. É uma informação puramente documentacional que poderá ser
usada em relatórios.
Para a classe de custo pode ser definido, ainda, se irá armazenar lançamentos em quantidade e, neste caso, qual será a unidade
de medida. As quantidades consumidas deverão ser armazenadas na unidade de consumo ou em uma unidade de medida que
possa ser convertida. No planejamento, a unidade de medida pode ser alterada a nível de centro de custo/ classe de custo. Se
nehuma unidade for informada, no primeiro planejamento, poderá esr informada qualquer unidade de medida.
Se não for informada nenhuma unidade de medida e diferentes unidades de quantidades forem determinadas para cada centro
de custo/classe de custo, não será possível armazenar quantidades na distribuição real/planejada.
Em Product Cost Controlling, materiais com diferentes unidades quantitativas são armazenados numa mesma classe de custo.
Este materiais podem ser armazenadas individualmente em CO, mas não a nível de classe de custo. Neste caso, a unidade do
material será usada no custeio.
Ainda pode ser informado valores padrão para um centro de custo e/ou uma ordem interna de forma que, sempre que se fizer
um lançamento para esta classe de custo, o sistema irá sugerir estes objetos de custo como valores default. Inclusive, através de
outras configurações, estes campos podem ser bloqueados para alteração. Estes valores padrões se aplicam a classes de custo
primária usadas lançamentos de FI.
Cada classe de custo pertence a uma única Área de Contabilidade de Custos e possuem um período de validade.
21.1.2.1 Categoria de Classes de Custo
PRIMARY COST ELEMENT CATEGORIES
01 General Primary Cost
Elements
Classe de custo usada para lançamento de custos primários (fora de CO) vindo de FI, MM, etc.
03 Accrual Cost
Elements, Percentage
Method
Usada somente em Contabilidade de Centro de Custo (CO-OM-CCA) para cálculo de
provisões com base em porcentagens. Os lançamentos de custos reais podem ser gerados
diretamente de FI e o R/3 irá usar esta categoria par lançar provisões em CCA. A conta
vinculada à classe de custo precisa existir a nível de plano de contas. Mas não precisar ser
cadastrada a conta no G/L.
04 Accrual Cost
Elements,
Target=Actual
Method
Semelhante à categoria anterior só que para o Target = Actual Method que considera o custo
teórico como sendo o custo real.
11 Revenue Elements Usada para lançamentos de receitas. As receitas parecem como lançamentos negativos em CO
exceto em CO-PA. Um centro de custo só pode receber lançamentos estatísticos de receita o
que significa que os lançamentos podem ser transferidos para outros centros de custos por
Reposting (erro) mas não podem ser alocados e as receitas não serão consideradas durante a
precificação de atividades iterativa e não estão incluídas nos preços da alocação das
atividades.
Quando se tratar de um lançamento de crédito referente a um credit memo (lançamento que
reduzi valores a receber ou a pagar – nota de crédito) definir a classe na categoria para que
aparecem em CO com valores negativos e possam ser tratadas como custos.
As receitas só integram com PA se tiverem a classe 11 ou 12.
CONTROLADORIA 111 de 325
PRIMARY COST ELEMENT CATEGORIES
12 Sales Deductions Usada para lançamento de deduções de vendas (descontos, abatimentos). Algumas deduções
de vendas são classificadas como classe de receitas e não de deduções tais como, frete
destacado na NF, surcharges para pequenas quantidades, ordens especiais. Funcionam da
mesma forma que a categoria anterior.
22 External Settlement Usada para liquidar, custos de ordens, projetos ou objetos de custos para um objeto fora de CO
que pode ser um ativo (AM), um material (MM) ou uma conta do G/L (FI). Não poderá ser
usada para liquidação dentro de CO (centros de custo, ordens, projetos, etc.) quando deve ser
usada a categoria 21. O R/3 somente cria um documento em CO quando a liquidação for feita
para fora de CO.
90 Financial Accounting
Balance Sheet
Accounts
Atribuída automaticamente na criação de uma classe de custo de CO cuja conta em FI seja de
conciliação de ativo (contas patrimoniais especiais), not income statement accounts. Os dados
cadastrais desta categoria não podem ser alterados. Os lançamentos serão estatísticos. Esta
categoria permite verificar orçamento de aquisição de ativos em ordens e projetos. Para tal, a
ordem de investimento ou o WBS element deve ser informado no cadastro do ativo. As classes
de custos desta categoria podem ser tratadas como activity independent como parte do
planejamento do centro de custo.
SECONDARY COST ELEMENT CATEGORIES
21 Internal Settlement Usada para liquidação de ordens ou projetos para objetos em CO.
31 Order/Project Results
Analysis
Usada para armazenar Dados de análise de resultado de ordem / projeto.
41 Overhead Usada para distribuir custos indiretos dos centros de custo para as ordens podendo ser custos
com materiais, vendas ou administrativos.
42 Assessment Usada para rateio.
43 Internal Activity
Allocation
Usada para alocação de custos durante Internal Activity Allocation e também no Custeio
ABC.
21.1.3 Centros de Custo (Cost Centers)
A manutenção dos centros de custo pode ser feita pela função específica ou através da hierarquia padrão (standard) definida
para a Área de Contabilidade de Custos. Todos os centros de custos deverão estar contidos na hierarquia de forma que o nó
principal represente o somatórios de todos os centros de custo da ontrolling Area.
O Centro de Custo é gerado dentro de um período de validade. Se, por exemplo, o centro de custo for cadastrado válido para
somente um ano, para aumentar a sua validade, será preciso cadastrar novamente o centro de custo como sendo válido para o
período adicional de validade requerido. O Sistema irá considerar como o mesmo centro de custo já que terá a mesma chave de
identificação.
A moeda do centro de custo será igual à moeda da empresa (e não da Área de Contabilidade de Custos). A moeda do Centro de
Custo somente poderá ser diferente da moeda da empresa quando for definido que a Área de Contabilidade de Custos irá
trabalhar com somente uma moeda e, neste caso, a moeda da empresa e da Área de Contabilidade de Custos serão as mesmas.
As categoria dos Centro de Custo define o tipo de atividade executada pelo Centro de Custo (Produção, Administrativo, etc.). O
SAP fornece algumas categorias cadastradas mas a empresa pode definir suas próprias categorias conforme sua necessidade. A
Categoria de Centro de Custo é usada para definir valores padrões para os centros de custo desta categoria sendo: se o centro de
custo aceita ou não lançamentos de classes de custos primárias, secundárias e/ou receitas a nível de planejamento e dados reais
e lançamentos de compromisso e de quantidade. Ao cadastrar os centros de custos, a informação vem default da categoria mas
pode ser alterada a nível de centro de custo.
As categorias de centro de custo também são usadas para restringir os centros de custo que poderão executar uma determinada
atividade, ou seja, ser associado a um tipo de atividade (activity type) nas funções de planejamento. No dados mestre do Tipo
de atividade pode ser definido qual o tipo de centro de custo pode executar aquele tipo de atividade. Para aceitar todos as
categorias o campo pode ser preenchido com um asterisco (*).
CONTROLADORIA 112 de 325
G1
G1 G1
G1 G1 CC1 CC2
CC3CC4CC5CC6
O R/3 permite a manutenção em massa dos dados cadastrais dos centros de custos. Podem ser selecionados por intervalos,
grupos ou variantes de seleção. Podem ser alterados todos os campos exceto os campos adicionais específicos da empresa.
Depois de cadastrado um centro de custo, a empresa, a business area ou o centro de lucro associados somente poderão ser
alterados se: a moeda da nova empresa seja a mesma, só existam lançamentos de planejamento para um dado ano fiscal e o
centro de custo não tenha associado a um ativo, a um centro de trabalho ou a um registro do HR.
A vinculação do centro de custo com um centro de lucro é opcional. No então, quando não existir esta amarração, o sistema irá
jogar todos os custos para um centro de lucro definido como Dummy.
TEMPLATE - MODELO
Os modelos podem ser associados a Centros de Custo para execução de planejamento de custos primários e consumo de
atividade. Neste caso, o planejamento pode ser dependente ou independente da atividade. Os modelos também podem ser
usados para efetuar alocações de processos empresariais (ABC) e, ainda, como ser vinculados a um Esquema de Cálculo de
Custo (Costing Sheet) para calcular sobretaxas (custos indiretos).
O Esquema de Cálculo de Custos controla o cálculo custos indiretos. Cada objeto de custo (ordem, centro de custo) deve ter um
Esquema de Cálculo de Custos associada para o cálculo dos custos indiretos. Para as ordens de custo indiretas, o Esquema de
Cálculo de Custos pode ser assumida do modelo da ordem (tipo de ordem).
Para os centros de custo e processo ABC, o Esquema de Cálculo de Custos precisa ser definida no cadastro
Para as ordens de produção de CO sem estrutura quantitativa, o Esquema de Cálculo de Custos proposto pelo sistema será o
constante no Perfil de Planejamento (Planning Profile). Para ordens de produção, ordens de processo, coletores de custo de
produto, ordens de manutenção, ordens de manutenção regular e ordens de serviço, o Esquema de Cálculo de Custos é definido
pela Variante de Avaliação (Valuation Variant). A Variante de Avaliação é definida pela Variante de Cálculo de Custos
(Consting Variant) que, por sua vez, está definida nas parametrizações do tipo de ordem e centro.
Para os projetos, o Esquema de Cálculo de Custos é definido no perfil do Projeto. Para materiais, é definido pela Variante de
Avaliação. Para base objet plannings, é definido nos dados mestres. Para objetos de custo, é definido no perfil do objeto de
custo. Para os itens de documentos de vendas, é definido nas classes de requirements.
VARIANTE DE SELEÇÃO
Para os centros de custos podem ser criadas Variantes de Seleção que corresponde a um grupo dinâmico de centros de custos
para ser usado em relatórios. Os relatórios disponíveis são:
Relatórios Disponíveis
RKKOASEL Classes de custo
RKKSTSEL Centros de custo
RKLSTSEL Tipos de atividade
RKPRZSEL Processos Empresariais (ABC)
RKOSEL00 Ordens internas
RKPSEL00 Projetos
CONTROLADORIA 113 de 325
Para uma Variante de Seleção, devem ser definidos os campos para os quais se deseja atribuir valores. Estes valores podem ser
alterados no momento da execução do relatório conforme o que for parametrizado nos atributos. Os campos não desejados
podem ser suprimidos. Por exemplo, para selecionar os objetos por período de tmepo, defina selection variant que somente irá
contem os campos do cadastro referentes a período.
LIST VARIANTS PARA PROCESSAMENTO COLETIVO
As list variants correspondem ao layout de telas de entrada para processamento coletivo. Define-se quais os campos serão
apresentados na tela de lista e na tela de detalhe eestarão disponíveis para apresentação. O SAP disponibiliza as seguintes list
variants para processamento coletivo de centro de custo: Standard one row, Standard two rows, Standard three rows e Standard
four rows. Estes variants não podem ser alteradas.
21.1.4 Tipos de Atividade (Activity types)
O tipo de atividade classifica uma atividade específica executada por um ou mais centros de custo. Na execução de uma
atividade, um centro de custos consome recursos e, naturalmente, o custo destes recursos precisam ser alocados para os objetos
(centros de custo, ordens, processos, etc.) que estão se beneficiando da atividade executada. O centro de custo que executa a
atividade é dito emissor e os centros de custo (ou outros objetos de custos) que recebem as atividades ~sao denominados
receptores.
O tipo de atividade fornece o tracing fator (grandeza de referência) para alocação dos custos (exemplo: homem-hora, hora-
máquina). Os tipos de atividades se dividem em quatro diferentes categorias. A categoria da atividade determina o método para
alocação e planejamento da quantidade da atividade. Os métodos de alocação para os tipos de atividade são:
Alocação Direta – a quantidade de atividade a ser alocada é informada manualmente e multiplicada pelo preço planejado
para a atividade pelo emissor.
Predistribuição de custos fixos
Indireta (cálculo inverso ou retroativo da atividade)
Não alocada; a quantidade de atividade foi executada para o próprio centro de custo emissor.
21.1.4.1 CATEGORIAS DE TIPO DE ATIVIDADE
Categoria 1 (planejamento e alocação manual) - as atividades desta categoria são usadas para planejamento e alocação
manual. O planejamento da quantidade de atividade a ser executada pelo centro de custo emissor (executante) é feito pelo
Responsável pelo Centro de Custo Emissor através da função de planejamento da saída de atividade, planejando, inclusive
o valor da atividade. Já as quantidades de atividade a serem solicitadas a este centro de custo pelos centros de custo
receptores será feita, manualmente, pelos responsáveis por estes centros de custos através da função de planejamento de
entrada de atividade Percebe-se, então, que, pode existir uma variação entre o montante planejado pelo emissor e o
somatório do montante planejado pelos receptores. Será necessário, portanto, fazer uma conciliação para ajustar o
planejamento do emissor de acordo o planejamento dos receptores. Esta função não a parte de fixa da atividade e as
variações são listadas. Esta conciliação é executada iterativamente.
Categoria 2 (alocação indireta e cálculo indireto) – as atividades desta categoria são aquelas para as quais o cálculo das
quantidades é impossível ou extremamente trabalhoso. O cálculo das quantidades planejadas e reais é feito através da
alocação indireta de atividade através do relacionamento definido entre o emissor e o receptor, através dos tracing factor
(base de referência) do receptor ou através de quantidades fixas definidas nos segmentos. As quantidades de atividades
planejadas e reais será o somatório das quantidades solicitadas de atividade calculada pelos tracing factor (base de
referência) em cada um dos recpetores. Portanto, para esta categoria a conciliação é automática.
Categoria 3 (planejamento manual com alocação indireta) – Para as atividades desta categoria serão planejadas
manualmente para o centro de custo emissor através de uma função especial (nom-allocatable activities) sem informar
nenhum objeto receptor. O sistema, com base no relacionamento estabelecido entre emissor e receptores, irá calcular as
quantidades de atividades a serem alocadas para cada receptor com base na proporção dos tracing factor (base de
referência) para todos os receptores e alocar completamente a quantidade planejada no emissor para os receptores.
Portanto, após a alocação indireta de atividades, as atividades planejaados estarão totalmente conciliadas.
Categoria 4 (manual entry, sem alocação) – as atividades desta categoria são planejadas manualmente para o centro de
custo emissor e os custos permanecerão no próprio centro de custo. São atividades internas ao centro de custo, com, por
exemplo, atividades de planejamento, apurações, etc..
CONTROLADORIA 114 de 325
Os valores default podem ser gravados para um tipo de atividade ou um processo ABC para as categorias de atividades
alocáveis ou categorias de alocação (categoria 1, 2 ou 3). Os valores default podem ser alterados no planejamento para uma
categoria de atividade alocável diferente ou categoria de alocação se for o primeiro planejamento. Somnete é possível alterar
categorias de atividades não-alocáveis ou categorias de alocaçao (categoria 4) para categorias de de atividades alocáveis ou
categorias de alocação (ou vice-versa) se existirem dados dependente da atividade.
Alocação interna de atividade – na alocação interna de atividade o sistema irá calcular o total do custo a ser alocado
considerando o montante da atividade executada pelo emissor para o receptor definida pela quantidade de atividade (tracing
fator) e o preço estabelecido pela atividade. O R/3 gera um débito no receptor e um crédito no emissor a nível de quantidade e
de valor. A classe de custos usada nestes lançamentos será uma classe de custo secundária definida no cadastro do tipo de
atividade.
Como já foi dito, um tipo de atividade pode ser restringido a determinados tipos de centro de custo (categorias de centro de
custo – produção, administrativo, serviço, etc.) até, no máximo, oito. Para permitir para todos os centros de custo digitar “*”
(asterisco).
Cada tipo de atividade precisa ter uma classe de custos secundária associada que será usada pelo sistema para efetuar os
lançamentos de débitos e créditos nos centros de custos referente às alocações de atividades. Esta classe de custos deverá ser,
obrigatoriamente da categoria 43. Se estiver planejando pela primeira vez, esta classe de custo pode ser alterada. Esta
informação é time-based, obrigatoriamente,. Isto significa que, para cada ano fiscal, pode ser definida uma classe de custo
diferente.
Para cada centro de custo que puder executar uma atividade, deve ser definido o preço por unidade da atividade. A
determinação do preço pode ser manual ou automática dependendo do campo price indicator. Para planejamento manual, deve
ser definido o indicador de preço 3 (informado manualmente). O planejamento é feito na função activity/output price para um
centro de custo. A função de planejamento funciona como manutenção cadastral.
Além do lançamento manual, o preço da atividade pode ser calculado automaticamente pelo R/3. O cálculo automático pode ser
definido com base na quantidade de atividade total executada (indicador de preço 1) ou na capacidade total do centro de custo
(indicador de preço 2). O lançamento manual é usado quando a determinação do preço é simples ou quando depende de
fornecimentos externos e não dos custos internos do centro de custo ou quando a tarifa não depende das atividades produzidas
internamente.
Através do planejamento integrado, é possível extrair as quantidades das informações do PP através da vinculação dos grupos
de trabalho com os centros de custo. Em PP, são definidas as quantidades de atividades planejadas para os centros de trabalho.
Em CO, estas atividades são repassadas ao centro de custo vinculado e valorizadas conforme a tarifa definida para aquela
atividade e aquele Centro de Custo.
Flag Actual qty set – se este flag por selecionado será obrigatório lançar, manualmente, a quantidade real, alpem da quantiade
com a qual o objeto é creditado. Esta opção faz sentido quando a quantiade creditada no objeto foi determinada indiretamente
mas a quantiade real do do ponto de vista do emissor já é conhecida.
Flag: Average Prices – indica se os preços da atividade por centro de custo/tipo de atividade permanece constante para todo o
ano fiscal (preço médio dos períodos). Esta campo também é dependente do tempo podendo ser alterado a cada ano fiscal.
Flag: Plan quantity set – indica que a quantidade de atividade planejada não pode ser alterada pela função de Conciliação do
Planejamento mesmo que encontre ajustes a fazer.
Flag: PreDistribFixedCost – indica se será permitido que este tipo de atividade (ou processo ACB) seja usado na
predistribuição de custos fixos.
Variance values por actual alocation – uma vez feito o planejamento das atividades, podem ocorrer variações com os valores
reais. O sistema permite que seja definida uma outra categoria para a atividade diferente da planejada. As definições possíveis,
além das do planejamento são, igual à definida no planejamento ou target = actual alocation.
Categporia 5 – Target=Actual Aloccation – este é um tipo especial de alocação indireta que determina os valores
reaias a partir das necessidades de atividade planejadas através de uma índice operacional. Esta categoria somente
pode ser definida para alocação real. As categorias para o planejamento deve ser 1, 2 ou 3 (via de regra, categoria 1).
Este tipo de alocação permite determinar iterativamente uma rede de atividade em múltiplos níveis usando um índice
operacional como um tracing fator. Isto significa que as relações de atividade recursivas entre os centros de custo são
consideradas. Relacionamento recurvisos ocrrem, por exemplom quando um centro de cutos recebe e fornece
atividade para um outro centro de custo.
Neste caso, o R/3 calcula as quantidades a serem alocadas com base nas entradas de atividades planejadas nos
receptores, considerando o índice operacional definido nestes receptores para estes tipo de atividade. Isto resulta na
CONTROLADORIA 115 de 325
atividade target do centro de custo emissor, que nada mais é do que a quantidade de atividade que deve ser realmente
produzida baseada nos ajustes do índice operacional. A parte variável da quantidade de atividade planejada é ajustada
pelo índice operacional definida para a relação centro de custo repector/tipo de atividade e é, então, atualizada como
uma quantidade de atividade real variável. A parte fixa da quantidade da atividade é transfrida do planejamento para o
real. Para usar este tipo de alocação, é necessárip que a conciliação do planejamento tenha sido assegurada para evitar
a obtenção de índices operacoinais incorreto e, consequentemente, alocações incorreta.
Se estiver trabalhando com preço de transferência (fluxo parelelo de valores), a alocação é executada pela valorização
principal.
Price indicator – estão disponíveis as mesmas opções do planejamento.
Output factor - fator a ser aplicado sobre a quantidade de atividade para determinar a quantidade de saída.
O R/3 permite consultar os excluir tipos de atividades em massa.
Da mesma forma que para centros de custo, é possível criar variantes de seleção.
21.1.5 Índices estatísticos (Statistical key figures)
Assim como os tipos de atividades, os índices estatísticos são critérios para alocação periódica de custos (distribuição e rateio)
para os quais devem ser atribuído um valor. Só que os índices estatísticos são medidas numéricas que auxiliam na alocação de
custos entre os centros de custo, ordens internas, centros de lucro. Também pode ser definido um índice estatístico
especificamente para um determinado tipo de atividade executada por um centro de custo, tal como o número de empregados
que executam reparos em um centro de custo de transporte (índice estatístico dependente da atividade). Os índices estatísticos
também podem ser usados para cálculo de índices em relatórios.
Podem ser lançados tanto valores planejados como reais para os índices estatísticos.
Os índice estatísticos podem ser fixos (categoria 01) ou totais (categoria 02). Um índice fixo, significa que seu valor em
constante em longo dos períodos. O valor é informado uma vez e vale para todos os períodos. Por exemplo, o número de
empregados de um centro de custo pode ser considerado como um índice fixo. No entanto, seu valor pode ser alterado
manualmente pelo usuário se necessário. Por exemplo, um funcionário pode mudar de setor, ou ser demitido, etc. O índice total
corresponde a valores acumulados ao longo do período. Por exemplo, número de ligações telefônicas efetuadas no mês. Estes
índices precisam ser informados periodicamente.
Os índices estatísticos também podem ser extraídos do LIS (Logistic Information System) sem a necessidade de informá-los
manualmente. Para isto, o LIS precisa estar ativo em Logística para que o banco de dados do LIS esteja sendo atualizado e deve
ser especificado no cadastro do índice estatístico seu vínculo com a key figure correspondente no LIS. O R/3 oferece dois
métodos para as key figures do LIS: Info Structures, que são tabelas de bancos de dados automaticamente atualizadas dos
componentes de logística (SD ou PM – Plant Maintanance) ou os Info Set que também estruturam as key figures do LIS mas
com algumas distinções.
O R/3 fornece dois métodos de pesquisa para os indicadores (key figures) do LIS. Info Structures são tabelas do banco de
dados gerenciadas pelo R/3 que atualizam, automaticamente, os indicadores do LIS de cada componente específico (SD ou
PM). Info Sets também são uma estrutura dos indicados do LIS mas com uma pequena diferença.
Diferenças Info Structure Info Sets
Extent Key figures de:
Análises padrões do LIS
Key figures de:
Análises padrões do LIS,
Relatórios, Transações,
Tabelas
Profundidade Três níveis:
1. Componente
2. Info Structure
3. key figure
Várias níveis:
1. Info Set
2. …
3. …
n-1. Info Set
n. key figure
CONTROLADORIA 116 de 325
Através das Info Structure, a pesquisa requer conhecimento de conexões técnicas entre as tabelas do banco de dados. Através
das Info Set, a pesquisa requer conhecimento de conexões lógicas entre as tabelas. Independente do método, o sistema
apresenta a informação do índice estatístico na tela de manutenção inicial.
A transferência pode ser feita independentemente da atividade para um centro de custo, grupo de centro de custo ou para todos
os centros de custo de uma área de controle ou então dependente da atividade para um centro de custo, um grupo de centro de
custos e para todos os centros de custos de uma Área de Contabilidade de Custos com base no tipo de atividade, um grupo de
tipo de atividade ou para todos os tipos de atividade.
O R/3 permite processamento coletivo para alteração e exclusão dos índices estatísticos.
21.1.6 Recursos
Recursos são mercadorias e serviços adquiridos para a execução de uma determinada atividade empresarial. Em CO-OM, os
recursos podem ser usados somente para planejamento. Podem ser planejados durante o planejamento de custos primários para
os centros de custo/tipo de atividade, para ordens e para elementos WBS de projeto. Custos primários são os custos gerados
pelo consumo de mercadorias e serviços oriundos de fora da empresa. Associando mais de um recursos para um classe de custo,
pode-se reduzir o plano de contas sem perder detalhes relevantes para análise de custos.
Os recursos não podem ser usados no planejamento estruturado de ordens e elementos WBS. Os quatro tipos de registros
disponíveis são:
Tipo R – existe somente em CO-OM e seus preços são armazenados diretamente nas tabelas de preço.
Tipo M – referentes a uma material e seus preços são definidos no mestre de material. Em MM, o recursos, em conjunto
com a categoria do item, descreve o que o item representa em uma estimativa de custos (materiais, tipo de atividade, Info
records de compras ou custo indireto)
Tipo B – referente a um base planning object e considera o preço do objeto base de planejamento custeado para valorizar o
consumo do recurso. Um Base planning object refere-se a um objeto em unidade de custeio que pode ser usada como um
componente em uma outra estimativa de custo. Um base planning object pode ser copiado no planejamento de outros
objetos em CO.
21.2 Lançamentos baseado em eventos
21.2.1 Automatic Commitment and Funds Reservation
Compromissos são obrigações futuras de pagamento geradas no cadastramento de uma ordem de compra, requisição interna de
compra. Para que seja gerado um lançamento de compromisso em CO é preciso que o gerenciamento de compromissos esteja
liberado para a Área de Contabilidade de Custos, para o centro de custos e deve ser informado um objeto de custo no
lançamento da ordem ou requisição de compra. Se for gerada uma ordem de compra baseada em uma requisição de compra, o
lançamento de compromisso em CO é reclassificado. No recebimento da fatura, o compromisso é convertido para custo real.
O compromisso não é gerado no momento da abertura de um contrato (outline agreement), somente na criação de uma ordem
liberada de contrato (contact) ou ordem liberada de mercadorias (schedule agreements).
21.3 Lançamentos reais
21.3.1 Transferência manual de custos e receitas (Reposting Cost And Revenues Manually)
As receitas são lançamentos estatísticos nos centros de custo e, portanto, não podem ser usadas nos métodos de alocação
periódica. No entanto, os custos e receitas primários podem ser reclassificados manualmente usando a Transferência Manual de
Custos para corrigir erros de lançamentos. O lançamento de transferência é feito na mesma classe de custo primária original.
Portanto, para alterar a classe de custo é preciso corrigir o lançamento em FI. O sistema não irá fazer nenhuma verificação de
existência prévia de custos no objeto a ser creditado. Isto pode gerar um saldo negativo no objeto de custo mas o controle deve
ser feito pelo usuário. Serão gerados lançamentos de débito e crédito.
Este procedimento também pode ser usado de forma automática o que irá permitir, por exemplo, reduzir os lançamentos em FI.
Exemplo: os custos de salários podem ser lançados em um único centro de custo (Centro de Custo que será zerado
CONTROLADORIA 117 de 325
posteriormente) e reclassificados em CO via transferência para os devidos centros de custo. Trata-se da Transferência Periódica
que será discutida nas funções de fechamento do período.
Permite corrigir erros de lançamentos em FI para um item específico de um documento de CO. Ao contrário da Transferência
manual de custos, na Transferência de Partida Individual, o R/3 irá manter um vínculo entre o novo documento de CO gerado e
o lançamento original de FI. Corresponde a um estorno (reversal) no objeto emissor. O custo poderá ser redirecionado para um
ou mais de um objeto recebedor.
Se estiver trabalhando preço interno (Transfer Price) entre unidades organizacionais (Empresas ou Centros de lucro) (avaliação
paralela) não será possível realocar custos e receitas para as valorizações em paralelo. Será preciso usar a Transferência de
Partida Individual. Transfer prices permite dividir o montante das tarefas entre as diferentes unidades organizacionais para
valorizar mercadorias e serviços intercambiáveis entre estas unidades.
21.3.2 Transferência de partida individual (Reposting Line Items)
Este tipo de lançamento também é usado para corrigir erros de lançamentos no FI. Os custos são transferidos em parte ou
totalmente para outro objeto de custo fazendo referência ao documento original ao contrário do caso anterior. O lançamento
original permanece sem alterações. O ideal é que os erros sejam corrigidos no componente original, no caso FI, para garantir a
conciliação dos dados. Mas, se tratando de erro do objeto de custo, não tem nenhum reflexo em FI. O custo poderá ser
transferido para mais de um receptor e funciona com um estorno (reversal) no objeto emissor.
21.3.3 Time de Trabalho (Time Sheet)
É uma ferramenta do R/3 usada por várias aplicações. Agrupa as necessidades de armazenamento de informações sobre tempo
de várias aplicações em uma só função. Possui informações para:
Presença e ausência para RH;
Alocação interna de atividades em CO;
Reporte de manutenção (PM), de projetos (PS), e Gerenciamento de Serviços (SM);
Entrada de serviços externos executados por External Services Management (MM-SRV).
A Folha de Trabalho pode ser usada tanto por funcionários quanto por prestadores de serviço. Existe também uma tela para
entrada centralizada de informações de vários funcionários. Os tempos podem ser alimentados por quantidade de horas ou
horário real e está sempre vinculado a uma pessoa especificamente. A Folha de Trabalho de cada usuário pode ser customizada
de acordo com o nível de conhecimento do usuário e a área de atividade limitando inclusive os campos apresentados na tela.
21.3.3.1 Alocação direta de atividade (Direct Activity Allocation)
Alocação direta de atividade envolve o dimensionamento, armazenamento e alocação de serviços executados na empresa. Para
isto, é preciso definir bases de referência (tracing factor) relevantes (mensuráveis) que serão os critérios para alocação dos
serviços ou atividades. Estes fatores são definidos como tipos de atividades para o R/3.
Uma atividade pode ser definida como sendo uma ação executada por um centro de custo. Por este método, os custos de um
centro de custo são distribuídos conforme a quantidade de atividade produzida por ele para outros centros de custo. Para
estabelecer uma alocação direta de atividade é preciso definir o centro de custo que executou o serviço (sender - emissor), o
centro de custo ou centros de custo que receberam o serviço (receiver - receptor), o tipo de serviço executado (activity type) e a
quantidade de serviço prestado a cada receptor, ou seja, a quantidade de atividade consumida por cada receptor. Somente um
centro de custo poderá ser definido como emissor mas para receber o custo pode ser qualquer objeto de custo real ( centro de
custo, ordens, projetos, etc.).
Este tipo de lançamento gera um crédito e um débito usando uma classe de custo secundária (categoria = 43) definida no
cadastro do tipo de atividade. O R/3 irá debitar o centro de custos executante da atividade (o objeto emissor do custo, na
alocação direta de atividade necessariamente será um centro de custo) e debitar os receptores (qualquer objeto de custos).
Pelo planejamento da saída da atividade (planning activity output) é definido quais os centros de custos irão fornecer que
tipos de atividades e planejar os preços destas atividades por centro de custo. Em caso de erro, pode ser usado o Transferência
de Alocação de Atividade para efetuar a correção mantendo uma referência com o documento original. A quantidade total
deve continuar sendo a mesma mas distribuída de forma diferente. Podem ser efetuados ajustes mas referindo-se a documentos
de períodos anteriores dentro do mesmo ano fiscal. Os documentos que podem ser reclassificados são: documentos entrados
CONTROLADORIA 118 de 325
manualmente em CO; documentos de CO gerados por Confirmação de Produção (de Production Planning and Controlling);
documentos de CO gerados com pela folha de atividades do usuário (Folha de Trabalho).
É preciso cadastrar também o preço planejado para o tipo de atividade para cada centro de custo que executa a atividade para
que o sistema possa calcular o valor total do custo multiplicando a quantidade de atividade consumida pela tarifa planejada.
Opcionalmente, o sistema pode determinar o preço da atividade automaticamente através do Cálculo Iterativo do preço das
atividades. O sistema considera todas as trocas de atividades entre os centros de custos e calcula o preço da atividade de forma
iterativa (processo repetitivo) dividindo os custos planejados pelas quantidades de atividades planejados ou pela capacidade
total do centro de custo (conforme configurado indicador de preço 1= planejado e 2 = capacidade). Trabalhar com a capacidade
total é bastante útil quando os custos provisionados para a capacidade total não afetam, posteriormente, o custo do produto. O
cálculo automático pode ser feito ainda considerando um preço periódico, médio ou acumulado conforme o indicador de
processamento.
A alocação direta de atividade é mais comumente usada para custeio padrão (estático ou flexível), para custeio ABC e para
custeio direto.
Se a alocação de atividade interna for utilizada em conjunto com a pre-distribuição de custos fixos e o emissor participa da pre-
distribuição, o receptor é que irá definir se será alocado ou custo total ou somente a parte variável. Se os emissores e os
receptores participam da pre-distribuição e foram feitos lançamento reais ou estatísticos para o receptor, o sistema irá calcular
somente os custos variável. Caso contrário, será alocado o custo total. Se estiver trabalhando com preço interno (avaliação
paralela), a alocação interna de atividade será executada somente na valorização principal. O preço da atividade usada na
alocação se aplicará a todas as valorizações.
21.3.4 Transferência de Alocação de Atividade (Activity Allocation Reposting)
Esta função permite fazer correções nos documentos de alocação real de atividades não ligadas ao processo produtivo que
precisam ser lançadas manualmente através da função de Activity Allocation. Nela, os custos são alocados dos centros de custo
para ordens, processos ABC, etc. Esta é uma função para Transferência de lançamentos para classes de custo secundária.
Elimina a necessidade de reverter (estornoa) a alocação.
A traansferênica de alocação de atividade permite:
Processar em conjunto todas as alocações de um receptor;
Alterar o número de receptores original;
Transferir parte da quantidade lançada
Alterar o receptor
Somente poderão ser transferidas alocações diretas efetuadas dentro de CO.
21.3.5 Entrada de Quantidade / Preço Atividades nos Emissores (SENDER ACTIVITY / ACTUAL PRICE)
Nesta função serão lançadas as quantidades de atividades do emissor para alocação indireta ( categoria 3 – entrada manual,
alocação indireta) e para atividades não alocáveis (categoria 4 – entrada manual, sem alocação). Esta função também pode ser
usada para processo ABC. A quantidade de atividade será distribuída para os receptores de acordo com os seus tracing factor
(bases de referência). Para as atividades não alocáveis, as quantidades não produzidas são usadas como base para controle do
custo. O sistema calcula a operating rate através da atividade planejada e a atividade não alocável determinando os custos
teóricos (target) e as variações para o Centro de Custo.
Depois do lançamento das quantidades no emissor, os lançamentos para os receptores devem ser feitos através da função de
alocação periódica "Alocação Indireta de Atividade" onde o critério para o emissor deve ser “quantidades lançadas”. O critério
para os receptores pode ser qualquer um. Exemplo: embora seja possível medir a quantidade total de horas gasta por um
funcionário nos testes de qualidade, não é possível determinar a quantidade de atividade destinada a cada centro de custo
produtivo ligado ao teste. No entanto, podem ser usado o número de itens testados para cada centro de custo produtivo
(Statistical key figure que pode ser extraído do LIS).
O Centro de custos de vendas gera custos variáveis para cada unidade de produto vendido. Estes custos não podem ser
creditados contra um segmento de rentabilidade através de uma alocação direta de atividade remanescendo no centro de custo a
menos que seja usado Ordens Internas ou Demonstração de Resultados.
CONTROLADORIA 119 de 325
O preço para cálculo dos custos seja planejado, seja real, podem ser informados manualmente ou automaticamente calculados
pelo sistema. A função de Actual Price permite informar o preço real manualmente. No cadastro de tipo de atividade, deve ser
definido se o preço será calculado automaticamente ou informado manualmente. Se for informado manualmente, o usuário
deverá alimentar o preço para cada tipo de atividade/centro de custo ou processo ABC. Caso seja definido automaticamente, o
R/3 permite dois critérios para cálculo, com base na quantidade planejada/real ou na capacidade total do centro de custo. O
indicador de preço pode ser definido diferentemente para o planejamento e o custeio real. Também a categoria da atividade
pode ser definida diferente para o planejamento e o real com a diferença que, para o real, também pode ser definida a categoria
Target=actual allocation.
21.3.6 Alocação Manual de Custos
A alocação manual de custos permitir alocar, manualmente, custos REAIS não dependentes de atividade. Não existe uma
função de alocação manual para custos planejados. Podem ser alocados tanto custos primários como secundários (com exceção
da categoria 43). Ao contrário do Reposting de custos, que reduz a linha de débito original, no centro de custo, será gerada ima
linha de credito no emissor. Esta função é útil para reduzir tempo de configuração do IMG para alocações simples e também
para corrigir lançamentos secundários e dados importados de sistemas externos. Estes lançamentos não geram um estorno e,
sim, uma nova alocação.
O Emissor pode ser um Centro de Custo, Ordem, elemento PEP, Processo ABC, ordem de vendas, objeto de custo e rede. O
receptor pode ser um Centro de Custo, Ordem, elemento PEP, Processo ABC, ordem de vendas, objeto de custo, rede, grupo de
produto, canal de distribuição. Vai depender da Variante de Exibição informada. Além dos emissores e receptores, devem ser
informados o montante do custo, a quantidade, a moeda, o personal number (chave a nível de mandante que identifica um
empregado. Esta chave é usada no cadastro do empregado no time data).
Se for executada uma alocação periódica seguindo uma alocação manual, é preciso assegurar que todos as classes de custo
usadas no lançamento manual estão contidas no esquema de cálculo para alocação automática. Custos debitados para um
centro de custo através da alocação manual não poderão mais ser debitados através de Transferência periódica. Reclassificação
periódica é para correção de lançamentos e deve ser executada antes mesma que qualquer alocação manual.
21.4 Fechamento de período
21.4.1 Cálculo de Provisões (ACCRUAL CALCULATION) - Delimitação
A execução dos cálculos de provisões é efetuado após a definição das estruturas de overhead e a manutenção dos dados
relevantes para esta estrutura, ou após a manutenção dos lançamento de créditos atual=teórico. O cálculo de provisões pode ser
simulado para teste ou projeções. O cálculo pode ser feito individualmente para um centro de custos ou um grupo de centros de
custos ou para toda a área de contabilidade de custos.
Para o cálculo das provisões devem ser definidas a Estrutura de Custos Indiretos (Overhead Structure) se for usado o método de
percentagem ou Target=Actual Credit pelo método do Target=Actual. Assim como todos os processos dentro do R/3 seu
processamento pode ser efetuado background ou on-line, somente teste (simulação) ou definitivo e gerar ou não uma Lista
Detalhada (lista os resultados dos cálculos). No cálculo de provisões planejadas, deve ser informada a versão do plano já que o
R/3 permite trabalhar com diversas versões como será detalhado mais tarde.
Custos provisionados são custos de oportunidade não lançados em FI (salário de gerência, juros) ou custos lançados de outra
forma em FI (depreciação, férias, 13. Salário). Estes custos podem ser calculados de duas formas: diretamente em FI através de
entradas recorrentes refletindo em CO ou calculando em CO. Para ver os custos em FI, é preciso lançar dos custos de CO para
FI já que o sistema somente irá gerar os valores dentro de CO-CCA.
Existem dois métodos para cálculos destes custos em CO: método da percentagem e target=actual.
Método da Percentagem
O sistema irá calcular estas valores aplicando um percentual sobre os valores lançados em determinadas classes de custos
parametrizadas pelo usuário. Serão efetuados lançamentos de débito nos centros de custos receptores e crédito na ordem
ou centro de custo definida como objeto de provisão (delimitação de Custos). A classe de custo para este lançamento
deverá ser uma classe de custo primária da categoria 03.
Para este cálculo é preciso criar uma ESQUEMA DE CUSTOS INDIRETOS (OVERHEAD STRUCTURE) definindo
a base, a taxa de overhead e o crédito. A base determina o intervalo de classe de custos que serão consideradas para
determinação dos valores que irão compor a base de cálculo do custos indiretos. A taxa de overhead define o percentual a
ser aplicado. Esta taxa pode ser definida com dependente de uma OVERHEAD KEY definindo as condições para
CONTROLADORIA 120 de 325
aplicação da taxa para um centro de custo. Dependendo da classe de custo, por exemplo, pode-se lançar diferentes valores
de custos para os diferentes centros de custo. A overhead key é associada a uma ordem ou no mestre de materiais.
Dependendo do material alocado para o centro de custo, a taxa de overhead poderá variar. Também podem ser usadas
dependências definidas pelo usuário. A Overhead Structure pode ser associada a qualquer Área de Contabilidade de
Custos dentro de um mandante para um determinado período.
Os cálculos de provisões podem ser efetuados a partir de valores planejados, de valores reais e/ou de valores
compromissados (Commitment).
Análise de Resultados: em CO-PC, a análise de resultados corresponde à valorização periódica de ordens de longo
prazo. Valoriza a proporção entre os custos e a base definido como critério para o progresso da ordem, tais como
receita ou quantidade produzida. Por exemplo, se o progresso da ordem é medido em receita real, o custos de vendas é
calculado proporcionalmente à receita já ocorrida. A receita, o custo de vendas e a reservas para perdas emitentes (se
calculadas) representa o lucro da ordem para o período, e são liquidadas para CO-PA. A diferença entre o custo de
vendas calculado e o custo real e considerada como WIP (Work in Process) ou reservas para custos não realizados. São
gerados lançamentos em FI.
Método Target=Actual
Este método não usa percentual. É preciso planejar os custos usando uma classe de custo também primária (categoria 04)
nos centros de custos. Este método calcula os custos teóricos (target) usando esta classe de custo como valores
provisonados nos campos de custo real. Neste método os custos fixos planejados são assumidos como custos fixos reais e
os custos variáveis planejados são ajustados de acordo com a quantidade real.
É possível lançar os custos realmente incorridos em FI para o objeto de custo de provisão (delimitação de custos) usando o
classe de custo de acrrual (categoria 03 ou 04). A diferença gerada entre o valor provisionado e o valor real pode ser
transferida para o CO-PA.
No cálculo de custo de oportunidade, nenhum lançamento será efetuado em FI. Neste caso, simplesmente será necessário
criar uma conta contábil a nível de plano de contas. Não será preciso criar a conta em FI a nível de empresa.
21.4.2 Actual overhead
21.4.3 Overhead Commitment
21.4.4 Alocação Periódica
Para executar alocações periódicas, tais como, transferência periódica, distribuição, rateio e alocação indireta de atividade, é
preciso definir os ciclos. Os ciclos são criados separadamente para alocações planejadas e reais e para cada um dos tipos de
alocação já citados. Quantidades consumidas NÃO podem ser alocadas em rateios.
Antes de definir as alocações periódicas é preciso definir quais os objetos alocam os custos e onde os custos serão alocados, ou
seja, é preciso definir a relação emissor-receptor. Esta definição pode ser feita tanto no menu de CCA como no IMG – CCA.
Por exemplo, um centro de custo Restaurante aloca seus custos para todos os centros de custos na organização incluindo o
próprio restaurante. Também vários centros de custo poderão ser definidos como emissores. Também é preciso definir quais os
custos ou atividades serão alocados. As regras de alocação podem ser definidas nos emissores e nos receptores conforme
mostra a figura:
CONTROLADORIA 121 de 325
Os valores do emissor para distribuição, rateio e transferência periódica podem ser determinados de acordo com o total lançado,
o total fixo ou o preço fixo da atividade. Para alocação indireta de atividade podem ser definidos o total lançado, o total fixo ou
quantidade determinadas inversamente.
Para o receptor, as regras para todos os métodos são, partes variável, montante fixo, percentual fixo ou quotas fixas. Para a
proporção variável pode ser definir as seguintes bases de referência: custos reais, custos planejados, consumo real, consumo
planejado, índice estatístico real, índice estatístico planejado, atividade real, atividade planejada, custos reais estatísticos, custos
planejados estatísticos. Usando, por exemplo, custos planejados ou reais, denomina-se flexible tracing factor determination.
O tracing factor é determinado dinamicamente pelo sistema durante a locação baseado em montantes lançados.
Combinações possíveis para transferência periódica, distribuição e rateio
Regras do Repector
Montante Fixo Percentual fixo Quotas fixas Partes variáveis
Regras do Emissor
Montante lançado X X X X
Montante fixo X X X X
Tarifa fixa da atividade X X X X
Combinações possíveis para transferência periódica, distribuição e rateio
Regras do Repector
Montante Fixo Percentual fixo Quotas fixas Partes variáveis
Regras do Emissor Categoria do Tipo
de Atividade
Montante lançado 3 X X X
Montante fixo 2 X X X X
Tarifa fixa da atividade 2 X X X X
Se for especificado valores fixos como regra para o emissor e o receptor, o sistema considera os valores fixos do receptor.
CONTROLADORIA 122 de 325
Ainda, é preciso definir qual o critério (receiver tracing factor) para alocação dos custos e da atividade especificando como os
custos deverão ser alocados. EM CCA, as chaves de alocação são denominadas tracing factor.
Os diversos segmentos podem ser alocados em um só ciclo para cada tipo de alocação. No entanto, por questões de
performance e lógica de alocação, sugere-se criar vários ciclos e executá-los seqüencialmente. A vantagem é que é possível
reprocessar somente o ciclo com erro e não todo o processo. Se os ciclos forem dependentes deve ser definida corretamente a
ordem de execução para garantir um resultado correto. Podem ser criados grupo de fluxo de ciclos para garantir que os ciclos
dependentes sejam executados em seqüência. O sistema não permite processar ciclos de um mesmo grupo em paralelo. Os
ciclos independentes podem ser processados em paralelo. Para isto, é preciso criar grupos de fluxo de ciclos diferentes para
estes ciclos. O processamento paralelo pode, por exemplo, ser executado em background.
Note que a iteratividade só funciona dentro de um mesmo ciclo. Portanto, todos os centros de custo que fazem parte na mesma
relação de alocação devem estar em um mesmo ciclo.
O Ciclo de alocação pode ser definido como hierárquico ou iterativo:
Método Hierárquico
M
é
t
o
d
o
h
i
e
r
M
é
t
o
d
o
h
i
e
r
á
r
q
u
i
M
é
t
o
d
M
é
t
o
d
o
h
i
e
r
Método Iterativo
M
é
t
o
d
o
h
i
e
r
á
r
q
M
é
t
o
M
é
t
o
d
o
h
i
M
é
t
o
d
o
h
i
M
é
t
o
Método hierárquico (onde o usuário determina a seqüência de lançamento) Deve ser usado quando existir nenhum
vínculo recursivo entre os centros de custos, ou seja, nenhum centro de custo receberá custo de um de seus receptores
diretos ou indiretos. Neste caso, o R/3 processa os segmentos em um ciclo em sucessão sem repetição. Este método
também pode ser usado quando os custos referente consumo interno de serviços devem permanecer no centro de custo que
executou o serviço, tal como, os custos de consumo de energia interno dentro do Centro de custo de Suprimento de
Energia.
Método iterativo (onde o sistema determina a seqüência repetitivamente) No processamento repetitivo, o R/3 também
considera a estrutura cíclica na rede de centro de custo durante a alocação (um centro de custo receptor também pode ser
prestador de serviço). Se, por exemplo, um centro de custo A deve ter os seus custos distribuídos para os centros de Custo
B e C e o centro de C deve ser parte de seus custos atribuídos ao centro de custo A, o processamento de alocação será
efetuada várias vezes até que o centro de custo A não tenha mais valores:
MÉTODO / SEQÜÊNCIA DE CÁLCULO
A B C
1 A 1000 - 500 500
2 C 500 250 250 -
3 A 250 - 125 125
CONTROLADORIA 123 de 325
MÉTODO / SEQÜÊNCIA DE CÁLCULO
4 C 125 62,5 62,5 -
5 A 62,5 - 31,25 31,25
6 C 31,25 15,625 15,625 -
7 ....
...
N - 1000 -
Esquema de Alocação – permite efetuar lançamentos de rateio, distribuição e transferência periódica em mais de uma conta
secundária de rateio.
21.4.4.1 Definição de Ciclos
Os ciclos são uma ferramenta disponível no R/3 para o processamento de alocações periódicas. Os tipos de alocação periódicas
são distribuição, rateio, transferência periódica e alocação indireta de atividade. Cada ciclo trata individualmente de um tipo de
alocação. Ainda, devem ser definidos separadamente os ciclos para o processamento de alocações planejadas e o processamento
de alocações reais. No caso do planejamento, deve ser criado um ciclo para cada versão.
Para definir um ciclo de alocação periódica, deve-se definir os emissores (objetos cujos custos serão alocados) e os receptores
(objetos que irão absorver os custos). Além disto, é preciso definir quais os custos serão alocados (de quais classes de custo) ou
quais as quantidades de atividades (tipos de atividade) e qual o critério que será usada para estabelecer a alocação seja ela direta
ou indireta.
No caso de distribuição, rateio e transferência periódica, os valores a serem rateados podem ser:
valor total planejado ou lançado(real);
valor fixo planejado ou lançado (real);
parte fixa da tarifa da atividade.
No caso específico de alocação indireta de atividade, os valores a serem rateados podem ser:
valor total planejado ou lançado(real);
valor fixo planejado ou lançado (real);
Quantidade determinada inversamente.
Os critérios de alocação podem ser diversos: partes variáveis (custos reais ou planejados, consumo real ou planejado, índice
estatístico real ou planejado, etc.), montante ou fixo (pre-estabelecido no segmento do ciclo) ou quotas fixas.
O processamento dos segmentos do ciclo pode ser hierárquico (seqüencial) onde o usuário determina a seqüência do
lançamento ou iterativo (repetitivo) onde o sistema determina a seqüência repetitivamente. O primeiro método somente pode
ser usado quando não houver recursividade (um centro emissor recebe, direta ou indiretamente, custos de um de seus
receptores). É um processamento mais rápido.
Cada ciclo definido pode conter um ou vários segmentos devendo conter pelo menos um segmento. Tanto podem ser definidos
diversos segmentos em um só ciclo como podem ser definidos diversos ciclos com um segmento cada um. Alguns aspectos
devem ser considerados:
Quando houver recursividade é importante que todas alocações envolvidas estejam no mesmo ciclo visto que a
recursividade (processo iterativo) somente é tratado em um ciclo.
No caso de um reprocessamento, é possível reprocessar somente um ciclo mas todos os segmentos de um ciclo
obrigatoriamente são reprocessados. No entanto, se os ciclos forem dependente deve ser seguida corretamente a seqüência
de execução para garantir o resultado correto. Podem ser criados grupos de ciclos garantindo que dois ciclos dependentes
não sejam processados simultaneamente. O sistema não permite que ciclos de um mesmo grupo sejam processados em
paralelo.
Para efetuar os lançamentos de alocação tanto pode ser usada uma única classe de custo secundária como pode ser usado um
esquema de alocação. O esquema de alocação permite efetuar lançamentos de alocação em mais de uma conta secundária de
CONTROLADORIA 124 de 325
acordo com a classe de custo que está sendo rateada. É possível, inclusive, usar a mesma classe de custo original do objeto
emissor.
Para criar um novo ciclo de alocação pode-se usar a opção do menu Suplementos Ciclo Criar ou ir diretamente para a
transação através do caminho: Contabilidade Controlling Contabilidade de Centro de Custos Planejamento
Opções Atuais S_ALR_87005808 – Definir Transferência periódica.
Campo Descrição Ações do usuário / conteúdo Comentários
Ciclo Definir um nome para o ciclo que está
sempre criado. É recomendável usar um
padrão para a denominação dos ciclos para
facilitar identificação e memorizaçao.
Data de Início Data de Início da
validade do ciclo
Definir uma data no qual o ciclo começará a
ser processado. O sistema não permitirá que
o ciclo seja processado antes desta data.
Modelo Opcionalmente poderá ser informado um
ciclo que já esteja cadastrado para que o
sistema copie os dados deste ciclo para o novo
ciclo que está sendo criado.
CONTROLADORIA 125 de 325
Campo Descrição Ações do usuário / conteúdo Comentários
Data de Início....
até
Período de validade do
ciclo
Definir a data final da validade do
ciclo.
Posteriormente
será possível
alterar a data fim
mas não é possível
alterar a data de
início
Texto Informe uma descrição breve para o
ciclo
Código Definir se deseja que o processamento
seja seqüencial ou iterativo.
Grupo de Campos Consumo – define se o consumo
planejado no emissor deve ser
alocado juntamente com os
valores.
Moeda do objeto – define se a
alocação deve ser gravada na
moeda do objeto.
Moeda da transação – define se a
alocação deve ser gravada na
moeda da transação.
A alocação será
sempre gravada
na moeda da área
de contabilidade
de custos
Critérios de
seleção pre-
definidos
Versão – Definir de quais versão
do planejamento os dados devem
ser extraídos
Pressionar este botão para iniciar a
inclusão dos segmentos do ciclo
CONTROLADORIA 126 de 325
21.4.4.1.1 Pasta Cabeçalho do Segmento
Campo Descrição Ações do usuário / conteúdo Comentários
Nome do segmento Definir um nome abreviado e uma
descrição breve para o segmento.
Código bloqueio Marcar este campo quando desejar
que o segmento fique bloqueado para
execução.
Valores do emissor
– regra emissor
Define como devem ser
determinados os
valores dos custos dos
emissores a ser alocado
Montantes lançados – considera os
valores efetivamente lançados no
planejamento.
Montantes fixos – considera os
valores fixos definidos na pasta
“Val.Emissor”.
Tarifas fixas – multiplica as tarifas
fixas definidas na pasta
“Val.Emissor” pela base de
referência dos receptores para
achar os valores.
A alocação será
sempre gravada
na moeda da área
de contabilidade
de custos
Valores do emissor
– quotas em %
Informar o percentual do total dos
custos dos emissores que serão
alocados. O restante do valor
permanece no centro de custo.
Normalmente este percentual será
100%.
CONTROLADORIA 127 de 325
Campo Descrição Ações do usuário / conteúdo Comentários
Valores do emissor
– Vals.plan X
Val.reais
Definir se serão considerados, para
determinação do valor dos custos dos
emissores a serem alocados, valores
planejados ou reais
independentemente de se tratar de um
ciclo de alocação planejada ou real.
Note que, definindo valores reais para
um ciclo planejado ou vice-versa, pode
gerar saldo negativo nos emissores.
Normalmente, os ciclos reais
trabalham com valores reais e os ciclos
planejados com valores planejados.
A determinação se
a alocação gerada
será planejada ou
real depende a
transação usada
para a montagem
do ciclo e não da
definição deste
campo.
Base de referência
receptora – Regra
receptor
Define com deve ser
efetuada a distribuição
dos custos dos
emissores entre os
diversos receptores.
Ver alternativas possíveis abaixo (*)
Tp.Quota Variável Define qual a quota
variável deverá ser
usada para a
determinação da base
de referência
Ver alternativas possíveis abaixo (*) Somente fica
disponível se for
definida a regra
“partes variáveis”
Padronização Define qual o
procedimento a ser
adotado se nos cálculos
o sistema encontrar
bases de referência
negativas.
Ver descrição abaixo (**) Somente fica
disponível se for
definida a regra
“partes variáveis”
(*) Regra do Receptor – Existem as seguintes possibilidades :
1. Partes variáveis – estabelece que o sistema deverá usar valor já gravado na base de dados para determinação do valor
recebido por cada receptor. As alternativas disponíveis são:
Custos planejados – considera os lançamentos de planejamentos para a versão e classes de custos informadas na pasta
“Base de referência receptora”. Assim, o sistema irá somar o total dos custos planejados para todos os receptores
envolvidos nas classes de custo e versões definidas e dividir o total de cada receptor pelo total geral para determinar o
percentual que cada receptor irá receber.
Custos reais – funciona da mesma forma que a alternativa anterior só que considerando lançamentos reais e não
planejados.
Consumo planejado / real – estas duas alternativas também seguem a mesma lógica das anteriores só que considera
os consumos lançados e não os valores dos custos.
Índices estatísticos reais / planejados – considera os lançamentos (planejados ou reais) efetuados para os receptores
para os índices estatísticos definidos na pasta “Base de referência receptora”. Assim, o sistema irá somar o total dos
valores apurados para todos os receptores envolvidos e dividir o total de cada receptor pelo total geral para determinar
o percentual que cada receptor irá receber.
Atividade real/planejada – considera os lançamentos (planejados ou reais) para os tipos de atividade informados na
pasta “Base de referência receptora”. Assim, o sistema irá somar o total dos valores apurados para todos os receptores
envolvidos e dividir o total de cada receptor pelo total geral para determinar o percentual que cada receptor irá receber.
Custo estatítiscos reais/planejados – segue a mesma lógica de raciocínio só que considera somente lançamentos
estatísticos para ordens ou centros de custo. Um centro de custos recebe lançamentos estatísticos quando os
lançamentos reais foram destinados para uma ordem. Uma ordem recebe um lançamento estatístico quando for
definida como estatística no registro mestre. Neste caso, será obrigatório informar o centro de custo para onde irá os
lançamentos reais também no registro mestre da ordem.
CONTROLADORIA 128 de 325
Exemplo
Emissor A distribui 100.000 DM por três receptores. A base de referência são os custos reais.
Receptor Cl.custo Montante
B 430000 2000 DM
C 430000 1000 DM
D 430000 2000 DM
Total 5000 DM
O sistema SAP determina os seguintes valores:
Receptor B: 100.000 DM/5000 * 2000 = 40.000 DM
Receptor C: 100.000 DM/5000 * 1000 = 20.000 DM
Receptor D: 100.000 DM/5000 * 2000 = 40.000 DM
OBS: Com a ajuda da função "Fatores de ponderação do receptor" na atualização de segmento poderão ser gravados
adicionalmente fatores de ponderação para as bases de referência do receptor, em bases de referência do receptor. O valor
proposto é 1. A base do emissor é calculada a partir do total das bases de referência do receptor individuais e ponderadas.
Exemplo:
Emissor A distribui 100.000 DM por três receptores com as seguintes bases de referência:
B: 50 partes Fator de ponderação do emissor: 1
C: 50 partes Fator de ponderação do emissor: 9
D: 100 partes Fator de ponderação do emissor: 5
Disto resultam as bases de referência seguintes utilizadas para a alocação:
B: 50 partes * 1 = 50
C: 50 partes * 9 = 450
D: 100 partes * 5 = 500
Total Base emissor: 1000 partes
O sistema SAP determina os seguintes valores:
Receptor B: 100.000 DM/1000 * 50 = 5.000,00 DM
Receptor C: 100.000 DM/1000 * 450 = 45.000,00 DM
Receptor D: 100.000 DM/1000 * 500 = 50.000,00 DM
Padronização para bases negativas
Podem surgir bases de referência negativa, caso as bases de referência não tenham sido propostas como tamanhos fixos ou
percentagens, e sim obtidas no banco de dados. Este é o caso, por ex., de uma distribuição segundo tipos de atividade ou
índices estatísticos.
Se uma parte dos receptores tiver bases de referência positivas e outra parte negativas, distinguem-se dois casos:
Se o total de todas as bases de referência do receptor for maior que 0 , serão também creditados, juntamente com
os emissores, os receptores com bases de referência negativas, sem padronização. Os receptores com bases de
referência positivas serão, por isso, mais fortemente debitados.
Se o total de todas as bases de referência do receptor for menor que 0 , serão também creditados, juntamente com
os emissores, os receptores com bases de referência positivas, sem padronização. Os receptores com bases de
referência positivas serão, por isso, mais fortemente debitados.
Em um processamento iterativo, isto pode levar à não convergência e ao cancelamento da iteração ou ao fornecimento de
resultados divergentes.
Para a padronização de bases de referência negativas, estão disponíveis as seguintes possibilidades:
CONTROLADORIA 129 de 325
Sem padronização – conta-se com bases de referência do receptor negativas.
Padronização standard – a padronização depende do total das bases de referência do receptor:
Se o total das bases de referência do receptor for positivo ou zero, a maior base de referência negativa,
em termos de montante, é definida a 0. As outras bases de referência serão respectivamente aumentadas.
Deste modo, todas as bases de referência do receptor são positivas.
Se o total das bases de referência do receptor for negativo, a maior base de referência positiva é colocada
a zero. As outras bases de referência serão respectivamente diminuídas. Deste modo, todas as bases de
referência do receptor são negativas.
Valor absoluto – nas bases de referência do receptor negativas, o sinal +/- é invertido. Deste modo, todas as bases
de referência do receptor são positivas.
Bases de referência negativas serão zero – bases de referência negativas serão postas em zero. A este receptor
nada será alocado.
Menor base de referência negativa será zero – a maior base de referência negativa, em termos de montante, é
definda com zero. As outras bases de referência serão respectivamente aumentadas. Deste modo, todas as bases de
referência do receptor são positivas. Os receptores, que antes da padronização tinham a base de referência 0,
recebem uma base de referência positiva.
Menor base de referência negativa será zero, mas zero permanece zero – A maior base de referência negativa,
em termos de montante, é colocada a zero. Todas as outras bases de referência serão respectivamente aumentadas.
Os receptores, que antes da padronização tinham a base de referência 0, mantêm a base de referência 0.
2. Montantes fixos – considera os valores fixos definidos na pasta “Base de referência receptora” para determinação dos
valores que cada receptor irá receber. O emissor será creditado pelo somatório destes valores. Neste caso, a regra do
emissor é desprezada prevalecendo os valores fixos do receptor.
3. Percentagens fixas – considera os percentuais fixos definidos na pasta “Base de referência receptora” aplicando-o
sobre os valores creditados no emissor. Neste caso, se o somatório dos percentuais definidos for inferior a 100% ficará
um saldo residual no emissor.
4. Quotas fixas – este critério é bem semelhante ao anterior só que neste caso, ao invés de percentuais são definidos
valores quaisquer, como, por exemplo, o total de linhas de impressão. O sistema irá somar todos as quotas definidas e
dividir a quota de cada receptor pelo total para achar o percentual atribuído a cada receptor. Neste caso, sempre todo o
saldo do centro de custo será alocado, salvo se for definido um percentual inferior a 100% para o emissor.
Exemplo:
Emissor A distribui 100.000 DM por três receptores com as seguintes bases de referência:
B: 50 partes
C: 50 partes
D: 100 partes
Total: 200 partes
O sistema SAP determina os seguintes valores:
Receptor B: 100.000 DM/200 * 50 = 25.000 DM
Receptor C: 100.000 DM/200 * 50 = 25.000 DM
Receptor D: 100.000 DM/200 * 100 = 50.000 DM
21.4.4.1.2 Pasta Emissor/Receptor
CONTROLADORIA 130 de 325
Campo Descrição Ações do usuário / conteúdo Comentários
Emissor Definir os critérios para seleção dos
emissores que, neste tipo de alocação
pode ser ordens ou centros de custo.
Ainda pode-se restringir a
determinação dos valores a alocar de
acordo com a classe de custo e o tipo
de atividade (somente para centro de
custo). Tanto podem ser definidos um
intervalo com um grupo para a
seleção.
Este é o único tipo
de alocação que
permite ter ordens
como emissores,
ou seja, somente
através da
transferência
periódica é
possível alocar
custos de ordens
internas.
Receptor Definir os critérios para seleção dos
receptores sendo que, para este tipo de
alocação, pode ser ordens ou centros
de custo
21.4.4.1.3 Pasta Val. Emissor
Esta pasta varia conforme a regra definida para o emissor. Abaixo são apresentadas três telas sendo, respectivamente, para
montantes lançados, montantes fixos e tarifas fixas.
CONTROLADORIA 131 de 325
Campo Descrição Ações do usuário / conteúdo Comentários
Valores do
Emissor
Ver descrição da pasta de cabeçalho
Critérios de
seleção
Definir a versão do planejamento da
qual serão extraídos os dados.
Campo Descrição Ações do usuário / conteúdo Comentários
Moeda Definir o código da moeda na qual os
montantes fixos serão definidos.
CONTROLADORIA 132 de 325
Campo Descrição Ações do usuário / conteúdo Comentários
Ordem/Centro de
Custo.... Montante
O sistema irá listar, automaticamente,
todos os emissores selecionados pelos
critérios definidos na pasta
Emissor/Receptor para que sejam
informados os montantes fixos de cada
emissor na moeda informada na
campo anterior.
Antes de entrar
nesta tela é preciso
definir os emissor.
Campo Descrição Ações do usuário / conteúdo Comentários
Moeda Definir o código da moeda na qual os
tarifas fixas serão definidas.
Ordem/Centro de
Custo.... Tarifa
O sistema irá listar, automaticamente,
todos os emissores selecionados pelos
critérios definidos na pasta
Emissor/Receptor para que sejam
informadas as tarifas fixas de cada
emissor na moeda informada na
campo anterior.
Antes de entrar
nesta tela é preciso
definir os emissor.
21.4.4.1.4 Pasta Base de Refer.Receptora
Da mesma forma que a pasta anterior. Esta tela também irá variar conforme a regra definida para os receptores. Abaixo são
apresentadas as telas para partes variáveis, montantes fixos, percentagens ou quotas fixas.
CONTROLADORIA 133 de 325
Campo Descrição Ações do usuário / conteúdo Comentários
Base de referência Ver descrição na pasta de cabeçalho
Critérios de
seleção
Os critérios de seleção apresentados
irão variar conforme o tipo de quota
variável definida. Informar um
intervalo ou um grupo
Campo Descrição Ações do usuário / conteúdo Comentários
Moeda Definir o código da moeda na qual os
montantes fixos serão definidos.
CONTROLADORIA 134 de 325
Campo Descrição Ações do usuário / conteúdo Comentários
Ordem/Centro de
Custo.... Montante
O sistema irá listar, automaticamente,
todos os receptores selecionados pelos
critérios definidos na pasta
Emissor/Receptor para que sejam
informados os montantes fixos de cada
receptor na moeda informada na
campo anterior.
Antes de entrar
nesta tela é preciso
definir os
receptores.
Campo Descrição Ações do usuário / conteúdo Comentários
Moeda Definir o código da moeda na qual os
montantes fixos serão definidos.
Ordem/Centro de
Custo....
Quota/percent
O sistema irá listar, automaticamente,
todos os receptores selecionados pelos
critérios definidos na pasta
Emissor/Receptor para que sejam
informados os percentuais ou as
quotas fixos de cada receptor na
moeda informada na campo anterior.
Antes de entrar
nesta tela é preciso
definir os
receptores.
21.4.4.1.5 Pasta Fator ponderação rec.
Esta pasta somente fica disponível se for selecionada o opção de regra de receptor partes variáveis. Nela podem ser atribuídos
fatores a serem aplicados às bases de referência encontradas antes do cálculo dos valores a alocar.
CONTROLADORIA 135 de 325
21.4.4.2 Transferência Periódica (Periodic Reposting)
Com o objetivo de reduzir o número de lançamentos a serem efetuados em FI, pode ser definido, por exemplo, que todos os
custos primários de telefone serão atribuídos a um único objeto de custo, que pode ser uma ordem de overhead, um processo
ABC, um elemento de projeto, um centro de custo ou um objeto de custo. No final do período, os custos serão distribuídos para
dos objetos correspondentes usando um critério (tracing rule) definido pelo usuário. Este objetos podem ser um centro de custo,
elementos de projeto, ordens internas ou objetos de custo. O número de categorias de receptores podem ser restringido no IMG.
Neste tipo de lançamento, somente poderão ser usadas classes de custo primárias, ou seja, a classe de custo original
permanecerá a mesma. Neste tipo de lançamento, o sistema irá gravar partidas individuais (line items) tanto para o emissor
quanto para os receptores. Porém, não irá guardar informações de liquidação do saldo do centro de custo (clearing) no registro
de totais (total records) reduzindo espaço em disco.
Os relacionamentos entre os emissores e receptores serão definidos através do método de ciclo-segmento. Podem ser definidos
vários ciclos e cada ciclo pode conter vários segmentos. Os ciclos podem ser definidos como iterativos para garantir que o saldo
dos centros de custo sejam zerados quando um mesmo centro de custo que aparece como emissor, aparece como receptor em
outro segmento.
Este tipo de lançamento pode ser revertido e refeito quantas vezes for necessário, lembrando que, na reversão são gerados
lançamentos de estorno.
21.4.4.3 Distribuição (Distribution)
Esta função é bastante semelhante à primeira. Só que, na distribuição, somente centros de custo ou processos ABC poderão ser
emissores. Os registros de totais referentes aos zeramento do centro de custo emissor serão gravados.
Usa-se a Transferência periódica quando é o centro de custos emissor que determina o critério de rateio e a distribuição quando
as informações são definidas pelos receptores. É possível fazer distribuições para gerar valores planejados. A diferença básica
entre os dois tipos de lançamento é com relação ao conteúdo das informações e performance.
Para o Transferência Periódica, nenhum registro de crédito individual é gravado para o emissor na classe de custo no relatório
sumarizado. Ao contrário, o registro de totais na classe de custo é reduzida no lado do débito, significando que não poderão ser
conferidos os valores originalmente debitados ( “unclean credit”). Na distribuição, o sistema grava o registro de totais para o
crédito (“clean credit”). A informação no receptor é a mesma para os dois processos (“clean débito”).
Para a distribuição, o sistema não considera nenhum custo primário que foi planejado dependente da atividade. Durante o
Transferência Periódica assim como também no rateio, os custos planejados dependentes da atividade no emissor são
totalmente alocados como custos fixos no receptor. Isto ocorre por que a transferência não é baseada na relação de atividade
entre emissores e receptores e sim, somente nos custos, que são coletados na liquidação de saldo (zeramento) do centro de
custo.
CONTROLADORIA 136 de 325
Diferenças básicas entre Distribuição e Transferência periódica
Distribuição Transferência periódica
Emissor: pode ser um centro de custo ou processo empresarial
(ABC)
Emissor: pode ser um centro de custo, um processo
empresarial, um elemento PEP, uma ordem ou um objeto de
custo.
Grava registro de totais no emissor (gera lançamento de
crédito)
Não grava registros de totais (reduz o lançamento de débito)
Critério de alocação definido pelo receptor Critério de alocação definido pelo emissor
Não aloca custos dependentes da atividade Aloca custos dependentes da atividade como custos fixos no
receptor.
21.4.4.4 Alocação de atividade teórico = real
Esta é uma forma especial de alocação indireta de atividade real que permite determinar uma rede de atividades multi-nível de
forma interativa baseado em um percentual de operação definido como uma base de referência. Este percentual estabelecido a
relação a nível operacional planejada e real que mede a utilização efetuva de uma atividade por um centro de custo.
Este tipo de alocação pode ser usado para centros de custos e processos empresariais. Neste tipo de alocação, a quantidade de
atividade não é informada diretamente. Ela é calculada pelo R/3 baseado na quantidades de atividades informadas para os
receptores e no percentual estabelecido para o centro de custos receptor. Como este tipo de alocação somente se aplica a valores
reais, o tipo de atividade deverá ser categorias distintas para o planejamento e o real (categoria 5 para real e 1,2 ou 3 para o
planejamento sendo a categoria 1 a mais comumente usada).
O processo de cálculo é executado da seguinte forma:
O percentual de utilização efetiva do centro de custos e calculado para todos os centros de custos receptores baseado nos
seus consumos reais e planejados.
Baseado neste percentual e na atividade planejada, o R/3 calcula a total a ser prestado de atividade para o emissor.
A parte varíavel da quantidade de atividade planejada é ajustado de acorod com o percentual determinado usando a
alocação de atividade teórico = real. Este valor apurado é atualizado como sendo a quantiade de atividade real variável. A
parte fixa da quantiade de atividade é transferida do planejamento para o real.
O processo é executado iterativamente tratando possíveis recursividades. Naturalmente, para trabalhar com este tipo de
alocação é imperativo também usar afunção de reconciliação do plano. No caso de operar com avaliaçãp paralela, o sistema irá
calcular a alocação de atividade para a visão legal e esta tarifa definida será usada para as demais visões.
21.4.4.5 Rateio (Assessment)
O rateio, através dos ciclos e segmentos, transfere os custos primários e secundários dos centros de custo ou processos para
outros objetos de custo (centro de custo, elemento PEP, ordem interna, objeto de custo ou processo ABC) por meio de um
critério estabelecido pelo usuário. A diferença da distribuição é que, neste caso, os custos do emissor são sumarizados e
transferidos em uma única classe de custo secundária definida no segmento (categoria 42). Além disto, serão distribuídos tanto
os custos primários quando os secundários ao passo que na distribuição. Como serão gravados poucos registros de totais, o
rateio tem uma performance melhor que a distribuição e o transferência periódica. Os receptores não conseguem ver, portanto,
as classes de custo originais. Assim como na distribuição, o parceiro é atualizado no registro de totais. O rateio também pode
ser revertido sempre que necessário.
Até a versão 4.5A, somente era possível alocar uma classe de custo de rateio para cada segmento. Atualmente, podem ser
usadas várias classes de custo informando, ao invés de uma única classe de custo uma Estrutura de Alocação (Allocation
Structure). Em uma estrutura de alocação, podem ser definidos quais classes de custo serão alocadas usando quais classes de
custo de rateio (categoria 42). Portanto, não é necessário criar mais de um segmento para obter informações sobre a natureza
dos custos que estão sendo rateados. Naturalmente, a estrutura deve contem todos as classes de custos que deverão ser rateadas
e ainda não pode ser definida uma mesma classe de custo em mais de uma associação (assignment).
CONTROLADORIA 137 de 325
ALLOCATION STRUCTURE – 01
Assignment Origem (classe de
custo)
Classe de custo de rateio
001 – Material 400000 a 400200 631600 - Material
002 – Comunicação 472000 a 473120 631501 – Comunicação
003 – RH Grupo HR 631200 - RH
A Estrutura de Alocação pode ser usada também na liquidação de ordens internas.
21.4.4.6 Alocação indireta de atividade (Indirect Activity Allocation)
A alocação indireta de atividade pode ser usadas para os tipos de atividade da categoria 02 (cálculo indireto, alocação indireta)
e 03 (entrada manual, alocação indireta). O primeiro caso, se refere aos custos que não podem ser definidos no emissor e
necessitam de informações oriundas dos receptores. Um exemplo prático, seria a alocação do centro de custo de manutenção
para os centros de custo produtivos. Pode se estabelecer, por exemplo, uma relação proporcional entre as horas de produção
executadas pelos centros de custo produtivos e as horas de manutenção por ele recebidas. Assim, através da alocação indireta
de atividade, define-se o centro de custo de manutenção como o emissor tendo, como critério, a quantidade calculada
inversamente e os receptores como tendo uma porção variável proporcional ao tipo de atividade “horas de produção” por eles
prestada. O sistema irá somar o total de horas de produção dos receptores para determinar as quantidades de horas de
manutenção do emissor e distribuir o custo total (quantidade x tarifa) para os receptores. O preço da tarifa pode ser informado
manualmente ou determinado automaticamente.
No segundo caso, a quantidade do emissor é informada manualmente na função de Sender Activity e a alocação é feita
indiretamente pela alocação indireta. Neste caso, o critério do emissor pode ser quantidades lançadas. O critério do emissor
também pode ser quantidade de planejadas, tendo o mesmo significado para o planejamento sendo que estas quantidades serão
informadas na função de planejamento (Activity Output Price).
No caso da alocação indireta não faz sentido se pensar em processo iterativo já que não estamos falando em distribuição de
valor e sim de quantidade. O que, na verdade, deverá ser iterativo é o cálculo do preço da atividade.
21.4.4.7 Estorno e Reclassificação de Segmentos (Segment Adjustment)
Várias empresas necessitam alterar alocações de períodos passados, por questões de auditoria, de informações recebidas
posteriormente ao encerramento do período ou erros simplesmente. O estorno e relançamento de segmentos gera um
lançamento de estorno e refaz o lançamento de maneira correta no período corrente. É claro, o período encerrado permanece o
mesmo mas o valor acumulado do exercício fica corrigido a partir do período corrente. Podem ser alterados índices estatísticos,
alterar sinais, selecionar receptores diferentes, etc. O relançamento somente pode ser feito em conjunto com o lançamento de
estorno.
Esta função, também, pode ser usada para períodos ainda em aberto. Está disponível para rateio, distribuição e transferência
periódica. Não está disponível, portanto, para alocação indireta de atividade. Somente segmentos individuais serão refeitos e
não o ciclo inteiro. Isto significa que não serão consideradas relações iterativas podem gerar erros se não forem refeitos todos
os segmentos iterativos ao mesmo tempo.
21.4.4.8 Alocação por modelos (Template Allocation)
A alocação de templates ajuda no cálculo das quantidades utilizadas pelos receptores individualmente. O custo é determinado
usando a tarifa para valorizar a quantidade. Para obter as informações desejadas, o modelo utilizar fórmulas padrões do R/3 ou
fórmulas definidas pelo usuário. Estas fórmulas auxiliam na obtenção de informações dos campos e facilita a execução de
algoritmos complexos usados dados operacionais. A alocação com modelo pode ser feita usando um centro de custo para
objetos dependentes ou independentes de atividade.
Para isto, é preciso definir o modelo e associá-lo ao centro de custo no dados mestre. A alocação é dependente do período/ano
fiscal. Os receptores podem ser centros de custo, centros de custo/ tipos de atividades, segmentos de rentabilidade, objetos de
custo e objetos de negócio.
CONTROLADORIA 138 de 325
TEMPLATE
Um modelo é uma ferramenta dinâmica que usa fórmulas e lógica boleana para calcular valores em uma estrutura de tabela
(linha/coluna). O objeto deve ser definido pelo usuário ou determinado pelo sistema (por exemplo, o centro de custo de uma
categoria específica). Pode ser usado para definir o valor de um item como ativo ou inativo, definir condições a serem
verificadas durante a valorização ou definir requisitos para as alocações.
Durante a alocação independente da atividade, o fator de quantidade variável determina a quantidade de saída do emissor
multiplicando a quantidade de saída do receptor pelo fator variável. O valor do fator pode ser uma constante, calculado pelo
sistema. A quantidade planejada fixa corresponde às quantidades consumidas fixada informadas como valores constantes ou
calculadas pelo sistema.
Durante a alocação de processo estruturado, o R/3 rompe as estruturas dos processos ABC para lançar as relações de alocação e
quantidades de alocação determinadas na estrutura. Se o processo não for estruturado, o desmembramento da estrutura é
cancelado e, consequentemente, a alocação posterior. O sistema calcula quantidade dos processo indiretamente, alocando dos
processos receptores para os subprocessos e centros de custo. Pela valorização do fluxo do processo com a tarifa planejada, o
sistema consegue atribuir custos de processo para os processos ABC durante a alocação. A alocação de processos pode ser feita
através da alocação Target=actual se as colunas do objeto, ativação e quantidade do modelo nos processos estruturados sejam
idênticas tanto no planejado quando no real e o planejamento esteja completo, significando que todas as alocações
emissor/receptor existentes no planejamento também existam no real.
Para a alocação de quantidades reais, as quantidades e seus fatores planejados devem ser diferentes dos reais, e os processos
estruturados devem ser construídos mantendo os requisitos da alocação target=actual.
Alocação de processo estruturado é baseado no período e ano fiscal.
Antes de alocar quantidades dos processos, é preciso estruturar, pelo menos, um processo ABC e calcular as quantidades reais
dos processo dos processos receptores, no nó principal da hierarquia estruturada. O sistema pode usar as seguintes approaches:
Confirmações manual de quantidades reais – é preciso ativar selecionar a opção Quantidade de atividade manual no
cadastro de processo estruturado.
Alocação indireta de atividade – fornece dados de custeio ABC valorizado com uma tarifa determinada ou
automaticamente via um modelo de processo ou lançada manualmente.
O sistema valoriza os templates do processo dos objetos de custo – os templates fornecem as quantidades dos processos
pelo objetos de custo para cálculo real em CO-PC.
21.4.4.9 Pre-distribuição de custos fixos
A pre-distribuição de custos fixos é uma ferramenta que permite gerar lançamentos reais de custos fixos a partir dos valores
planejados para os custos fixos para estes tipos de atividades/centros de custo (válido também para processos ABC) baseado na
proporção de quantidade de atividades solicitada pelos receptores.
A predisribuição de custos fixos é útil para a determinação dos custos totais de produção já que distribui os custos fixos para os
objetos de custo. Predisribuição de custos fixos garante, assim, que o planejamento integrado de atividades considere os custos
fixos (atividades de preparação por exemplo) dos centros de custo emissores (e processos ABC) em conjunto com a alocação
dos custos variáveis e permite que a parcela destes custos fixos a ser atribuída a cada receptor seja definida pelos próprios
receptores e não pelo centro de custo emissor.
Como os custos fixos não são proporcionais à atividade prestada pelo centro de custo emissor, estes custos não podem ser
alocadas com base na quantidade destas atividades. A quantidade alocada será igual à quantidade de entrada de atividade fixa
planejada do receptor multiplicada pelo preço fixo da atividade do emissor.
Os objetos receptores de custo fixo na pre-distribuição são, obrigatoriamente, centros de custos e, em alguns casos, processos
ABC. Não poderão ser ordens nem projetos já que o sistema sempre irá debitá-los com os custos fixos e variáveis. No entanto,
se estes objetos forem associados a um centro de custo usado em liquidações planejadas, a pre-distribuição e transferida para o
centro de custo receptor.
Ordens associadas a atividades com pre-distribuição de custo fixo não podem ter sua liquidação real completa.
A pre-distribuição afeta a alocação real e o encerramento do período. Para as atividades que trabalham com pre-distribuição de
custos fixos é preciso definir se o receptor irá ou não receber a parcela do custo fixo na alocação real. Isto garante que um
receptor não recebe este custo mais de uma vez. O R/3 não irá distribuir os custos fixos para os receptores que tenha recebido
lançamentos reais. Se o emissor participa da pre-distribuição e o receptor, para o qual foi lançado valores reais, não participa,
CONTROLADORIA 139 de 325
ele recebe os custos fixos e variáveis. Se o emissor não participa, obrigatoriamente o sistema irá alocar os custos fixos e os
variáveis.
Para os objetos de custos que receberão lançamentos estatísticos ocorre o seguinte: o objeto participa da pre-distribuição, recebe
somente os custos variáveis, caso contrário, recebe os custos totais. Estas regras se aplicam à alocação real independentemente
do fato de a pre-distribuição gerar ou não lançamentos de custos fixos para os receptores.
A pre-distribuiçõa é usada como parte do custeio marginal. É valida no custeio total para determinação dos custos de produção
baseado no custo cheio.
Aloca os custos fixos do Centro de Custos. Como os cutsos de preparação não são proporcionais à quantidade de atividade
executada pelo Centro de Custo emissor, é necessário outro critério para a distribuição destes custos.
Os custos serão distribuídos para os centros de custos que planejaram entrada de atividade.
OBS: o indicador deve estar ativade no mestre de materiais.
A distribuição é proporcional à parte fixa da atividade planejada no receptor.
A pre-distribuição pode ser afetada no momento do cálculo da tarifa. Aloca custos fixos planejados da versão zero para o
receptor planejado.
21.4.4.10 Decomposição de Custos em atividades e reavaliação da Tarifa (Splitting / Price Calculation)
No final do período, poderá ser solicitado que o sistema recalcule o preço destas tarifas com base nos custos realmente
incorridos no período. Ou seja, pode ser atribuído um valor planejado para ser usado durante o período na alocação dos custos
de um centro de custo para outro para uma ordem de produção, por exemplo. No final do período, o sistema irá recalcular esta
tarifa com base nos custos realmente incorridos. Primeiro é preciso fazer a decomposição (splitting) do custo total do centro de
custo para as atividades executadas por ele tomando como base o peso definido para cada atividade ou um regra de
decomposição definida. Posteriormente, o montante atribuído para cada atividade é dividido pelo total da quantidade de
atividade executada pelo centro de custo para definir a nova tarifa, agora, real. Por fim, é preciso reavaliar as ordens para que
estas passem a enxergar estas diferenças em CO-PC.
A forma como estes cálculos serão executados e os critérios para a determinação das quantidades de atividades executadas pelo
centro de custo e recebidas por ele irá depender da categoria de cada tipo de atividade definida.
Se não for executado o cálculo iterativo das tarifas, o sistema considera a tarifa planejada no versão 000 para a alocação direta
tanto para os lançamentos planejados como os reais.
21.4.5 Cálculo de Desvios de Centros de custos (Variances)
Os desvios em CO podem surgir por diversos motivos: o planejamento desviou do objetivo, os custos reais de um centro de
custo ou processo ABC deferiram dos custos teóricos ou ocorreram sub ou super absorção de custos em um centro de custo ou
processo ABC> O cálculo das variações permite analisar as causas e outras situações.
O cálculo do desvio se baseia na comparação entre o planejamento de atividades internas entre centros de custos e processos e
os custos destas atividades. OS desvios, portanto, correspondem às diferenças entre os custos reais e os custos planejados ou os
custos teóricos. Eles são divididos em porções fixas e variáveis e, quando possível, classificados pelas classes de custo.
O cálculo do desvio faz uma distinção entre centros de custo com tipos de atividade (tais como os centros de custo de produção)
e os centros de custo sem tipos de atividades definidos (tais como os administrativos). Os custos reais são lançados como
independente da atividade. Para vincular com a atividade, os custos reais e o planejamento independente da atividade ou os
custos teóricos são distribuídos pelas atividades executadas pelos centros de custo. Isto permite efetuar análises das causas das
variações específicas de atividade.
O cálculo do desvio permite dividir as diferenças em diversas categorias facilitando a identificação das causas. Os desvios
podem resultar de débitos (input) ou crédito (output).
O cálculo dos desvios é uma das funções a serem executadas no encerramento do período. O cálculo do desvio utiliza todos os
valores resultantes de todas as transações da Contabilidade de centros de cusos e Custeio ABC. O R/3 calcula, primeiramente, o
custo teórico, em seguida, divide os custso reais entre os tipos de atividades e, então, calcula os devios por centro de custos,
tipos de atividade ou processos.
CONTROLADORIA 140 de 325
O R/3 calcula as diferentes categorias de desvios de forma acumulada, ou seja, o total dos desvios nas diversas categorias é
igual ao total do desvio do centro de custos ou processo empresarial. No períodos especiais, os desvios são acumulados.
You can use reporting tools to analyze the variance calculation results further. These allow you to display relevant data divided
into fixed and variable portions, or as totals:
Plan costs and quantities
Operating rate
Target costs and quantities
Actual costs and quantities
Variance categories
In addition, the R/3 System also displays:
The calculation basis for the individual values (for instance, the distribution basis in actual cost splitting)
How the individual values are made up (for example, individual variance categories)
You can use the functions Splitting explained, Target costs explained and Variance explained to show the results in different
formats.
You can display an overview of the different variance categories in a hierarchical structure. To do so, you can choose the
Variance categories function. You can move from the structure to the variance categories and the online help for definitions.
The results list displays the variances and the formulas used for calculating the different variance categories.
You can change the appearance of the results list using the totals and sorting functions.
You can also select objects for detailed display and run the variance calculation one step at a time to view information on each
step as you proceed.
21.5 Planejamento
O planejamento dos centros de custos faz parte do planejamento da empresa como um todo e deve ser integrado ao processo de
planejamento global. Pode ser feito o planejamento de custos primários, secundários, de atividades de quantidades consumidas.
O planejamento é feito para um período de tempo definido, normalmente um ano fiscal.
O planejamento do centro de custo é tratado diferentemente em quase todas as organizações variando conforme o tipo de
indústria, a estrutura organizacional e as responsabilidades. Todo o planejamento de centro de custo pode ser feito online no
R/3 fornecendo resultados imediatos que podem ser analisados no Sistema de Informação.
Para execução do planejamento é preciso considerar as circunstâncias do negócio e suas possíveis alterações e os objetivos da
empresa. O planejamento também pode ser usado para criar as Benchmarks para controle das atividades dentro de um período
contábil. Permite estabelecer um padrão de controle periódico para valorização de atividades internas estimando um custo
unitário para cada atividade em cada período e monitoramento da eficiência após o fechamento do período contábil analisando
variações entre planejado e real e teórico (target) e real apontando possíveis correções para melhoria do resultado.
Os gerentes dos centros de custos responsáveis por suas áreas devem ser realistas no planejamento de seus custos para permitir
um controle efetivo, de forma que o plano só precise ser revisado raramente (na maior parte dos casos por fatores externos).
Inicialmente, é preciso delegar as responsabilidades do planejamento, o grau de detalhamento e a periodicidade (anual,
semestral, mensal, etc.). Em seguida, define-se a seqüência de execução das atividades de planejamento e as áreas (índices
estatísticos, tipos de atividade, custos primários, custos secundários e receitas) a serem planejadas e conciliadas. Para o
planejamento, o sistema fornece ferramentas de auxílio, de cálculos e métodos de revalorização. Depois do planejamento, os
resultados são disponibilizados em forma de consumo de recursos, valores de custos planejados e esperados a nível de
atividades e de centros de custo.
Para compensar flutuações sazonais, podem ser usadas as chaves de distribuição flexíveis.
Para a planejamento de centros de custos, podem ser definidos tipos de taxa de câmbio (exchange rate type) opcionais. O tipo
de taxa de câmbio armazena taxas de câmbio para diferentes propósitos ao mesmo tempo. O R/3 padrão disponibiliza a tipo de
taxa de câmbio P e este tipo é assumido na geração automática da versão 000 do planejamento por cinco anos quando da
criação da Área de Contabilidade de Custos. No lançamento e liquidação de documentos, o R/3 usa o tipo de câmbio M.
CONTROLADORIA 141 de 325
O processo de planejamento constitui-se de vários ciclos iterativos para os diversos tipos de alocação possíveis (rateio,
distribuição e alocação indireta de atividade).
21.5.1 Escopo e Métodos de Planejamento
No Planejamento de Centro de Custos é preciso diferenciar planejamento de índices estatísticos, planejamento de preços e saída
de atividades e o planejamento do custo baseado em quantidade e valor os custos primários e secundários, assim como o
planejamento das receitas.
Principais cenários de planejamento:
Planejamento de Custos
Planejamento de Valor
Analise comparativa real/planejamento
Planejamento de atividade
Planejamento do atividade: quantidade de saída do cento de custo
Planejamento do Custo
Independente da atividade
Cálculo de preço iterativo (preço manual ou fixo)
CONTROLADORIA 142 de 325
Planejamento de Custos Fixos e Variáveis
Custos planejados dependente da atividade
Determinação da tarifa separando fixo e variável
Análises de real e teórico
Custeio padrão flexível
Custeio marginal opcional
21.5.2 Layout e Perfil (Profile)
O planejamento é feito através de telas predefinidas no R/3 contendo somente os campos que devem ser informados pelo
planejador e associados aos perfis dos planejadores. Estas telas são conhecidas como layout de planejamento Estes layouts
devem ser definidos conforme as áreas de planejamento, como, por exemplo, classe de custo e tipo de atividade. A ferramenta
usada para geração dos layouts de planejamento é o Report Painter.
Existem três áreas de planejamento: classes de custo/ entrada de atividade; tarifas/saídas de atividades e índices estatísticos.
Para cada área é preciso definir pelo menos um layout. O R/3 tem alguns layouts predefinidos. Os perfis de planejamento
deverão ser associados tanto às áreas de planejamento quanto aos layouts. O R/3 também tem diversos perfis padrões
disponíveis que cobre boa parte das situações de planejamentos. O perfil SAPALL pode ser usado para o planejamento das três
áreas com diversos layouts disponíveis em cada área. O perfil SAPEASY é preparado para um planejamento mais simplificado.
Normalmente, as empresas copiam e adequam estes perfis para as suas necessidades.
O planejamento pode ser feito de forma centralizada (para todos os centros de custo numa determinada classe de custo) ou de
forma descentralizada (para todas as classes de custo em um único centro de custo) dependendo da forma de execução da sua
empresa (top-down ou down-top). Os dois critérios podem ser mesclados.
Para a definição dos layouts pode ser usado o Report Painter. O layout contém um área de cabeçalho (critérios de seleção –
linhas de cabeçalho fixas), colunas chave (definindo para o que se quer planejar: uma coluna para custo independente da
atividade – classe de custos - e duas colunas para custos dependentes da atividade – classe de custo e tipo de atividade) e
colunas de valores. Como coluna de valores podem ser definidos índices e características, somente características, fórmulas.
Em uma coluna de atribuição pode ser escolhida a unidade, a chave de distribuição e a atividade. A unidade e a chave de
distribuição pode ser criada como um campo adicional para a coluna.
Na função de planejamento propriamente dita, o usuário poderá escolher um dos layouts de planejamento permitidos para
aquela área.
Nos perfis podem ser especificados valores propostos e controle de acesso (grupo de autorização) restringindo o planejamento
por áreas (descentralização do planejamento).
21.5.3 Ajuda do planejamento (Plaining Aids)
O R/3 possui uma função de cópia que permite aproveitar informações planejadas de períodos ou anos anteriores, de outras
versões ou mesmo tomar com base custos reais incorridos para gerar os custos planejados. Os dados podem ser copiados dentro
de um mesmo ano fiscal, período, versão e centros de custo ou entre ano fiscal, centro de custos, períodos e versões. A cópia
também pode ser limitada a dados de um tipo de planejamento.
Através de outra ferramenta (Revaluation) é possível aplicar percentuais aos valores planejados. São gerados lançamentos (plan
line items) durante a revalorização. A revalorização pode ser reprocessada e, neste caso, os lançamentos de planejamento são
desconsiderados usando, sempre, os valores originais iniciais, mas somente serão gerados lançamento para ajustes. Não é
gerado lançamento de estorno.
As funções básicas para a entrada de valores para o planejamento do empresa são as funções de Planejamento de índices
estatísticos para ordens internas e centros de custos, planejamento de custos primários e consumo de atividades para ordens
internas e centros de custos e prestação de atividades e tarifas para centros de custo. As demais funções são auxiliares para
alocar estes custos entres os diversos centros de custo e para facilitar o processo de entrada de dados. As funções de Ajudas do
Planejamento são, basicamente, funções auxiliares à entrada de dados:
Copiar
Reavaliar
CONTROLADORIA 143 de 325
Eliminar
Transferências
Custos de pessoal HR
Depreciação e juros/AM
Atividade alocada de PP
Índice estatístico
Conciliação do Plano
Transferência Periódica
Delimitação de Custos
Planejamento de Fórmula
Ativar Integração
Reavaliar planejamento manual
21.5.3.1 Copiar
Esta funcionalidade permite gerar uma nova versão a partir de outra, copiar dados entre exercícios, entre períodos do mesmo
exercício ou de exercícios distintos. Permite, ainda, copia o planejamento de um determinado centro de custo para vários. Os
dados tomados como base tanto podem ser dados planejados como dados reais, ou seja, é possível gerar uma versão planejada a
partir de dados reais passados. Esta função é muito usada para gerar a versão de planejamento 0. Como a versão 0 (zero) é a
versão operativa do sistema e permite comparar dados reais com planejados, recomenda-se sempre que o planejamento seja
efetuado em uma outra versão e copiado para a versão zero somente para comparações preservando uma cópia dos dados
planejados na versão original. Esta funcionalidade é válida para centros de custo e ordens internas.
KP97 – Planejamento no planejamento
KP98 – Real no planejamento
Os dados que podem ser copiados são: custos primários dependentes e independentes da atividade, consumo de atividades
dependente e independente da atividade, outros custos secundários dependentes e independentes da atividade, volume de
atividade e tarifas, receitas e índices estatísticos. Opcionalmente, também podem ser copiados os textos descritivos e o
planejamento detalhado das classes de custo.
Os custos podem ser copiados na moeda da Área de Contabilidade de Custos, do objeto ou da transação. O valor proposto é a
moeda da Área de Contabilidade de Custos. Já as tarifas podem ser copiadas na moeda da Área de Contabilidade de Custos ou
na moeda do objeto. O valor proposto é a moeda da Área de Contabilidade de Custos.
Por questões de performance siga, sempre que possível as seguintes instruções:
Selecione somente os dados que realmente foram planejados. Se, por exemplo, não foi efetuado nenhum planejamento para
ordens, desative esta transação;
Se o volume de dados for muito grande, solicite sempre o processamento em background processando os dados num
momento de menor utilização do sistema;
Se for efetuar a cópia on-line, garanta que a cópia do tipo de atividade seja feita antes da cópia das outras áreas de
planejamento uma vez que ela é necessária para a atualização dos registros dependentes da atividade.
Evite a opção Reinicializar e Sobregravar para reduzir a quantidade de informações as serem lidas durante o
processamento;
Somente solicita a lista detalhada (com os registros copiados) se for absolutamente necessário. A lista básica é sempre
gerada;
Somente copie textos descritivos se for absolutamente necessário. A cópia destes textos aumenta consideravelmente o
tempo de processamento.
Copie somente partes da hierarquia de centros de custo.
CONTROLADORIA 144 de 325
21.5.3.2 KSPU – Reavaliar
Esta funcionalidade permite aplicar um percentual sobre os valores planejados para uma determinada versão / exercício / área
de contabilidade de custos. É possível definir-se valores diferenciados por período, por intervalo de classes de custos, para
custos e consumo. Esta funcionalidade é válida somente para centros de custo.
21.5.3.3 Eliminar
Esta funcionalidade permite eliminar da base os valores já planejados de uma determinada versão / exercício para efetuar novo
planejamento. É importante tomar cuidado pois todo usuário autorizado a planejar está também autorizado execução esta
função a menos que seja especificamente determinado o contrário. A eliminação de custos limpa somente os valores planejados
mantendo a estrutura. A eliminação de dados elimina, além dos dados toda a estrutura. Esta funcionalidade está disponível no
menu de centro de custo mas também elimina dados das ordens internas.
KP90 – Custos primários planejados
KP91 – Dados planejados
Transações consideradas na eliminação de custos primários
RKP1 Planejamento de Custos primários
RKP5 Planejamento de Receitas
RKP6 Planejamento de Custos primários dependente da atividade
RKP8 Planejamento de custos de liquidação
RKP9 Planejamento de custos de ordens dependentes da atividade
RKPZ Planejamento de crédito de overhead
Transações consideradas na eliminação de dados (além das anteriores)
CPPP Planejamento de rateio de processo ABC
KAZP Provisão de Centro de Custo planejado
KOAM Planejamento liquidação alocação interna atividade
RKP2 Planejamento de atividades
RKP3 Planejamento de Custos Secundários
RKP4 Planejamento Índices estatísticos
RKP7 Planejamento de custos secundários dependente da atividade
RKP8 Planejamento de Transferência Periódica
RKPD Transferência de PP
RKPK Planejamento de índices estatísticos com modelos
RKPL Planejamento de alocação indireta de atividade
RKPP Planejamento primário com modelo
RKPS Planejamento secundário com modelo
RKPU Planejamento de rateio de custos de overhead
RKPV Planejamento de distribuição de custos de overhead
RKPW Planejamento de custos de ordens secundários
RKPX Planejamento de custos de ordens secundários dependente da atividade
KSP0 Planejamento de decomposição
KSP1 Planejamento de decomposição primário
KSP2 Planejamento de decomposição secundário
KSP3 ???????? decomposição
KZPP Taxas de overhead planejamento periódico
CONTROLADORIA 145 de 325
21.5.3.4 Transferências
Esta funcionalidade permite trazer de outros componentes do R/3 informações para o planejamento de centros de custos ou ordens. As informações disponíveis
são:
KPHR – Custos de pessoal do HR (custos primários para os centros de custos calculado no HR conforme a alocação dos funcionários nos diversos centros de custo);
S_ALR_87099918 – Depreciação / Juros AM (valor das depreciações e juros dos bens do ativo imobilizado definidos conforme o objeto de custo do bem – centro de custo ou ordem – no período do planejamento). O valor da classe de custo será sobreposto. Se o tipo de atividade estiver definido no
cadastro do bem, o custo será importado como dependente da atividade – custo variável. Caso contrário, é considerado custo fixo;
KSPP – Atividade alocada PP – somatório das necessidades de atividades calculadas com base nas ordens planejadas pelo MRP. Para planejamento de longo prazo. Para transferir as necessidades de atividades de PP primeiro é preciso efetuar o planejamento manual dos centros de custo/tipo de atividade
para criar um registro com esta relação no planejamento. Isso pode ser feito, por exemplo, copiando o planejamento de outra versão ou período. Caso não encontre um registro com a relação, o sistema emite mensagem de erro. Após a transferência, com êxito, é preciso executar a função de conciliação do
plano para que os valores trazidos de PP sejam efetivamente atualizados em CO.;
KVA4 – Índice estatísticos independente da atividade – extraído do SIL (Sistema de Informação de logística conforme parametrizado no registro mestre do índice estatístico);
KVD4 – Índice estatísticos dependente da atividade – extraído do SIL (Sistema de Informação de logística conforme parametrizado no registro mestre do índice estatístico);
21.5.3.4.1 Transferência de Depreciação e Juros (S_ALR_87099918a46)
O R/3 permite que sejam importados, para o planejamento de custos primários para os centros de custos e/ou ordens, os valores
de depreciação e juros periódicos de qualquer área de depreciação real da Contabilidade do Ativo. O programa permite
parametrizar se os valores de depreciação de um ativo vinculado a uma ordem deve ser lançado na ordem ou no centro de custo
com o qual ela está vinculada.
As definições das classes de custo que irão receber os valores é definido em AM (transação AO90 – Atribuir contas do razão).
Mesmo para os grupo de contas que não tem cálculo de depreciação, as contas devem ser parametrizadas para que a importação
possa ser efetuada.
O procedimento para cálculo da depreciação planejada é semelhante ao cálculo da depreciação simulada. O cálculo é feito tanto
para ativos já capitalizados como para investimentos planejados seja em OS (projeto – elemento PEP), IM (programa de
investimento) ou no próprio CO (Ordens Internas). Para os investimentos planejados, podem ser definidos se deverão ser
considerados os valores planejados ou orçados. Os termos de depreciação considerado serão considerados os termos de
simulação da depreciação. No caso das ordens de investimento, os termos da depreciação simulada são informados no momento
do cadastramento da ordem. Para os elementos PEP e programas de investimentos os dados da simulação também estão no
registro mestre.
OBS: Os valores calculados sobrepõem os valores anteriores. Portanto, o programa pode ser reprocessados quantas vezes
necessário. No entanto, nenhum outro planejamento deverá ser efetuado manualmente nas contas atualizadas por esta função
uma vez que serão sempre sobrepostos.
Quando parte do valor do investimento já foi capitalizado (liquidado contra um ativo), o R/3 não ajuste a base de cálculo para a
simulação gerando duplicidade de valores. Para correção deste problema deve-se utilizar o parâmetro “Tratamento das
ativações do exercício atual” para ou desprezar os lançamentos de capitalização do ano corrente no ativo, ou subtrair os valores
referente às capitalizações da base de cálculo nas simulações.
Caso o sistema não encontre um centro de custo ou ordem para efetuar o lançamento, será gerada mensagem de erro e o
programa é interrompido. Este erro ocorre, particularmente, para ordens com regras explícitas de liquidação e o sistema não
consegue determinar um centro de custo já que não estará mais disponível no registro mestre.
Também é possível separar os valores em parte fixa e variável. Para isto é preciso que o planejamento seja dependente da
atividade (foi parametrizado para considerar o tipo de atividade e o registro mestre do ativo tem um tipo de atividade
informada) e seja informado o fator de turnos (informar 1quando não se aplica).
Parâmetro Descrição
Empresa Informar um intervalo de empresas para selecionar os ativos a serem considerados. Através
do botão de seleção múltipla podem ser definidas várias empresas independente de
intervalo. (*)
CONTROLADORIA 146 de 325
Parâmetro Descrição
Investimentos
planejados
Investimentos planejados são Ordens de Investimento (CO), Projetos (OS) ou Programas de
Investimento (IM).
Versão do planejamento – informar a versão do planejamento para considerar os valores
base de cálculo das depreciações.
Exercício de aprovação – exercício em que foi aprovado o programa de investimento.
Seleções – Centro de
Custo
Informar um intervalo de centros de custos para os quais se deseja calcular os valores
planejados de depreciação. Opcionalmente, pode ser usada a seleção múltipla (*)
Opções – Área de
avalização
Uma área de avaliação representa a avaliação dos imobilizados para um determinado
objetivo (por ex., balanço comercial, balanço fiscal, balanço geral consolidado, avaliação de
bens, avaliação baseada em cálculo de custos, etc).
Informar a área de avaliação para determinação dos critérios.
OBS: Deve ser uma área de avaliação real
Período planejamento Informar o exercício para o qual devem ser calculadas as depreciações e o intervalo de
períodos dentro deste exercício.
Outras opções para o
planejamento
Versão – informar a versão do planejamento que deve ser atualizada.
Relatório de totais – se esta opção for selecionada será exibido o relatório resumido do
processamento.
Variante de exibição Selecionar a variante de exibição do realtório que irá ser gerado. A variante de exibição
pode ser criada ou alterada na tela de exibição do relatório. Ela define quais as colunas a
serem impressas, critérios para classificação dos dados, totais, etc..
Selecionar Imobilizado Permite importar a depreciação de apenas alguns ativos especificados.
Orçamento X
Planejamento
Definir se deseja que os dados dos investimentos planejados (ordens de investimento,
projetos e programas de investimentos) trabalhem com os dados orçados ou planejados.
Selecionar ordens Definir para quais as ordens de investimentos se deseja efetuar os cálculos
Tratamento das
ativações do exercício
atual
Como o R/3 normalmente considera o valor total planejado para a ordem ou elemento PEP
não levando em consideração as depreciações efetuadas, é preciso selecionar uma das opções
para que:
1 – o valor já capitalizado não entre no cálculo da depreciação simulada ou
2 – o valor das capitalizações efetuadas no ano corrente sejam desprezadas
permanecendo os valores compondo a base de cálculo das depreciações simuladas.
Area de contabilidade
de custos
Definir as áreas de contabilidade de custos que irão receber valores
Chave de Distribuição Se a chave não for informada, o sistema irá calcular os valores período a período. Se a chave
for informada será efetuado o cálculo do total dos períodos definidos e distribuídos os
valores conforme a chave
Planejamento
dependente da
atividade
Definir se deverá ser considerado o tipo de atividade definido no mestre de materiais para
gerar o planejamento dependente da atividade. Para os ativos sem tipo de atividade
informado, o planejamento será independente da atividade.
Planejamento
independente da
atividade
Neste caso, o tipo da atividade não será considerado e todos os planejamentos serão
lançados independente da atividade
Dicas
Em todas as funções de processamento onde precisam ser informados parâmetros para a execução de um programa, o R/3
permite que estes parâmetros sejam gravados em variantes de seleção de forma a minimizar digitação e erros.
Selecionar a opção de processamento background sempre que o volume de dados for grande para melhorar performance e
não sobrecarregar o sistema em horários de grande utilização. A execução através de jobs permite o processamento fora do
horário normal de trabalho e libera a estação para outras tarefas.
CONTROLADORIA 147 de 325
Sempre antes de executar o programa definitivamente, solicitar uma execução teste e verificar se o processamento foi
efetuado com sucesso para evitar necessidade de acertos e estornos que sobrecarregam o banco de dados.
21.5.3.4.2 Transferência de necessidades de atividades de PP
Esta funcionalidade permite que sejam importados para CO o consumo previsto de atividades pela produção com base no
planejamento efetuado em PP (Plano global, MRP ou Planejamento de Longo prazo). A transferência efetiva dos valores se dá,
na verdade, através da conciliação do plano. Portanto, o procedimento de transferência, na verdade, ocorre em três etapas:
O primeiro passo é a geração dos registros de planejamento para cada relação centro de custo/tipo de atividade para as quais PP
possa gerar necessidade de atividades. Isto pode ser feito manualmente através da transação KP26 – Planejamento de Prestação
de Serviços/Tarifas ou, também, através da função de copia de plano (KP97) copiando apenas estrutura sem valores . Caso o
sistema não encontre um registro, o programa gera uma mensagem de erro e nenhum valor é importado. Basta gerar o registro e
reprocessar.
O próximo passo seria execução desta transação para que o sistema gere a outra parte da relação que é o consumo de atividade.
Só que, neste caso, os receptores serão ordens de produção e não centros de custo. Este valores podem ser visualizados no
relatório gerado pelo processamento ou, posteriormente, pelos relatórios do planejamento (S_ALR_87013629 – Tipo de
Atividade: reconciliação). Nele são mostradas as quantidades de atividades alocadas para cada centro de custo / tipo de
atividade.
O último passo é a execução da Conciliação do Plano (KPSI) quando os valores irão, efetivamente, para o planejamento de
prestação de atividade dos centros de custos produtivos (localizados no final da cadeia dos ciclos de alocação).
O processamento é efetuado, individualmente, para cada centro (planta) de logística.
Controle de Transferência para versão / exercício
Parâmetro Descrição
Área de Contabilidade de
Custos
Informar CTS para Santanense e FTSH para Santa Helena
Versão Informe a versão para a qual os volumes deverão ser importados
Exercício Informe o exercício para o qual os volumes de atividades deverão ser importados.
Transferência da
necessidade de atividades
de:
Define o critério a ser usado para o cálculo das necessidades de desempenho de
cada centro de custo.
Plano Global – as quantidades de produção criadas no planejamento global são
programadas e analisadas através dos roteiros ou perfis do planejamento global.
Neste caso, deve ser informado o número da versão do planejamento global a ser
importada.
MRP – as ordens planejadas para produção interna, criadas no planejamento de
longo prazo ou no planejamento de necessidades, são programadas e analisadas
através dos roteiros.
Plan.Longo Prazo – as ordens planejadas criadas para produção interna, através de roteiros, são programadas
e analisadas, no âmbito do planejamento de longo prazo ou do planejamento de necessidades de material. Neste caso, deve ser informado o Cenário de planejamento.
UltGrpProd Utiliza Grupo de Produtos
Indica se os dados do grupo de produtos ou do planejamento de material devem
ser transferidos do planejamento de vendas e operações (SOP-standard) para CO-
CCA.
Cenário de planejamento Com o cenário de planejamento, são definidos os parâmetros de controle para o
planejamento de longo prazo. Isto significa, entre outros, o centro, no qual o
planejamento deverá ter lugar, o período de planejamento e as versões a ser
planejadas, das necessidades independentes previstas.
Informar o cenário de planejamento a ser extraído os dados.
CONTROLADORIA 148 de 325
Controle de Transferência para versão / exercício
Parâmetro Descrição
Nível Programação Informar qual a necessidade de capacidade a ser selecionada.
Planejamento detalhado
Planejamento de taxas de produção
Planejamento Global
Ultima transferência Data da última transferência de dados efetuada.
Principais parâ metros para execução da função:
Campo Ações do usuário / conteúdo
Efetuar adaptação de
período
Código que controla se as quantidades de atividade planejadas das ordens
planejadas ou SOP simuladas, situadas fora do período de transferência, serão
transferidas ou não como atividade alocada para a contabilidade de centros de
custo.
Se este código estiver ativo, o sistema SAP R/3 transfere todas as quantidades de
atividade planejadas de todas as ordens planejadas ou SOP do cenário planejado
selecionado ou da versão de planejamento global selecionada, como quantidades
de atividade alocada para a contabilidade de centros de custo. Nisto, as datas
situadas fora do período de transferência serão de tal modo ajustadas, que todas
as quantidades de atividade alocada estarão no período de transferência.
Verificação relacionamento
com objeto
Controla se deve ser efetuadas algumas verificações nos dados básicos
relacionados às ordens planejadas ou as ordens de SOP.
Se este flag não estiver marcado as verificações não serão completadas e não serão
geradas mensagens de erros no log caso ocorram. Se as verificações forem
efetuadas, o tempo de processamento irá aumentar consideravelmente.
Nível de Detalhe listagem Centro de custo / tipo de atividade
Material / Centro
Ordem planejada / SOP
Exemplo de Execução de adaptação de período
No planejamento integrado para o exercício seguinte foi gerada no cenário planejado utilizado do planejamento a longo prazo
uma necessidade independente planejada de um produto acabado, no primeiro período do exercício seguinte. Os produtos semi-
acabados necessários à produção deste produto acabado, são gerados como necessidades dependentes, completa ou
parcialmente, no último período do exercício atual.
Da programação dos roteiros para a necessidade independente ou dependente resulta que algumas operações, completa ou
parcialmente, se encontram ainda no exercício atual.
Se o usuário tiver ativado o código, todas as quantidades de atividade destas operações são transferidas para o exercício
seguinte. Se o usuário não tiver ativado o código, então ,em operações, as quantidades de atividade que se encontram
parcialmente ou que não se encontram no exercício seguinte serão, respetivamente, transferidas parcialmente ou não serão
transferidas.
21.5.3.5 KPSI – Conciliação do Plano
Esta funcionalidade permite que o sistema faça ajustes nas saídas dos centros de custos conforme as solicitações de atividades
efetuadas pelos receptores. Assim, por exemplo, se o centro de custo de manutenção tiver feito uma planejamento de volume de
atividade de 300 h no mês e os centros de custo de fiação, tecelagem e acabamento fizeram uma previsão de consumo de 150 h
cada um, o sistema irá ajustar, automaticamente, o volume de atividade do centro de custo de manutenção para 450h.
Naturalmente, que irá alterar os custos Variáveis da entrada do centro de custo de manutenção proporcionalmente à alteração na
CONTROLADORIA 149 de 325
saída (+50%). Se algum destes custos se referir a um consumo de atividades, o sistema também irá ajustar o centro de custo
emissor desta atividade e assim sucessivamente. O sistema trata a recursividade (processamento iterativo). A figura a seguir
mostra a situação antes da conciliação:
AlmoxarifadoS: 200 h
ManutençãoS: 300 h
E: 400 h
FiaçãoE: 150 h
AcabamentoE: 150 h
TecelagemE: 150 h
Na conciliação, os valores das entradas dos centros de custo de Fiação, Tecelagem e Acabamento serão somados totalizando
450h. A saída do centro de custo de manutenção é ajustada para 450h. Proporcionalmente, sua entrada é ajustada para 600h
(aumento de 50%) e a saída do centro de custo almoxarifado é ajustado para 600h com mostra a figura abaixo.
Almoxarifado
S: 600 h
ManutençãoS: 450 h
E: 600 h
FiaçãoE: 150 h
AcabamentoE: 150 h
TecelagemE: 150 h
Note que este procedimento é feito para cada tipo de atividade. No ajuste dos custos de entrada, não serão considerados os
custos fixos primários ou de consumo de atividades. Se não for feito nenhum planejamento de consumo de atividade para um
determinado tipo de atividade, não será feita nenhuma conciliação. Isto significa que não será preciso efetuar planejamento para
os centros de custo produtivo cujas atividades serão alocadas para ordens de produção e não para centros de custo.
21.5.3.6 KSWB – Transferência Periódica
Esta funcionalidade permite reduzir o número de lançamento a serem efetuados em FI. Por exemplo, pode-se definir que os
custos de energia elétrica ou telefone serão lançados para um só centro de custo ou ordem interna. No final do período, estes
custos seriam alocados para os seus respectivos receptores (ordens ou centros de custo) tomando como base um critério que
tanto pode ser um percentual fixo, um índice estatístico ou outro critério a ser definido. Da mesma forma que os rateios,
distribuições e alocações de atividade, as transferências periódicas são definidas através de ciclos com um conjunto de
segmentos.
Na transferência periódica somente poderão ser usados classes de custos primárias já que seu objetivo e reduzir lançamentos de
FI e em FI somente são usadas classes de custos primárias. Este processo é bem semelhante a distribuição distinguindo-se,
basicamente por não gravar um registro de totais para o centro de custo emissor. O sistema, na verdade, ao invés de gerar um
registro de crédito, irá reduzir o valor total debitado. Este procedimento proporciona melhor performance e redução de área em
disco. No entanto, não aparecerá nos relatórios os lançamentos a débito e crédito.
Outra grande diferença com a distribuição é que a transferência periódica permite ter a ordem interna como um emissor.
Este tipo de lançamento poder ser revertido e refeito quantas vezes for necessário, lembrando que, na reversão são gerados
lançamento de estorno. Para ver mais informações sobre ciclos e segmentos, consulta o manual sobre alocações.
21.5.3.7 KSA8 – Delimitação de Custos
Esta funcionalidade permite efetuar lançamento de provisões diretamente em CO com o objetivo de reduzir flutuações nos
custos periódicos conseqüência de gastos que embora ocorram em um único período se referem a todos os períodos do
CONTROLADORIA 150 de 325
exercício. Os critérios para os cálculos são definidos através de um Esquema de Cálculo de Custos. Só deverão ser consideradas
aqui, as provisões que não sejam efetuadas em FI. O R/3 grava registros de totais e partidas individuais para estes lançamentos.
A data do lançamento será sempre a data do primeiro dia do mês do calendário (no caso de lançamentos reais a data é a do
último dia do mês).
21.5.3.8 Planejamento de Fórmula
Esta funcionalidade é bastante útil no planejamento de custos primários e consumo de atividades nos casos em que os valores
planejados são determinados de forma semelhante para diversos centros de custo como, por exemplo, custo de pessoal: várias
classes (planejadas com índices estatísticos) derivam do número de empregados. As fórmulas são gravadas em Modelos. Estes
modelos são vinculados aos centros de custo no seu registro mestre podendo ser definido um modelo para o planejamento
dependente da atividade e outro para o planejamento independente da atividade.
Para cada centro de custos podem ser planejados custos primários, consumo de atividades e índices estatísticos. Os modelos
contendo as fórmulas são associados a ambientes e sub-ambientes. Cada modelo possui linhas e colunas. As linhas identificam
um tipo de objeto (ex: linha de cálculo, linha de comentário ou linha de leitura de classe de custo). As colunas define os valores
para as características a serem calculados (Ex: tipo de objeto, nome, fórmula de custos fixo, fórmula de custos variável, fórmula
de consumo de atividade fixo e variável). Nestes modelos, podem ser usados todos os dados do centro de custo, do tipo de
atividade, dos custos primários planejados, consumo de atividade planejadas, volume de atividade e capacidade para todas as
relações centro de custo / tipo de atividade e índices estatísticos.
KPT6 – Custos e índices estatísticos
KPPS – Consumo de atividade
21.5.3.9 KP96 – Ativar integração
Esta funcionalidade garante que todos os registros de dados planejados para uma determinada área de contabilidade de custos /
versão / ano fiscal seja atualizadas como partidas individuais na interface FI/CO. Esta funcionalidade está disponível não
somente no menu de Centros de Custos como de Ordens Interna e ABC. A integração pode ser ativada em qualquer um deles.
A integração deve ser ativada quando os dados da Contabilidade de Custos de Custos forem distribuídos a outras aplicações (
como Special Ledger ou Centro de Lucro) e se desejar que sejam gravadas as partidas individuais para cada alteração efetuada
nos dados planejados. Uma vez ativada, a geração das partidas individuais será automática.
21.5.3.10 KP95 – Reavaliar planejamento manual
Esta funcionalidade permite corrigir os valores planejados manualmente numa determinada data de acordo com a variação
cambial. Antes de executar esta função, é preciso definir em qual moeda os custos e as tarifas deverão ser gravados após a
reavaliação.
21.5.4 Accrual - Provisões (Accrual Calculation)
Os lançamentos de provisões podem ser feitos através de recurring entry transaction em FI transferidas para CO através de uma
classe de custo de alocação de provisão especial ou calcular a provisão em CO a partir de custos lançados. Neste caso, pode-se
usar o método PERCENTAGE ou TARGET=ACTUAL.
O método da percentagem consiste em definir uma taxa percentual a ser aplicado os custos planejados para determinadas
classes de custo ou um determinado grupo de classe de custo. Pode ser usado, por exemplo, para provisão de férias. O débito é
gerado contra o centro do custo e o crédito é lançado no objeto de provisão definido (centro de custo ou ordem interna). Os
custos reais incorridos em FI serão lançados para este objeto de provisão para permitir comparações.
Os lançamentos serão feitos em uma classe de custo de provisão (categoria 3) e os critérios para os cálculos é cadastrado na
Overhead Structure (Esquema de Cálculo de Custos). É possível determinar o cálculo de provisão sobre outro valor
provisionado, por exemplo, poderia ser definida uma provisões adicional sobre a provisão de férias considerando-se custos com
benefícios.
O método target=actual é usado para o cálculo de provisão de custos dependente ou independente da atividade. O R/3 usa o
custo real para calcular o custo target e gerar o lançamento novamente usando uma classe de custo específica para provisão
(activity-dependent total costs - cost element type 4). Este método é útil se os custos a serem alocados puderem ser planejados
CONTROLADORIA 151 de 325
periodicamente. Quando se tratar de custos independente da atividade, não é feito o cálculo do custo target, é usado o próprio
custo planejado para efetuar o lançamento.
21.5.5 Índices estatísticos – (Statistical Key Figures)
Os índices estatísticos podem ser planejados para fins cálculo de índices para o centro de custo (com, por exemplo, custo por
empregado) e para funcionar como critérios de alocação do ponto de vista do receptor (distribuição, rateio) ou configuração de
key figures (índices) para relatórios. Podem ser planejados em conjunto com os centros de custos ou os tipos de atividade. O
layout disponível para índice independente da atividade é o 1-301 e dependente o 1-302 (perfil SAPALL)
Planejar índices estatísticos (como, por exemplo, número de funcionários) tem por objetivo efetuar análises estatísticas através
de relatórios (por exemplo, determinar o custo de um centro de custo por empregado) ou servir de base para alocação de custos
entre centros de custos.
Todo o processo do planejamento é efetuado visando gerar valores comparativos e permitir o cálculo mensal do preço standard
dos produtos acabados e semi-acabados. Estando a empresa trabalhando com mais de uma visão de avaliação (por exemplo,
legal e de Centro de Lucro – preço interno), e importante considerar os valores para as duas visões.
Esta transação permite definir, manualmente, valores planejados dos índices estatísticos (já previamente cadastrados) para os
centros de custos ou ordens internas (exemplo: informar o número planejado de funcionários por centro de custo). Como os
centros de custo definidos somente estarão executando um tipo de atividade, os índices estatísticos serão planejados
independentemente da atividade através do layout 1-301 para centros de custo e layout 1-601 para ordens internas.
Como o número de funcionários é um índice estatístico fixo, somente será necessário lançar o valor uma vez. No caso de
índices estatísticos com valor total, como, por exemplo, número de pedidos de compras, será necessário informar um valor para
cada período do planejamento. Além do lançamento manual, os valores planejados para os índices estatísticos podem ser
transferidos automaticamente do LIS (Sistema de Informação de Logística) através da transação KVA4. Para isto, o índice
estatístico deve estar configurado adequadamente no registro mestre (transação KK02).
21.5.6 Classe de custos (Cost Elements)
Do ponto de vista da entrada, os centros de custos são afetados quando são planejados os valores dos custos primários e
secundários referenciando os custos incorridos na produção da saída do centro de custo (custo dos recursos). O planejamento
dos custo primários podem ser feito de forma dependente ou independente da atividade. No planejamento independente
somente poderão ser definidos custos fixos. Pode ser usado o layout 1-101 (SAPALL) para este planejamento.
O planejamento dos custos primários e secundários por quantidade é baseado nas quantidades de atividade executadas
valorizadas de acordo com o preço da atividade aplicável para o tipo de atividade. O planejamento de custos secundários por
quantidade ( activity input planning) pode ser feito manual (layout 1-102 do SAPALL) ou automaticamente usando a alocação
indireta de atividade.
Manual – planejamento das classe de custo primárias e secundárias pode ser feito dependente ou independente da
atividade;
Automático – cálculo de provisões, distribuição, transferências periódicas, planejamento de fórmulas. para custo primário e
rateios, alocação indireta de atividade e planejamento de fórmulas. para custos secundários. Os valores são definidos com
base nas regras definidas pelos usuários. Para fins de planejamento, os únicos custos primários que podem ser transferidos
para um centro de custo são custos oriundos de HR e AM.
O objetivo do planejamento de custos primários é planejar os custos primários para os diversos centros de custo e ordens
internas e o consumo de atividades dos centros de custos ou ordens (receptores) como é o caso, por exemplo, dos centros de
custos produtivos em relação aos serviços de manutenção.
Custos primários são os custos referentes a materiais consumidos, máterias-primas, folha de pagamento, serviços de terceiros,
etc. que normalmente serão gerados fora do módulo de CO. Os custos secundários referem-se à alocação de custos entre
diferentes objetos dentro do módulo de CO e tem funções específicas para cada tipo de alocação.
Todo o processo do planejamento é efetuado visando gerar valores comparativos e permitir o cálculo mensal do preço standard
dos produtos acabados e semi-acabados. Estando a empresa trabalhando com mais de uma visão de avaliação (por exemplo,
legal e de Centro de Lucro – preço interno), e importante considerar os valores para as duas visões.
Estas transações permitem definir, manualmente, valores planejados para os custos primários dos centros de custos e ordens
internas. Para o planejamento dos centros de custo, será usado o layout Excel e 1-101. Os custos primários podem ser
CONTROLADORIA 152 de 325
vinculados à atividade que o centro de custo está executando. Se cada centro de custo somente executar um tipo de atividade,
não será necessário fazer esta vinculação embora mesmo assim possa ser efetuada para separar custos fixos e variáveis. Porém,
é importante lembrar que, se formos trabalhar com a função de conciliação automática do plano, esta função não altera os
custos fixos (independentes da atividade). O SAP faz uma distinção entre custos fixos e variáveis. Custos fixos serão os custos
planejados sem a definição do tipo de atividade e custos variáveis serão os custos planejados dependente da atividade. Esta
classificação é usada, inclusive no cálculo das tarifas dos centros de custos separando custos fixos dos variáveis.
Cada responsável pelo centro de custo irá efetuar o planejamento de seus custos primários através planilha excel e
posteriormente estes valores serão importados para o sistema através destas transações. Futuras alterações, poderão ser
efetuadas diretamente no SAP ou pode-se, opcionalmente, reimportar as planilhas. Na reimportação (upload) todas as classes de
custo constantes da planilha terão seus valores sobrepostos. As classes não constantes, permanecerão com os valores anteriores.
Para cada centro de custo deverá ser gerada uma planilha diferente. O sistema permite importar várias planilhas de uma só vez
deste que estejam dentro de um mesmo diretório.
Para o planejamento dos ordens será usado o layout 1-401. No caso das ordens internas não se aplica o conceito de fixo e
variável.
O planejamento do consumo de atividades corresponde à previsão do total de atividade de cada centro de custo e ordem estarão
recebendo. Neste caso, não será informado valor já que o valor será calculado pelo sistema através da tarifa informada ou
calculado para o centro de custo emissor. Para este planejamento será usado o layout 1-402 para ordens e 1-302 para centros de
custo. Assim como o custo primário, o consumo de atividade pode ser planejado dependente ou independente de atividade, seno
qualssificado pelo sistema, respectivamente como variável e fixo. A parte fixa do consumo de atividade não é alterada pela
função de conciliação do plano.
Procedimentos para importação de planilha excel: destricação dos principais parâmetros:
Parâmetro Descrição
Importar file individual
X Importar diretório de
file
Importar file individual – selecionar esta opção para importar apenas a planilha
de um centro de custo.
Importar diretório de files – selecionar esta opção para importar todas as planilhas
dos diversos centros de custo. As planilhas devem estar num mesmo diretório.
Caminho ou file Se informado Importar file individual, informar o nome do arquivo a ser importado
com o caminho completo.
Se informado Importar diretório de files, informar o diretório (caminho completo)
onde estão as planilhas que devem ser importadas.
OBS: para ambos os casos o nome das planilhas deve seguir uma denominação padrão
iniciando com PLANCC e com terminação XLS para que o sistema reconheça a
formatação do layout EXCEL. As planilhas geradas também deverão ser geradas a
partir da planilha padrão gerada pelo R/3 (plancc.xls) conforme abaixo
Descrição de File Define o relacionamento entre as células da planilha Excel e os objetos do R/3.
Exemplo
Célula B3 centro de custo
Coluna A/linhas 6 a 20 classes de custo
Não é necessário informar, o sistema irá determinar a descrição a partir do nome da
planilha. Por isto, o nome da planilha deve seguir o padrão pre-estabelecido.
Representação decimal Indicar se na planilha o separador de decimais é a vírgula ou o ponto
Separador em files CSV Não se aplica
Descrição dos campos da planilha:
Campo Descrição
Classe de Custo Informar a classe de custo que será planejada
CONTROLADORIA 153 de 325
Campo Descrição
Custos planejados fixos Corresponde à parcela do custo do setor que independente de atividade.
Informar o valor planejado fixo para a classe de custo.
OBS: A separação de fixos e variáveis é puramente documental, não tem nenhum
efeito sobre os cálculos.
Custos planejados
variáveis
Corresponde à parcela do custo do setor que dependente de atividade executada por
ele.
Informar o valor planejado variável total para a classe de custo.
CD (Chave de distribuição)
Determina a forma de distribuição do valor informado no campo anterior entre os diversos períodos constantes no intervalo informado na primeira tela. Selecione a mais adequada à sua necessidade:
Manual – indica se será informado manualmente período a período;
Uniforme – divide o valor igualmente para os períodos;
Análoga – distribui conforme distribuição prévia;
Percentual – o valor informado é considerado percentual e é aplicado a valores
prévios;
Valores p/períodos seguintes sem valor – distribui os valores dos períodos com
valor para os períodos subsequentes sem valor;
Copiar p/períodos seguintes sem valor – copia o valor planejado de um período
para os períodos subsequentes sem valor;
Análoga ao número dias do período – distribui os valores proporcionalmente ao
número de dias do calendário de cada período;
Análoga ao volume de atividades planejada – distribui de acordo com o volume de
atividades planejado para o centro de custo.
Consumo planejado
fixo / variável
Opcionalmente, o sistema permite informar uma quantidade associada ao valor do
custo planejado para emissão em relatórios também distinguindo fixo e variável.
OBS: As quantidades de consumo podem ser planejadas posteriormente.
Un Unidade de medida referente ao conusmo de atividade
Opcional
Q Determina se o sistema emite uma mensagem se não for informada a quantidade ou unidade de medida nos lançamentos de compromisso ou reais.
OBS: O código não tem qualquer efeito sobre o planejamento.
É preciso definir o código quando, no cálculo de custos, se pretende calcular uma
sobretaxa em função da unidade de medida lançada com esta classe de custo.
E Indica se existe um não um texto descritivo cadastrado para este planejamento
21.5.7 Tipo de Atividade (Activity Type)
Planejar uma atividade significa definir a saída ou o volume de um centro de custo. Pode ser planejada também a capacidade
requerida para a fornecimento para cada tipo de atividade.
Manual – Entrada manual das quantidades e preços planejados para as atividades;
Automatic – valorização durante a alocação sendo que este preço pode ser sobrescrito pela rotina de Cálculo de preço da
atividade (conforme parametrização). A Alocação indireta de atividade (alocação inversa) ocorre quando é necessário
obter informação do centro de custo receptor para determinar os valores dos custos a serem distribuídos.
O objetivo desta funcionalidade é planejar o volume de atividades a serem efetuadas pelos centros de custo para outros centros
de custo, ordens internas ou outros objetos de custo como ordens de produção, etc. Para valorizar as atividades pode-se, através
desta mesma função informar manualmente um valor de tarifa (parte fixa e variável) para as atividades ou, através da função de
determinação automática, solicitar que o sistema efetue o cálculo (transação: KSPI).
CONTROLADORIA 154 de 325
Note que o volume total de atividade aqui definido para cada relação centro de custo/tipo de atividade deve coincidir com o
somatório do consumo de atividades planejadas pelos centros de custos ou outros objetos de custo receptores. O R/3 possui uma
ferramenta para facilitar a conciliação ajustando a quantidade dos emissores ao somatório dos receptores.
Todo o processo do planejamento é efetuado visando gerar valores comparativos e permitir o cálculo mensal do preço standard
dos produtos acabados e semi-acabados. Estando a empresa trabalhando com mais de uma visão de avaliação (por exemplo,
legal e de Centro de Lucro – preço interno), e importante considerar os valores para as duas visões.
As transações desta funcionalidade permitem definir, manualmente, valores planejados para o volume de atividade prestada
pelos centros de custo (uma ordem interna não pode prestar uma atividade) emissores (exemplo: manutenção, refeitório, etc.) e,
opcionalmente, informar uma tarifa para valorizar estas atividades planejadas.
Aqui, estamos fazendo o planejamento do serviço prestado. Nas transações (KP06 e KPF6) fazendo o planejamento dos
serviços recebidos. Obviamente, estes dados devem ser compatíveis, ou seja, o somatório dos serviços recebidos por cada
relação centro de custo/tipo de atividade, deve coincidir com o volume planejado para esta mesma relação. Em casos de
planejamento descentralizado, onde a pessoa que planeja a prestação do serviço não é a mesma que planeja o recebimento, o
sistema possui uma ferramenta para efetuar a conciliação dos dois planejamentos. O sistema irá ajustar a quantidade de
atividade planejada para o centro de custo emissor de acordo com o somatório dos receptores. Naturalmente fará os ajustes no
planejamento dos custos e consumos de atividade deste centro de custo proporcionamente ao ajuste da saída. Esta função trata
também a recursividade.
Um mesmo centro de custo pode executar mais de uma atividade.
No caso dos centros de custo produtivos, o volume total de atividades pode ser atualizado automaticamente pelo sistema através
do somatório das necessidades geradas pelo MRP.
21.5.8 Conciliação automática do planejamento
21.6 Análise de Desvios (Variance)
22 Ordens Internas
22.1 Dados mestre
Object Class – de acordo com as necessidades da empresa os objetos e as unidades organizacionais dentro de CO serão
atribuídos às seguintes classes:
Overhead Cost Management (Cost center)
Product Cost Control (Cost Object)
Investment Control
Sales Management (Profitability segments)
Enquanto certos objetos de CO são atribuídos a uma classe de custo particular (por exemplo: centros de custo são atribuídos a
OCM), outros, tais como ordens e projetos, tem sua classe definida no cadastro básico (dados mestre). Uma ordem interna
pode pertencer a qualquer uma destas classes.
CONTROLADORIA 155 de 325
22.2 Event-based postings
22.3 Fechamento do Período
22.4 Planejamento e Orçamento
Geralmente o planejamento é feito na moeda da Área de Contabilidade de Custos.
Controle de Disponibilidade (Availability Control) – define os limites de tolerância de utilização de verba do orçamento.
Posteriormente será vinculado ao tipo da ordem. Pode gerar três ações: (1) uma mensagem de alerta, (2) aviso + sap-mail (aviso
na tela mais o envio de uma mensagem para o gerente definido para o tipo de ordem) e/ou (3) uma mensagem de erro
dependendo os percentuais alcançados em relação à verba predefinida. Após atingir o percentual definido para a mensagem de
erro não será mais permitido fazer lançamentos para a ordem. O R/3 permite definir mais de um gerente para um mesmo tipo de
ordem. Todos receberão o e-mail de aviso.
22.4.1 Planejamento Global (Overall Planning)
Fomra mais importante e fundamental de planejamento da ordem. Este tipo de planejamento é independente das classes de
custos. É usado para estimar os custos da forma como serão incorridos na ordem. Não aparecem nos relatórios como custos
planejados e não podem ser apropriados para outros objetos. O planejamento global é sempre feito na moeda da Área de
Contabilidade de Custos. O sistema atualiza os custos e as quantidades planejadaos (assim como os custos reais). Estes custos e
quantiade permanencem variáveis. Isto se aplica tanto a custos primários como secundários.
22.4.1.1 Estrutura temporal
O planejamento podem ser geral ou anual (dependente do exercício). Ao entrar na transação é proposto o ano fiscal de início
definido no perfil do planejador de planejamento global.. O perfil do planejador é definido no mestre de tipo de ordem.
O planjemado pode ser feito em um período futuro e ou passado. Planejamento de anos anteriores podem ser usados, por
exemplo, para transferir valores de sistemas anteriormente usados antes da implantação do SAP guardano histórico da
informações e permitindo uma análise mais precisa de todo o planejamento da ordem.
O R/3 permite verificar se o somatório dos valores anuais planejados ultrapassou o valor global planejado. Dentro do
planejamento global podem ser chamadas as transações de Custo Unitário, Planejamento de Receitas e Custos Primários e
Planejamento de Índices Estatítiscos.
22.4.2 Sumarização da Ordem
As ordens podem ser sumarizadas em um grupo para serem analisadas em conjunto. Utilizando-se as características de
sumarização são criados registros de totais. É muito útil quando se trabalha com um número muito grande de ordens. A
estrutura para análise é definida hierarquicamente. Cada nível da hierarquia corresponde a uma característica. A Área de
Contabilidade de Custos é sempre o primeira nível da hierarquia. Pode ser feita a sumarização tanto dos custos (planejados,
reais, variações, dados de análise de resultados) e quantidades (entrada e saída).
A hierarquia define, então, quais os campos (campos de cadastros básicos predeterminados) serão sumarizados e para quais
objetos deverão ser sumarizados. Pode ser usado, inclusive, campos específicos incluídos pela empresa. É importante observar
que depois de sumarizado se uma nova ordem for incluída, ela não aparecerá na hierarquia. Será necessário reprocessar a
sumarização.
A sumarização pode ser executada em background ou processamento paralelo caso o número de ordens seja muito grande. O
sistema de informação possui relatórios prontos para sumarização de ordens.
23 Schedule Manager
O Schedule Manager é uma ferramenta do R/3 útil na execução do fechamento de período seja custeio por ordem ou por
período de forma rápida e eficiente, executando as funções de cálculo de custos de overhead, de WIP, de variação e liquidação
CONTROLADORIA 156 de 325
em background (jobs) agrupados de forma a permitir análises de erros após o processamento. Resumindo, o Schedule Manager
permite automatizar o processo de fechamento (somente a partir da versão 4.6).
Não é uma ferramenta exclusiva de CO podendo ser usado em qualquer módulo para definição e scheduling de passos do
processamento, monitoramento de jobs e verificação de resultados e correção eficiente de erros. Permite executar qualquer
transação, mesmo que ela não esteja disponível para executar em background, ou seja, podem ser executadas transações on-
line, permitindo, assim, fazer um acompanhamento mais próximo do processo.
23.1 Componentes
Os componentes do Scheluder são: lista de tarefas, revisão diária, revisão mensal.
A lista de tarefas é uma estruturação (em árvore) das atividades (tarefas) encadeadas a serem executadas no final do período
seja por um ou mais usuários. Para cada transação podem ser anexados documentos microsoft office ou mesmo textos simples.
As tarefas podem ser um programa ABAP, um fluxo (flow definition – background job chains), transações e programas on-line,
jobs individuais (programs with variant) , notas descrevendo atividades não processada no R/3.
Flow definition – Fluxo predefinido (passo a passo) usando ferramentas de workflow (fluxograma) que inclui agendamento de
programas com variantes como jobs, interações com os usuários sap-mails). O SAP fornece flow definition padrões a serem
customizados.
Job monitor – Ferramenta para gerenciamento do processamento dos jobs (status e mensagens). É dividido em três áreas:
Structure tree – apresenta os workflows em ordem cronológica e os jobs que serão executados dentro um certo período
fornecendo informações do status dos jobs, o runtime, e o nível de atualização.
Visão detalhado do job – lista a fila de jobs, log dos jobs batch, extract (apresentação online da lista de resultados gravada),
lista básica.
Lista de Mensagens – mensagens geradas e gravada para os jobs.
Lista de tarefa multi-nível - Conjunto de objetos a serem processados. Permite reprocessar somente os objetos com problema
dentro da Lista de Tarefas gerenciando pelo Job Monitor. Acelera o processo. É gerada para um seqüência de passos do
processo especificados em um flow definition. Está disponível para coletores de custo de produto, ordens de produção, ordens
de processo, ordens e elementos PEP.A seleção do escopo é determinado uma única vez e é válida para todo o processo
enquanto a worklist contém os objetos permitidos e necessários para a execução do passo corrente. Podem ser especificadas
restrições no escopo para passos individuais sendo, normalmente, definidos os perfis de seleção especificadas na criação da
variante de relatório.
Cada passo do processamento é executado na seqüência especificada no fluxo no scheduler. O status do processamento (indica
se o objeto pode ser processado no passo seguinte) é mostrado no worklist para cada objeto e cada passo.
Worklist monitor – Permite editar as worklist analisando as mensagens para cada objeto e função, visualizar o status de
processamento retornados pelo sistema para cada objeto e função e manualmente, permite alterar estes status.
23.2 Benefícios
A Worklist permite reduzir o tempo necessário para o processamento através de:
Eliminação da interação manual após a execução de um job substituindo-a por uma interação para grupo de jobs
interrelacionados;
Possibilita o reprocessamento apenas do objeto realmente com erro;
Redução do tempo de CPU pela seleção coletiva dos objetos (vários passos), principalmente, em estruturas que envolvem
objetos mutualmente dependentes (projetos complexos).
Envio de sap-mails para permitir um intercâmbio ágil entre as áreas de processamento do fechamento do período e os
usuário responsáveis pela tomada de decisão.
24 Basics of the Report Painter
CONTROLADORIA 157 de 325
25 ASAP
25.1 ASAP Overview: Topics
25.2 Implementation Roadmap: Topics
26 Product Cost Planning
26.1 Introdução
Planejamento de materiais e estimativas de custo, simulação de custos (para desenvolvimento de novos produtos) tendo como
principal objetivo a geração do custo padrão. A partir da versão 4.5 é sugerido controlar até mesmo as matérias-primas como
padrão (standard). O custeio real irá fazer um ajuste no final do mês para atender a legislação tanto para FI como para CO
(material ledger).
Para valorizar as movimentações em Logística, o R/3 considera a Área de Avaliação que determina o nível organizacional para
valorização do material. Para valorizar o custeio de material, portanto, cada centro é definido como uma área de valorização.
Assim, o cálculo do custo de produto é sempre individual por centro para permitir diferenciar os custos de fábricas diferentes.
O Planejamento procura atender a todas as fases do ciclo de vida do produto fornecendo inicialmente ferramentas ágeis e
flexíveis para estimativas de custos usando produtos e estruturas similares (se for o caso) e sem a necessidade de grande
alimentação de dados cadastrais. Nesta fase, Custo Unitário (sem o código do produto) e Custo Unitário multi-nível (com o
código do produto) são os métodos ideais. Os dados são extraídos do Base Planning Object (dados mestre de CO).
Na fase de especificação e projeto as estimativas são refinadas. Na fase de protótipo, são cadastradas as listas técnicas
aumentando a integração com Logística que complementa as informações (com a integração pode-se usar a Estimativa de custo
com estrutura quantitativa). Na fase de maturidade de mercado a integração com logística é total.
O cadastro de materiais (mestre de materiais, material, item mestre, produto e montagem) possui diversas visões. As visões
importantes para CO são MRP (status, scrap factor, special procurement, indicadores de co-produto e bulk material (consumo a
granel – não relevante para custo, versão de produção(ligada a definição de roteiro – linha de produção)), Contabilidade
(valorização de material, controle de preço, determinações contábeis) e Custos (parâmetros de custeio, informações para Cost
Objeto Controlling).
26.1.1 Mestre de Materiais
A nível de dados gerais, o cadastro de materiais possui informações do tamanho padrão do lote, da unidade de medida básica
(considerada para CO) e descrição. A nível de contabilidade, possui as informações para determinação de custos indiretos:
classe de avaliação (que juntamente com o tipo de movimentação define a conta contábil), grupo de origem (campo de
utilização livre que permitirá subdividir os materiais na definição dos componentes de custos – visão sintética gerencial dos
custos – subgrupo das classes de custo) e grupo de overhead (define a overhead key e, consequentemente, a sobretaxa para
determinação de custos indiretos).
A determinação da taxa de custos indiretos é definida segundo o seguinte procedimento: Com base na variante de avaliação, o
R/3 determina o Esquema de Cálculo de Custos, e irá selecionar a linha destes esquema que estiver vinculada à Chave de
Overhead do material determinado através do Grupo de Overhead.
O tipo de material define se uma visão de custos é permitida para o material e contém valores propostos para o material. O tipo
de material divide os materiais em: matéria-prima, semi-acabados, acabados, Trading goods, Operating supplies. Determina o
tipo de aquisição e controla a seqüência de telas, a seleção de campos, o número de tipos de associações na manutenção do
cadastro e determinações contábeis.
Dentro das visões de custeio e contabilização estão as informações de preço:
Preço planejado 1, 2 e 3 – usado para matérias-primas e componentes comprados para valorização em estimativas de custo
CONTROLADORIA 158 de 325
Tax-based e comercial price – usado para componentes comprados para valorização do estoque (determinação do menor
valor) e guardar os resultados do custeio para produtos acabados e semi-acabados nestes campos.
Controle de Preço - Padrão (S) ou Média móvel (V). A definição de V na verdade determina que será usada uma variant e
nesta variante está determinado a média móvel ponderada. O cálculo do média móvel para produto acabado funciona da
seguinte maneira. Durante o período, as entradas no estoque são feitas com base no padrão. No final do período, através do
ledger de materiais, é calculado o custo real e a variação é enviada proporcionalmente para o estoque e o resultado (conta
de variação de preço) conforme a quantidade em estoque.
Na criação de um novo produto é usual manter o seu status inativo até que tenha sido custeado.
Para o processamento coletivo, o R/3 fornece a transação “CK40N – Processar execução de Cálculo de Custos (Costing Run)
que agrupa todos os passos necessários para o cálculo e atualização do preço standard. No processamento coletivo, o tamanho
do lote não pode ser alterado.
26.1.2 Informações básicas para o cálculo do custo
Estrutura quantitativa
BOM (Bill of Material) – lista técnica – relaciona o material necessário. Não possui informações de valor, somente de
quantidade. A escolha da BOM está vinculada ao status (01=ativo; 02 = inativo; 03 = ativo com history requirements)
e a utilização (1 – produção; 2-engenharia e desenvolvimento de produto; 3-universal; 4-manutenção; 5-vendas e
distribuição; 6-custos; 7-returnable packing).
Roteiro – Custos de fabricação – não possui informações de valor somente de quantidade de atividade. Os custos de
produção são gerados a partir de informações vindas de PP, CO-CCA ou CO-ABC.
Variante de Cálculo de Custo (Costing Variant) – define as regras para a valorização da estrutura quantitativa (preço
médio móvel, preço de reposição (última compra), standard e planejado). A escolha irá depender do objetivo no cálculo do
custo definindo um variante diferente para cada um. Para valorização do roteiro pode ser usado uma média anual, o valor
do período.
Custos indiretos – a alternativa mais comum era a Costing Sheet. Atualmente, tem sido uma tendência definir uma
atividade dentro do roteio para alocação destes custos. Normalmente para custo indireto é usado o backflush (sem
apontamento manual).
Esquema de Cálculo de Custos (Costing Sheet) – define como os valores lançados no R/3 serão calculados. Compõe-se de
linhas de base, cálculo e totais. A base define o montante sobre o qual o custo indireto (sobretaxado) será calculado. É definido
a partir de um outro lançamento. A linha de cálculo define o percentual a ser aplicado e o crédito a ser efetuado e a linha de
total sumariza tanto linhas de base como de cálculo para ser utilizadas como base de cálculo de novas sobretaxas. Pode ser
usada em CO-OPA (Overhead Orders) e em CO-PC para cálculo de custos indiretos e em CO-PA para valorização dos campos
de valor.
Permite o cálculo do planejamento para tamanhos de lotes diferentes.
Visões diferentes – diferentes critérios de alocação de custos:
(1) considerando somente os custos de produção;
(2) considerando esforço de vendas;
(3) somatório de um e dois, etc.
Podem ser geradas diferentes estimativas de custos gerando resultados diferentes para cada uma das combinações dos seguintes
campos (código do material, centro, variante de custeio, data de validade e versão de produção.
26.1.3 Esquema de Elementos (Cost Component)
Através de configurações na Implantação, o usuário pode agrupar os custos em componentes sumarizando as informações do
ponto de vista gerencial. Não é hierárquico. É base para levar informações para CO-PA (campos de valor). Toda formação de
custos de material passa por uma conta, seja classe de custo primária ou secundária. Tem disponível um relatório da abertura
dos custos por classe de custo.
O objetivo do cost rollup é garantir que todos os materiais estejam incluídos no custo do produto no nível zero da BOM. Para
tal, é feita uma associação dos custos de uma estimativa de custo com os componentes de custo. Para cada componente, a
estratificação fornece informações sobre o valor adicionado do material dos custos dos materiais subordinados. Até 40 campos
CONTROLADORIA 159 de 325
de custo podem ser rolled up em uma esquema de elementos (cost component split). Um componente de custo conter custos
fixos e variáveis. Cada linha de uma itemização é associada uma um componente de custo como definido na estrutura de
componente de custo.
Nível Produto Consumo Matéria-prima
No nível Acumulado
0 A 10 40
1 B 20 30
2 C 10 10
A visão de Composição do custo consiste em uma combinação de componentes de custos de acordo com várias características.
Gera um filtro no SI de forma que somente os dados associados à visão podem ser apresentados. No cabeçalho de estimativas
de custos, podem ser apresentadas até 5 visões como um resultado de custo inicial. Estas visões são configuradas em Settings
menu. As visões se aplicam a Esquema de Elementos, itemização e lista técnica multi-nível valorizada.
26.2 Bens tangíveis e intangíveis.
Os bens tangíveis correspondem ao produtos fabricados interna ou externamente. Estes bens possuem uma estrutura
quantitativa (BOM + Roteiro ou Recipe (receita mestre)), aquisições externas de matérias-primas e beneficiamentos,
subcontratações, inventário, preços podendo ser definidos em diferentes cenários (make-to-order, make-to-stock, engineer-to-
order production). O planejamento de custo é independente do cenário. Os dados serão gravados nos componentes de Logística
(PP, PP-PI e MM) e acessados por CO. A estimativa de custo pode ser usada para valorização de estoque e comparações.
Os bens intangíveis correspondem aos serviços e processos internos, serviços contratados fora, não tendo, portanto, estoque
(exemplo: remessa, telecomunicação, consultoria, treinamento, etc.)
26.3 Variante de Cálculo de Custo (Costing Variant)
Special Quantity Structure Control – determina se pode será considerado o tamanho do lote dos componentes no cálculo
de estimativa do item pai. Assim, se for definido como sempre, será considerado o tamanho do lote do pai. Por exemplo, se
para fabricar um determinado item for necessária a fabricação de 1000 componentes e o tamanho ideal do lote do
componente for 100, o sistema irá considerar a fabricação de 1 lote de 1000. Se for definido não, o tamanho do lote do
componente considerado para a valorização será o definido no mestre de materiais. No exemplo, será calculado 10 lotes de
100, ou seja, 10 tempos de preparação. Se for definido somente para materiais com necessidades individuais, também será
considerado o lote do pai para estes materiais. No custeio de ordens de vendas e recomendado sempre. O campo pass on lot
size não é considerado no caso de processamento coletivo, somente no cálculo da estimativa de custo individual.
Custos adicionais (Additive Cost) – custo adicional que pode ser lançado para um material em uma Estimativa de Custo
Unitário (planilha de custos) para ser incorporado ao custo do material no cálculo de uma estimativa de custos. É usado,
por exemplo, para incluir custos de fretes e seguros para matérias-primas quando não for informado no Info record de
compras.
Update – determina se será permitido criar a estimativa de custo quando o cálculo usar esta variante de custos. Se for
permitido, sempre será gravado o esquema de elementos. É recomendado, porém, que sempre seja gravado também o log
de mensagens e a itemização. Sem a itemização não é possível visualizar a BOM multi-nível costeado e o relatório de
itemização. Bloquear a atualização de estimativas é válido, por exemplo, quando se define uma cost variant somente para
vendas fazer estimativas na análise de uma vendas para aprovar ou não.
Assignments – permite definir as associações entre a variante de cálculo de custos e a estrutura de componentes de custo,
versão de custeio, se o esquema de elementos está ativo na moeda da Área de Contabilidade de Custos (associa empresa /
tipo de custos (costing type) / variante de avaliação, se é necessário custeio entre empresas).Uma estrutura de componentes
de custo pode ser asociada a uma empresa / centro / variante de cálculo de custos definindo a data de validade para a
associação e a estrutura de componentes de custo auxiliar. Associação com a costing version?????.
Estrutura de Componentes de Custo 02
Seqüência Plano de Contas Classe de Custo Descrição
10 INT 400000 400010 Matéria-prima
20 INT 410000 410000 Serviços Externos
CONTROLADORIA 160 de 325
Estrutura de Componentes de Custo 02
Seqüência Plano de Contas Classe de Custo Descrição
20 INT 415000 419000 Serviços Externos
30 INT 420000 421000 Remuneração
30 INT 422000 422000 Remuneração
30 INT 430000 431000 Remuneração
30 INT 432000 432000 Remuneração
40 Outras despesas.
50 INT 466000 466000 Custos imputados
50 INT 481000 481000 Custos imputados
Estrutura de Componentes de Custos IE – auxiliar
Seqüência
auxiliar
Seqüência
principal
Descrição
10 30 Remunerações
20 30 Salários
30 40 Outras despesas pessoal
40 120 Custo de materiais
50 50 Custos imputados
Miscelâneas – gerenciamento de mensagens de erro permitindo alterar a categoria das mensagens para adequar às
necessidades da empresa. Nem todas as mensagens poderão ser alteradas para garantir a integridade dos dados.
Tipo de Cálculo de Custos (Costing Type) – determina se será permitido fazer alterações no mestre de materiais, quais os
campos podem ser atualizados, qual a data de atualização, etc..
Updade prices – determina quais os preços do mestre de materiais podem ser alterados usando-se esta Variante de
cálculo de custos com este tipo de cáluclo de custos (nenhum, preço padrão, fiscal (tax-based), comercial, todos exceto
o padrão).
OBS: Não é possível criar um tipo de cálculo de custos que atilize o mestre de materiais. Somente os tipos standard
fazem esta atualização.
Perspectiva Avaliação – define se a avaliação a ser considerada será legal (da empresa), do grupo ou de centro de
lucro (preço interno).
Cálculo de custos com estrutura quantitativa - definir se terá uma data fixa para definição da estrutura, sem data ou
considerar a do início do perído para o qual o cálculo do custos está sendo efetuado.
Cálculo de Custos adicionais
O R/3 permite visualizar as transações entre unidades organizacionais de três diferentes pontos de vista: a nível de Grupo
Corporativo, de Centro de Lucro ou de Empresa. A visão de grupo, considera a consolidação eliminando lucros entre
empresas. No ponto de vista de Centro de Lucro, as transações entre centros de lucros são reproduzidas para aproaches de
gerenciamento (definindo preços internos dentro da empresa para negociação entre os Centros de Lucro). No ponto de vista da
empresa (legal), as transferências são tratadas de acordo com as restrições legais, incluindo impostos, fretes, etc. sobre o custo
de produção que é usado na visão de grupo.
O modelo para levar os custos para o produto é determinado por material. Este modelo é encontrado dinamicamente.
Identificação: Overhead key + esquema de cálculo de custos.
Objeto Un.Med Qt. Fixa Qt. Var.
Processo –
300900
ST
Centro Custo + tipo de atividade -
4120/1414
MIN 2000 0
CONTROLADORIA 161 de 325
Objeto Un.Med Qt. Fixa Qt. Var.
Processo – 300910 ST 1000 0
Centro de custo/tipo de atividade -
4120/1414
MIN 500 0
Centro de custo/tipo de atividade -
4275/1421
H 20 0
26.4 Cálculo de Custos standard
26.4.1 CK40N - Processar a execução do cálculo de custos (Costing Run)
Esta transação pode ser usada para o processamento em massa do cálculo dos custos standard. Permite calcular, marcar e liberar
o custos de um ou vários materiais ou mesmo tempo. Assim, todos os passos necessários para o cálculo do custo standard com
estrutura quantitativa pode ser executado nesta transação.
O primeiro passo é criar uma Execução de Cálculo atribuindo um código descrição e data de execução. Em seguida, devem ser
definidos os parâmetros necessários para o cálculo: variante de cálculo de custos, versão do cálculo de custos, área de
contabilidade de custos, empresa, controle de transferência e as datas de referência (período de validade do cálculo, data base
para selecionar a estrutura quantitativa e o valor dos materiais). Deve ser informada, também, a avaliação (legal, grupo ou
centro de lucro), a variante de avaliação no cálculo dos custos, o esquema de cálculo de custos do produto principal e dos
componentes para cálculo de sobretaxas. Estes campos são preenchidos de acordo com a variante de cálculo de custos.
A variante de avaliação determina que preços serão selecionados para avaliar a estrutura quantitativa do cálculo de custos com
estrutura quantitativa ou da ordem ou para avaliar os itens de cálculo de custos do cálculo de custos unitário. Por meio da
variante de avaliação, determinar que preços são utilizados para avaliar os materiais utilizados, que tarifas são utilizadas para
avaliar as atividades internas e processos empresariais, que versões do plano devem ser utilizadas, que preços são utilizados na
avaliação do processamento externo de um conjunto ou de uma operação, que esquema de cálculo de custos é utilizado para
determinar as sobretaxas de custos indiretos.
Ainda pode ser informado o grupo de servidores RFC que deve ser utilizado peloa transação no processamento paralelo.
Status do cálculo de custos
Satus Descrição
ER Aberto
SE Selecionado sem erros
SC Selecionado com erros
KA Calculado sem erros
KF Calculado com erros
VO Marcado sem erros
VF Marcado com erros
FR Liberado sem erros
FF Liberado com erros
FM Liberado via liquidação ledger de materiais.
26.5 Produção Repetitiva
No ambiente de manufatura repetitiva, é preciso criar coletores de custos para coletar os custos de manufatura de um material.
Para carregar os coletores com preços atuais para alocação de atividades por meio de confirmações para uma versão de
produção, selecionar o flag Produção Repetitiva na visão MRP4 do mestre de materiais. Atividades só podem ser alocadas em
confirmações se este flag estiver selecionado.
No mestre de materiais também deve ser especificado um perfil de produção repetitiva. Neste são especificados:
Se deve ser efetuada a baixa de componentes por explosão
CONTROLADORIA 162 de 325
Se o ponto de contagem é obrigatório
Se deve ser feita a entrega para estoque no lançamento de dados reais do último ponto de controle.
Controle do processo de confirmação – Controla a execução do processo de confirmação. Através desta chave o usuário
pode configurar os processos que desejar executar separadamente do registro de entrada de mercadorias ou da confirmação
dos pontos de contagem. São possíveis os seguintes processos:
o registro de saída de mercadorias dos componentes
o registro de atividades
Ao executar os processos separados posteriormente, o usuário pode, inclusive, efetuar os lançamentos individuais de forma
agregada. Para executar os processos posteriormente, o usuário tem as seguintes opções:
executar no diálogo
executar na tarefa de atualização
executar em background
Caso não esteja selecionada nenhuma chave, a atualização é efetuada no diálogo.
O usuário pode definir a chave de controle de processo na transação OPKC.
A agregação é possível somente para o registro de saída de mercadorias e para o registro de atividades conjuntamente. Não é
possível agregar apenas um destes processos.
Os processos de confirmação que podem ser influenciados pelo usuário são:
a entrada de mercadorias automática (somente ordens de produção)
a retirada retrógrada
a determinação dos custos reais
Controle de erros na baixa por explosão
Definir se serão lançadas as atividades, e, neste caso se deve ser considerada as atividades planejados poara o material ou
as atividades obtidas através do cálculo de custos preliminares para o coletor.
Etc.
Tipos de movimentação em MM
Tipos de Movimento
Saída merc. 261 Saída mercadoria/estorno 262
Entrada mercad. 131 Entr.mercadoria/estorno 132
Refugo 551 Refugo/estorno 552
Subproduto 531 Co-produto/estorno 532
Tipos de Movimento adicionais p/cenário indiv.cliente
EM ord.montagem 571 EM ord.mont./estorno 572
SM estq.ind/OrdMont. 572 SM estq.ind/ord.mont./est 571
SM estq.cen/ord.mont 291 SM EstqCen/ord.mont./est. 292
A SAP faz algumas recomendações para manufatura repetitiva:
1. criar um coletor para cada versão de produção
Na criação do coletor, selecione o nível de controle de versão de produção. Se, no entanto, for selecionado o controle a nível de
Lista técnica / roteiro, a lista técnica e o roteiro do coletor devem ser os mesmo da versão de produção. Neste caso, ainda, a
esturura quantitativa da versão não poderá ser alterada posteriormente pois poderia gerar as seguintes inconsistências:
O WIP do coletor original não poderia ser reduzido e reorganizado
CONTROLADORIA 163 de 325
O novo coletor teria desvios no montante de custos carregados para o coletor original. O processo de cálculo de desvios do
segundo coletor não poduziria valores reais.
2. Criar um estimativa de custos preliminar para o coletor
3. Mantenha as quantidades de atividade que deverão ser confirmadas como default baseado no roteiro usado para a
estimativa de custos preliminar.
4. Valorize o WIP e o refugo com base na estimativa de custos preliminares para o coletor.
ACC Ver D.R Chave D.R Status n. status Tipo de Determinação de Resultados
CTS 0 000002 LIB 2 Determinação WIP com base nos custos reais
CTS 0 000002 LBPA 1 Determinação WIP com base nos custos reais
CTS 0 000002 FORN 3 Explodir dados da determinação WIP e de resultados
CTS 0 000002 ENTE 4 Explodir dados da determinação WIP e de resultados
CTS 0 000003 LIB 2 Determinação WIP com base nos custos teóricos
CTS 0 000003 LBPA 1 Determinação WIP com base nos custos teóricos
CTS 0 000003 FORN 3 Explodir dados da determinação WIP e de resultados
CTS 0 000003 ENTE 4 Explodir dados da determinação WIP e de resultados
CTS PCA 000002 LIB 2 Determinação WIP com base nos custos reais
CTS PCA 000002 LBPA 1 Determinação WIP com base nos custos reais
CTS PCA 000002 FORN 3 Explodir dados da determinação WIP e de resultados
CTS PCA 000002 ENTE 4 Explodir dados da determinação WIP e de resultados
CTS PCA 000003 LIB 2 Determinação WIP com base nos custos teóricos
CTS PCA 000003 LBPA 1 Determinação WIP com base nos custos teóricos
CTS PCA 000003 FORN 3 Explodir dados da determinação WIP e de resultados
CTS PCA 000003 ENTE 4 Explodir dados da determinação WIP e de resultados
Status Descrição
LIB Liberado
LBPA Liberado parcialmente
FORN Fornecida
ENTE Encerrado em termos técnicos
Esta configuração é feita no Customizing para Controlling periódico dentro de Encerramento de período SIP definir
variante de avaliação para WIP e refugo ou dentro de Encerramento do período cálculo de desvio definir variante de
avaliação para WIP e refugo.
Se o ponto de contagem (reporting point structure for alterado, usar os pontos de contagem flexiíveis para atualizar a estimativa
de custos preliminar.
Read the following sections:
Flexible Reporting Points
Updating the Preliminary Cost Estimate
If the production environment is repetitive manufacturing on a sales order basis, read the following sections:
Product Cost Collectors in Sales-Order-Related Production (valuated sales order stock)
Sales-Order-Oriented Repetitive Manufacturing (Nonvaluated Sales Order Stock)
Goods Receipts for Sales Orders (in repetitive manufacturing)
There are a number of special aspects to be noted regarding actual costs in repetitive manufacturing. For more information, refer to the section Actual Costs in Cost Object Controlling.
CONTROLADORIA 164 de 325
26.6 Cálculo de WIP e refugo
26.6.1 Chave de Determinação de Resultados (Results Analysis Keys)
Para valorizar material em processo (WIP), a ordem precisa ter uma chave de determinação do resultado. A chave de
determinação do resultado pode ser gravada como um valor proposto para cada tipo de ordem ou centro e pode ser alterada para
cada ordem.
O método de avaliação é definido através da combinação da área de contabilidade de custos com a versão de determinação do
resultado, a chave de determinação do resultado e o status.
Adicionalmente tem-se a possibilidade de atribuir as classes de custo de origem para cada chave de determinação do resultado -
sob as quais uma ordem é debitada - a diferentes identificações de linhas e atualizar assim as datas de determinação do
resultado sob as diferentes classes de custo da determinação do resultado. Isto pode fazer sentido no caso de se trabalhar
paralelamente com vários métodos de determinação do resultado. No cálculo do WIP relativo a custos reais no controlling de
produtos por ordem e na determinação do resultado no controlling de ordem do cliente segundo a determinação do resultado, as
datas de determinação do resultado serão sempre atualizadas segundo a versão de determinação do resultado 0. Para poder
possibilitar diferentes grupos de custos, atualizar as datas de determinação do resultado em dependência da chave de
determinação do resultado. Na versão de determinação do resultado pode-se definir se as datas de determinação do resultado
são atualizadas em dependência da chave de determinação do resultado.
No sistema standard SAP existem já chaves de determinação do resultado predifinidas. A SAP recomenda utilizar uma destas
chaves.
No caso de não querer utilizar as chaves de determinação do resultado, criar novas chaves de determinação do resultado da
seguinte maneira:
Entrar um texto correspondente para as novas chaves de determinação do resultado.
Inscrever a chave de determinação do resultado como valor proposto para o tipo de ordem relevante e o centro relevante.
A determinação WIP serve para determinar o valor do material em processo no controlling por período de objeto e no
controlling do objeto por ordem. A determinação WIP no controlling de objeto por período/ordem é inserida, sobretudo na
produção para estoque, na produção por ordem de cliente com estoque avaliado de ordem de cliente e na produção por projeto
com estoque avaliado de projeto.
26.6.1.1 Estoque especial não avaliado
Caso se trabalhe com o estoque não avaliado de ordem de cliente ou com o estoque não avaliado de projeto, o material em
processo é determinado para ordens, atribuídas a um item de documento de vendas e distribuição ou a um projeto, normalmente
por meio da determinação do resultado para o item de documento de vendas e distribuição ou para o projeto.
Mas com o código Calcular WIP para ordens de produção na produção por ordem de cliente ou Calcular WIP para ordens de
produção na produção por projeto na versão da determinação do resultado, é possível especificar que se pode determinar
material em processo separadamente para as ordens atribuídas. Neste caso, é decisiva a indicação de uma chave de
determinação do resultado na ordem:
Se não estiver inscrita qualquer chave de determinação do resultado para a ordem, são considerados os custos reais
para a ordem durante a determinação do resultado para a ordem de cliente ou para o projeto. A apropriação de custos é
feita por meio da ordem de cliente ou do projeto.
Se estiver inscrita uma chave de determinação do resultado para a ordem, é constituído e apropriado material em
processo no valor dos custos reais incorridos, para a ordem. Estes custos não são considerados durante a determinação
do resultado para a ordem de cliente ou para o projeto. Este procedimento é recomendado, principalmente, durante a
produção interempresarial.
Por meio da classe de necessidade, é controlado se um estoque de ordem de cliente ou um estoque de projeto é administrado de
forma avaliada ou não avaliada.
CONTROLADORIA 165 de 325
26.6.2 Versão de Determinação de Resultado
Todos os dados da determinação do resultado (WIP de coletor WIP e provisões para custos não realizados para ordens de
produção) calculados por meio da determinação WIP, são atualizados na ordem, com referência à versão da determinação do
resultado. Assim, é possível determinar o material em processo paralelamente, com base em várias versões da determinação do
resultado. Isto significa que, em função da versão da determinação do resultado,
é possível configurar vários processos para a determinação WIP.
É possível criar versões da determinação do resultado, paralelamente à avaliação operacional, que não se baseiam em uma
avaliação operacional, mas sim em uma versão da determinação do resultado paralela e "interna" criada para fins informativos.
Isto significa que, em função da versão da determinação do resultado,
é possível configurar vários processos para a determinação WIP
é possível definir, de forma diferente, a parte do material em processo a ativar
Se se trabalhar em países diferentes, é possível definir, por exemplo, várias versões da determinação do resultado para estar de
acordo com as normas legais de cada país.
é possível determinar, no controlling de objetos por ordem , o material em processo para os custos reais até três
perspectivas paralelas de avaliação.
Na alocação de preços internos, é possível determinar os dados da determinação do resultado nas perspectivas de avaliação
seguintes:
na perspectiva legal
na perspectiva de grupo de empresas
na perspectiva de centro de lucro
OBS: No controlling periódico de produtos, o material em processo para custos teóricos é sempre determinado na avaliação
operacional.
26.6.2.1 Controle simplificado
No controle simplificado, a versão da determinação do resultado exibe
as visões de avaliação (legal, grupo, preço interno) que atualizam os dados de determinação do resultado;
Se a empresa não trabalhar com os preços internos, a versão da determinação do resultado é sempre executada na avaliação
operacional. As versões de determinação de resultados de visões paralelas de avaliação são sempre versões reais e referem-se à
versão da determinação do resultado das avaliações operacionais.
se os dados são transmitidos à contabilidade financeira
É possível transmitir as versões da determinação do resultado de várias perspectivas de avaliação à contabilidade financeira. Se
a contabilidade de centros de lucro está ativa, é possível criar, com base na apropriação de custos, na contabilidade financeira,
um lançamento adicional para o material em processo na contabilidade de centros de lucro, quando um centro de lucro é
inscrito na ordem.
26.6.2.2 Controle ampliado
Com o controle ampliado é possível selecionar, entre outras coisas, se
se será determinada separadamente e comprovada a constituição e o consumo do material em processo ou das
provisões para custos não realizados;
se será permitida a criação de uma partida individual por lançamento;
se será permitida a transferência de dados de sistema anterior;
será permitida a eliminação dos dados da determinação do resultado determinados com uma versão da determinação
do resultado;
CONTROLADORIA 166 de 325
se serão atribuídas as classes de custo a diversas identificações de linha, por chave de determinação do resultado. Para
definir regras diferentes para WIP para cada chave de determinação do resultado, é necessário definir o código
Atribuição chave de determinação do resultado na versão da determinação do resultado.
Se serão atualizados os dados de determinação do resultado com classes de custo da determinação do resultado
próprias, por chave de determinação do resultado.
Calcular WIP para
Ordens durante produção para ordens de clientes - é possível determinar, em separado, material em processo,
durante a produção por ordem do cliente com estoque não avaliado de ordem de cliente para as seguintes ordens
atribuídas a um item de documento de vendas (item de uma solicitação de cotação, de uma cotação ou de uma ordem
do cliente):
Ordens de produção
Ordens internas sem receita
Ordens sem receita na administração de serviços (ordens de manutenção, ordens de assistência, etc.)
Este flag só tem relevância, na produção da ordem por cliente, caso se trabalhe com o estoque não avaliado da
ordem do cliente e é importante, sobretudo, caso se execute uma produção interempresarial.
A condição para considerar o código é a gravação de uma chave de determinação do resultado no item de documento
de vendas e distribuição atribuído à ordem ou em um item superior a este item de documento de vendas e distribuição.
Caso esta condição não seja satisfeita, o material processo é sempre determinado, independentemente de o código estar
definido ou não.
Se este flag forma selecionado, é determinante se uma chave de determinação do resultado está gravada nas ordens de
produção atribuídas ao item de documento de vendas e distribuição.
Se não foram inscritas chaves de determinação do resultado para a ordem, são considerados os custos reais para a
ordem durante a determinação do resultado do item de documento de vendas e distribuição. O material em
processo é determinado e apropriado para a contabilidade financeira por meio do item de documento de vendas e
distribuição.
Se foi inscrita uma chave de determinação do resultado para a ordem, o material em processo é criado em custos
reais, no montante igual à diferença entre débito e crédito da ordem, desde que esta possua o status TFRE
(liberado parcialmente; este status é relevante só para ordens de produção) ou FREI (liberado). Depois de
apropriada a ordem, o material em processo é transmitido para a contabilidade financeira. O material em processo
é liquidado se, para a ordem, for definido o status GLFT (entregue totalmente; este status é relevante só para
ordens de produção) ou TABG (encerrado tecnicamente).
Uma vez liquidado o material em processo, são considerados os custos reais da ordem durante a determinação do
resultado para o item de documento de vendas.
Se o código não for definido, o material em processo é determinado, para as ordens de produção atribuídas, por meio
da determinação do resultado do item de documento de vendas.
Se for executada uma produção interempresarial no âmbito de uma produção por ordem do cliente com estoque não
avaliado de ordem de cliente, deve-se definir o código.
Neste caso, gravar uma chave de determinação do resultado nas ordens de produção atribuídas ao item de documento
de vendas e distribuição. É possível gravar esta chave de determinação do resultado como valor proposto, por tipo de
ordem
O código Determinar WIP para ordens internas e de serviço sem receita só é relevante se as ordens internas e de
serviço sem receita não estiverem atribuídas a itens de documento de vendas e distribuição. Se estiverem atribuídas, é
válida a opção executada com o código Ordens durante a produção por ordem do cliente .
Ordens durante produção por projeto - é possível determinar, em separado, material em processo, durante a
produção por projeto com estoque não avaliado de ordem de cliente, para as seguintes ordens atribuídas a um elemento
PEP:
Ordens de produção
Ordens internas sem receita
Ordens sem receita na administração de serviços (ordens de manutenção, ordens de assistência, etc.)
CONTROLADORIA 167 de 325
Este flag só é relevante, durante a produção por projeto, caso se trabalhe com o estoque não avaliado de projeto e é,
sobretudo, importante caso se execute uma produção interempresarial.
A condição para que o código seja considerado é a gravação de uma chave de determinação do resultado no elemento
PEP atribuído à ordem ou no elemento faturável superior a este elemento PEP. Se esta condição não for satisfeita, o
material em processo é sempre determinado, independentemente de o código estar definido ou não.
Se o código for definido, é determinante se uma chave de determinação do resultado está gravada na ordem atribuída
ao elemento PEP.
Se não forem inscritas chaves de determinação do resultado para a ordem, são considerados os custos reais para a
ordem, durante a determinação do resultado do elemento PEP. O material em processo é determinado e apropriado
para a contabilidade financeira por meio do elemento PEP.
Se for inscrita uma chave de determinação do resultado para a ordem, o material em processo para a ordem é criado
em custos reais, no montante igual à diferença entre débito e crédito da ordem, desde que a ordem possua o status
TFRE (liberado parcialmente; este status é relevante só para ordens de produção) ou FREI (liberado). Depois de
apropriada a ordem, o material em processo é transmitido para a contabilidade financeira. O material em processo é
liquidado se, para a ordem, for definido o status GLFT (entregue totalmente; este status é relevante só para ordens de
produção) ou TABG (encerrado tecnicamente).
Uma vez liquidado o material em processo, são considerados os custos reais da ordem durante a determinação do
resultado para o elemento PEP.
Se o flag não for definido, o material em processo é determinado para as ordens atribuídas por meio da determinação
do resultado do elemento PEP.
Se for executada uma produção interempresarial no âmbito de uma produção por projeto com estoque não avaliado de
projeto, deve-se definir o código.
Neste caso, gravar uma chave de determinação do resultado nas ordens atribuídas ao elemento PEP. É possível gravar
esta chave de determinação do resultado como valor proposto, por tipo de ordem.
O código Determinar WIP para ordens internas e de serviço sem receita só é relevante se as ordens internas e de
serviço sem receita não estiverem atribuídas a elementos PEP. Se estiverem atribuídas, é válida a opção executada
com o código Ordens durante a produção por projeto.
Ordens de produção sem apropriação de custos para o material - é possível determinar material em processo
também para ordens de produção que não apropriam custos para material. Se for marcado este flag, assegurar que está
gravada uma chave de determinação do resultado nas ordens de produção sem apropriação de custos para material, em
relação às quais se pretende determinar material em processo. Exemplos
Determinação WIP de redes de ordens sem movimentos de mercadorias (processamento anterior de redes de
ordens)
material em processo é liquidado, para as ordens de produção sem apropriação de custos para material, se o status
TABG (encerrado tecnicamente) estiver definido.
Ordens internas e de serviços sem receita - é possível determinar material em processo também para ordens internas
e para ordens de serviço sem receita. Se o flag for selecionado, assegurar que está gravada uma chave de determinação
do resultado nas ordens internas ou nas ordens de serviço em relação às quais se pretende determinar material em
processo. O material em processo é liquidado para as ordens internas e para as ordens de serviço sem receita se o
status TABG (encerrado tecnicamente) for definido.
O código Determinar WIP para ordens internas e de serviço sem receita só tem relevância se as ordens internas e de
serviço sem receita não estiverem atribuídas a elementos PEP e a itens de documento de vendas e distribuição. Se
estiverem atribuídas, é válida a opção com o código Ordens na produção por projeto ou Ordens na produção por
ordem do cliente.
Na utilização de avaliações paralelas com vários métodos de determinação do resultado (por ex., determinação WIP no
controlling de objeto por ordem e determinação do resultado proporcional à receita no controlling por ordem do cliente), seria
necessário definir as regras de atualização por chave de determinação do resultado. Deste modo, é possível classificar, de forma
diferente, as mesmas identificações de linha.
No sistema SAP, está preconfigurado que os dados de determinação do resultado são atualizados com outras classes de custo da
determinação do resultado, por chave de determinação do resultado. Se for utilizado um únivo método, é possível anular o
CONTROLADORIA 168 de 325
código Atualização chave de determinação do resultado na versão de determinação do resultado. A regra de atualização é válida
para todas as chaves de determinação do resultado.
se será determinado o material em processo em ordens de produção dependentes, na produção por ordem do cliente com
estoque não avaliado de ordem de cliente ou na produção por projeto com estoque não avaliado de projeto.
26.6.3 Classes de custo da determinação do resultado
Com uma classe de custo técnica da determinação do resultado, é possível agrupar as classes de custo da determinação do
resultado da determinação WIP. O sistema necessita internamente desta classe de custo técnica da determinação do resultado.
Para isto, será necessário que, anteriormente, tenham sido atualizadas as versões, a ACC, as classes de cusots, efetuar a
configuração preliminar, criar e executar a pasta batch input e criar a chave de determinação de resultados. No controlling
Geral, deve ser atualizada uma versão na atualização geral de versão, bem como nas opções na área de contabilidade de
custos e marcar esta versão como sendo relevante para a determinação WIP.
No sistema SAP, estão configuradas versões de determinação do resultado standard. Para uma utilização produtiva destas
versões e para determinar material em processo, é necessário:
que estejam criadas ou geradas classes de custo para lançamento dos dados de WIP calculado com base na
determinação do resultado na área de contabilidade de custos respectiva. Os dados determinados para WIP são
atualizados nas ordens, com estas classes de custos.
atribuir as classes de custo, incluídas na relação de classes de custo, às identificações standard de linha. A ativação do
material em processo é controlada por meio de identificações de linha.
Ter em atenção que as classes de custo da determinação do resultado são classes de custo secundárias da categoria da classe de
custo "31".
26.6.4 Método de avaliação (custos teóricos)
O método de avaliação estabelece-se uma ligação entre área de contabilidade de custo, chave da determinação do resultado,
versão da determinação do resultado e status de sistema. Na criação de novos métodos de avaliação define-se se o material em
processo é avaliado para custos teóricos ou para custos reais.
26.6.4.1 Material em processo para custos teóricos
No controlling periódico de produto, o material em processo é avaliado para custos teóricos. Efetua-se a avaliação com base em
operações ou com base em pontos de contagem de quantidades confirmadas. O sistema determina por período que materiais
foram fornecidos ao depósito, que materiais foram confirmados às operações, que materiais e atividades inseridos não são
considerados na determinação WIP (material em processo) devido a confirmações de refugo às operações subsequentes.
No encerramento do período do controlling periódico de produto, as quantidades relevantes (quantidade WIP) são avaliadas
segundo a Variante de avaliação para material em processo e refugo (custos teóricos) e especificadas como material em
processo.
No controlling periódico de produto trabalha-se com uma administração de status reduzida. Os seguintes status são relevantes
para a determinação WIP:
Status Descrição
TFRE A ordem foi parcialmente liberada (ordem para a qual foram liberadas operações de trabalho individuais).
FREI A ordem foi liberada.
No status TFRE e FREI, o sistema forma no controlling periódico de produto o material em processo no qual é multiplicada a
quantidade WIP com os custos teóricos segundo Variante de avaliação para material em processo e refugo (Custos teóricos).
Caso se pretenda determinar material em processo para custos teóricos, gravar por cada combinação de área de contabilidade de
custo, versão da determinação do resultado e chave da determinação do resultado um método de avaliação para os status
relevantes para a determinação WIP.
Proceder assim:
Status Número Procedimento adotado pelo sistema
CONTROLADORIA 169 de 325
do status
TFRE "1" Criar um método de avaliação do tipo de determinação do resultado S (determinar WIP com base em
custos teóricos).
FREI "2" Criar um método de avaliação do tipo de determinação do resultado S (determinar WIP com base em
custos teóricos).
26.6.4.2 Material em processo para custos reais
No controlling de produto da ordem, o material em processo é normalmente avaliado para custos reais. Nisto, o valor do
material em processo corresponde à diferença entre débito e crédito de uma ordem, desde que tenha o status TFRE
(parcialmente liberado) ou FREI (liberado). O método de avaliação para a determinação WIP é ligado a um status de sistema.
Os status seguintes são relevantes para a determinação WIP:
TFRE A ordem é parcialmente liberada.
FREI A ordem é liberada.
GLFT A ordem é completamente fornecida.
TABG A ordem está tecnicamente concluída.
No status TFRE e FREI, o sistema forma material em processo no montante dos custos reais, com os quais a ordem foi
debitada. No status GLFT e TABG, o sistema expande o material em processo. A diferença de débito por lançamentos de
custos reais e crédito real da ordem por entradas de mercadoria é interpretada como desvio nestes status.
Caso se pretenda determinar o material em processo para custos reais, gravar por combinação de área de contabilidade de
custos, versão da determinação do resultado e chave da determinação do resultado um método de avaliação para os status
relevantes para a determinação WIP. Ela indica como o material em processo deve ser determinado para cada i, dos status
(TFRE, FREI, GLFT e TABG)
Se o material em processo for avaliado com os custos reais, deve certificar-se que o material em processo formado e liquidado
em um período pode ser retirado em um momento posterior, no qual também se definem métodos de avaliação para a estrutura
quantitativa.
Proceder assim:
Status Status Descrição Número
status
Procedimento adotado pelo sistema
LIB TFRE Liberado "1" Criar um método de avaliação do tipo de determinação do
resultado F (determinar WIP).
LIBP FREI Liberado parcialmente "2" Criar um método de avaliação do tipo de determinação do
resultado F (determinar WIP).
FORN GLFT Fornecida "3" Criar método avaliação tipo determinação resultado Z (expandir
dados da determ.WIP e do resultado).
ENTE TABG Encerrada tecnicamente "4" Criar método avaliação tipo determinação resultado Z (expandir
dados da determ.WIP e do resultado).
Dados determinados com o método de avaliação do tipo de determinação do resultado F são transmitidos à contabilidade
financeira segundo as opções gravadas nas regras de lançamento na apropriação de custos e aí ativados como estoque de
produtos não acabados. Dados determinados com o método de avaliação do tipo de determinação do resultado Z são executados
na apropriação de custos para a estrutura quantitativa dos estoques ativados de produtos não acabados na contabilidade
financeira.
O método de avaliação para o status TABG certifica que o material em processo pode ser expandido para ordens que nunca
atinjam o status GLFT.
26.6.4.3 Preços internos
Caso se trabalhe no Controlling de produto da ordem durante a determinação de Material em processo para custos reais com
visões de avaliação paralelas, o sistema atribui automaticamente o ZMétodo de avaliação atribuído à versão da determinação do
resultado da visão da avaliação operativa e também as versões da determinação do resultado referenciadas na versão operativa
da determinação do resultado às visões de avaliação paralelas.
CONTROLADORIA 170 de 325
Devem ter-se processado as seguintes etapas de trabalho:
Definir chave da determinação do resultado
Definir versão da determinação do resultado
Verificar dados de controle dos perfis de produção repetitiva
Na produção repetitiva, deve ter-se determinado no perfil de produção repetitiva que as quantidades de pontos de contagem
podem ser criadas.
No sistema standard SAP estão pré-definidos processos para a determinação WIP.
26.6.5 Wip no custeio periódico
O processo de cálculo do WIP valoriza os produtos semiacabados. No custeio periódico, o WIP é valorizado como custo
teórico. As quantidades confirmadas para a operação para ordens de manufatura ou versões de produção (somente na
manufatura repetitiva) que não são refugo são valorizadas a custo teórico de acordo com a variante de avaliação para WIP e
refugo. O WIP a custos teórico pode ser calculado para coletores, ordems de produção com esturutra quantitativa e ordens de
processo.
Pode ser usado o Schedule Manager para auxiliar no fechamento do período.
A diferença entre o WIP do período corrente e o WIP do período anterior corresponde à variação do estoque de produtos
semiacabados. Esta variação pode ser transferida para FI e PCA durante o fechamento do período do custeio periódico
(apropriação). Apropriação para FI resulta na capitalização da variação de estoque de semiacabados. O sistema gera o
lançamento na conta parametrizada (seja a maior ou a menor). O número da ordem é gravado no campo de associação em FI
permitindo analisar o lançamento em FI.
Para coletores, as regras default STR (com estratégia para determinação da base de referência - with strategy for tracing factor
determination) devem estar determinadas para permitir o cálculo do WIP. Para ordens de manufatura que se deseja apropriar
por periodo, é preciso garantir que a regra default PP2 (Production Material Periodic Settlement) esteja espeficiada no tipo de
ordem.
No custeio periódico, utilize a chave de determinação de resultados 000003 (Wip calculado a custos teóricos).
Definir a versão de determinação de resultados. As versões de determinação de resultado permite valorizações múltiplas
de um mesmo objeto (tais como item de ordem de vendas) na determinação do resultado e no cálculo do WIP. Por
exemplo. Para fim de balanço patrimonial, o objeto é valorizado usando um método que determina o valor dos produtos
semi-acabados com base nos custos reais incorridos até a data. Para fim de análises internas, o valor dos produtos semi-
acabados são determinados usando o método que inclui lucros não realizados.
Definir o método de avaliação (custos teóricos).
Definir a variante de avaliação para WIP e Refugo (custos teóricos) (opcional). Nesta variante define-se a base a ser
usada no cálculo dos custos teóricos para a determinação do WIP:
Estimativa de custos preliminar do coletor ou da ordem
Estimativa de custos alternativa do material
Estimativa e custos padrão para o material(se estiver sendo usada uma avaliação de estoque de ordem de vendas, o
sistema acessa a estimativa na qual o standard foi baseado)
Define-se, ainda:
Associação de variante de avaliação para WIP
As linhas de identificação
Associações
Classes de custos para WIP
Atualizações
Regras de lançamento para liquidação do WIP. Especifica-se as contas do razão para onde será lançado o valor do
WIP apurado.
CONTROLADORIA 171 de 325
Definir os pontos de reporte de produção - backflushes (na produção repetitiva), confirmações de operação (na produção
por ordem) ou confirmações a nível de fase ( na produção por processo) - que deverão ser usados para informar
quantidades produzidas e refugadas. Na produção repetitiva, é preciso especificar também o perfil de produção repetitiva.
Deve ser definida pelo menos uma chave de controle para cada operação. Se somente um operação for definida como marco
(milestone), deve, normalmente, ser a última operação do roteiro.
Definir se estes pontos de contagem que serão relevantes para custos.
Definir se a estrutura destes pontos é a mesma usada para calcular os custos teóricos. Por exemplo, será problemático
valorizar o WIP baseado na estimativa de custos padrão para o material quando esta estimativa foi baseada em uma
estrutura de pontos de coletor diferentes do coletor. Na produção repetitiva, quando a estrutura de pontos de contagem é
alterada pode ser usados os pontos de contagem flexíveis para converter os backflushes dos pontos de conagem e atualizar
a estimativa de custos preliminar do coletor.
A SAP recomenda, na produção repetitiva:
A criação de um coletor para cada versão de produção;
A criação de uma estimativa de custos preliminares para cada coletor;
Ter as quantidades de atividades que devem ser confirmadas default baseado no roteiro usado na geração dos custos
preliminares do coletor;
Valorizar o WIP e os desvios de refugo baseado na estimativa de custos preliminares do coletor
Se a estrutura de pontos de controle for alterada, usar os pontos de controle flexíveis para atualizar a estimativa de
custos do coletor.
Garantir que o tipo, grupo e contador de grupo do roteiro nos quais o cálculo dos custos teóricos para determinação do WIP
se baseiam deve coincidir com os mesmos parâmetros definidos para lançamento dos dados atuais.
Garanta que a estimativa de custos usada para cálculo do custos teóricos tem uma itemização. Isto significa que o cálculo
para determinação dos custos do material deve ser feito pelo sistema e não através de valor informado. Para isto é preciso
criar a estimativa de custos padrão do material, estimativas de custos alternativas e, no ambiente de produção make-to-
order com valorização de material para a ordem de vendas, estimativas de custos da ordem de vendas com itemização.
Se for efetuado o cálculo de WIP com base em um estimativa de custos preliminar para ordem de produção ou de processo, o
sistema gera uma itemização dinamicamente. Tal fato, pode, no entanto, afetar performance.
Garantir que os componentes do material constantes na lista técnica são associados às operações nas quais serão usados
(opcional);
Garantir que o flag Origem do Material esteja selecionado (opcional)
Definir um período de cutoff para proteger os dados de períodos anteriores de serem sobregravados. O período de cutoff
divide a ciclo de vida da ordem de produção em períodos em aberto e períodos fechados. O WIP calculado antes do
período de cutoff não é alterado até que o próximo WIP seja calculado. O WIP calculado pra períodos posteriores é sobre
gravado pelo cálculo do WIP corrente. Para garantir que dados já lançados sejam alterado, definir o período de cutoff como
o período anterior ao período de determinação de resultados.
O WIP é sempre calculado no moeda da ACC e sempre lançado em FI na moeda da empresa. No caso de custeio entre
empresas com deferentes moedas, o WIP também é calculado na moeda da empresa.
26.6.6 Capitalização do WIP
No Customizing para Planejamento de Custos de Produto, deve ser definidos quais os valores devem ser captalizados para
avaliações de estoque, avaliação de estoque físico seguindo leis comerciais e a avaliação de estoque físico para leis fiscais. Os
elementos de custos mostram a decomposição dos custos calculados na estimativa de custos.
As linhas de indentificação para o cálculo do WIP`são normalmente agrupadas da mesma forma que os elementos decustos, ou
seja, o mesmo intervalo de classes de custos são usualmente associados à linha de identificação para matérias-primas, por
exemplo. Portanto, custos somente são considerados no cálculo do WIP se estiverem associados a um linha de identificação.
Para cada linha de identificação deve ser determinado que o WIP deve ser captalizado, que parte do WIP deve ser capitalizado
ou que nenhum WIP deve ser capitalizado.
CONTROLADORIA 172 de 325
26.6.7 Definir regras de lançamento para apropriação de material em processo
Nesta etapa de trabalho determina-se em que contas do Razão da contabilidade financeira são apropriados os custos do material
em processo. Para tal, atribuir uma classe de custo da determinação do resultado ou um grupo de classes de custo da
apropriação de custos a duas contas do Razão. Com base na apropriação de custos do material em processo é criado um
documento de lançamento na contabilidade financeira.
Os dados são atualizados no balanço.
Os dados são atualizados na contabilidade de lucros e perdas.
Se na ordem (coletor de custos do produto ou ordem de produção) foi indicado um centro de lucro, os dados são transmitidos
adicionalmente à contabilidade de centro de lucro através desta classificação contábil.
Os dados da determinação do resultado podem ser atribuídos às contas do Razão por categoria de demonstração de resultado ou
por classe de custos de determinação de resultado.
Em cada apropriação de custos são novamente lidas as regras de contabilização determinadas no customizing. Caso se tenham
modificado as entradas nas regras de capitalização, isto pode levar a inconsistências na contabilidade financeira e na
contabilidade do centro de lucro.
Caso a apropriação de custos do material em processo seja estornada, o sistema lê de novo as regras de capitalização
determinadas no customizing. Se entretanto as entradas tiverem sido alteradas, o material em processo estornado é atualizado
sob outra conta que não o material em processo original.
Para as contas do Razão indicadas nas regras de contabilização não se podem criar nenhumas classes de custo no CO.
26.6.7.1 Por categoria de demonstração do resultado
As seguintes categorias de determinação do resultado são formadas com base na atribuição de custos para identificações de
linhas:
WIPO - Material em processo, ativação obrigatória
WIPF - Material em processo, ativação facultativa
WIPN - Material em processo, ativação não permitida
Regra geral, define-se uma regra de contabilização que atribui material em processo de contabilização obrigatória às contas do
Razão Estoque a produtos inacabados (conta patrimonial) e Modificações do estoque (conta de resultado).
Se a contabilidade de centro de lucro estiver em funcionamento, devem também ser criadas regras de contabilização para o
material em processo não contabilizável para a transmitir a uma Conta “Dummy” na contabilidade financeira, através da
apropriação de custos. Isto é necessário porque a contabilidade de centro de lucro cobre os dados da contabilidade financeira e,
na contabilidade do centro de lucro, regra geral, o material em processo não contabilizável deve ser identificado. Caso se
transmita o material em processo não contabilizável para a mesma conta que o material em processo contabilizável, é
necessário efetuar um lançamento de ajuste manual, depois da apropriação de custos para a contabilidade financeira.
Caso se determine o material em processo para custos reais, o sistema determina provisões para custos não realizados, se o
crédito de uma ordem de produção for maior do que o débito da ordem com os custos reais incorridos até à data, devido a
registros de entrada de mercadoria. Neste caso formam-se as seguintes categorias de determinação do resultado:
RFKA - Provisões para custos não incorridos (grupo de capitalização obrigatória)
RFKW - Provisões para custos não incorridos (Grupo capitalizável)
RFKN - Provisões para custos não incorridos (Grupo não capitalizável)
Provisões para custos não incorridos são de passivização obrigatória. Se se formarem identificações de linhas para as três
categorias de determinação do resultado, têm que se definir regras de capitalização para as três categorias.
26.6.7.2 Por classe de custo de determinação do resultado
Neste caso atribuiem-se as classes de custo de determinação do resultado individuais às contas do Razão.
CONTROLADORIA 173 de 325
Se, por exemplo, o material em processo para os custos de utilização de material for atualizado sob a classe de custo de
determinação do resultado 672111 e o material em processo para os custos de fabricação sob o tipo de determinação do
resultado 672131, estas informações podem ser transmitidas a várias contas do Razão na contabilidade financeira.
26.6.7.3 Preços internos
Caso se trabalhe no Controlling de produto da ordem na determinação de Material em processo para custos reais com visões
de avaliação paralelas, o sistema atribui automaticamente as regras de contabilização definidas para a versão de determinação
do resultado da visão de avaliação operativa às versões de determinação do resultado das visões de avaliação paralelas,
referenciadas na versão de determinação do resultado operativa.
26.6.7.4 Atividades
1. Determinar para que contas do Razão se pretende apropriar os custos do material em processo.
2. Definir regras de contabilização por Área de contabilidade de custo, Empresa, Versão da determinação do resultado, Conta
de resultado, conta patrimonial. É possível gravar nas regras de contabilização contas do Razão para as quais foi definido o
código Só lançamento automático , no registro mestre de contas do Razão. Caso uma conta do Razão para a qual esteja
definido o código Só lançamento automático for gravada nas regras de contabilização, e caso seja necessáio efetuar
lançamentos de ajuste para os dados da determinação do resultado (por ex., material em processo), existem as
possibilidades seguintes:
Retira-se o código Só lançamento automático no registro mestre de contas do Razão.
Executa-se o lançamento de ajuste através de uma outra conta do Razão.
3. Entrar uma classe de custo da determinação do resultado ou uma categoria da determinação do resultado.
4. Depois de se ter processado esta etapa de trabalho, definir o código "Contabilidade financeira" para a versão da
determinação do resultado atual.
5. Caso a contabilidade de centro de custo estiver em funcionamento, definem-se as regras de contabilização para o material
em processo não capitalizável.
26.6.8 Funções a serem executadas antes do WIP
Antes do cálculo do WIP, devem ser executadas as alocações de modelos, reavaliação de tarifas e cálculos de custos indiretos
se aplicável. Se forem associados custos atuais para um hierarquia de objeto de custos, executar a distribuição de custos antes
do cálculo do WIP.
Somente as ordem que tenham uma chaves de determinação de resultados válida e não tenham o status DLFL (marcada para
eliminação) ou DLT (eliminada) são incluídas no cálculo do WIP. Portanto, pode-se melhorar a performance do cálculo do WIP
para as ordens que estão completamente encerradas, para as quais a variação já foi calculadoe as ordens para as quais não forma
antecipados nenhum custos. A marcação para eliminação pode ser revertida caso seja necessário.
26.6.9 Exemplo de cálculo de WIP
Exemplo de cálculo de WIP com desvio de refugo.
Condições
Refugo de 20% planejado para as operações 10 e 20.
Na operação 10, 312kg de refugo )refugo atual = refugo planejado_ foi confirmado.
Na operação 20, 300kg de refugo foi conformado.
Uma vez que a quantidade de refugo teórico é de 212,5 kg, obtém-se um desvio de quantiade na operação 20 de 87,5 kg.
Determinação de quantidades de referência para WIP a custos teóricos
As quantidades de WIP nas operações são determinada abaixo:
CONTROLADORIA 174 de 325
Operação 10
Produção na operação 10: 1.250
Produção na operação 20: 850
Quantidade de refugo na operação 20: 300
= quantidade de WIP: 100 (1.250 – 850 – 300)
Operação 20
Produção na operação 20: 850
Produção na operação subsequente: 0
Quantidade de refugo na operação subsequente: 0
= quantidade de WIP: 850
Teoricamente, é possível determinar o valor de WIP através de todas as operações como abaixo
100 x custos teóricos na operação 10 +
Cálculo da quantidade de referência
Operação 10
Produção na operação 10: 1.250
Quantidade de refugo nas operações subsequentes: 300
- quantidade mercadorias entregues para estoque: 0
= quantidade de referência: 950
Operação 20
Produção na operação 20: 850
Quantidade de refugo nas operações subsequentes: 0
- quantidade mercadorias entregues para estoque: 0
= quantidade de referência: 850
Determinação do WIP
950 x custos teóricos da OP 10 + 850 x custos teóricos da OP 10
Os custos teóricos para a avaliação do WIP são calculados automaticamente quando o WIP é calculado. Os valores planejados
(tais como o custo standard) são convertidos para a produção da operação. A estimativa de custos usada na valorização do WIP
pode conter custos que não são relevantes para a avaliação do estoque, tais como, cusos administrativos e de vendas. No custeio
do produto com estrutura quantitativa, estes custos são mostrados em separado na visão de elementos de custos. Estes custos
não são considerados no cálculo do WIP.
26.6.10 Cálculo de Custos teóricos baseado na estimativa de custeio padrão
Se for confirmado baseado na estimativa de custos padrão para o material e valorizado WIP e refugo correspondentemente,
existem várias situações:
roteiro corrente para a versão de produção e a estimativa de custos standard para o material acessam a mesma lista técnica,
tem o mesmo tipo de roteiro, têm o mesmo grupo de roteiro, têm o mesmo número de grupo de roteiro. O WIP e o refugo
são normalmente avaliados.
O roteiro corrente para a versão de produção e a estimativa de custos standard para o material acessam a mesma lista
técnica, têm o mesmo tipo e grupo de roteiros mas têm um número de grupo de roteiro diferente mas a estrutura de pontos
de contagem é similar. Pode ser usado o gerenciamento de erros definidos pelo usuário para garantir que o WIP e o desvio
de refugo sejam calculados atingindo valores basicamente corretos.
CONTROLADORIA 175 de 325
O roteiro corrente para a versão de produção e a estimativa de custos standard para o material acessam a mesma lista
técnica, têm o mesmo tipo e grupo de roteiros mas têm um número de grupo de roteiro diferente e uma estrutura de pontos
de contagem também diferentes. Pode ser usado o gerenciamento de erros definidos pelo usuário para garantir que o WIP e
o desvio de refugo sejam calculados atingindo valores que podem não estar corretos.
O roteiro corrente para a versão de produção e a estimativa de custos standard para o material acessam a mesma lista
técnica, têm o mesmo tipo e um grupo de roteiros diferentes. Não é possível calcular WIP. Para evitar esta situação e a
situação anterior, é recomendado trabalhar com a estimativa de custos preliminar do coletor.
26.6.11 Atualização do WIP
O WIP é atualizado para o coletor ou a ordem de produção em classes de custos secundárias da categoria 31. Estas classes de
custos são denominadas classres de determinação de resultados.
O WIP para ordens de produção sem estrutura quantitativa (ordens de CO) devem ser valorizadas a custos atuais e o tipo de
apropriação deve ser FULL. O WIP calculado a custos teóricos para ordens de produção PP e ordens de processo não é
recomendado. No entanto, se necessário, o roteiro ou a receita mestre da ordem deve ser a mesma da estimativa de custos do
WIP.
Para analisar o WIP utilize a facilidade de Explicação do WIP. O WIP somente considera a produção. Custos atuais pra refugo
e desvios são ignorados. Quando o Wip é calculado, o status RESA (Results analysis carried out) é atualizado para a ordem.
Estes dados são considerado para sumarização. Podem ser criadas hierarquias no Sistema de Informação para ver variações
acumulados por centro ou ACC, por exemplo.
26.6.11.1 Restrições
Se já tiver sido lançado um crédito (valor atual) através de uma entrega de mercadoria para estoque para uma ordem (coletor ou
ordem de produção) que é liquidada por período, mas a ordem ainda não recebeu débitos, a saldo da ordem não é apresentado
como WIP negativo (resersão de custos não realizados). O saldo é lançado como variação.
Se um roteiro de uma ordem de produção especifica uma seqüência de operaç~eos definidas como seqüências em paralelo, o
sistema não podem incluir as quantidades confirmadas no cálculo do WIP. Portanto, nenhum cálculo do WIP a custo teórico
pode ser calculado. Se estiver usando pontos de controle na produção repetitiva, seqüências em paralelo não são permitidas e,
portanto, esta restrição não é relevante em produção repetitiva.
Em ambiente de co-produção não pode ser calculado o WIP a custo teórico. O WIP a custos teórico é sempre calculado na
visão de avaliação. Preço interno não é suportado.
26.7 Cáclulo de Desvio
O cálculo dos desvios deve ser efetuado após o cálculo do WIP. O desvio pode ser calculado para coletores de custos, ordens de
produção e objetos de custo. O cálculo do desvio fornece informações detalhadas sobre o custo dos produtos e das ordens de
produção. O cálculo do desvio engloba:
Apresentação do desvio entre os custo teóricos e os custos de controle (por exemplo, os custos de controle podem ser os
custos reais de uma rede);
Determinação da diferença entre os custso reais debitados para o objeto e os créditos dos fornecimentos (desvio total)
Valorizar as quantidades de refugo não planejadas com os custos teóricos para determinar as desvio de refugo;
Determinação dos desvios de produção e os desvios de planejamento para fins gerenciais;
Apresentar as causas dos desvios e atribuir os desvios a diferentes categorias dependendo da causa.
O R/3 calcula o desvio do objeto por classe de custo, ou por classe de custo e origem do material. O calculo dos desvios
fornecem informações para tomar medidas para melhorias de custos.
O Schedule manager pode ser usado para o processamento das atividades do final do período.Através do Schedule Manager
com definição de fluxo, pode-se usar a lista de trabalho multi-nível para reprocessar abjetos faltantes. Os valores dos desvios
apurados podem ser apropriados para CO-PA na liquidação. Através do gerenciamento de erros definidos pelo usuário é
possível interferir no fluxo do processamento.
CONTROLADORIA 176 de 325
Os desvios podem ser calculados periodicamente ou de forma acumulativa. A regra default está definida no tipo de ordem.
Todas as ordens de produção e coletores de custos para os quais devem ser calculados os desvios por período dentro do
Controlling Periódico de Objeto devem ser liquidados por período, devendo, portanto, exisitir uma regra de liquidação do tipo
PER para a ordem. A regra default para os Coletores deve ser STR (com estratégia para determinação da base de referência –
with strategy for tracing facto determination) e para as ordens definir a regra PP2 (Liquidação periódica para produção do
material).
Os desvios acumulados podem ser calculados para todoas as ordens para as quiais se deseja analisar os custos por lote. A ordem
deve ser uma regra de liquidação do tipo TOT (FUL) e a regra default para cálculo do desvio deve ser PP1 (liquidação total
para produção do material). Para as ordens de produção e as ordens de processo esta é a regra default standard.
As ordens de produção e coletores de custos serão todas considerados no cálculo exceto os que tiverem os status LKD –
bloqueado, CLSD – encerrado, DLFL – marcada para eliminação ou DLT – eliminada. Isto significa que a performance ndo
cálculo do desvio pode ser otimizada consideravelmente com a marcação das ordens para eliminação.
Não será permitido calcular o desvio para período bloqueado pela transação KVAR.
O cálculo do desvio sempre compara os custos de controle com os custos teóricos. Para todos os tipos de desvios com base de
referência real (no sistema standard com versões 0, 1 e 3), os custos de controle serão os custos reais menos WIP e desvios de
refugo. Para permitir que o desvio de refugo seja subtraído dos custos de controle, o falg disvio de refugo deve estar setado na
variante de desvio.
No cálculo periódico o desvio é claculado pela seguinte fórmula:
Débito de custo real – custos reais alocados (crédito de fornecimento) – custos teóricos = desvios + desvios de refugo + WIP.
Não é possível calcular desvios planejados entre o custos padrão e os custos preliminares do coletor.
Os custos de controle para o cálculo dos desvios acumulados são assim determinados:
Para o desvio total, os custos de controle sãos iguais aos custos reais menos os desvios de refugo.
Para o desvio de produção, os custos de controle são iguais aos custos reais menos os desvios de refugo.
Para o desvio planejado, os custos de controle são iguais aos custos preliminares da ordem.
Os pré-requisitos para cálculo dos desvios são:
Uma itemização deve ser gerada para a estimativa de custos usada para o cálculo dos custos teóricos.
Os componentes do material constantes na lista técnica da estimativa de custos usada para o cálculo dos custos teóricos
devem estar atribuídos às operações onde são usadas. Caso contrário, não será possível listar corretamente os desvios e o
refugo quando as operações são confirmadas.
Os objetos para os quais os desvios serão calculados deverão conter uma chaves de desvio válida.
No custeio por ordem, a ordem deve ter o status de LIB (DLV – liberada) ou ENTE (TABG/TECO – tecnicamente
encerrada). Durante o cálculo do desvio, o sistema também para as quias o status LIB ou ENTE estiveram ativos. Mas, se o
status foi cancelado, nenhum desvio é calculado.
O flag de origem do material na visão de custo 1 dos mestre de materiais deve estar setado para todos os componentes do
material com custo crítico, ou devem ser usados os grupos de origem. Deve forma, é possível determinar quais materiais
causaram quais desvios em cada classe de custos. Caso este flag não esteja setado pode ser usado o programa
RKHKMATO para setar este campo. O flag deve estar setado antes da criação da estimativa de custos padrão do material.
OBS: A marcação do flag de origem ou o uso de grupos de origem aumentam o volume de dados e portanto degradam a
performance nas rotinas de encerramento mensal. Recomenda-se, portanto, a marcação deste flag somente para os
materiais que são relevantes para o custo.
As ordens de produção e os coletores para os quais se deseja calcular os desvios devem ter uma chave de desvio atribuída.
Pode ser definida uma chave de desvio padrão no Customizing para cada Centro. Esta informação é trasnferida para o
mester de materiais no momento da sua criação e, posteriormente, é transferido para as ordens de produção e coletores
criados para o material.
Para o cálculo dos desvios total, é preciso:
Na produção make-to-stock, os materiais devem ser uma estimativa de custos standard liberadas. A estimativa de custos
padrão, para coletores com liquidação PER, deve estar válida no último dia do período e, para as ordens (produção e
processo) com liquidação TOT, deve estar válida na data da última entrega.
CONTROLADORIA 177 de 325
Na produção mke-to-ordem, a estimativa de custos padrão é usada para a determinação do desvio total.
Se os desvios são calculados na versão de custos teóricos relevante para liquidação, as ordens recebem o status VCAL (desvios
calculados). Este status pode ser incluído no perfil de status no customisinz para o sistema de informação deo Controlling de
Custo de produto.
26.7.1 Parametrizações dos desvios
26.7.1.1 Chaves de Desvio
Para valorizar os refugos não planejados durante o cálculo do desvio, setar o flag Scrap. A chave de desvio deve ser atribuída
ao centros.
26.7.1.2 Variantes de desvio
A variante de desvio determina quais as categorias de desvio a serem determinadas. As seguintes categorias de desvio podem
ser determinadas:
26.7.1.2.1 Desvios de refugo (entrada)
Na etapa de trabalho Definir chaves de desvio define-se se os desvios de refugo são determinados. Na variante de desvio
indica-se se os desvios de refugo são exibidos. Assim é possível definir a exibição do refugo ou a depuração dos custos reais à
volta do refugo, por variante de desvio e, através da atribuição para a versão teórica, por versão teórica.
Exemplo:
foi gravado na chave de desvio que os desvios de refugo devem ser determinados.
na versão teórica 0 trabalha-se com a variante de desvio 001. Na variante de desvio 001 estão ligados os desvios de
refugo.
Lado de entrada Lado de saída
Custos reais
Refugo
Material em processo
Csts.de controle
Custos teóricos Csts.reais alocados
Desvio total
Desvio de preço de input
Desvio de quant.de input
Desvio de estrutura
Desvio residual de input
Desvio preço interno
Desvio de preço misto
Desvio tamanho lote
Desvio residual
CONTROLADORIA 178 de 325
na versão teórica 3 trabalha-se com a variante de desvio 999. Na variante de desvio 999 estão desligados os desvios de
refugo.
Em a Variante de avaliação para material em processo (custos teóricos) e refugo é possível definir-se qual o cálculo de
custos que está na base da determinação dos custos teóricos para a avaliação de desvios de refugo. Esta variante de avaliação é
gravada para o refugo na versão teórica 0. O cálculo do desvio de refugo é efetuado em todas as versões teóricas, de acordo
com a variante de avaliação gravada na versão teórica 0.
26.7.1.2.2 Desvio de preço de input (entrada)
Os desvio de preço de input são as diferenças entre preços planejados e preços reais dos recursos colados. Se este código estiver
definido, deve assegurar-se que
o código Origem Material está definido para os materiais fundamentais para os custos na estratificação do cálculo de
custos do registro mestre de material
o código Administrar quantidade está definido para todas as classes de custo relevantes
26.7.1.2.3 Desvio de quantidade de input (entrada)
Os desvios de quantidade de input são as diferenças entre a quantidade empregada planejada e real dos recursos. No caso deste
código ter sido definido, deve assegurar-se que
o código Origem material para materiais críticos para os custos tenha sido definido na visão de cálculo de custos no
registro mestre do material
o código Administrar quantidade para todas as classes de custos relevantes tenha sido definido
26.7.1.2.4 Desvio de estrutura (entrada)
Os desvios de estrutura são as diferenças que surgem por causa de recursos diferentes no plano e no real.
26.7.1.2.5 Desvio residual do input (entrada)
Os desvios residuais do input são diferenças do lado de entrada que não podem ser atribuídas a uma outra categoria de desvio
do lado de entrada (p.ex., sobretaxas)
26.7.1.2.6 Desvio de tamanho de lote (saída)
Os desvios de tamanho de lote são as diferenças entre custos planejados independentes do lote e os custos reais independentes
do lote liquidados pelo fornecimento. Os desvios de tamanho de lote só podem ser determinadas pela versão teórica 0.
26.7.1.2.7 Desvios de preço interno (saída)
Os desvios de preço interno são as diferenças entre o crédito teórico (pelo preço padrão) e o crédito real (p.ex., pelo preço
médio móvel).
26.7.1.2.8 Desvios de preço médio (saída)
No caso de avaliar os estoques com um preço misto, então podem aparecer desvios de preço misto, se o preço padrão calculado
na base do cálculo de custo misto não corresponder aos custos teóricos da alternativa de suprimento.
Exemplo:
O preço padrão para um material foi determinado por um cálculo de custos misto. Como o material é controlado pelo preço
padrão, as entradas de mercadoria são avaliadas pelo preço padrão e a ordem é respetivamente creditada. No caso de determinar
o desvio total com a determinação do desvio então os custos a controlar (neste caso os custos reais) são comparados com os
custos teóricos da alternativa de suprimento para qual a ordem foi criada. No caso de os custos teóricos da alternativa de
suprimento não corresponderem aos créditos do preço padrão então é criado um desvio de preço misto.
CONTROLADORIA 179 de 325
ver: Nova categoria de desvio: desvio de preço misto
26.7.1.2.9 Desvios residuais (saída)
Os desvios residuais são diferenças que não podem ser atribuídas a outras categorias de desvio (p.ex., diferença por
arredondamento). No caso de o sistema não poder determinar custos teóricos, só são registrados os desvios residuais.
Os desvios são determinados para todas as categorias de desvio que são marcadas nesta visão.
No caso de uma categoria de desvio não ter sido marcada, os desvios são atribuídos aos desvios residuais. Constituem
uma excepção os desvios de refugo. Caso os desvios de refugo não devam ser exibidos, estes desvios podem ser
inseridos em todas as outras categorias de desvio do lado de entrada.
No caso de não terem sido marcadas a categorias de desvio então só são determinados os desvios residuais.
Através do campo "Diferença mínima" pode determinar-se que montantes mínimos devem ser atribuídos à tela detalhada da
determinação de desvios da categoria de desvios relevante, mas que devem ser lançados e apropriados como desvios residuais.
26.8 Definir desvios de preços de dados primários (System settings for vairance calculations)
O cálculo de desvio é executado em várias etapas. É preciso diferenciar entre configurações do sistema no Customizing, que é
prerequisito para o cálculo do desvio, e os demais passos executados dentre do cálculo do desvio em si. Estas etapas incluem o
cáluco do custo teórico e a decomposição de custos. Uma vez completa estas etapas, o sistema pode calcular os desvios. O
cálculo do custo teórico e da decomposição de custos pode ser feito separadamente, No entanto, no cálculo do desvio, o sistema
executa estes passos automaticamente.
26.8.1 Versão teórica
Antes do cálculo dos desvio, é preciso configurar uma versão teóricoa para a ACC que determina, a versão que o sistema usa
para dados reais e planejados, a versão para a qu
Before you can calculate variances, you must set up a target version for the relevant controlling area. The target version determines the following.
– The versions the system uses for plan and actual data
– The version to which the system posts split actual costs and the variances
Moreover, you must specify the cost element group for which the first stage of actual cost splitting is performed, and the variance variant for which the variances are calculated.
Version 000 is the only version permitted for all plan, actual, and target versions. The system automatically sets any plan or actual versions to version 000. The target version is necessary nevertheless for standardization of variance calculation in the Cost Center Accounting and Product Cost Controlling components.
Assigning Variance Variants to Target Versions
The variance variant controls which variance categories are to be calculated.
Determining Splitting Rules in Splitting Structures
You assign splitting rules to a splitting structure. You save the splitting structure in the cost center master data (see: Cost Center Master Data). The splitting rules you define determine the criteria for actual cost splitting on the activity types of a cost center.
26.9 Cálculo de Custo real
26.9.1 CKMLCP – Processar o cálculo de custos reais
Deve-se ter cuidado quanto ao encerramento do ledger de materiais visto que o sistema só permite o fechamento do período
atual e do anterior. O período atual é definido na Administração de materiais através da transação de diferimento de período
CONTROLADORIA 180 de 325
(transação MMMPV). Além disto, o sistema não permite encerrar um período se o período anterior não estiver encerrado. No
entanto, existe uma forma de se encerrar períodos anteriores detalhado na nota 361236 de CO-PC-ACT. Actual/Material
Ledger. Nos passos de determinação de tarifas nível-único e multi-nível e encerramento do período, após definir os parâmetros,
é preciso informar, no campo de comando, o nome de uma função a ser executada e teclar enter para que o passo seja disparado
dentro desta tela de parâmetros e não através do botão de execução.
O mesmo procedimento é válido para o programa ZSAPRCKML_COGS criado pela SAP para apropriação a reavaliação do
CPV e consumos para centro de custos de materais com controle de preço standard. Este programa é específico para o Brasil.
Para a implementação deste programa deve ser seguido um procedimento detalhado em diversas notas:
305056 Alteração do customizing, alterações em funções e outros objetos. Deve ser totalmente implementada antes de
iniciar o período.
320152 Instalação do programa ZSAPRCKML_COGS, alterações em tabelas, alterações em programas DFKBINT. Pode
ser aplicado no final do período sem problemas
339389 Criação e modificação do programa ZSAPRCKML_COGS_DOC – está obsoleta a partir da nota 367588
338351 Alterações a serem efetuadas no início do período para a correta execução da nova versão do ZSAPRCKML_COGS
no final no final do período.
364954 Nova versão do ZSAPRCKML_COGS
367588 Nova versão do programa ZSAPRCKML_COGS para permitir estornar e reprocessar os lançamentos através deste
programa.
353530 Correção do programa ZSAPRCKML_COGS para buscar corretamente as classe da avaliação dos materiais.
Passos Função
Determinação de tarifa nível único MUST_SETTLE
Determinação de tarifa mult-nível MUST_MULTI
Encerramento do período MUST_CLOSE
ZSAPRCKML_COGS MUST_COGS
Categoria do Item do Ledger de Materiais
CL Liquidação ledger de materiais
UP Atualização do ledger de material
PC Modificação de preços
DC Débito/crédito material
ST DeterminaçãoTarifa nível único
MS Determinação de tarifa multinível
MI Material input (determinação de tarifa multinível)
MO Material de saída (determinação de tarifa multinível)
MB Estoque inicial (determinação de tarifa multinível)
MC Material input: tipo de moeda output (DetermTar.multinível)
RE Reparação ledger de material
AT LM atualização consumo de atividade
AC Tipo atividade input/processo ABC (determTarifa multinível)
CC Encerramento acumulação
CONTROLADORIA 181 de 325
26.9.1.1 Determinação de tarifa multi-nível
Parâmetros para Processamento posterior
Aviso em caso de desvio maior que – definir um percentual (total ou multi-nível) a partir do qual será gerada mensagem de
aviso. Este procedimento é útil para evitar grandes modificações de preço. O sistema executa a apropriação de custos do ledger
de materiais e emite um aviso. A verificação é efetuada segundo dois métodos de controle. Só quando os dois métodos
resultam em um desvio de preço que ultrapassa o valor limiar, é saída a mensagem de aviso.
A verificação do valor limiar é feita durante a apropriação de custos do ledger de materiais multinível segundo dois métodos:
Método de controle 1: controla se o total de todos os desvios multinível da quantidade do material suprida a vários níveis
resulta em um preço, cuja divergência percentual em relação ao preço-padrão é superior ao valor limiar.
Método de controle 2: controla se o total de todos os desvios de nível único e multinível do estoque acumulado do material
resulta em um preço, cuja divergência percentual em relação ao preço-padrão é superior ao valor limiar.
É editada uma mensagem de erro ou de aviso só para materiais que excederam o valor limiar durante a determinação de preço
multinível. O método 1 não é suficiente por si só, uma vez que existem materiais em que os desvios de nível único e multinível
relativamente altos se anulam. Segundo o método 1, esses materiais seriam considerados incorretos, enquanto o método 2 os
apresenta como corretos.
O exemplo seguinte é típico da anulação dos desvios de nível único e multinível:
No período, um produto acabado possui um estoque inicial de 100 unidades que apresentam desvios de DM 500 do período
anterior. O preço-padrão do produto é de DM 100. As outras 100 unidades do produto foram produzidas internamente neste
período. Na lista técnica utilizada para tal, foi substituída, no início do período, uma matéria-prima avaliada com um preço-
padrão de 10 DM por uma matéria-prima criada recentemente. Esta matéria-prima nova foi avaliada com um 'preço simulado'
de DM 1. Segundo a lista técnica, são necessárias 5 unidades da matéria-prima antiga ou da matéria-prima nova para cada
produto acabado. Nas ordens de produção para produzir o produto, são consumidos no período um total de 500 unidades da
matéria-prima nova. Cada matéria-prima debitou a ordem respectiva com custos de apenas DM 1, em vez dos habituais 10 DM
da matéria-prima antiga. Daí resultou uma diferença total de DM -4500. O preço-padrão do produto acabado, no valor de DM
100, foi determinado por meio de um cálculo de custos planejados, utilizando a lista técnica antiga. Isto significa que, após o
fornecimento dos produtos acabados no depósito, a diferença de DM -4500 continua a existir nas ordens de produção. Essa
diferença é alocada por meio da apropriação de custos de ordem como desvio de nível único negativo sobre o produto acabado.
A apropriação de custos do ledger de materiais de nível único resulta em um preço realista de DM 11. Isto significa um desvio
de DM 10 em relação ao preço-padrão. As 500 unidades consumidas correspondem a um valor de DM 5000 em relação ao qual
é necessário agora fazer o rollup para o produto acabado com a apropriação de custos do ledger de materiais multinível.
O método de controle 1 considera apenas esses desvios multinível e calcula um valor de DM 15000 para a quantidade acabada
de 100 unidades, resultante da avaliação provisória (DM 10000) mais os desvios multinível (DM 5000). Isto corresponde a um
preço de DM 150 e a um desvio de 50 porcento em relação ao preço-padrão.
O método de controle 2 calcula, para o estoque acumulado de 200 unidades, um valor de DM 21000, resultante da avaliação
provisória (DM 20000) mais o total de todos os desvios (multinível: DM 5000, nível único: DM -4500, estoque inicial: DM
500). Isto corresponde a um preço de DM 105 e a um desvio de apenas 5 porcento em relação ao preço-padrão.
Aviso em caso de desvio maior que – além do valores limites para mensagens de aviso, também podem ser estabelecidos
valores para emissão de mensagens de erro impedindo o cálculo da apropriação do ledger.
Verificar preço padrão do período / preço média móvel do período anterior – deve ser informado se os valores calculados
devem ser comparados tendo como baseo preço standard definido para o período do cálculo ou o preçó interno periódico
calculado no período anterior.
Tratamento automático de erros
Nível unidirecional – Permitir lista técnica real (erro de valor limiar) – quando as variações de preço multi-nível
ultrapassem os valores limiares definidos pelo usuário, o sistema poderá tentar reduzir a lista técnica real considerando o
consumo teórico. Se o consumo teórico for maior, não será feito nenhum cálculo multinível. Se o campo não for
selecionado, não serão feitos os cálculos múltiníveis destes materiais. Somente serão considerados os custos deste nivel. As
diferenças de preço ods materiais consumidos que não forem distribuídos para os níveis posteriores permanecerão como
valores NÃO ALOCADOS.
Cortar Ciclo completamente (erro de valor limitar) – se este campo for selecionado, o sistema irá cortar todas as
coneções de um ciclo durante a determinação de tarifa multinível caso encontre a situação de erro de valor limiar. Isto
implica que os materiais consumidos que também são materiais produzidos em um ciclo serão ignorados. O ciclo é
CONTROLADORIA 182 de 325
calculado com um nível único. Se este campo não for selecionado, em caso de erro, os materiais não serão custeados e as
variações de todos os materiais neste ciclo aparecerão como NÃO ALOCADO.
Preço negativo – tratamento automático de erros
Nível unidirecional (estratégia de preços alternativa) – se este campo for selecioando, sempre que o sistema encontrar
um preço negativo, tentará usar um tarifa alternativa. As alternativas pesquisadas pelo sistema são:
Considerar somente as entradas e não estoque acumulado;
Se não for suficiente, o sistema tentará considerar a valorização do estoque inicial caso a quantidade inicial seja maior
do que zero.
Caso contrário, o sistema tentará usar o preço interno periódo do período anterior caso o período anterior esteja
encerrado.
Se nenhuma destas alternativas for suficiente, será usado o preço standard do mestre de materiais.
O sistema irá emitir uma mensagem informando qual for foi usado. As diferenças de preço são apresentado como NÃO
DISTRIBUÍDAS.
Cortar ciclo complemtamente (preço negativo) – o sistema adota a mesma alterantiva que para o erro de valor limiar
quando encontrar a situação de preço negativo.
Nenhuma convergência no ciclo (tratamento automático de erros)
Cortar ciclos sucessivamente (divergência) – se este campo for marcado, quando a determinação de tarifa multinível
iterativa não ofr bem sucedida (o ciclo não converge), o sistema irá sucessivamente cortar as coneções do ciclo. Todas as
coneções num ciclo são examinada e todas aquelas com quantidades de menor peso serão cortadas. Se não obtiver êxito, a
coneção com o próximo fluxo de quantidade (em termos de peso) serão cortadas e assim por diante. O cálculo do peso do
fluxo de quantiade de cada material é efetuado dividindo-se o fluxo de quantiade do ciclo pelo somatório do consumo total
do material com o estoque final do material). Se o material for consumido em um processo de produção conjunta, somente
uma parte do consumo correspondente à estrutura em quesztão é incluído como fluxo de quantiade no ciclo. As variações
não distribuídas, aparecem como NÃO ALOCADO.
26.9.1.2 Programa RMMMINIT – Inicialização períodos mestre de material
Este programa está relacionado com o Programa de diferimento de períodos (RMMMPERI). Funciona da seguinte maneira:
ele define o período atual
Porém, o programa não pode ser utilizado para definir um novo período ao final de um. Também não pode ser definido no
lugar do programa de diferimento de períodos, e sim somente em complemento a este.
cria o registro de controle ou atualiza-o.
possibilita a criação de registros mestre de material na primeira inicialização de uma empresa.
Porém, na inicialização de uma empresa, deve-se preferir, em vez deste programa, a utilização da atividade IMG Atualizar
empresas para a administração de materiais.
O usuário pode também utilizar este programa para evitar inconsistências de dados, geradas por erros do usuário durante a
execução do programa de diferimento de períodos, ou que ocorreram porque vários períodos foram ignorados em um sistema
de teste. Antes de utilizar este programa, o usuário deve primeiramente determinar as causas da inconsistência de dados, para
poder avaliar se este programa poderá resolvê-las.
Atenção Cuidado, se o período utilizado para a inicialização for anterior ao período atual no registro de controle para a empresa. Isto
pode gerar uma inconsistência de dados entre os movimentos de mercadorias e os segmentos do mestre de materiais. Neste
caso, pode ser que as informações de estoque nos segmentos de mestre de materiais foram atribuídas ao novo período atual (ver
exemplo seguinte).
Exemplo
Período atual 02
Estoque inicial em depósito 0 unidade
CONTROLADORIA 183 de 325
Entrada de mercadorias 10 unidades
Para a inicialização
Período utilizado 01
O segmento do mestre de materiais indica que 10 unidades encontram-se em depósito no período 01. De acordo com o
documento de movimento de mercadorias, foram acrescidas ao estoque em depósito 10 unidades no período 02.
Condição
O usuário deve utilizar este programa somente se conhecer por completo suas funções.
O ledger de materiais não pode estar ativo.
Para poder executar este programa em background, o usuário deve ter criado uma variante de seleção para o programa.
Saída
Este programa dá saída a um protocolo, que informa se as empresas foram inicializadas com sucesso.
26.9.1.3 LINHA DE NÃO DISTRIBUÍDO
Está disponível um relatório para analisar valores não distribuídos. Programa ZVERIFY_PRICE_DET (nota 324754)
Na tela de seleção selecionaro centro, período e ano fiscal. A listagem gerada apresenta um ícone na primeira linha oara
selecionar entre diferentes moedas/visões de avaliação.
Descrição das áreas essenciais apresentadas:
Logo abaixo do cabeçalho, o estoque acumulado, the price limiter quantity e a parte da tarifa não distribuída e a as diferenças
cambiais são apresentadas. A secunda área começa com linhas azuis PRICE LIMITER RELEVANT LM DOCUMENTS. Aqui,
são listados todos os documentos que contribuíram para o price limiter quantity (coluna de quantidade) e as variações de preço
relevantes para o price limiter (comulnas PRICEDIF e EXCHRATEDIF). Os documentos são agrupados em categorias de
entrada (ZU) e outrs de entradas e consumos (VP).
Portanto podem ser analisadas as transações responsávies pelos valores não dsitribuídos , no entanto, nenhuma alteração poderá
ser efetuada aqui. Entre esta área e o cabeçalho do relatório pode-se encontrar dados técnicos que possam ser usados para
suportar a análise dos possíveis problemas.
ZREMOVE_PRICE_LIMITER: Programa para acerto das quantidades gerenciais do ledger de materiais para eliminar as
linhas de Não distribuído. As linhas de não distribuídos são geradas quando as quantidades do ledger e de MM divergem. As
quantidades do Ledger devem ser atualizadas com a quantidade atual de MM ou simplesmente zeradas.
Campo Descrição
P_MATNR Código do material
P_BWKEY Área de avaliação = centro
P_BWTAR Tipo de avaliação
P_VBELN Número do documento de SD
P_POSNR Item do documento de SD
P_PSPNR Elemento PEP
P_BDATJ Ano fiscal
P_POPER Período Contábil
P_NPOPO Nova Quantidade limite de preço (new price limiter quantity)
P_CPOPO Ataulizar Banco de dados
CONTROLADORIA 184 de 325
26.9.1.4 Resultado do cálculo de custos
Informações apresentadas no resultado do cálculo:
SG Status Global
PI Determinação de nível único
PM Determinação multi-nível
PRD Lançamento de encerramento
26.9.2 MR21 - Alteração de preco de material
Se o ledger de materais estiver ativo, o preço dos materiais cujo indicador de determinação de preço esteja setado como 3
somente pode ser alterado no início do período antes de qualquer movimentação de material que afete preço. Se o ledger não
estiver ativo, o preços dos materiais podem ser alterados a qualquer momento. Uma alteração de preço provoca uma reavaliação
do materias para todos os controles de preço, incluindo a avaliação com preço padrão e valorização com preço interno
periódico.
Logística Administração de Materiais Avaliação Alterar preço do material Modificar preço do material
26.9.3 Custos teóricos totais
O Valor total dos custos teóricos calcula-se segundo a seguinte formúla:
custos teóricos total = débito de custos teóricos + crédito de custos teóricos
Custos teóricos resultam dos custos planejados adaptados à atividade real.
O débito teórico em uma ordem de produção resulta do total do débito planejado da ordem independente da atividade e do
débito planejado da ordem dependente da atividade multiplicado com a quantidade real da ordem.
O crédito teórico de uma ordem de produção resulta através do registro de entradas de mercadorias no depósito. Desta forma, a
quantidade real fornecida é avaliada com o preço planejado segundo controle de preço.
O valor total dos custos teóricos resulta do total de débitos teóricos e créditos teóricos.
Os custos teóricos são calculados durante a determinação de desvios e atualizados no banco de dados.
Assim, uma apresentação de custos teóricos só pode ser efetuada, caso o usuário tenha executado a determinação de desvios
para esta versão teórica. Um crédito teórico só pode ser calculado na determinação de desvios, caso esteja presente uma
quantidade real para uma ordem, através de um registro de entradas de mercadorias.
Para a determinação de desvios, os custos teóricos são comparados aos custos a controlar.
O cálculo dos custos teóricos é dependente da versão teórica selecionada.
26.10 Sistemas de Informação de CO-PC
Para conseguir efetuar análises sumarizadas no Controlling de Objeto de Custos através da relatórios com drill-down de
produtos é preciso efetuar algumas configurações. Defina os tipos de ordens que devem ser sumarizadas e os grupos de
produtos para sumarização dos dados a nível de grupo.
26.10.1 Pesquisa de Produtos (Drilldown Product)
A Pesquisa de Produtos é uma ferrameta para apresentação e avaliações interativas de dados no Controlling de Objetos de
Custos. Ao contrário dos outros relatórios do SI de CO-PC, o drill-down não mostra as classes de custos, é sim, dados
sumarizados por um conjunto de características predefinidas, tais como, centro ou grupo de produtos. A partir da lista
sumarizada, é possível navegar até chegar a nível dos objetos individuais ou documentos.
A configuração standard do R/3 contém um número de relatórios de drilldown predefinidos mas podem ser definidos relatórios
específicos.
CONTROLADORIA 185 de 325
26.10.2 Sumarização e Seleção de Ordens
Vamos falar sobre o uso de ordens e os benefícios que elas trazem. Através do sistema de classificação, é possível selecionar
ordens através de uma Característica, ou seja, um critério pelo qual os dados serão selecionados. Pode-se, por exemplo,
selecionar todas as ordens de um determinado material. Também é possível organizar as ordnes em hiearquias para sumarizar
os valores em níveis superiores, acumulando, por exemplo, as ordens de um determinado centro.
Se a classificação está ativa para um determinado tipo de ordem, cada nova ordem criada é automaticamente classificada após a
criação. Isto significa que as características de classificação são preenchidas e atualizada com as informações da ordem (tais
como, o nome do usuário e a área de contabilidade de custos. A ordem pode, portanto, ser selecionada por qualquer uma destas
informações.
Existem dois tipos de características para classificação: características de referência e características definidas pelo usuário. As
características de referência são fornecidas pela SAP e podem ser escolhidas a partir de uma lista. Correspondem a campos do
mestre de ordens.
As características definidas pelo usuário precisam ser informadas manualmente na criação da ordem. Estas características tem
importância relativa e normalmente não são necessárias.
Ao acessar uma seleção de ordens, certas características (tais como centro ou material) são apresentadas na tema inicial para a
seleção das ordens. No Customizing, podem ser definidos critérios adicionais como características tais como centro de lucro.
Através dos perfis de seleção de status podem ser estabelecidas outras limitações para a seleção de ordens. Os perfis permite
limitar a seleção a certos status, tais como Tecnicamente Encerradas.
Para sumarizar ordnes é necessária a criação de uma hiearquia cujos níveis consistem de características que serão usadas pelo
sistema para selecionar e classificar as ordens. Os dados poderão, posteriormente, ser analisados no sistema de informação para
cada nó da hierarquia (objeto de sumarização).
26.10.2.1 Seleção e Geração de Características
A seleção e geração de características é feita no Customizing Controlling Controlling de Custos de Produto Sistema Info
Contabilidade de Objeto de Custos Opções para análise compacta/seleção de ordens Hierarquia e seleção de ordens
Selecionar e Gerar características. è apresentada uma lista de características sendo que as verdes ainda não foram geradas e
as azuis já foram geradas.
O processo de geração de características cria uma classe SAP_KKR_CLASS (objetos: objetos de CO, tipo de classe 013). As
características de referência ou de objeto armazenadas de forma centralizada são adicionadas a esta classe e torna-se disponível
para a seleção e sumarização de ordens.
Entrarão no processo de classificação as ordens cujo tipo de ordem permitir a classificação. Para ativar a calssificação dos tipos
de ordens no Customizing seguir o caminho: Controlling Controlling de Custo de Produto Contabilidade de Objetos de
Custo Controlling de Produtos por orden Cálculo de Custo Preliminar Ordem de Produção Verificar tipos de
ordens para ordens de produção e marcar o flag “Classifcação” na seção Código de Controle. A classificação somente pode
ser executada se os valores das características forem atualizados. Portanto, para incluir novas características é preciso executar
a Reavaliação (Recalculation Run).
Transporte: Se as características já foram geradas em outro mandante, pode ser feito o transporte sendo que as características e
a classe SAP_KKR_CLASS serão geradas no mandante destino. Alterações posteriores no mandante de orgime são marcadas
para serem transportadas.
26.10.2.2 Definir esquemas de seleção (selection profiles)
O esquema de seleção é usado para combinar status para a seleção de objetos (por exemplo: ordens ou operações). Pode ser
especificado na seleção de ordens ou na definição de uma hierarquia de ordens. O esquema é especialmente últil para seleção
de uma grande número de objetos de acordo com as mesmas condições (por exemplo, ordens para impressão, para liberação em
massa, para criação de valorização de ordens).
As condições de seleção são avaliadas top-down e um OR prevalece a um AND. Devem ser definidoa qual a situação do
“status” a ser selecionado: ATIVO; INATIVO ou NEVER ATIVO.
Porque questões de performance, as condições de maior limitação devem ser inseridoa no início da profile.
CONTROLADORIA 186 de 325
26.10.2.3 Definir telas de seleção para a lista de ordens
Nesta opção são defindas as telas de seleção e seleções adicionais para a seleção de ordens classificadas. No Sistema de
Informação, as ordens podem ser selecionadas a partir das características definidas para a classificação. A tela de seleção
permite determinar quais as características serão oferecidas como critério de seleção e a seqüência em que aparecerão na tela. A
definição de seleções adicionais permite limitar a seleção ainda mais.
26.10.2.4 Definir regras de exceção
As regras de execeção determinam quando as ordnes ou nós da hierarquia que possuem certas variações são negritadas,
permitindo apontar certas ordems para análises mais apuradas. A determinação pode ser feita por percentual ou valor absoluto
vinculadando a uma configuração de cor.
26.10.2.5 Criar hierarquia de ordens
A definição de estrutura para criação de hierarquia de ordens permtie sumarizar os valores de cada ordem de acordo como os
critérios definidos. O nívle da hierarquia consiste de características definidas na classificação. O sistema usa estas
características para selecionar e sumarizar ordens. O sistema calcula um total para cada valor de característica e atualiza os
valores para um objeto de sumarização. Os valores de um objeto de sumarização por ser analisado no sistema de informação.
A sumarização é usada, por exemplo, para agrupoar os custos por período, por material ou por centro. Os dados que podem ser
sumarizados são: Custos planejados, custos teóricos, desvios, WIP, categiroas de análise de resultados, quantidades de saída e
refugo.
O primeiro nível da hierarquia é sempre a Área de Contabilidade de Custos. uma vez que a hierarquia foi gerada, não pode mais
ser alterada. A nível de Volume de dados (Data scope) podem ser definidos parâmetros para melhoria de performance:
N.COMP - os registros de totais não serão gravados na sumarização. Melhora a performance na execução da hierarquia mas
reduz o detalhamento do relatório.
S/ORIG - os dados do serão sumarizados sem a origem (tais como objeto parceiro). Melhora a performance na execução da
hierarquia e na geração do relatório mas não será possível ver a origem nos relatórios.
26.10.2.6 Coleta de dados para hierarquia de ordens
Os dados para as ordens na hierarquia de ordens são compactados por período.
Os valores no objeto de compactação (total dos valores num nó de hierarquia, tal como o total dos valores compactados
através do tipo de ordem PP01) para períodos dentro das datas de compactação especificadas são reinicializados e
recalculados.
Os dados no objeto de compactação para períodos fora da perspectiva temporal especificada são retidos. Isso evita que os
dados calculados numa compactação anterior sejam eliminados quando as ordens forem reorganizadas.
A informação é atualizada para um objeto de compactação. O sistema gera um objeto de compactação separado para os valores
característicos de cada nó da hierarquia de ordens. Se sua hierarquia de ordens consistir nas características área contabilidade de
custos e centro, por exemplo, o sistema cria os seguintes objetos de compactação:
Centro A
Centro B
Área de contabilidade de custos 1, centro A
Área de contabilidade de custos 1, centro B
É possível limitar a seleção de ordens para compactação de ordens pela especificação de um perfil de seleção de status ao
definir a hierarquia de ordens. O perfil de seleção de status permite selecionar somente as ordens que têm um determinado
status (tal como liberada ou confirmada) ou para as quais um determinado status não está definido. Os possíveis status para as
ordens de produção estão relacionados abaixo.
CONTROLADORIA 187 de 325
ST Status do sistema
LIB Liberado
CONF Confirmado
FORN Fornecida
CDEL Cód.eliminação possível arquivar
CAPC Cálculo previsto de custos efetuado
MREL Marcação para eliminação
DSVA Desvios apurados
MOME Movimento mercadoria efetuado
NOLQ Norma liquidação registrada
Se desejar compactar somente ordens apropriadas, por exemplo, e limitar a perspectiva temporal de compactação aos dois
últimos períodos, mesmo que uma ordem seja executada por quatro períodos, os valores (tais como custos reais) dos dois
primeiros períodos da ordem não serão compactados e portanto não estarão na hierarquia de ordens.
Se estiver usando seleção de status, especificar uma perspectiva temporal de compactação que seja grande o suficiente para
incluir todo o prazo de uma ordem. Se não estiver usando seleção de status, é suficiente especificar uma perspectiva temporal
de compactação que inclui todos os períodos abertos em Contabilidade financeira.
Para reduzir os tempos de execução, é possível executar a compactação para hierarquias de ordens simultaneamente em
múltiplos servidores.
É possível executar a coleta de dados para:
A hierarquia de ordens como um todo
Se executar a execução de coleta de dados para a hierarquia de ordem como um todo, o usuário pode exibir um relatório
para cada nó na hierarquia.
Para uma hierarquia parcial
Por exemplo, se desejar calcular os custos para todas as ordens para um material em particular, é possível executar a coleta
de dados para a hierarquia parcial. Também é possível exibir um relatório para os nós subordinados.
O usuário também pode efetuar uma execução de eliminação. Essa execução elimina todos os nós de compactação na área de
controlling que foram criados através da hierarquia de ordens. O usuário deve ser cuidadoso aqui pois pode eliminar todos os
dados da hierarquia de ordens.
Podem ser definidas hiearquias também para projetos e objetos de custo. A hierarquia de objetos de custos é usada na
manufatura repetitiva e na manufatura de processo para coletar custos reais ( tais como diferenças de estoque ou atividade de
produção) a um nível superior em caso onde a ceta a nível de ordem não é possível ou não é desejável.
27 Custeio ABC
27.1 Introdução
A Contabilidade de Custos pressupõe que podemos medir o impacto de uma decisão local no lucro final da empresa olhando
principalmente no custo que essa decisão incorre, ou seja, medindo quanto dinheiro essa área (ou decisão) absorve ou libera.
Esse pressuposto só é válido se aceitarmos que a importância de todas as coisas numa organização está diretamente relacionada
com a despesa operacional gasta nelas. O dia a dia nos ensina o oposto.
A Contabilidade de Custos também pressupõe que as despesas irão variar proporcionalmente ao aumento do consumo dos
recurso pelos produtos, o que não é necessariamente verdade pois, um sistema tem muito poucas restrições e, por isso, a
maioria dos recursos do sistema tem capacidade disponível para absorver aumentos de volume e/ou mudanças de mix.
27.1.1 Problemas com a Contabilidade de Custos
O problema com a Contabilidade de Custos é que ela pressupõe que todos os recursos da empresa são igualmente importante e,
que se maximizarmos as eficiências de qualquer recurso, estaremos maximizando a eficiência da empresa como um todo.
CONTROLADORIA 188 de 325
Comparando uma empresa com uma corrente, dizemos que ela contém vários elos (recursos) interdependentes e seu
desempenho depende da interação e do sincronismo entre esses elos. Essa noção de sistema traz uma importante constatação, a
do papel fundamental da restrição do sistema. Quando tracionamos uma corrente, ela quebrará, obviamente, no seu elo mais
fraco, num único elo. Portanto, para aumentar a resistência da corrente precisamos identificar o seu elo mais fraco e melhorar
seu desempenho. Se aumentarmos a resistência de qualquer outro elo que não o mais fraco, não estaremos aumentando a
resistência da corrente como um todo.
Então, podemos concluir que, para melhorar o desempenho de qualquer sistema precisamos identificar sua restrição. Se não
soubermos onde está a restrição não poderemos aumentar seu desempenho. Depois de identificada a restrição, precisamos
decidir o que fazer para melhorar o desempenho do sistema.
O custo varia quando precisamos aumentar a disponibilidade de algo de que não temos o suficiente. Então, só aumentamos os
custos nas restrições do sistema, nos pontos onde precisamos aumentar a nossa capacidade. Os custos de uma atividade devem
aumentar apenas quando aquela atividade não tiver mais capacidade em excesso, isto é, apenas quando aquela atividade for
uma restrição do sistema.
27.1.2 Custeio Baseado em Atividade (Activity Based Costing)
O Custeio baseado em atividade é uma ferramenta de melhoria que fornece custo unitário (a única) permitindo aos usuários
funcionais determinar as necessidade de cada atividade, reduzindo os gastos antes das atividades automatizadas. Atribui custos
às atividades fornecendo, assim, informações para a priorização de melhorias de longo prazo e medições de sucesso de curto
prazo. Permite analisar os custos de cada atividade descobrindo formas de reduzir custos ou mesmo eliminar atividades que não
agregam valor aumentando a eficiência da produção.
O custeio baseado em atividades permite monitorar funções, produtos e processos. É um método adicional de controle e
alocação para a Contabilização por Centro de Custo e o Controle de Custo por produto.
ATIVIDADE –processo, função ou tarefa que ocorre ao longo do tempo e utiliza recursos para gerar um resultado específico
(produtos e/ou serviços) executada pelos empregados da empresa e sua ferramentas. Embora uma atividade possa ter mais de
uma saída, somente uma delas é definida como principal ou primária.
RECURSOS - técnicas, métodos, ferramentas, sistemas de informação, recursos financeiros e todo o conhecimento envolvido
na sua utilização.
PROCESSO (BUSINESS PROCESS) – Compreende um conjunto de atividades realizadas na empresa, associadas às
informações que manipula, utilizando os recursos e a organização da empresa. Os processos representam as atividades que se
entrelaçam para elaborar determinados produtos ou serviços. Forma uma unidade coesa e deve ser focalizado em um tipo de
negócio, que normalmente está direcionado a um determinado mercado/cliente, com fornecedores bem definidos. A
organização engloba não somente os aspectos organizacionais e estruturais das empresas, como também os seus agentes, ou
seja, as pessoas com sua qualificação, motivação, etc.. A capacidade de aprendizado da empresa também é um dos elementos
da organização de um processo.
A abordagem de ABC é um método alternativo ao custeio clássico por absorção. O ABC propõe que se direcione os custos
indiretos para os produtos, pois eles são cada vez mais significativos nas empresas de manufatura. Devido às características
semelhantes do custo por absorção, afirma-se que o verdadeiro ganho está no ABM (Activity Based Management). O ABM
preconiza que se deve analisar as atividades visando a sua otimização, antes de serem custeadas através de seus direcionadores
de custo. Percebe-se então que o conhecimento do business processo é essencial para a prática do ABM. Em algumas empresas
a definição das atividades para o ABC/M parte do empresa dos processos.
DIRECIONADOR DE CUSTO (COST-DRIVER) Direcionador de custo para uma atividade organizacional é o fator único
que mais influencia um indivíduo a gastar mais ou menos tempo em uma atividade. Os cinco principais Direcionadores de custo
são: Complexidade, inovação, volume, recursos e localização. Em um processo orientado a transação com grandes volumes de
trabalho repetitivo, Volume é o principal Direcionador de Custo indicando que existe muito pouca variabilidade no
processamento do trabalho. Se algum dos outros quatro direcionadores de custo possui uma influência significativa na maioria
das atividade executadas, este representam oportunidade de simplificação do trabalho e redução do custo. Nesta forma, o
objetivo é conseguir que a maior parte dos trabalho executados possam ter o volume como direcionador de custo.
A diferença básica entre as abordagens tradicionais de custos e a do ABC/M é que aquela contabiliza os custos indiretos do
processo para depois rateá-lo no produto segundo algum parâmetro (normalmente volume) e esta se utiliza do mecanismos dos
direcionadores de custo (direcionador de custo (cost-drivers) para atribuir os custos indiretos às atividades que os geraram.
Nesse sentido, os recursos (mão-de-obra, insumos, etc.) são consumidos por atividades (atendimento, produção, etc.) que são
desempenhadas em função de determinados objetos de custos (produtos, clientes, linha de negócios, segmentos, etc.).
CONTROLADORIA 189 de 325
Um direcionador de custo (cost-driver) é uma espécie de unidade de medida para a distribuição dos custos. O direcionador de
custo (cost-driver) para distribuição dos custos de um processo de operação do CPD pode ser minutos de utilização da CPU, ou
linhas de relatórios impressas, ou homem/hora dos profissionais que executam o processo. Pode haver ainda um direcionador
de custo (cost-driver) que combine ponderadamente duas ou mais unidades de medida. O importante é que seja definida uma
forma justa de se distribuir o produto daquele processo.
Os custos do produto do processo são representados pelos custos totais acumulados num determinado período dividido pelo
produção do mesmo período. Assim, os processos que consomem os produtos do processo de operação do CPD deverão estar
"pagando" de acordo com os produtos que consomem. Novamente, podem ser minutos de CPU...
O ABC fornece cinco (5) tipos de informações:
O custo das atividades e processos
O custo das atividades que não têm valor adicionado
As medidas de desempenho à base da atividade
O custo correto dos produtos e serviços
Os fatores causadores de custo em forma de objetos de custo.
Uma importante função do ABC é a definição de quais atividades agregam valor e quais não agregam. Atividades que agregam
valor são aquelas pelas quais o cliente está disposto a pagar e as que não agregam valor são aquelas que geram despesas, geram
atrasos, aumentam o custo dos produtos ou o cliente não está disposto a pagar por elas. A dificuldade desta metodologia está na
identificação das atividades e nas medições de seus resultados.
OVERHEAD – resultado (bens ou serviços) de atividades que não agregam valor mas que necessárias à organização.
Os passos para determinação do custo ABC é:
1. Definir as atividades separando-as entre primárias e secundários.
2. Agregar os custos às atividades (ou aos produtos e serviços gerados pela atividade). Estes custos podem ser salário,
despesas com pesquisa, maquinário, móveis, etc. Estes custos são usados como custos básicos da atividade (Baseline
activity costs). Os custos podem ser atribuídos por meio de documentos ou fórmulas.
3. Calcular o custo total de cada atividade, ou seja, distribuir os custos pelas atividades.
4. Calcular o custo unitário dividindo o custo total da entrada incluindo o custo atribuído a atividades secundárias para o
volume ou quantidade de saída das atividades primárias.
5. Análise dos custos para identificar melhoria possíveis aos processos.
O ABC, considerado pela maioria das pessoas como o melhor substituto para a Contabilidade de Custos tradicional, também
não considera a empresa como um sistema. “Num sistema de custeio baseado em atividade, o custo do produto é a soma dos
custos de todas as atividades requeridas para produzir e entregar o produto.” Logo, não pode resolver o problema da falta de
consistência da informação fornecida.
Os direcionadores de custos do ABC são medidas de eficiências locais, eles estão estimulando os administradores a otimizarem
cada elo da corrente (cada atividade), dizendo que isso os levará há uma otimização do sistema. Na verdade, o ABC tenta
maximizar a eficiência de toda atividade, o que certamente não pode contribuir para o bom desempenho do sistema.
A Contabilidade de Custos tradicional perdeu relevância porque aloca custos aos produtos. Com isso, o ABC também perdeu
relevância. Mudar do custeio tradicional para o ABC é como “...rearranjar as cadeiras do Titanic.”
É por tudo o que vimos aqui que Goldratt classificou a Contabilidade de Custos, e nela está incluído o ABC (e qualquer outra
metodologia que se baseie no mesmo paradigma), como inimigo número 1 da produtividade.
27.2 Versão Delta
27.2.1 Introdução
Activity-Based Costing (CO-OM-ABC) is reconciled with Contabilidade de Centro de Custo (CO-OM-CCA) through the delta
version, which can be assigned business transactions.
CONTROLADORIA 190 de 325
With this assignment you can control which transactions from the reverence version are brought over into the delta version, as
well as which transactions are carried out there.
If you select the transactions to be transferred (for plan and actual) from the reference version, the corresponding data will be
taken from there, and not from the delta version. This means that the transactions cannot be carried out in the delta version.
Primary actual costs are always taken from the reference version.
27.2.2 Business management transactions
27.2.2.1 Primary costs:
Área de Contabilidade de Custos relevant postings from other R/3 System components
(COIN)
Transfer postings of costs and CO line items
(RKU1, RKU2, RKU3, RKPB, RKIB)
Planning activity-dependent and activity-independent costs
(RKP1,RKP6,RKP8,RKP9)
27.2.2.2 Secondary costs:
Distribution: cost element appropriate allocation of primary costs
(RKPV, RKIV)
Accrual calculation: accounting for baseado em custos costs
(KAZI, KAZP)
Assessment of cost centers: allocation of primary and secondary cost center costs
(RKIU, RKPU)
Process assessment: allocation of primary and secondary process costs
(CPPA, CPPP)
Activity allocation:
Activity planning
(RKP2)
Direct and indirect activity allocation
(RKL , RKPL, RKIL)
Planning activity-dependent and activity-independent activity inputs
(RKP7, RKP3)
Non-allocatable activities
(RKN)
Splitting
(KSP1, KSP2, KSI1, KSI2)
Price calculation
(KSII)
Secondary order cost planning
(RKPW, PKPX)
Order and project settlement
Settlement of orders and projects
(KOAO, KOAP)
Settlement to profitability analysis
CONTROLADORIA 191 de 325
Assessment of cost center to profit
(KSPA)
27.2.2.3 Statistical key figures:
Entry of statistical key figures (plan, actual)
(RKP4, RKS)
27.2.3 Recommendation
Due to the internal dependencies of many of the business management transactions, SAP recommends transferring the
following transactions from the reference version:
Plan Actual
Primary costs X X
Accrual calculation X X
This selection guarantees that all reference version primary costs are transferred to the delta version. It then becomes possible to
allocate these costs to business processes using a parallel calculation for reconciliation.
27.3 Ambientes (Enviroments)
Define uma área de acesso para sistemas de informação, interna ou externa, para um dado modelo de processo no Custeio ABC.
Contém somente as funções úteis no contexto selecionado. Um Template de Processo é uma ferramenta de alocação de custos
de processos ABC usada, no planejamento, para relacionar o CO-OM-ABC com o CO-PC e, nos lançamentos reais, para
alocações periódicas dos custos processos para objetos de custo. Pode ser usado para determinar o consumo baseado em
atividades dos processo para os objetos de custo, permitindo, assim, cálculo de sobretaxas com uma approach ABC.
O ambiente de um modelo define as informações disponíveis dentre e for a do R/3. O sistema possui ambientes padrões para
ordens de produção, run schedule headers (desativado na versão 4.6), ordens de vendas e transferências de materiais planejadas
de PP. Cada ambiente pode ser vários sub-ambientes relacionados. Um sub-ambiente pode ser amarrado a mais de um
ambiente.
Sempre que possível, é recomendado que se use os sub-ambientes padrões que possuem poucas funções estando bem focalizado
e, portanto, tendo manutenção mais fácil.
Ambientes padrões disponíveis
001 Cost estimate for material / production orders
002 Reference and simulation costing
003 Cost estimate for material without quantity Structure
004 Network
005 WBS element
006 General cost objects / CO hierarchy
007 Internal order
008 Sales order
009 Process order
010 Run schedule header
SBP Structured business processes
SOP Transferring materials planning from PP
Sub-ambientes padrões disponíveis
101 Sub-environment: Business processes
CONTROLADORIA 192 de 325
Sub-ambientes padrões disponíveis
102 Sub-environment: Order dates
103 Sub-environment: Materials
104 Sub-environment: Bill of material
105 Sub-environment: Routing
106 Sub-environment: Unit costing
107 Sub-environment: General data
108 Sub-environment: Network
109 Sub-environment: WBS element
110 Sub-environment: Internal order
111 Sub-environment: Sales order
28 Demonstração de Resultado (Profitability Analysis)
No cadastramento de uma ordem de vendas em SD, o sistema já determina o custo (padrão) e permite fazer uma análise da
rentabilidade para aquele ordem. No entanto, em PA, poderão ser feitas análises mais detalhadas, com maior flexibilidade,
considerando, por exemplo, uma outra estimativa de custos que não a padrão. Além disto, o CO-PA permite uma análise mais
global, em SD a visão é por ordem de vendas.
Tabelas sumarizadas. A Implantação o sistema não consegue dimensionar o nível de sumarização. Na 4.6, o sistema sugere
estes níveis a partir do comportamento do usuário (utilização de drilldown)
Finalidade: Ferramenta da análise de rentabilidade do ponto de vista externo. No PCA é preciso definir com que visão se deseja
trabalhar (área divisional, unidades de negócio, linha de produtos, etc.) Só é possível trabalhar com uma visão – visão estática.
Só o PA, é voltado para análise com o mercado externo. A análise por ser, por exemplo, por produto, cliente e região, ou por
filial, vendedor, grupo de produto, cliente, ou qualquer outra. Em PA, existe uma flexibilidade maior na visão de análise. Os
segmentos de mercados vão sendo definidos dinamicamente à medida que surgem novas combinações de características. Não
existe a necessidade de uma pre-difinição estática como acontece com o Centro de Lucro.
No PCA, existem diversos relatórios padrões pré-definidos oferecidos pela SAP. Já no PA, pela sua própria característica, não
existem relatórios pre-definidos.
28.1 Profitalibity Management
Conceitos
Métodos de apresentação de resultados – periódico e custos de vendas
Valores –
Keyfigures ( / ratios (quota)
CONTROLADORIA 193 de 325
Variável
fixo
$
Quantidade
Débito = Aplicação de Recursos
Crédito = Origem do Recursos
28.2 Structures
28.2.1 Definição das características a nível de segmento
Esta função permite definir quais as características deverão ser usadas para geração dos segmentos de rentabilidade. Esta
definição irá influenciar na performance do CO-PA já que CO-PA é fortemente dependente da quantidade de segmentos de
rentabilidade. Um ou mais registros são mantidos na tabela de segmentos para cada segmento de rentabilidade e ano fiscal.
Num ambiente de produção repetitiva que tenha um grande número de ordens de clientes por dia não deverá ser usado o
número da ordem de vendas como caraterística na formação de um segmento de rentabilidade. No entanto, o número da ordem
de vendas continua sendo exibido nos lançamentos de CO-PA baseado em custeio. Analogamente, o objeto acumulador de
custo não deverá ser usado para relatórios e planejamentos de rentabilidade.
Na criação de uma nova Área de Resultado, a tabela relevante é automaticamente configurada de forma que os campos: ordens
de vendas (KAUFN), item da ordem de vendas (KDPOS), ordem de CO (RKAUFNR), projeto (PSPNR) e objeto de custo
(KSTRG) não serão usados para formação de segmentos de rentabilidade, enquanto todas as outras (incluindo clientes e
produtos) serão usadas e estarão disponíveis para relatórios de rentabilidade, planejamento e lançamentos contábeis para os
segmentos de mercado.
Por motivos técnicos, o campo “Sender Cost Center” normalmente não pode ser usado como característica para relatórios de
rentabilidade e planejamento.
É válido somente para a tabela CE3??????????
28.3 Dados mestre
28.3.1 Derivação de Características
As derivações são regras definidas em CO-PA para atribuir valores para as características partindo de informações nas bases de
dados do R/3 ou fora do R/3. Define-se uma estratégia de derivação composta de um conjunto de passos a serem executados
pelo sistema. É o próprio sistema que irá definir a seqüência de execução dos passos para a correta obtenção dos valores das
características.
Basicamente os tipos ou as opções de derivações, ou seja, os tipos passos da estratégia de derivação, são quatro: table look-up,
fixas, pre-definidas e as definidas pelo usuários. As fixas e as pre-definidas são fornecidas pela SAP. As outras duas são
definidas pelo usuário. Estes tipos não podem misturados. Assim, se, por exemplo, para a determinação de uma característica
como, por exemplo, Unidade Estratégia de Negócios, for preciso obter informações de dois campos de tabelas do R/3 (a
CONTROLADORIA 194 de 325
categoria do produto e o código da indústria de cliente), é preciso primeiro criar duas características, uma para cada um dos
campos e, posteriormente, uma derivação do tipo table lookup que atribua os valores destes campos para as características.
Portanto, dentro de uma Regra de Derivação, a origem dos campos fontes terá de ser, necessariamente, características definidas
em CO-PA. Percebe-se, portanto, que algumas características precisarão ser definidas apenas para geração de outras
características. Por isto, a funcionalidade de se poder definir que não se deseja gerar segmentos para algumas características é
bastante útil para melhoria de performance do CO-PA.
Basicamente, as informações para geração dos valores das características são extraídas das tabelas de cliente e produto. Para
extrair dados de outras tabelas, é preciso usar o conceito de Data Elements do ABAP.
Através da enhancement (user exit) é possível chegar ao estabelecimento de qualquer regra de derivação.
28.3.2 Valuation
Valorização é uma função disponível em CO-PA baseado em custos para complementar informações fornecidas diretamente
pelas transações. Estas informações adicionais podem ser estimadas, calculadas ou extraídas de uma fonte diferente (por
exemplo, informações detalhadas de custo de produto). Estas informações serão armazenadas em campos de valores (value
fields).
O primeiro passa para se efetuar uma valorização é definir qual a estratégia de valorização deverá ser usada. Podem ser
definidas diversas estratégias dependendo do ponto em que se deseja executar a valorização (no lançamento real, na
revalorização periódica, no planejamento manual ou no planejamento automático) e o tipo de registro a ser gravado (ordem de
vendas, fatura, lançamento de FI, liquidação de uma ordem de produção ou projeto ou projeto relacionado a ordem de venda).
Ainda, se falarmos em planejamento, podem ser definidas diferentes estratégias de valorização para as diferentes versões de
planejamento.
Uma Estratégia de valorização define os campos de valores a serem preenchidos bem como a forma e a seqüência de
preenchimento destes campos de valores. Cada Estratégia de Valorização recebe um código e uma descrição. As informações
podem ser extraídas tanto do componente de Custeio de Produto, de Condicition Technique (procedimentos de determinação de
preços em SD e Costing Sheet em CO-PA) ou mesmo de Customer Exists dependendo os métodos definidos em cada uma das
linhas da sua estratégia. Os lançamentos de valorização podem ser planejados, se gerados no momento do planejamento ou em
agregações ou podem ser reais se gerados no momento do lançamento real ou periodicamente.
A valorização é freqüentemente usada no planejamento em CO-PA para acessar precificação e informações de custo de produto
para os produtos que tenham quantidades planejadas relacionadas permitindo calcular automaticamente receitas projetadas e
custos de vendas.
A valorização pode ser definida para ser real-time ( executada no primeiro lançamento de CO-PA) ou periódica (acionada
manualmente). Esta segunda opção é recomendada por questões de performance. Se for processada em tempo real,
posteriormente poderá ser executada uma rotina de revalorização.
Cada uma das linhas da Estratégia de Valorização contém ou um esquema de cálculo de custos, uma estimativa de custo de
produto ou usa user exit. O objetivo de ser usar um esquema de cálculo de custos é antecipar os cálculos de custo. Para cada
linha devem ser informados:
Sequence – seqüencial numérico para determinação da ordem de execução. Os campos de valores valorizados em um
passo, poderão ser usados nos passos seguintes. Uma vez que um campo foi valorizado, não poderá mais ter seu valor
alterado em outros passos exceto através de user exit de CO-PA. Se for configurada a transferência de um Condition Types
de SD para CO-PA e forem atribuídos diversos condition types para um mesmo campo de valor, o sistema irá somar os
valores deste condition types. O mesmo ocorre com condition type oriundos de diferentes procedimentos de precificação,.
(pricing procedures).
Application ID – Para custeio de produto ou user exit., não preencher este campo. Para esquema de cálculo de custos,
determinar sua origem: PA (KE) ou SD (V). Lembrar que um esquema de cálculo de custos de SD somente pode ser usada
no planejamento.
Costing Sheet Name
Product Cost estimative
Quantity field – nome do campo que conterá a quantidade a ser considerada no custeio do produto. O campo ABSMG
(sales quantity) é um campo quantitativo da Área de Resultados S001. O campo quantitativo de CO-PA a ser aqui
informado deve estar associado a um campo quantitativo de SD. Um número de campos quantitativos são definidos no
sistema de faturamento de SD e é onde é feita a associação. Este campo somente será informado para estimativas de custo.
CONTROLADORIA 195 de 325
User exit – define o nome da user exit caso esta linha corresponder a uma user exit.
28.3.2.1 Valorização usando condições específicas de CO-PA (Condition Technique e Costing Sheet)
As técnicas de condições em PA permite calcular valores fictícios necessários para análise de margens de contribuição que não
são conhecidos no momento do lançamento do documento original. Torna possível, assim, calcular as comissões de vendas,
descontos financeiros, outros descontos ou custos de frete para um determinado documento de vendas. As condições são usadas
para cálculo de valores baseados em um determinado número de critérios (tais como, quantidade vendida, o produto vendido, o
cliente que efetuou a compra, etc.)
Neste método, podem ser definidos esquemas de cálculo de custos específicos de CO-PA usando as mesmas funções usadas na
definição de procedimentos de precificação (pricing Procedures) em SD que se constitui nas seguintes etapas: criação das
tabelas de condições (Condition Tables), criação das seqüências de acesso (Access Sequence), criação das Condition Types,
vinculação das Condition Types com as Access Sequences, definir a Costing Sheet e associar a condition type a um campo de
valor.
CONDITION TABLES
As Condition Tables são as tabelas geradas em CO-PA para guardar os condition records. Cada Condition Records possui uma
chave que consiste de uma combinação de valores das características. Cada tabela representa, assim, uma combinação de
características diferentes que poderão ser usadas em quaisquer condições. Assim, cada tabela, corresponde a uma das
alternativas possíveis definidas para a determinação do valor a ser atribuído a um campo de valor de PA.
OBS: Esta tabela precisa ser uma Transparent table (“T”).
Por exemplo, pode ser criada uma tabela que contenha como chave de acesso, as características produto e cliente que serão
fatores determinantes de um desconto, por exemplo, a ser atribuído a um campo de valor. Agora, se o fator determinante do
percentual for o grupo de material, deverá ser criada uma tabela tendo o grupo de material como chave. Agora, se, para alguns
materiais especificamente o critério para a determinação de percentual não for mais o grupo de material e sim, o próprio
material, será preciso criar uma outra tabela tendo o código do material como chave.
Posteriormente, estas tabelas serão relacionadas em uma seqüência de acesso que irá definir em que tabela o sistema deve
primeiro procurar os registros que atendem a uma condição específica, em seguida, qual a próxima tabela, e assim por diante.
No nosso exemplo, a primeira tabela deve ser a do grupo de material e depois a de material. Assim, primeiro o sistema irá
verificar o percentual de acordo com o grupo de material. Em seguida, irá verificar se na próxima tabela, existe também um
registro que atenda àquela mesma condição. Se encontrar, assume o novo valor. Se não encontrar, permanecerá com o valor
anterior. Assim, na segunda tabela, somente estarão cadastrados os materiais para os quais os percentuais de desconto não
atendam à condição geral definida.
Observe que, pela própria lógica, a seqüência das tabelas na Access Sequence será do mais genérico para o mais detalhado.
Dentro da Access Sequence, também, pode ser solicitado que o sistema interrompa a pesquisa em um determinada tabela da
seqüência se encontrar um valor válido. Esta opção é bastante interessante, por exemplo, quando se deseja desativar uma
condição específica anteriormente usada. Se, por exemplo, as restrições do cálculo do percentual por material por desativada,
basta selecionar a condição de exclusivo para a tabela de grupos e o sistema não irá mais acessar a tabela de materiais sempre
que encontrar um percentual atribuído ao grupo de material. Também pode ser por questões de performance. Se os registros
forem cadastrados de forma que sempre que for encontrado um registro válido na tabela mais genérica não existirá um registro
válido na tabela mais detalhada, podem marcar a opção de exclusivo para interromper o processamento antes do final.
ACCESS SEQUENCE
Uma seqüência de acesso nada mais é que um diretório contendo as tabelas nas quais o sistema deverá procurar por registros
válidos que atendam à condition type. Para cada tabela, deve ser definidos os campos especificando, o nome do campo no
condition record, a tabela interna onde a informação será extraída, o nome do campo desta tabela a ser associado ao campo do
registro, a descrição do campo. Opcionalmente, pode ser definido um valor constante para este campo ou invés de um campo de
tabela.
A condition type is a key used that defines the attributes of a condition and identify the condition in the system. You can use
condition types to calculate expected costs or sales deductions. For example, you can define conditions to create expected costs
as a percentage of the sales revenue or based on the quantity sold. In addition, you can define price conditions to determine the
standard price of the product sold. And you can define base conditions to find or calculate values to be used as a basis for
calculating other conditions in a costing sheet.
CONDITION TYPE
CONTROLADORIA 196 de 325
Os condition types correspondem a um tipo de critério para se obter um determinado valor que posteriormente será atribuído a
um campo de valor em CO-PA baseado em custos. Ou seja, corresponde ao procedimento a ser adotado para encontrar um
determinado valor para preenchimento de um campo de valor. Para cada condition type deve ser definidos os seguintes
atributos: categoria, tipo de cálculo, classe e escala. Além disto, pode-se definir se a condition type pode ser alterada durante
uma análise de condição e quais os campos podem ser alterados: montante/percentual, valor, tipo de cálculo ou conversão de
quantidade). É possível também permitir que o usuário elimine uma condition type.
Todos os tipos de condição não associados às categorias K, G, S, T e E deverão, necessariamente, ser associados a uma Access
Sequence para que seja possível gerar os condition records para esta condition type.
Condition category – agrupamento das condition types de acordo com critérios predefinidos, como, por exemplo, se a
condição é uma valor base ou um preço. As categorias disponíveis em CO-PA são:
E Cash discount – desconto financeiro
G Transfer price – preço de transferência
K Base value excluding tax – valor base sem impostos
S Standard cost – custo padrão
T Moving average cost – custo média móvel
" " (no condition category): for conditions that do not fit into any of the
above categories, such as surcharges and deductions
Para as condições da categoria G (preço de transferência) o sistema irá considerar ou o preço padrão ou a média móvel
dependendo do flag no cadastro de materiais condition class B. Para a categoria S (preço padrão) ou V (média móvel), o
sistema assumirá o preço standard ou a média móvel, independentemente do controle de preço do material. Nenhuma
seqüência de acesso é necessária para estas categorias (G, S e T).
As condition types da categoria E (desconto financeiro) permite estabelecer critérios para a determinação do percentual da
chave de pagamento do cadastro de clientes. Isto significa que, esta categoria só terá sentido se a chave de pagamento
estiver definida no cadastro de clientes.
Calculation type – O tipo de cálculo determina como o valor será calculado para a condição podem ser um percentual (A),
um montante fixo (B) (tal como um preço) ou dependentes da quantidade (C).
Condition class – As classes definidas são: preço ou percentuais a serem aplicados (a maior ou a menor – discounts ou
acréscimos)
Scale basis – determina a forma de interpretação dos registros de condição: se baseado em quantidade (C) ou em
valor (B)
Condition record maintenance
Na manutenção dos condition records pode ser definidos se o sistema deve verificar as scaled rates, ou seja, pode ser
determinado se as scales devem ser definidas de forma ascendente ou descendente.
COSTING SHEET
Uma Costing Sheet estabelece uma seqüência de condições (condition types) usadas para calcular os valores esperados, ou seja,
estabelece um inter-relacionamento entre as condições. São utilizadas, particularmente, para determinar base values a serem
usados nos cálculos de markup, cálculo de subtotais. Segue o mesmo conceito dos esquemas de cálculo de custos usados nos
demais componentes de CO sendo que, agora, ao invés de trabalhar com classe de custos, como acontecia no CCA por
exemplo, trabalha-se com condition types.
Exemplo de uma Costing Sheet
Step Counter Condition Type Name From To
10 0 KB00 Revenue 00 00
20 0 DISC Customer discount 00 00
30 0 DISP Price reduction 00 00
40 0 Net revenue 10 30
CONTROLADORIA 197 de 325
Step Counter Condition Type Name From To
50 0 COGS Cost 00 00
60 0 Base for sales commission 40 50
110 0 PROV Sales commission 60
300 0 OUPA Outgoing packaging 00 00
310 0 OUTF Outgoing freight 50 00
28.3.2.2 Valorização através de estimativas de cálcuo de custos – Costing Key
É possível extrair informações das estimativas de custos de Product Cost Planning (ferramenta usada para planejamento de
COGM – cost of goods manufatured – dos produtos). Podem ser usadas, inclusive, estimativas sem estrutura quantitativa. As
estimativas do planejamento podem ser usadas tanto para planejamento quanto para lançamentos reais.
Para isto são usadas as Costing Key que corresponde a um conjunto de parâmetros de acesso usado para determinar qual a
estimativa de custos (ou seja, qual a costing variant) será usada para valorização. A determinação da Costing Key a ser usada
irá depender do momento em que o documento for valorizado em CO-PA (ponto de valorização PV 1=real; 2=revalorização
periódica; 3=planejamento manual; 4=planejamento automático), do tipo de registro, do produto vendido, do tipo de material
ou qualquer outra característica da Área de Resultado.
Uma costing key pode ser associada a um tipo de material, a um material ou a uma combinação de características (a partir da
versão 4.0A) que, naturalmente, tenham alguma relação com o produto. As estimativas de custos a serem usadas podem ser a
padrão, a padrão modificada, a estimativa de custos corrente, etc.
Naturalmente, a costing key definida para material ela terá prioridade sobre a definição do tipo de material que, por sua vez,
terá prioridade sobre a definição para a combinação de características.
A associação da costing key com uma combinação de características é uma ferramenta bastante flexível. Podem ser definidas
até 3 características com origem (por exemplo, centro, grupo de produto, etc.) Assim, pode-se obter um COGM para cada uma
das centros da empresa, especialmente útil quando se trabalha com vendas por diferentes centros.
A Costing key consiste na combinação dos seguintes parâmetros:
Flag de Estimativa de custos para ordem de vendas de transferência – se for selecionado, o sistema irá trazer a
estimativa preliminar de custos de cada um dos itens da ordem de vendas para PA. A ordem de vendas e o item da ordem
de vendas é determinado pelo line item de PA. Se este campo for selecionado, os campos variante de cálculo de custos,
versão de custeio, custos adicionais, data do custeio, período/ano e period indicator não devem ser selecionados já que o
sistema não necessitará destas informações para a determinação da estimativa de custos.
Variante de cálculo de custos (Costing Variant) – variante que foi usada o cálculo da estimativa de custos
Costing Version – versão da estimativa de custos
Flag Transferência de Custos adicionais – se selecionado, o sistema irá transferir somente os custos adicionais
manualmente informados em CO-PC. Na maior parte dos casos, os custos adicionais são criados com uma referência a uma
estimativa de custos calculada automaticamente. Se não for selecionado, o sistema transferir para PA o somatório dos
custos adicionais e dos custos calculados na estimativa de custos automática.
Na definição da costing key, pode ser informada ou a data de custeio ou um período ou um period indicator para selecionar a
cost estimate:
Costing Date – define a data.
Ano/período – define um período/ano. O sistema considera o primeiro dia do período.
Período de planejamento – a alternativas para este campo são:
0 Future standard cost estimate
1 Current standard cost estimate
CONTROLADORIA 198 de 325
2 Past standard cost estimate
3 Standard cost estimate valid on posting date
4 Standard cost estimate valid on the date of goods issue
Se for definido 0,1 ou 2, o sistema considera o primeiro dia do período para o qual uma estimativa de custos padrão futura,
corrente ou passada, foi efetuada dependendo das informações do cadastro de materiais. Se for informado 3 ou 4, o sistema
considerada a data do lançamento ou a data de entrega da mercadoria independentemente da data de armazenamento do
cadastro de materiais.
Flag de Transferência de esquema de elementos auxiliar – se for selecionado, o sistema transfere o esquema de
elementos auxiliar. Em Product Cost Planning, existem dois tipos esquema de elementos: o esquema de elementos para
custo produção do produto (COGM) e o esquema de elementos primário. As duas podem ser armazenadas em paralelo e,
neste caso, uma será a principal e a outra a auxiliar. Esta definição é feita no Customizing (configuração para costing
variant) a nível de empresa e centro.
Flag de Transferência da Estimativa de custo na moeda da Área de Contabilidade de Custos – se selecionado, o
sistema considerar o esquema de elementos na moeda da Área de Contabilidade de Custos. Para isto, é necessário que os
componentes de custos sejam armazenados tanto na moeda da empresa quanto na da Área de Contabilidade de Custos Se
isto não for feito e este campo for selecionado, o sistema irá informar que não conseguiu selecionar uma estimativa de
custos. Se a moeda da Área de Contabilidade de Custos for diferente da moeda da Área de Resultados, as informações
serão convertidas para a moeda da Área de Resultados durante a transferência (como é feito com a moeda da empresa).
ASSIGN COSTING ELEMENTS TO VALUE FIELDS
Depois de definida a estimativa de custos, é preciso saber em quais campos serão armazenados cada um dos componentes de
custos. Esta associação é feita no Customizing e é independente da costing key e também do esquema de cálculo de custos. A
associação é feita entre a estrutura de componentes de custo e a Área de Resultados.
Para cada uma das linhas de associação, é estabelecida uma associação entre um componente de custo e um campo de valor da
Área de Resultados para cada ponto de valorização.
Podem ser associados até seis campos de valores para um mesmo componente de custos. Isto é especialmente útil quando se
deseja usar aproximações de valorização múltipla com diferentes estimativas de custo. É possível associar até três diferentes
costing key para um produto ou tipo de material.
Através da função de associação flexível (combinação de características), podem ser definidas tabelas de associação próprias e
associadas a até seis costing key para valorização em paralelo.
Na valorização, o sistema inicialmente define quais as costing keys a serem usadas. Depois, define a estimativa de custo correta
para cada costing key. Em seguida, transfere o valor do componente de custo para o campo na mesma posição da costing key na
já mencionada tabela de associação.
28.3.2.3 Valorização através de rotinas definidas pelo usuário
Para definir uma user programmed “exits” em CO-PA é preciso programar a exit em uma SAP standard enhancement ou
programar a exit em um programa special. Todas as exits criadas da versão 3.0 em diante usam o former method. Portanto, só
será permitido um programa especial somente com o objetivo de upward compatibility.
User exit in valuation using the SAP standard enhancement
Enter the enhancement COPA0002 in a project in SAP project management for enhancements (transaction CMOD). The
enhancement contains two function modules -- one for plan and one for actual data transfer -- in which you can program your
own source code. Once you have finished programming, activate the project. You can then use the user exit in valuation.
The following example demonstrates which conventions you need to observe when you program the exit.
CONTROLADORIA 199 de 325
28.4 Configuração do Fluxo de valores reais
28.4.1 Intervalo de documentos
Nesta seção do Customizing são feitas as configurações básicas para os lançamentos reais oriundos de SD, FI e CO. O primeiro
passo é definir um intervalo de numeração, interno ou externo, para os lançamentos reais (actual line items) para cada uma das
Área de Resultados. Para cada intervalo, podem ser definidos um ou mais tipos de registro (chave que identifica a origem da
informação). Os intervalos associados às transferências de informações de outros componentes do R/3 para CO-PA deverão,
naturalmente, ser internos.
Os intervalos serão reunidos em grupos para os quais serão determinados os intervalos de numeração de documentos e os tipos
de registros.
Os intervalos definidos para a IDEA são
Grupo Tipo de Registro Intervalo
Entrada de Ordem de Vendas A – Incoming Sales Orders 300000000 a 399999999
Lançamentos diretos B – Lançamento direto de FI 800000000 a 899999999
Liquidação de Ordem C – Liquidação de projeto ou
ordem
700000000 a 799999999
Rateio de Centro de Custo D – Overhead Costs 500000000 a 599999999
Faturamento de SD F – Dados de faturamento 100000000 a 199999999
G – Costumer Agreement 900000000 a 909000000
H – Statistical Key Figure 600000000 a 699999999
I – projeto relacionado a
ordem
909100000 a 909900000
28.4.2 Grupos de Características e de Campos de Valores
Os grupos de características determina quais as características serão apresentadas ao usuário e em que ordem para associação
com os segmentos de rentabilidade para as transações de Lançamentos de FI, Alocação de Atividade para PA e na Função de
manutenção das regras de liquidação das ordens, projetos e ordens de vendas. Pode-se, por exemplo, criar um grupo para cada
uma destas transações.
Para cada característica do grupo deve ser definida se o campo pode ser alterado ou não e se sua entrada é obrigatória ou não.
Naturalmente, só faz sentido ter uma característica bloqueada para alteração se existir uma regra de derivação automática que
determine o seu valor sem a necessidade de informação do usuário. Se for permitida alteração para uma característica com regra
de derivação, prevalecerá o valor informado pelo usuário.
Note que estas serão as características apresentadas ao usuário e não as características que irão gerar o segmento. Se nenhum
grupo de características for associado a uma transação, o usuário poderá informar valores para qualquer uma das características
da Área de Resultados.
Em função da limitação nesta associação, é possível através da enhancement padrão COPA0003 otimizar esta associação.
Os grupos de características, além da associação com as transações externas de CO-PA, também poderão ser associados aos
tipos de registros, ou tipos de operação na tela de geração ou consulta de lançamentos (transação de CO-PA). Da mesma forma,
se nenhum grupo for associado, o usuário poderá manipular qualquer característica da Área de Resultados.
Analogamente são definidos os grupos de value fields para associação com as telas de lançamentos em CO-PA individualmente
por tipo de registro informando os campos que serão apenas exibidos, os de preenchimento obrigatório e os opcionais. Da
mesma forma, se nenhum grupo for especificado, todos os campos estarão disponíveis. Os campos só de exibição, dentro da
mesma lógica, deverão ter uma regra de valorização definida para determinação dos seus valores. Prevalecerá, também para os
campos de valores, o valor informado pelo usuário.
CONTROLADORIA 200 de 325
28.4.3 Sumarização dos dados durante a atualização
Para reduzir, significativamente, o volume de dados da tabela de line item (CE1XXXX), é possível sumarizar os itens dos
documentos lançados para um mesmo segmento. Isto melhorar também os runtimes para atualização.
A sumarização será definida dependendo da atividade (SD00=documento de faturamento; RFBU = documento de FI), do tipo
de documento (interno ou externo) e do o ponto de sumarização (1=antes da derivação/valorização ou 2= depois). A
sumarização de documentos de FI só é possível para documentos internos após a aplicação das regras de derivação e
valorização. Ainda no caso de FI, a conta e a classe de custo também serão consideradas.
Só é permitido sumarizar dados de um mesmo documento do emissor e, neste caso, somente o número do documento será
gravado como origem. Consequentemente, não será possível associar ao lançamento correspondente em PA.
Se nenhuma sumarização for definida, os itens serão gravados um a um.
28.4.4 Unidade de Medida padrão em CO-PA
Definindo uma unidade de medida padrão, o sistema irá, adicionalmente, gravar as quantidades, também, nesta unidade de
medida (para os campos quantitativos). Para isto é preciso definir, naturalmente, dois campos de valores. O primeiro estará
associado, por exemplo, à quantidade faturada em SD. O segundo, será associado ao primeiro informando a unidade de medida
para que o sistema faça a conversão. Pode, portanto, ser definida uma unidade de medida diferente para cada associação de
campos. No entanto, a unidade de medida deve ser selecionada que forma que o sistema consiga converter para esta unidade de
medida para todos os materiais que possam estar associados a este campo. Naturalmente, ela deve ser ou a unidade de medida
básica do material ou uma unidade de medida alternativa para que o sistema consiga fazer a conversão. Se a conversão não for
possível, o sistema gera uma mensagem de erro e o documento poderá não ser atualizado.
28.4.5 Geração de Lançamentos pelas Ordens de Vendas
Para ser possível analisar resultados em CO-PA em tempo real é preciso trazer informações para PA no momento do
cadastramento da ordem de venda assim como no faturamento. É preciso definir os critérios para que esta transferência seja
consistente. Naturalmente que a transferência de informações de ordens de vendas só se aplica a CO-PA baseado em custos.
Somente documentos que são representativos em FI podem gerar lançamentos em CO-PA baseado em contas.
Para a transferência das ordens de vendas, já deverão estar definidos os intervalos para os tipos de operação “A” – Ordem de
Venda. Se a ordem for de projeto, o tipo de operação será “I” e será transferida no momento da liquidação do projeto. Esta
transferência se aplica a PA baseado em custos e deve, portanto, estar ativado. A ativação é feita na criação da Área de
Resultados.
Em SD, todas as receitas, deduções de vendas e outros valores (tais como preço de transferência) são armazenados como
condições. Define-se como condição (condition type) um conjunto de critérios, válidos por um determinado período, para
definição de preços, acréscimos/descontos, impostos, e outros custos de acordo com fatores determinantes estabelecidos (tais
como, vendedor, cliente, grupo de cliente, material, serviço, etc.)
Em CO-PA, é possível associar estas condições aos campos de valor (value fields). Todas as condições associadas a campos de
valor serão transferidas para CO-PA no cadastramento da ordem (tipo de registro ou operação A) sem nenhum tipo de
validação como ocorre com as transferências no momento do faturamento porque estes lançamentos são meramente estatísticos.
Para que uma condição relevante para FI seja transferida, deve existir uma classe de custo cadastrada em CO correspondente à
conta em questão.
Via de regra, os valores das condições são atualizados como valores positivos, exceto no caso nas notas de crédito e
devoluções. Em CO-PA todos os valores são positivos e os custos e deduções de vendas serão subtraídos ao invés de somados
no sistema de informação.
Para cada associação entre uma condição e um campo valor, pode ser definido o tratamento de sinal. O flag de Transfer with
sign é usado, seletivamente, para as condition types que tenham tanto valores negativos como positivos (exemplo:
acréscimo/dedução de receitas) e para aquelas que ocorrem mas de uma vez num documento de faturamento gerando tanto
débitos quanto créditos (exemplo: execução de reserva/cancelamento de reserva). Se este flag for selecionado, o sistema
balanceia os valores positivos e negativos para a condition type para garantir o total correto no campo de valor associado.
No entanto, este flag não pode ser usado para conciliar FI, SD e CO-PA. Mesmo sendo selecionado, o sistema não irá tratar os
sinais de receitas de vendas, deduções de vendas e custos da mesma forma em CO-PA, SD ou FI.
Também poderão estabelecidos vínculos com as condition types de MM. Quais são as condições de MM????????
CONTROLADORIA 201 de 325
É preciso, ainda, associar os campos quantitativos definidos em SD com os campos quantitativos correspondentes em CO-PA.
Campos quantitativos não estão associados a condition types. A quantidade faturada pode ser transferida tanto na unidade de
medida de vendas quanto na do estoque (stockkeeping unit). A associação definida será válida tanto para planejamento quanto
para lançamentos reais sendo especialmente importante no planejamento manual de materiais. porque o sistema
automaticamente irá determinar a unidade de medida.
Depois de definidas as associações das condições e dos campos quantitativos de SD com os campos de valores de CO-PA, o
próximo passo é ativar a transferência. È preciso definir para quais Área de Contabilidade de Custos/ano fiscal será feita a
transferência e qual o período a ser considerado: o da data de cadastramento do ordem ou o da data de entrega planejada.
28.4.6 Geração de Lançamentos de Faturamento
Da mesma forma que para as Ordens de vendas é preciso definir os critérios para a transferência de informações para CO-PA
no momento do faturamento. É preciso associar as condition types com os campos de valores só que, agora, é preciso definir se
serão transferidos as valores reais (correspondentes aos lançamentos de FI) ou estatísticos (fictícios). Para condições reais, as
contas de receitas, deduções de vendas e custos de vendas correspondentes devem ser definidas como relevantes para CO (ter
uma classe de custo ou receita associada).
É possível, ainda, reset campos de valores individuais para documentos de faturamentos para certos tipos de faturamento.
Para CO-PA baseado em contas, o sistema somente transfere os lançamentos contábeis gerados em FI.
Existem algumas limitações na transferência de valores de condições de documentos de faturamento.
As contas de receitas, deduções de vendas correspondentes às condition types precisam ter uma classe de receita definida
em CO nas categorias 11 e 12 (em outra categoria não há transferência).
As condition types tais como VPRS (Custo) que são definidas como estatísticas em SD são sempre transferidas para CO-
PA se forem associadas a um campo de valor.
Somente serão transferidas as condition types ativas em uma Pricing Procedure em SD. Para as ordens de vendas, não
existe a necessidade desta ativação porque, como já foi dito, são meramente estatísticas.
Também é possível transferir condições de MM para atualizar dados de faturamento em pooled payment em IS Retail system
(Varejo). Estes são transferidos de acordo com as mesmas regras de SD.
No caso do faturamento, pode ser necessário desconsiderar algumas condições ou campos de valores dependendo do tipo de
faturamento. Neste caso, o conteúdo dos campos de valores associados será zerado. Este procedimento permite lançar somente
receitas e quantidade em PA (por exemplo, para retorno) mantendo os custos de frete do documento original definindo o tipo de
faturamento RE e resetando o campo Freight Cost.
28.5 Liquidação de Ordem e Projetos
Para liquidar ordens, projetos e ordens de vendas para PA, é preciso configurar o Perfil de Apropriação e associá-lo com a
ordem ou projeto a nível cadastral. Este perfil contém a Estrutura de liquidação que define os critérios para crédito da ordem.
O perfil também contém uma Estrutura de transferência para PA que determina como os valores serão transferidos para os
campos de valor.
A Estrutura de Transferência de PA é uma regra que associa os custos, receitas e quantidades de outras aplicações com os
campos de valores e campos de quantidade em PA. Além da liquidação da ordem, a estrutura de transferência também é usada
para associações de lançamentos diretos em FI, e alocação interna de atividades em CO-OM.
Cada campo de valor ou quantidade é associado a um grupo ou um intervalo de classes de custo/receita ou categorias de
variação apurada na ordem. Um mesmo grupo de classes de custo podem atualizar vários campos sendo um para quantidade,
um valor, sendo que o valor pode ser separado em fixo, variável e/ou total. A transferência deve ser completa, significando que
todas as classes de custos e receita devem estar contidas na estrutura, e única, ou seja, cada classe de custo só pode aparecer em
uma das linhas da estrutura de transferência.
É bom lembrar que se estamos falando em classes de custo, é preciso definir também a Área de Contabilidade de
Custos, ou seja.
CONTROLADORIA 202 de 325
28.6 Dados reais
28.7 Planejamento
PRINCIPAIS PONTOS DE INTEGRAÇÃO DE CO-PA COM SD
Transações em SD CO-PA BASEADO EM CUSTOS CO-PA BASEADO EM CONTAS
Ordem de Venda Valorização -
Delivery (Expedição)
Picking
Goods Issue
-
Real – CPV - a partir da versão 4.5
(opcional)
-
Real – CPV/Estoque
Billing (Faturamento) Real – Receitas e Impostos sobre
Vendas. Opcionalmente, o CPV pode
ser lançado neste momento via valuation
(Antes da 4.0 só ocorria via valuation).
Real – Cliente/Receitas e Impostos a
Recolher/Impostos sobre Vendas
Valorização do planejamento usando Pricing Procedures de SD
Uma das estratégias de valorização do planejamento possíveis são os procedimentos de precificação de SD (classe de aplicação
V no campo “Aplication”). Estes procedimentos só podem ser usados para planejamento. Não podem ser usados para
lançamentos reais porque os valores das condições já foram transferidos diretamente para o documento de CO-PA de acordo
com a maneira que as associações dos campos de valores foram definidas na interface com SD.
Para usar um procedimento, todos os campos necessários para uma condições (definido nas condition tables) precisam
corresponder a características na Área de Resultado.
O planejamento em PA é semelhante aos dos demais componentes de CO. É possível integrar os planejamentos do PA para PP
através do SOP, para o LIS, FI-SPL e FI-GL
28.8 Sistema de Informação
Usa um Report Painter modificado, mais poderoso.
29 Contabilidade de Centro de Lucro
O componente Contabilidade de Centro de Lucro (EC-PCA) é um componente de Enterprise Controlling que permite
determinar lucros e perdas por Centro de Lucro na visão de periódica ou de estimativa de custos de vendas. Permite analisar
também ativos fixos e índices estatísticos (número de empregados, metros quadrados, etc.) por Centro Lucro.
Consequentemente, permite calcular todos os índices financeiros e contábeis comumente usados na contabilidade de custos
(ROI, fluxo de caixa, vendas por empregado, etc.).
29.1 Métodos de cálculo de lucro
O componente Enterprise Controlling possui três ferramentas de análise da empresa:
Nível Ferramenta
Tático EC-EIS – Sistema de Informação Empresarial
Estratégico EC-CS – Consolidação
Operacional EC_PCA – Contabilidade de Centros de Lucro
CONTROLADORIA 203 de 325
Os métodos para cálculo dos lucros podem variar de acordo com o tempo (periódico ou on-line), conteúdo (custo periódico ou
custo de vendas) e forma de representação e base de valorização (contabilização periódica ou baseada em custos). Em PCA, os
dados são apresentados por período e por contas seguindo o mesmo princípio organizacional de FI o que permite uma
conciliação entre as informações geradas pelos dois módulos. Como FI suporta tanto o método de contabilização periódica
como o método de custos de vendas, PCA também segue esta regra.
Na contabilização periódica, os resultados são representados de acordo com as classes de custos e receitas. Isto permite
visualizar quais os fatores de produção geraram custos. Os custos totais do período podem ser comparados com as receitas
ocorridas no mesmo período. Os custos correspondem aos custos de produção de todos os bens e serviços do período
independentemente se foram ou não vendidos neste período somados aos custos dos bens e serviços produzidos em períodos
anteriores e vendidos neste período. O resultado total do período deriva deste total juntamente com as atividades internas
capitalizadas e as alterações no WIP.
A visão de custos de vendas, compara os custos correspondentes às receitas geradas. Os produtos vendidos que compõem estes
custos tanto podem ter sido fabricados no período como em períodos anteriores. Portanto, nenhuma distinção é feita a nível de
classe de custos. Ao contrário, os recursos são divididos de acordo com a função, desenvolvimento de produtos, produção,
vendas e administração.
29.2 Integração com outros objetos
Os centros de lucro são estatísticos, ou seja, os lançamento reais de custos sempre serão atribuídos a outro objeto (centro de
custo, ordem interna, material, projeto, ordem de venda, ativo, objeto de custos, e objetos de resultados). A vinculação de
centros de custo, materiais, processos empresariais, ordens internas, projetos, ordens de produção e objetos de custo é feita a
nível cadastral.
Para o lançamento da receita, normalmente, é verificado o Centro de Lucro no cadastro do material de cada item da ordem de
vendas. O CPV é lançado posteriormente ao mesmo Centro de Lucro. Os ativos são vinculados a centros de lucro através do
centro de custo.
Diferentemente dos Centros de Custos, os Centros de Lucro podem ser vinculados diretamente a contas contábeis de FI
inclusive contas patrimoniais (ativo fixo, contas a receber, contas a pagar, estoque, material em processo, etc.). Isto permite
realizar análises, por exemplo, dos ativos por centro de lucro utilizando os centros de lucro como “Centros de Investimentos”.
Naturalmente, portanto, o centro de lucro deverá pertencer a uma única Área de Contabilidade de Custos, mas pode estar
vinculado a várias empresas.
No cadastramento do centro de lucro, o sistema assume que o centro de lucro está automaticamente vinculado a todas as
empresas relacionadas às Área de Contabilidade de Custos. Esta configuração pode ser alterada pelo usuário e será considerada,
também, no EC-CS (Consolidação) para a criação das unidades de consolidação.
A integração com FI pode ser on-line ou batch.
Um centro de custo só pode estar ligado a um único centro de lucro. No entanto, esta vinculação não é obrigatória. Por isto,
deve ser criado um Centro de Lucro Dummy que irá absorver os custos de todos os centros de custos que não estejam
vinculados a nenhum outro centro de lucro. No caso dos projetos, cada elemento PEP e diagramas de rede podem ser
associados a um Centro de Lucro diferente.
29.3 Configurações Gerais
29.3.1 Opções para a área de contabilidade de custos (0KE5)
Para a utilização do EC-PCA, é preciso definir algumas configurações adicionais, que, uma vez definidas, não poderão mais ser
alteradas. A nível de ACC devem ser definidos:
Centro de Lucro Dummy – corresponde ao centro de lucro criado através de uma função específica (KE59) e funciona
como o centro de lucro padrão do sistema. Sempre que não for definido o centro de lucro que deverá receber um
lançamento, será assumido o centro de lucro Dummy. Isto ocorre porque o sistema não obriga a vinculação dos objetos
(material, centro de custo, ordem, projeto, etc.) com os centros de lucro. Cabe ressaltar que os lançamentos gerados neste
centro de lucro precisarão ser realocados no final do mês através de lançamentos dentro da própria contabilidade de custos.
Hierarquia Padrão (nó principal) – uma vez definido o nó principal o sistema irá gerar a hierarquia para permitir a
inclusão dos centros de lucro;
CONTROLADORIA 204 de 325
Anulação do volume de negócios internos – se for selecionado, o sistema não irá gerar nenhum lançamento em PCA
quando houver uma transação entre objetos (ordens, centros de custos, etc.) que estejam vinculados a um mesmo centro de
lucro. Deve ser sempre selecionado para evitar a geração de lançamentos de um centro de lucro para si mesmo.
Tipo de moeda interna do centro de lucro – define o tipo de moeda que será usada com a moeda especial dos relatórios
de centro de lucro (usado em alguns relatórios padrões). Os lançamentos em PCA são atualizados em até três moedas: a da
transação (opcional), a local (da empresa) e uma terceira moeda (especial) determinada pelo tipo de moeda. Esta moeda
pode ser a da Área de Contabilidade de Custos (20), a do grupo (30) ou uma outra moeda definida na configuração de PCA
(90) no campo moeda interna do centro de lucro
Administrar moeda da transação– define se os lançamentos também serão gravados na moeda da transação.
Preferencialmente, este flag deve estar desmarcado para reduzir o volume de dados a menos que seja realmente necessário
analisar os dados nesta moeda.
Visão de avaliação– determina o preço de transferência a ser usado: legal, grupo ou centro de lucro. O preço legal é o
preço de vendas de mercadorias ou serviços da transferência entre empresas legalmente independentes dentro de um grupo.
É o preço usado no Balanço Patrimonial das empresas envolvidas. O preço do grupo é o custos de produção das
mercadorias usado para valorização da transferência entre empresas dentro de um grupo sem nenhum ganho ou perda. O
preço do Centro de Lucro é o preço negociado e acordado entre os Centros de Lucro e usados para valorizar as
transferências de mercadorias e serviços entre Centros de Lucro.
Para o preenchimento deste campo, primeiro é preciso definir o perfil de avaliação / moeda da Área de Contabilidade de
Custos. Se for definido um perfil de avaliação e moeda que trabalha com a valorização por centro de lucro, será obrigatório
o uso da mesma valorização em PCA.
Se for definido que serão gravadas informações na moeda da transação, obrigatoriamente a valorização deverá ser a legal.
Indicador de Controle – ativa o PCA para a Área de Contabilidade de Custos a partir de um ano fiscal específico. É usado
por outros componentes do R/3 para saber se os dados devem ou não ser transferidos para o PCA. Os parâmetros
especificados são válidos, portanto, a partir do ano fiscal especificado. Se as configurações não forem alteradas para vários
anos consecutivos, somente será necessário fazer uma entrada para o primeiro ano fiscal. Além disto, uma vez que tenham
sido lançados dados para um dado período de tempo, não será mais possível alterar os parâmetros. Os dados transacionais
deverão ser excluídos primeiro.
29.3.2 Parâmetros de controle para lançamentos reais
Os parâmetros de controle para lançamentos de dados reais são definidos a nível de ACC. O exercício especificado corresponde
ao ano fiscal a partir do qual os parâmetros estão em vigor. Os parâmetros a serem atualizados são:
Código de bloqueio – se ativo, não será permitido efetuar lançamentos na ACC, ou seja, não será possível modificar os
dados reais.
Código on-line controla, se a transferência dos lançamentos para a contabilidade do centro de lucro é efetuada de acordo
com as operações. Se estiver desativado, os lançamentos devem ser lançados posteriormente em relação ao ano/ao período,
com os respetivos relatórios.
Partidas individuais é controlada a atualização das partidas individuais reais.
Os parâmetros de controle não podem ser modificados, após terem sido lançados os dados no intervalo de tempo em questão.
Caso se pretenda modificar os parâmetros de controle após a entrada de dados de movimento, é necessário eliminar os dados de
movimento em questão.
29.3.3 Atualizar versões de planejamento
A versão do planejamento possibilita a administração paralela de diferentes dados planejados para o mesmo centro de lucro. É
possível utilizar diversas versões do planejamento em paralelo. Inicialmente, na visão geral de versão, são criadas as versões
para a utilização geral no R/3. Em seguida, é preciso atualizar os parâmetros de controle para as aplicações individuais
incluindo a Contabilidade de Centro de Lucro. Os parâmetros são definidos para cada ACC e exercício. A ACC será a que foi
definida na função “Definir área de contabilidade de custos atual”.
Na visão dos parâmetros de versão dependentes do exercício é possível gravar um texto próprio para a versão de planejamento,
para a contabilidade de centros de lucro. Em seguida devem ser atualizados os códigos de controle para os exercícios.
CONTROLADORIA 205 de 325
Código de bloqueio - se ativado, esta versão estará bloqueada e não será possível efetuar modificações nos valores
planejados. Deste modo, é possível proteger uma versão de planejamento após o congelamento. Se estiver desativado, a
versão estará disponível para modificações. Este flag pode ser marcado e desmarcado livremente.
Código on-line controla, se a transferência dos lançamentos para a contabilidade de centros de lucro é efetuada por
transação. Se estiver inativo, as transferências serão feitas por lote. A função de transferência de dados planejados de CO
permite transferir dados planejados de centros de custos, ordens internas, projetos, processos empresariais, diagramas de
rede objetos de resultado, ordens de SOP e MRP (consumo de atividades de centros de custos) e objetos imobiliários.
A transferência pode ser executada para todos os objetos de um tipo selecionado (por exemplo, todos os centros de custo),
ou para alguns objetos (por exemplo, determinados centros de custos). Antes da transferência de dados são eliminados
todos os dados planejados que foram transferidos.
Observar, enquanto o programa estiver em execução, poderão estar sendo transferidos, simultaneamente, dados on-line.
Assim pode eventualmente acontecer a entrada dupla dos dados correspondentes. Para a correção deve ser executado
novamente o programa para lançamento posterior de dados planejados. Se a transferência de objetos individuais se repetir,
então os dados já transferidos para a contabilidade de centro de lucro só podem ser eliminados, se ali existirem partidas
individuais.
Partidas individuais – controla a atualização de partidas individuais planejadas, na modificação dos valores planejados
documentando, deste modo, a modificação de planejamento anteriores.
Categoria de taxa de câmbio – determina, se os dados planejados da versão devem ser convertidos para a taxa de câmbio
média, taxa de câmbio de venda, etc. Caso não seja indicada qualquer data efetiva, a conversão é efetuada no primeiro dia
de cada mês. Mediante a data efetiva é possível determinar uma data fixada para a conversão.
Variante Preço Interno tem de ser determinada, se o usuário desejar avaliar quantidades planejadas de materiais
representativos com preços internos no quadro do planejamento de movimentos de mercadorias baseado em quantidades,
ou se desejar derivar custos diretos de material do cálculo de custos. Somente a variante fixa 000 é necessária para
determinar o preço interno de movimentos de mercadorias e de materiais. Várias variantes poderão ser criadas para a
determinação de preços internos se os preços planejados tiverem que ser determinados com base nos dados do cálculo de
custos.
29.3.4 Ajustar saldos das partidas individuais e registros totais (KEE0)
Esta transação permite verificar a consistência entre as entradas da tabela de partidas individuais planejadas GLPCP e as
entradas da tabela de registros de totais GLPCT. Esta verificação é recomendada se foi alterado o flag de partidas individuais
para uma versão de planejamento na transação OKEQ.
A verificação é feita por área de contabilidade de custos, exercício e versão do planejamento. Pode ser feita simplesmente uma
verificação ou um ajuste efetivo nas partidas individuais.Executando a verificação, o sistema é compara os registros de totais e
os saldos das partidas individuais. Neste caso podem ocorrer os seguintes 5 casos:
1. O registro de partidas individuais está ativo e já existem registros de totais na versão do planejamento correspondente.
Além disto, nem todos os saldos das partidas individuais planejadas coincidem com os registros de totais correspondentes.
Deste modo, as entradas nas tabelas GLPCT e GLPCP não são consistentes para a respectiva versão. Neste caso, é
aconselhado executar a transação com a opção ajustar tabela de partidas individuais. Deste modo são criadas partidas
individuais de diferenças ou iniciais correspondentes que garantem, que no encerramento os saldos das partidas individuais
coincidam com os respectivos registros de totais.
2. O registro de partidas individuais está ativo e já existem registros de totais na versão correspondente. Além disto, todos os
saldos das partidas individuais planejadas coincidem com registros de totais pertencentes. Deste modo, as entradas nas
tabelas GLPCT e GLPCP são consistentes para a versão do plano correspondente.
3. O registro de partidas individuais está ativo e não existem registros de totais na versão do plano correspondente. Deste
modo, as entradas nas tabelas GLPCT e GLPCP são consistentes para a respectiva versão.
4. O registro de partidas individuais não está ativo. No entanto, existem partidas individuais planejadas na versão
correspondente. Deste modo, as entradas nas tabelas GLPCT e GLPCP não são consistentes e é aconselhado arquivar as
partidas individuais planejadas correspondentes no menu de aplicação em ambiente -> arquivamento.
Ao arquivar devem ser indicados os seguintes parâmetros: a área de contabilidade de custos pertencente, os tipos de
registro 1 e 3, a versão do plano pertencente, o exercício pertencente, o controle de processo geral arquivamento com
modificação de banco de dados e o tipo de arquivamento apenas são arquivadas partidas individuais.
CONTROLADORIA 206 de 325
5. O registro de partidas individuais não está ativo. Além disto, não existem partidas individuais planejadas na versão do
plano correspondente. Deste modo, as entradas nas tabelas GLPCT e GLPCP são consistentes para a respectiva versão do
plano.
29.3.5 Analisar opções
Com esta função, é possível verificar e visualizar as opções da contabilidade de centro de lucro. A análise é feita para a área
atual de contabilidade de custo. As opções consistidas são as informações gerais de controle que foram atualizadas no quadro
do customizing e outras informações técnicas de controle para o ledger geral, com cuja ajuda é executada a atualização de
dados. Estas entradas de controle são executadas automaticamente em background. Não é necessária qualquer atualização
manual.
Informações Gerais
os códigos de controle e as opções específicas da ACC, como o centro de lucros dummy, a hierarquia standard, a moeda
de relatório de centro de lucros e outros códigos (eliminação do volume de negócios internos, administração da moeda de
transação);
os parâmetros de controle relativos ao exercício para os lançamentos reais (código de bloqueio, partidas individuais, código
em diálogo); e de planejamento (código de bloqueio, partidas individuais, código em diálogo);
as operações de gestão de empresas, transferidas para a contabilidade de centro de lucro. Esta transação permite ativar a
SAP PCASELEK para cada transação individual. Possibilita influenciar as condições de seleção da transferência de dados
e, deste modo, divergir da lógica determinada como standard na transferência de dados. O usuário pode por exemplo
definir, que registros de dados que no standard seriam transferidos, não sejam transferidos para a contabilidade de centro
de lucro.
Outras informações técnicas de controle para o ledger geral, com cuja ajuda é executada a atualização de dados.
Atribuição das empresas da área de contabilidade de custo ao ledger fixo '8A' (Tabela T882)
Informação adicional de controle para as versões de plano (Tabela T894) e parâmetros de versão dependentes do exercício
(Tabela T895)
Informações gerais de controle para o ledger fixo do centro de lucro 8A (Tabela T881), como a administração das três
diferentes moedas, do código de débito/crédito.
Além de executar as informações acima referidas, é verificada a consistência entre a hierarquia standard de centro de lucro e os
dados mestre correspondentes.
A verificação ocorre em duas etapas. Primeiramente, verifica-se a exixtência das entradas da hierarquia standard (estão criados
todos os centros de lucro?) e se todos os centros de lucro criados estão representados na hierarquia standard.
Se se chegou a inconsistências nas informações técnicas de controle do ledger geral, é possível corrigir automaticamente estas
informações. Para tal, utilizar a função atualizar.
Atividade Nome Exit Planejado Real
HRP1 Cálculo da folha de pagamento HR X
KAMV CO alocação manual de custos reais X
KAZI CO delimitação de custos reais X
KAZP CO delimitação de custos planejados X
KEKB Cálculo de custo unitário linha base X
KEKP CO custos primários para Cálculo Custo Unitário X
KEKS CO custos secundários para Cálculo Custo Unitário X
KEKZ Cálculo custos unitário linha Custos Suplementares X
KFPI Compensação preço interno X
KFPP Acordo de preço interno X
KOAE Liquidação real externa X
KOAM Liquidação da ordem AIA planejada X
KOAO Apropriação de custos da ordem X
KOAP Liquidação planejada X
CONTROLADORIA 207 de 325
Atividade Nome Exit Planejado Real
KOLI Fornecimento na rede de ordens X
KPIV Distribuição de custos reais para os objetos de custo X
KPPB Ordem de produção linha base X
KPPP CO Custos primários Cálculo Custos Produto X
KPPS CO Custos secundários Cálculo Custos Produto X
KPPZ Ordem produção linha custos suplementares X
KSII CO determinação de tarifa real X
KSPA Rateio na conta de resultados X
KSPB Rateio em Demonstração Resultados (planejado) X
KZPI CO suplementos periódicos reais X
KZPP Co suplementos periódicos planejados X
KZRI Juros reais calculados X
PAPL Planejamento de vendas e resultado X
PCAA Rateio real entre centros de lucro X
PCAD Distribuição real entre centros de lucro X
PCAP Planejamento direto em centros de lucro X
PCPA Rateio planejado entre centros de lucro X
PCPD Distribuição planejada entre centros de lucro X
PRC4 Adoção item balanço do Centro de Lucro X
PRC5 Entrada de documentos de centros de lucro X
RFBU Lançamento em FI X
RFT1 Despesas de viagem X
RKIB CO transferências periódicas reais X
RKIL CO Alocação indireta de atividade real X
RKIU CO Rateio real X
RKIV CO Distribuição real X
RKL CO Alocação de atividade real X
RKLN CO Reavaliação de tarifa real X
RKLX Pré-distribuição de custos fixos X
RKP1 CO planejamento de custos primários X
RKP2 CO planejamento de tipos atividade X
RKP3 CO absorção de atividades X
RKP4 CO índices estatísticos planejados X
RKP5 CO planejamento de receitas X
RKP6 CO planejamento de custos primários dependente da atividade X
RKP7 CO planejamento consumo de atividade dependente da atividade X
RKP8 CO planejamento de custos de ordens X
RKP9 CO planejamento de custos ordens dependente atividade X
RKPB CO Planejamento transferência periódica X
RKPL CO Alocação indireta de atividade planejada X
RKPU CO planejamento de rateio X
RKPV CO planejamento distribuição X
RKPW CO planejamento secundário custos de ordens X
RKPX CO planejamento custos secundários ordem dependente atividade X
RKPZ Planejamento crédito custos suplementares X
RKS CO índices estatísticos reais X
RKU1 CO transferência de custos diretos reais X
RKU2 CO transferência de receitas reais X
CONTROLADORIA 208 de 325
Atividade Nome Exit Planejado Real
RKU3 CO Transferência de Partidas individuais reais X
RMBL MM Débito/Crédito material X
RMM1 Liquidação ledger de materiais X
RMPR MM Modificação de preço material X
RMRP MM fatura recebida X
RMRU Movimentação mercadoria p/confirmação X
RMUM MM reavaliação X
RMWA MM movimento de mercadorias X
RMWE MM entrada de mercadorias pedido X
RMWF MM entrada mercadorias ordem produção X
RMWI MM diferença de inventário X
RMWL MM saída mercadoria fornecimento X
RMWQ Movimento mercadoria decisão utilização X
RRIB Lançamento periódico real reverse / rebook X
RRIL AIA real reverse / rebook X
RRIU Rateio real reverse / rebook X
RRIV Distribuição real reverse / rebook X
SD00 Documento Faturamento SD X
29.3.6 Atualizar opções
A atualização técnica dos lançamentos da contabilidade de centros de lucro é efetuada mediante o componente FI-SL Special
Purpose Ledger. O ledger 8A é um ledger fixo, que só pode ser atualizado sob o controle da aplicação a qual pertencente (neste
caso, a contabilidade de centro de lucro). Ledger fixo são os ledger que podem ser atualizados independente de configurações
em FI. É a aplicação que controla a atualização desde ledger. Assim, a aplicação, além das tabelas próprias de controle, deve
também preencher as tabelas necessárias ou controle interno de FI. Este processamento é sempre em background, se forem
atualizadas opções superiores dentro da contabilidade de centros de lucro.
Sob determinadas condições, por exemplo, depois do transporte de opções de customizing ou da modificação da atribuição
empresa / área de contabilidade de custos, tem de se acionar manualmente a geração destas entradas de controle adicionais.
As seguintes informações de controle são geradas ou verificadas:
as entradas de instalação da tabela de registro de totais GLPCT, da tabela de partidas individuais reais GLPCA, e da tabela
de partidas individuais planejadas GLPCP em FI-SL (tabela T800A)
a definição do ledger fixo 8A (tabela T881)
a atribuição das empresas com contabilidade de centros de lucro ao ledger fixo '8A' (tabela T882)
as versões do planejamento (tabela T894)
os parâmetros de versão dependentes do exercício (tabela T895).
Se faltarem (na tabela T800A) entradas centrais, deverá ser executado um report de geração para instalar a contabilidade de
centros de lucro em FI-SL. Entretanto, no sistema não pode haver lançados na produção em nenhum mandante, pois alguns
lançamentos poderiam perder-se sem que o usuário reparasse.
O programa envia, se necessário, uma consulta de segurança, de tal forma que os empregados possam ser devidamente
informados. Depois de se assegurar que não se vai lançar mais, é possível confirmar a consulta de segurança. Em seguida,
executa-se automaticamente a geração, o que demora só alguns minutos. Se o usuário não tiver a certeza de que todas as tabelas
internas de controle estão no status atual, elas devem ser verificadas com a função analisar opções (transação 1KE1).
Notas para o transporte - A entrada de menu atualizar opções globais serve exclusivamente para eliminar inconsistências
imprevistas no customizing da contabilidade de centros de lucro. Visto que um transporte das modificações de banco de dados
aqui executadas não elimina necessariamente possíveis inconsistências no sistema de destino, esta transação não está ligada à
conexão de transporte da contabilidade de centros de lucro.
CONTROLADORIA 209 de 325
29.3.7 Ativar ledger de estoque médio
Esta transação permite ativar ou desativar um ledger de saldos médios para a contabilidade de centro de lucro. Como ledger de
saldos médios, é criado um ledger fixo adicional 8Z para a tabela de registros totais da contabilidade de centro de lucro
(GLPCT).
No ledger de saldos médios, são atualizados os movimentos de um mês (ponderados com uma data). Um movimento que tem
lugar no primeiro dia do mês é ponderado correspondentemente, e atualizado totalmente no ledger de saldos médios.
Contrariamente, os movimentos posteriores são introduzidos proporcionalmente (dias do mês que ficam / dias do mês).
É possível definir como o saldo médio deve ser calculado: se através da data de lançamento (exit / standard SAP G01), ou de
uma user exit.
No ledger de saldos médios (8Z), apenas são atualizados os movimentos ponderados por período. Para determinar o saldo
médio de um período, é levado em conta o saldo inicial do período para os movimentos ponderados. Este saldo inicial é
determinado a partir do ledger 8A da contabilidade de centro de lucro.
Exemplo:
Uma conta contém no início do período 2 um saldo de 10.000,-
Nº de dias no período 2: 28
Entrada a 15/02 10.000,-
=> movimento ponderado: 10.000,- * 14 dias / 28 dias 5.000,-
Entrada a 22/02 10.000,-
=> movimento ponderado: 10.000,- * 7 dias / 28 dias 2.500,-
--------
Saldo médio de 17.500,-
Ter em atenção que não são levadas em conta as quantidades durante a atualização do ledger de saldos médios através do exit
standard.
Um cálculo com base na data valor só é possível com restrições. Se a data valor e a data de lançamento se diferenciam no
período, o saldo médio não é atualizado de forma consistente.
A atualização das modificações médias de saldo de um movimento ocorre no período da data de lançamento. Além disso, para
determinar o saldo médio no sistema de informações, os saldos do mês anterior procedentes do ledger 8A, que não considera a
data valor, são adicionados ao saldo médio do ledger 8Z.
Uma atualização do ledger dos saldos médios apenas é possível numa atualização em diálogo das contas. Uma transferência
periódica suporta apenas a consideração da data fixada para o fim de período. Apenas os saldos podem ser avaliados; não é,
contudo, possível determinar quando é que os movimentos tiveram lugar.
29.3.8 Transporte de saldo inicial
Esta transação permite transferir saldo das contas de resultado e patrimoniais para a contabilidade do centro de lucro. As contas
do balanço são transportadas para a mesma conta do balanço, enquanto que as contas do resultado são transportadas para contas
do resultado transportado.
A funcionalidade do transporte de saldo inicial para itens do balanço também pode ser utilizada no planejamento.
Para efetuar o transporte é preciso autorizar. Uma vez autorizado poderá ser executado o programa de transporte de saldo inicial
no menu de aplicação da contabilidade de centro de lucro e efetuado para todos os lançamentos, que são transferidos da
contabilidade financeira ou entrados diretamente na contabilidade de centros de lucro eventualmente um transporte automático
de saldo inicial (em lançamentos no ano precedente).
Esta ativação tem efeito por cada mandante.
O próximo passo é a atualização das contas de resultado. Devem ser definidas as contas de resultado transportado que devem
ser utilizadas no transporte de contas de resultados. O usuário poderá atribuir várias contas de resultado transportado a cada
plano de contas através da utilização das categorias de contas de resultado. As contas de resultado transportado podem ser
CONTROLADORIA 210 de 325
idênticas ou diferentes. O plano de contas é incluído nos dados mestre da empresa durante a criação de uma empresa. Observar
que estas contas também podem ser utilizadas para o transporte de saldo inicial dos componentes FI-SL.
A conta de resultado transportado é definida para cada plano de contas e cada tipo de conta de resultado. O tipo de conta de
resultado representa um agrupamento de contas. Seu significado varia em relação a transação e defina-se à diferenciação da
determinação de contas. O significado está definido no sistema SAP e não pode ser modificado.
Por exemplo, para o lançamento de impostos é entrado o código de imposto. Para os lançamentos de compensação de impostos
em adiantamentos é entrada a chave modificadora definida para os adiantamentos, chave esta que foi determinada por tipo de
conta, código do livro do Razão Especial e conta de reconciliação.
Para lançamentos de contrapartidas estatísticos é entrada uma sigla de duas posições, cuja 1ª posição é o tipo de conta e a 2ª
posição é o respectivo código de livro de Razão Especial.
Em lançamentos de contrapartida para contabilizações da conta do balanço é entrada uma chave que se encontra atribuída ao
tipo de movimento e à cadeia de contabilização.
29.4 Organização empresarial
A partir da versão 4.6 foi disponibilizada em função em CO, Organização Empresarial que permite visualizar todas as
unidades organizacionais em uma só tela (empresas, centros de custos, centros de lucro, Área de Contabilidade de Custos, etc.)
de forma gráfica facilitando a compreensão da estrutura organizacional implementada.
O primeiro passo é definir um variante de planificação ativa. Somnet uma das variantes de planificação criadas no sistema pode
estar ativa. O sistema workflow considera esta variante de planificação (com o conteúdo) como a única variante de planificação
válida. Recomenda-se narcar a variante de planificação 01 como variante de planificação ativa. Todos os modelos workflow
fornecidos existem automaticamente na variante de planificação marcada como ativa.
A atualização de uma variante de planificação ativa pertence às configurações que são executadas no "customizing automático".
Executar o "Auto-customizing" de forma imediata, uma vez que assim são efetuadas outras configurações importantes. É
possível encontrar o "Auto-Customizing" no guia de implementação em SAP Business Workflow -> Atualizar configurações
standard para SAP Business Workflow. Se já foi definida uma variante de planificação ativa, esta não será sobregravada
através do "customizing automático".
29.5 Dados mestre
29.5.1 Centro de Lucro
Um Centro de Lucro é uma unidade organizacional definida para fins gerenciais internos, normalmente, definidos do ponto de
vista de responsabilidades, como “empresas” dentro da empresa. A principal diferença entre um Centro de Lucro e uma Divisão
(FI) é que os centros de lucros são usados para controles internos enquanto as Divisões são mais direcionadas para um visão
externa e, por este motivo, são definidas em FI.
Os centros de lucro são as unidades organizacionais cujo resultado se deseja analisar individualmente. Podem ser definidos de
acordo com o produto (linha, divisão), áreas geográficas (região, escritório, fábrica) ou funções (produção, vendas). Assim, ao
contrário dos objetos de resultado de CO-PA, que permite obter diversas visões diferentes conforme o enfoque, em EC-PCA,
obtém-se uma visão mais estática, definida na constituição dos centros de lucro.
Naturalmente que, escolhido um critério ou uma combinação deles, todos os centros de lucro deverão ser criados seguindo esta
mesma linha. Portanto, a empresa deverá optar por uma destas alternativas escolhendo a que melhor represente o cenário da sua
empresa.
As transferências de mercadorias entre centros de lucro podem ser valorizadas tanto pelo preço legal (externo), preço do
grupo(interno) ou um preço interno especialmente definido.
Todo centro de lucro é associado a uma área de contabilidade de custos. Deve ser criada uma hierarquia (organograma) de
centros de lucro da mesma forma que para os centros de custos. A Hierarquia Standard deve conter todos os centros de lucro de
forma que o nó principal tenha uma visão de toda a Área de Contabilidade de Custos. A hierarquia standard é criada e
vinculada à Área de Contabilidade de Custos como ocorre com o Centro de Custo.
Da mesma forma que para os centros de lucros, além dos nós da hierarquia, podem ser criados grupos de centros de lucro com o
mesmo propósito.
CONTROLADORIA 211 de 325
Empresa
Administrativo Financeiro Produtos
Veícu losAcessóriosDepartamento TécnicoVendas e Marketing
Se a estrutura de centros de lucro for semelhante a estrutura de centros de custo, pode ser usada a função de cópia para gerar a
estrutura de centros de lucro a partir da estrutura de centros de custo. Em seguida, os grupos de centro de lucro podem ser
alterados. Também é possível copiar os grupos dos centros de custos. Só não é possível copiar grupos uma hierarquia standard
para um grupo e vice-versa.
Assim como os centros de custo, os centros de lucro também possuem um período de validade. O cadastro de centros de lucro
também é dependente do tempo, ou seja, podem ser armazenadas informações diferentes para cada período de tempo. Também
um centro de lucro pode ser bloqueado, temporariamente, para não receber lançamentos. Se o centro de lucro for bloqueado, o
sistema não permitirá que sejam efetuados lançamentos para nenhum objeto de custo que esteja vinculado a este centro de
lucro.
29.5.2 Materiais representativos
Um material representativo é um material que representa um grupo de materiais com características semelhantes. Por exemlpo,
difernetes materiais que tenham um processo produtivo semelhante ou um estrutura de custos semelhante podem ser agrupados
em um material representativo.
Quanto se tem um grande número de variações de um mesmo materiais cadastrados individualemtne, podem ser útil selecionar
um destes materiais para representar todos. Muitas vezes, não faz sentido gravar dados reais, planejar e definir preço interno a
nível de material. Através do material representativo, podem ser gravados e analizados dados reais e planejados por produto ou
grupo de produto.
Um material representativo pode ser ou um pateria que compõe um grupo ou um material adicional criado com este objetivo.
Em ambos os casos é necessário criar um mestre de materiais no sistema da mesma forma de qualquer material. Normalmente,
produtos acabados e semi-acabados utilizam materiais representativos.
A criação de materiais representativiso é feita no customizing. Podem ser definidas as regras para derivação do material
representativo. Os materiais podem ser associados na nível de área de contabilidade de custos, empresa ou área de depreciação
ou qualquer combinação dos três.
29.5.2.1 Ativar materiais representativos
A ativação de um material representativo para determinados materiais é efetuada em cada área de contabilidade de custos, por
cada código de agrupamento de avaliação e por cada classe de avaliação, isto é basicamente por cada conta de estoque de
material.
CONTROLADORIA 212 de 325
O código de agrupamento de avaliação indica um agrupamento de áreas de avaliação com o objetivo de facilitar a
administração da tabela de conta fixa, através de um número mínimo de entradas. Além de outros fatores, o código de
agrupamento de avaliação determina as contas do Razão, nais quais um movimento de mercadorias será registrado
(determinação de contas automática).
A classe de avaliação é um valor proposto para a classe de avaliação para estoques avaliados para este material. A classe de
avaliação permite, por um lado, o lançamento dos valores de estoque de materiais do mesmo tipo de material em contas do
Razão diferentes e por outro lado, o lançamento dos valores de estoque de materiais de tipos de material diferentes na mesma
conta do Razão.
Em conjunto com outros fatores, a classe de avaliação determina as contas do Razão que são atualizadas no caso de uma
operação relevante para avaliação (p.ex. movimento de mercadoria).
O controle de avaliação está instalado na determinação de conta da administração de materiais. Isto é efetuado no customizing
da administração de materiais em determinar controle de avaliação e agrupar áreas de avaliação. As classes de avaliação
estão atualizadas nos registros mestre de material. Isto acontece no customizing da administração de materiais em determinar
classes de avaliação.
OBS: A derivação dos materiais representativos não devem ser ativados para as matérias-primas. Este fato pode conduzir a
longos tempos de execução do programa.
29.5.2.2 Selecionar materiais representativos
Informar os números dos materiais que deverão funcionar como materiais representativos na área de contabilidade de custos.
Os materiais deverão estar cadastrados no mestre de materiais.
29.5.2.3 Derivar materiais representativos
As regras de derivação determinam os materiais representativos para materiais individuais ou para intervalos de materiais. É
possível derivar um material representativo de um dos seguintes campos de origem ou de uma combinação destes campos:
área de contabilidade de custos
empresa
área de avaliação
Através da combinação destes campos de origem, é possível determinar diversas etapas de derivação sucessivas. Selecionar
para isso processar -> selecionar ou processar -> criar etapa .
Pode-se atualizar várias regras de derivação por etapa de derivação em saltar -> atualizar entradas de regras . Estas são
executadas pelo sistema sucessivamente. Assim que sobre uma regra de derivação é encontrado um valor proposto para o
campo destino, este é aceite e não serão mais executadas as restantes regras de derivação e etapas de derivação.
Possivelmente não estão definidas todas as características em todos os lançamentos. Se o sistema não encontrar, para um
lançamento, uma proposta para nenhuma das entradas de regra contidas em uma etapa de derivação, passa para a próxima etapa
de derivação.
Deve ter-se em consideração, que as estratégias de derivação complexas aumentam significativamente os tempos de execução
do programa.
De modo a garantir uma consistência dos materiais representativos, deve efetuar-se a atribuição no nível da área de
contabilidade de custos.
Observações
Se o código saída de mensagem de erro foi ativado para uma etapa de derivação em processar -> selecionar na ficha de
registro características segue se um aviso assim que não estiver atualizada nenhuma entrada de regra para o lançamento atual.
A etapa de derivação correspondente será então encerrada e as etapas de derivação existentes não serão mais executadas. Para
evitar isso é necessário entrar uma entrada de regra para todas as combinações possíveis de valores de origem.
Na mesma ficha de registro pode ser definido, que entradas de regra devem ser atualizáveis com data de validade. Assim existe
a possibilidade de desativar provisóriamente entradas por exemplo para fins de teste sem que estas tenham de ser eliminadas.
O transporte das regras de derivação deve ser acionado manualmente. Selecionar para este efeito suplementos -> transporte.
CONTROLADORIA 213 de 325
29.5.3 Síntese de atribuição de centro de lucros a outros objetos (Assignment Monitor)
A síntese de atribuição permite visualiar e auxiliar na construção e alteração de todas as associações entre os vários objetos.
Podem ser listas dos objetos não associados para um determinado tipo de objeto ou objetos de um determinado tipo de objeto
associados a um centro de lucro em particular.
O menu de Materiais também contem um opção de Associação rápida qua permite associar um grande número de materiais a
um centro de lucros rapidamente.
Para os centros de custos, além das visões já mencionadas, também podem ser listados os centros de lucros para os quais
nenhum centro de custos foi asssociado.
O menu Ordens permite analisar associações para os senguitnes tipos de ordem: ordem interna, ordem de delimitação, ordens
de produção de CO, ordens de produção de PP, ordens de processo, diagramas de rede e ordens de manutenção.
O menu objetos de custos contém os objetos de custos gerais bem como os objetos de custos para processo de manufatura.
29.6 Transferência de contas patrimoniais
Como já foi dito, é possível analisar contas patrimoniais por centro de lucro já que os responsáveis por um centro de lucro
respondem não só pelo resultado mas também pelo investimento de capital aplicado ao centro de lucro. É importante, para
análise calcular o sucesso do centro de lucro em função do capital aplicado, por exemplo (ROI). As contas patrimoniais podem
ser transferidas on line ou periodicamente.
29.6.1 Transferência periódica
No encerramento do período podem ser transferidas as contas referentes a contas a pagar, contas a receber, estoques de
materiais, ativos e WIP. As contas a pagar e a receber podem ser transferidas no final do período ou no decorrer do período
sempre que desejado. A cada transferência, o sistema elimina as transferências anteriores do mesmo período. O processo se
divide em etapas:
Etapa 1
As contas a pagar e a receber a serem dividiades são calculada em FI no final do período através da opção do menu Contabilide
Contabilidade financeira Razão Processamento periódico Enecerramento reagrupar ajuste patrimonial
ajuste de cálculo de B/S.
Informe a empresa para a qual deseja executar o cálculo. Para estas empresa, as contas serão divididas de acrodo com os
centros de lucro e as divisões (divisão). Para acessar os documentos de FI após o cálculo pode ser usado o relatório padrão:
documento de FI para contas a pagar e a receber.
(see Standard Report Painter Reports in Profit Center Accounting).
You can display the breakdown of payables and receivables for each FI document under the menu option
Environment Subsqt BA/PA adjstmt.
Etapa 2
Os dados podem ser transferidos para PCA. Não selecione a próxima opção do menu lançar ajustes de B/S em FI. Ao contrário,
transfira os dados para PCA através da opção Lançamentos reais Encerramento de período Transferir contas a pagar e a
receber. É apresentada uma lista de todas as empresas ativas na área de contabilidade de custos. Selecione as desejadas e infor
período e ano fiscal. O sistema transfere os valores nas contas de conciliação do razão sem gerar nenhum documento em FI
associando ao centros de lucro atráves de documento contábeis.
First the program updates the final balance of open receivables and payables. It also determines the final balance of the previous period and updates this with a minus ("-") sign. As a result, the summary records in each period contain the movements in the payables and receivables, as is customary in Financial Accounting. This indirect method has the advantage that you do not need to carry the balance forward in Profit Center Accounting at the end of the year. The total balance of open payables and receivables is posted to the period 01 if there is no balance in period 0.
If you want to create your own Report Writer reports, note that you obtain the final balance of a period by adding up the summary records of the periods 0 through the desired period.
Prerequisites
CONTROLADORIA 214 de 325
Even if you decide to transfer balance sheets in realtime, you must first run the corresponding transfer programs, to create the opening balances.
Features
When you run the transfer program for the first time, the system calculates the opening balance via the source application, and transfers it to Profit Center Accounting. In subsequent periods, the system calculates the balance and posts the difference between this and the opening balance of the period in question to Profit Center Accounting.
If line items are created during the transfer, the accompanying reports do not provide you with the difference, but the current balance for each object (material, asset, debtor, creditor) and Profit Center.
All of these programs provide a Management function that allows you to see when what data has already been transferred.
You can also delete any management information that you no longer need. You cannot delete current entries, since the system still requires these.
If you run a manual transfer, the system overwrites any corresponding data that was already transferred to Profit Center Accounting. For example, if certain material stocks have already been transferred in realtime and you want to run a periodic transfer for the same period, the system first deletes the data that was already transferred. When this happens, you lose the information on the inventory posting documents for each transaction. The periodic transfer programs only create one posting per object, which contains the previous balance (the difference in the balance for work in process).
Activities
You can find details of the different kinds of periodic transfer under:
Period Closing Activities for Payables/Receivables
Period Closing Activities for Payables and Receivables l
Period Closing Activities for Material Stocks
Period Closing Activities for Work in Process
Period Closing Activities for Assets
29.6.2 Transferência on-line
The following balance sheet items can be transferred online in realtime:
Material stocks
Assets
Work in process
Other balance sheet items (transaction-based only)
The system posts balance postings directly to Profit Center Accounting from online postings which directly affect the balances of assets, materials and work in process. If you have line items in Profit Center Accounting, the system updates a profit center document for each reference document (e.g. MM or FI document).
Integration
In order to transfer assets online to Profit Center Accounting, you must be using the component Assets Accounting (FI-AA).
In order to transfer material stocks online to Profit Center Accounting, you must be using the component Materials Management (MM).
In order to transfer work in process online to Profit Center Accounting, you must be using results analysis in the component Product Cost Controlling (CO-PC).
Prerequisites
You first need to enter the accounts you want to transfer to Profit Center Accounting in the Customizing transaction for balance sheet and profit and loss accounts.
CONTROLADORIA 215 de 325
In addition, you need to run each program once to create the opening balance for materials, work in process and assets from the source application (see Transferring Balance Sheet Items Periodically). For further information, see:
Period Closing Activities for Material Stocks
Period Closing Activities for Work in Process
Period Closing Activities for Assets
Note that if you have also created asset accounts as statistical cost elements (type 90) to update investment orders, you must still treat these the same way as normal balance sheet accounts. Updating in realtime in Profit Center Accounting is only possible if you have entered the accounts as additional balance sheet accounts and P&L accounts in Customizing.
You must post the opening balance for other balance sheet items to transfer online by creating the documents manually, as transfer reports cannot be carried out here. You also have to assign a default profit center to each of the accounts in question in Customizing for Profit Center Accounting. When posting in FI, however, you can set a different profit center manually. You can also define derivation rules for finding the profit center, where no profit center has been set for a posting. See Derivation Rules for Finding the Profit Center in the Implementation Guide (IMG) for Profit Center Accounting. You can find further information about derivation in the documentation for Profitability Analysis (CO-PA) under Characteristic Derivation.
When you assign down payments to a work breakdown structure element, the system finds the profit center to which it is assigned. It can therefore make sense to transfer down payments online.
Features
After you have created the opening balance, the system always transfers the difference between the new balance and the previous balance.
At the end of the year, you need to carry forward the balances for the balance sheet items that were posted in realtime to Profit Center Accounting.
The system assigns work in process to profit centers by taking the assignment of open production order, projects, sales orders etc. (see Profit-Center-Assignments).
The system assigns assets to profit centers indirectly, via assigned internal orders or cost centers (see Assigning Assets). The program transfers the acquisition and product costs, as well as cumulated value adjustments.
The system assigns material stocks by taking the assignment in the material master record, in the plant segment (see Assigning Materials). The system assigns valuated sales order stocks via the sales document item or the WBS element.
If you run a manual transfer, the system overwrites any corresponding data that was already transferred to Profit Center Accounting. For example, if certain material stocks have already been transferred in realtime and you want to run a periodic transfer for the same period, the system first deletes the data that was already transferred. When this happens, you lose the information on the inventory posting documents for each transaction. The periodic transfer programs only create one posting per object that contains the balance from the previous period (or the difference to this balance for work in process).
Features
The graphic below illustrates the flow of data from other components to Profit Center Accounting, as occurs when balance sheet items are transferred online.
29.7 Sistema de Informação
Os relatórios standard do R/3 são baseados em uma divisão de acorod com a contabilização periódica. Para analisar resultados
usando o custos de vendas, no entanto, é necessário encontrar a área funcional especificada em FI ou CO. Uma vez que estas
áreas e as regras de sua utilização podem ser definidas, é preciso definir seus próprios relatórios.
Através do sistema de informações é possível comparar o planejado para o centro de lucro com o real. Ao contrário de CO-PA,
os centros de lucro trabalham com contas patrimoniais. Em CO_PA é preciso trabalhar com campos de valores. Os relatórios
tanto podem ter índices de contas patrimoniais (ativo, material em processo, estoque) como contas de resultado. Permite ainda o
cálculo de índices financeiros como o ROI e a identificação dos objetos geradores dos custos.
CONTROLADORIA 216 de 325
29.7.1 Relatórios standard de Centro de Lucro
A árvore de relatórios disponibilizada no R/3 engloba um série de relatórios do Report Painter reunidos em grupos que,
normalmente, consiste de dois relatórios de um mesmo tipo (tais como comparação de real/planejado). Cada relatório pode ser
executado inluindo ou não as movimentações entre empresas (entre centros de lucros). Na execução dos relatórios, deve ser
escolhida uma das visões.
29.7.1.1 Relatórios orientados por lista
8A22 S_ALR_87009734 - Grupo de centros de lucro: plano/plano/real
8A26 S_ALR_87013340 - Grupo de centros de lucro: planejado/real/desvio
8A2A S_ALR_87009712 - Lista de centros de lucro planejado/real
8A2C S_ALR_87009717 - Grupo de centros de lucro: comparação trimestral real
8A2F S_ALR_87009726 - Grupo de centros de lucro: planejado/real/desvio segund
8A80 S_ALR_87013342 - Centro de lucro: índices estatísticos
29.7.1.2 Partidas Individuais
KE5Z - Centro de lucro: partidas individuais reais
KE5Y - Centro de lucro: partidas individuais planejadas
29.7.1.3 Partidas em aberto
8A98 S_ALR_87013343 - Centro lucro: contas a receber
8A99 S_ALR_87013344 - Centro lucro: contas a pagar
29.7.1.4 Contas patrimoniais transferidas periodicamente
8A90 S_ALR_87013345 - Centro de lucro: clientes (transfer.periodicamente)
8A91 S_ALR_87013346 - Centro de lucro: fornecedores (transfer.periodicamente)
8A92 S_ALR_87013347 - Centro de lucro: imobilizado (transfer.periodicamente)
8A93 S_ALR_87013348 - Centro de lucro: materiais (transfer.periodicamente)
29.7.1.5 Funções especiais
2KEE - Centro de lucro: registros de totais
KE5X - Centro de lucro: índice de dados mestre
29.7.1.6 Ledger de Saldos médios
8A50 S_ALR_87013349 - Centro de lucro: saldo médio YTD / contas
8A51 S_ALR_87013350 - Centro de lucro: saldo médio YTD/centro de lucro
8A52 S_ALR_87013351 - Centro de lucro: saldo médio período/contas
8A53 S_ALR_87013352 - Centro de lucro: saldo médio período/centro de lucro
29.7.1.7 Cenário ALE descentralizado
S_ALR_87013354 - Grupo de centros de lucro: ALE plan./real/desvio grupo
CONTROLADORIA 217 de 325
29.7.1.8 Preços Internos
S_ALR_87013355 - Centro de lucro: preços ints.: reconcil.planejamento balanço
29.7.1.9 Transferência de Dados a EIS
8AE1 S_P99_41000117 - CCL-dados reais: transmissão a EIS
8AE2 S_P99_41000118 - CCL-dados planejados: transmissão a EIS
Na atualização de release, os relatórios padrões são importados somente para o mandante 000. É preciso transportá-los para o
seu mandante e gerá-los.
29.7.2 Relatórios Drilldown standard de Centro de Lucro
Diversos relatórios drilldown são disponibilizados com o R/3. Com exceção das comparações de centro de lucro, todos os
relatórios podem ser processados a nível de centro de lucro ou grupo de centros de lucro.
29.7.2.1 Reporting interativo
8A-PCA001G S_ALR_87013326 - Grupo de centros de lucro: planejado/real/desvio
8A-PCA001 Centro de Lucro: planejado/real/desvio
8A-PCA002 S_ALR_87013327 - Comparação de centros de lucro planejado/real/desvio
8A-PCA002G S_ALR_87013330 - Grupo de centros de lucro: planejado/planeado/real comp
8A-PCA005 S_ALR_87013332 - Grupo de centros de lucro: período atual/acumulado/ano
S_ALR_87013334 - Grupo de centros de lucro: comparação trimestral real 2
8A-PCA013G S_ALR_87013336 - Grupo de centros de lucro: contas patrimoniais planejado/real
8A-PCA004 Centro de Lucro: comparação planejado/planejado/real
8A-PCA004G Grupo de Centro de Lucro: comparação planejado/planejado/real
8A-PCA005G Grupo de Centro de Lucro: período corrnete, acumulado anula até a data
8A-PCA006 Centro de Lucro: comparação período corrnete, acumulado anula até a data
8A-PCA008 Centro de Lucro: coparações trimestral de dois anos
8A-PCA008G Grupo de Centro de Lucro: coparações trimestral de dois anos
29.7.2.2 Reporting interativo – índices estatísticos
8A-PCA010 Key figures: profit center
8A-PCA010G Key figures: profit center group
8A-PCA011 Return on investment: profit center comparison
29.7.2.3 Special Functions ® Decentralized ALE-Scenario
8C-PCA001 ALE plan/actual/variance: profit center
8C-PCA001G ALE plan/actual/variance: profit center group
Para ver informações, selecione Contabilidade de Centro de Lucro Sistema de Informações Ferramentas Report
Painter Relatórios Drilldown Exibir
CONTROLADORIA 218 de 325
30 Procedimento para encerramento de período em CO
30.1 Pré-requisitos
Antes de Iniciar o processo de apuração dos custos e encerramento mensal em CO, alguns aspectos abaixo relacionados devem
ser verificados:
1. As depreciações do ativo fixo já devem estar efetuadas nas três unidades.
2. Todos os lançamentos em FI, MM ,etc. que afetam as contas de despesas no mês a ser processado já deverão ter sidos
efetuados, ou seja, depois de iniciado o processo de apuração nenhum lançamento que afete as contas de despesas poderá
ser efetuado, seja em FI, em MM ou outro módulo qualquer.
3. Todos os lançamentos da produção e da manutenção já deverão estar encerrados, ou seja, nenhuma ordem poderá receber
lançamento, ser encerrada ou ter seu encerramento anulado dentro do período que será encerrado.
4. O mês subseqüente já deverá ter sido diferido, ou seja não é permitido fazer o encerramento do mês atual.
30.2 Bloquear operações em CO
Para garantir que não sejam efetuados mais lançamentos que afetem os custos, algumas operações podem ser bloqueadas no
início do procedimento de fechamento (ver tabela abaixo).
Transação Controlling Contabilidade Centros de Custos Ambiente Bloqueio de Períodos
OKP1 – Modificar
Operação Descrição Bloq
Adiantamento
Lançamentos referentes adiantamentos a fornecedores associados a
pedidos de compra para investimento (controlado por ordens internas de
imobilizações em andamento)
X
Alocação atividade teórica = real Alocação indireta de atividade tomando como base na proporção dos
consumos de atividade planejados/reais dos receptores
Alocação de custos manual Transação de lançamento manual que pode ser usada para ajustes dos
saldos dos centros de custos
Alocação de modelo real Alocação de atividades usando modelos
Apropriação de custos real
Lançamentos de apropriação de custos das ordens para centros de
custos, materiais, investimentos, etc. – corresponde a uma das etapas do
fechamento
Atividades não sujeitas a compensação –
Real X
Avaliação posterior para tarifa real
Centros de custos divisão real X
Compensação atividades indireta Real
Compensação atividades – Real
Correção segmento lançamento periódico
real
Função para acertar lançamentos de transferência periódica de períodos
anteriores já encerrados
Correção segmento distribuição real Função para acertar lançamentos de distribuição de períodos anteriores
já encerrados X
Correção segmento rateio real Função para acertar lançamentos de rateio de períodos anteriores já
encerrados X
Delimitação de centros de custo – Real Função de lançamentos de provisões de CO, normalmente não é muito
usada X
CONTROLADORIA 219 de 325
Operação Descrição Bloq
Determinação automática WIP/resultado Cálculo do WIP e do Resultado – uma das etapas do processo de
encerramento
Determinação manual WIP/resultados
Determinação de desvios Cálculo dos desvios de centros de custos, ordens, etc. – é uma das
etapas do processo de encerramento
Determinação de tarifa real Cálculo da tarifa real para os centros de custos – corresponde a uma das
etapas do processo de fechamento
Distribuição de custos reais – objeto de
custo
Distribuição de custos indiretos reais
Entrada de ordens: determinação
automática X
Entrar índices estatísticos É uma das etapas do processo de encerramento
Lançamentos diretos em CO por FI Pode ser necessário para lançarmentos de ajuste durante o fechamento
Pré-distribuição custos fixos É uma das etapas do processo (é executada automaticamente para
transação de cálculo de tarifa real)
Rateio a resultado Rateio tendo como receptor CO-PA
Rateio custos indiretos real É uma dos procedimentos para zerar os centros de custos X
Rateio processo real ABC Custeio ABC não implementado X
Suplementos periódicos - Real
Transferência da SIL (sistema de
informação de logística) de índices
estatísticos reais
Não está sendo usado X
Transferências periódicas reais Está sendo no processo para transferência dos custos de energia elétrica
Transferência de custos Rotina para acertos de lançamentos vindos de outros módulos para CO
– pode ser necessário para ajustes
Transferência de receitas CO não está trabalhando com lançamentos de receitas X
Transferência de partidas individuais em
CO
Rotina para acertos de lançamentos vindos de outros módulos para CO
– pode ser necessário para ajustes
30.3 Lançar índices estatísticos para os centros de custos ou ordens
Se os processos de alocação forem definidos com base em índices estatíticos, é preciso efeutar os lançamentos dos índices
estatísticos definidos como tendo atualização mensal obrigatória ou efetuar a transação de importação destes índices do SIL
(Sistema de Informação de logística).
Transação Controlling Contabilidade Centros de Custos Lançamentos reais Índices
Estatísticos KB31N – Entrar
Índice estatístico
Transação
Controlling Contabilidade Centros de Custos Encerramento do Período
Funções Individuais Transferências KVA5 - Índices estatísticos independentes da
atividade SIL Lançamentos reais
E
Controlling Contabilidade Centros de Custos Encerramento do Período
Funções Individuais Transferências KDA5 - Índices estatísticos dependentes da
atividade SIL Lançamentos reais
Índice estatístico
CONTROLADORIA 220 de 325
30.4 Alocar os custos de energia elétrica para os centros de custos
Os custos de energia elétrica, nromalmente, são lançados via provisão de FI para ordem interna criada para cada unidade para
posterior distribuição através de CO. A primeira etapa do processo de apuração dos custos, portanto, é alocar os custos destas
ordens internas através de transferência periódica para os centros de custos (os lançamentos normalmente são efetuados na
mesma conta)
Transação Controlling Ordens Internas Encerramento Período Funções Individuais
KSW5 – Transferência periódica
Ciclo de Alocação
30.5 Alocar os custos de centros de custos para mais de uma unidade fabril
Sempre que existirem centros de custos que prestam atividades para mais de uma unidade fabril, é preciso efetuar
primeiramente a alocação dos seus custos, seja via rateio, distribuição, transferência períodica ou alocação indireta de atividade
ou mesmo via lançamento manual.
Transação Controlling Contabilidade de Centros de Custos Encerramento Período Funções
Individuais Alocação ????
Ciclo de Alocação
2º PASSO:Após este procedimento, todos os custos dos centros de custos emissores estarão totalmente alocados para os
receptores. Ou seja, seus saldos deverão estar zerados. É recomendável verificar se o saldo dos centros de custos emissores
estão zerados antes de passar para a próxima etapa.
Transação
Controlling Contabilidade de Centros Custos Sistema Info Relatório para
Contabilidade de Centros de Custos Comparação Planejado/Real
S_ALR_87013611 – Centros de custo: real/planejado/desvio
Grupo de Centros
Custos
30.6 Apropriar os custos de Manutenção
1º PASSO: Alocar os custos da Supervisão de Manutenção para os centros de custos de manutenção através de alocação
manual de abaixo. Este procedimento é mais indicado do que o rateio (ou outro processo de alocação) visto que alguns centros
de custos de manutenção podem executar atividades para o centro de custos de supervisão. Tendo procedimentos distinto
(rateio e alocação de atividade) o SAP não consegue tratar esta recursividade. Portanto, agora, tanto a alocação dos custos dos
centros de custos de supervisão de manutenção como dos centros de custos de manutenção serão feitos através de um único
critério: alocação de atividade.
O critério para definição das quantidades de atividades pode ser o mesmo critério que seria usado para o ciclo de alocação,
como, por exemplo, número de funcionários de cada centro de custos. Pode ser criado um tipo de atividade que corresponda ao
número de funcionários.
É importante saber que o lançamento inicialmente será feito pela tarifa planejada e não pela tarifa real. Portanto, é obrigatório
que tenha sido informada uma tarifa planejada mensal. Esta atividade podem ser definidas com código (3) – Valor de tarifa
informado manualmente. O valor informado não é importante visto que o sistema será irá ajustar a diferença. No planejamento,
a alocação dos custos dos centros de custos de supervisão de manutenção podem continuar sendo feitos via rateio se desejado.
Transação Controlling Contabilidade de Centros de Custos Lançamentos reais Alocação de
atividade KB21N – Entrar
2º PASSO: Determinar as tarifas reais para os centros de custos de manutenção para todas as unidades. Neste momento, apenas
os centros de custos estarão com o valor da tarifa correto. No entanto, para que os saldos os centros de custos fiquem zerados,
será preciso, posteriormente, transferir o valor da tarifa real calculado para as ordens de manutenção, qualidade, etc..
OBS 1 : O código da tarifa real definido no planejamento do mês em processamento deve estar preenchido com 5 - Tarifa real
automática baseada em atividade. No cadastramento do planejamento, este campo é preenchido automaticamente de acordo
CONTROLADORIA 221 de 325
com o cadastro básico da atividade. Porém, ele pode ser alterado através da transação de planejamento (KP26) no layout 1-204:
Tipo de atividade: códigos de controle.
OBS 2 : Caso algum dos centros de custos cujas tarifas estiverem sendo calculadas tiver um total de atividades reais zerado,
será apresentada mensagem de erro e nenhuma tarifa será gravada. Portanto, nestes casos é preciso verificar porque o total de
atividades está zerado e, caso realmente seja zero, os custos reais do centro de custos deverão ser zerados e será preciso excluir
o centro de custo da lista de cálculo através da criação de outro grupo ou através de criação de uma variação de seleção
(transação KM1V).
Transação Controlling Contabilidade de Centros de Custos Encerramento Período Funções
Individuais KSII – Determinação de Tarifa
Grupos de Centros
Custos
3º PASSO: Transferir o valor da tarifa real calculada para as ordens de manutenção de forma a transferir todos os custos reais
dos centros de custos para as ordens zerando o saldo dos centros de custos. Definir uma variante de seleção contendo todas as
ordens de manutenção, restauração e reforma para cada unidade fabril.
Neste momento, algum dos centros de custos ainda poderá estar com saldo caso esteja recebendo custos de alguma ordem de
manutenção. Neste caso, o saldo será zerado somente após a liquidação das ordens (próximo passo).
Transação Controlling Ordens Internas Encerramento Período Funções Individuais Reavaliação de
Tarifas reais KON2 – Processamento Coletivos
Variantes de
seleção
4º PASSO: Liquidar as ordens de manutenção para transferir os saldo das ordens para os centros de custos de custos que
receberam o serviço prestado. Após este processamento, todos os centros de custos de manutenção e as ordens de manutenção
deverão estar com o saldo zerados. O procedimento deverá ser refeito caso ainda haja saldo. O próximo item mostra como
verificar o saldo dos centros de custos e das ordens.
Transação Controlling Ordens Internas Encerramento Período Funções Individuais Apropriação de
Custos KO8G – Processamento Coletivo
Variantes de
Seleção
5º PASSO: Verificar se o saldo das ordens de manutenção estão com os saldos zerados. Neste momento todas as ordens
deverão estar com os saldos zerados com exceção das ordens de restauração em aberto. As ordens de restauração são liquidadas
para estoque e o seu saldo somente será zerado depois que a ordem estiver encerrada tecnicamente. O próximo passo detalha
como retirar o valor referente a estas ordens das contas de despesas de forma a permitir o fechamento do balanço.
Caso alguma ordem de manutenção permaneça com saldo, executar a liquidação individual para verificar melhor a mensagem
de erro e definir o procedimento a ser adotado para correção do problema (transação: KO88).
Transação Controlling Ordens Internas Sistema Info Relatórios para Ordens Internas
Outros Relatórios KOC4 – Análise de Custos
Categoria de Ordens 30 (com exceção das ordens de restauração)
Consultar período acumulado (janeiro até ano corrente).
Variante de exibição Criar uma variante de exibição que liste apenas as ordens de apresentarem saldo diferente
se zero.
6º PASSO: No caso das ordens de restauração, o sistema não calcula WIP porque não são ordens de produção. No entanto,
contabilmente o procedimento deveria ser o mesmo. Portanto, o lançamento destes casos deve ser manual. Na implantação, foi
sugerido que se trabalhasse de forma que ordens de restauração não passassem em aberto de um mês para outro. Verificar o
saldo das ordens de restauração em aberto e Transferir os valores referente a estas ordens das contas de despesas através de
uma conta de transferência via lançamento manual em FI.
OBS 1 : As contas de WIP (estoque) e a conta de transferência de WIP normalmente estão configuradas para só aceitar
lançamentos automáticos. Antes de efetuar o lançamento, portanto, é preciso desbloquear estas contas e bloqueá-las novamente
após o lançamento (transação: FS00 – pasta Entrada/banco/juros).
CONTROLADORIA 222 de 325
Transação Contabilidade Financeira Razão Lançamento FB50 – Entrar documento de conta do
Razão
Conta de débito Produção em andamento – estoque
Conta de Crédito Produção em andamento – transferência
7º PASSO: Verificar se o saldo dos centros de custos de manutenção estão com os saldos zerados.
Transação
Controlling Contabilidade de Centros Custos Sistema Info Relatório para
Contabilidade de Centros de Custos Comparação Planejado/Real S_ALR_87013611 –
Centros de custo: real/planejado/desvio
Grupo de Centros
Custos
Criar um grupo ou uma variação de seleção com as ordens de manutenção
OBS 1 : Sempre que for efetuada qualquer alteração em uma ordem de manutenção ou nos custos dos centros de custos
emissores, todo o processo deve ser refeito a partir da determinação cálculo da tarifa real do centro de custos (1º passo)
Transações Auxiliares
Transação Descrição
Modificar Ordens de Manutenção
IW33 Consultar Ordens de Manutenção
IE03 Consulta Equipamento
OKOV Criar variante seleção
KSH1 Criar Grupos de Centro de Custos
CO03 Consultar ordens internas
30.7 Alocar os custos dos centros de custos produtivos para as ordens de produção.
1º PASSO: Os centros de custos que não estão ligados diretamente aos processos produtivos, como o os centros de custos de
gerência, climatização, planejamento e controle da produção, deverão ter seus custos rateados para os centros de custos
realmente produtivos. Estes centros de custos, por sua vez, terão seus custos zerados através de alocação de atividades para as
ordens de produção. Transferir os custos dos centros de custos produtivos indiretos para os centros de custos diretos através de
rateio.
Transação Controlling Contabilidade de Centros de Custos Encerramento Período
Funções Individuais Alocação KSU5 – Rateio
Variante de seleção Criar uma variante de seleção com os ciclos de rateio a serem executados na ordem
que precisam ser executados
2º PASSO: Verificar se o saldo dos centros de custos indiretos de produção estão com os saldos zerados.
Transação
Controlling Contabilidade de Centros Custos Sistema Info Relatório para
Contabilidade de Centros de Custos Comparação Planejado/Real S_ALR_87013611 –
Centros de custo: real/planejado/desvio
Grupo de Centros
Custos
Criar uma variante: .PRODIND que engloba os Centros de custos indiretos de produção
3º PASSO: A próximo passo é a determinar as tarifas reais para os centros de custos produtivos de todas as unidades fabris para
zerar transferir os custos destes centros de custos para as ordens de produção e posteriormente para os materiais (seja estoque,
seja CPV). Para que os custos sejam realmente transferidos, é preciso transferir este novo valor de tarifa para as ordens de
produção (próximo passo).
CONTROLADORIA 223 de 325
Transação Controlling Contabilidade de Centros de Custos Encerramento Período Funções
Individuais KSII – Determinação de Tarifa
Grupos de Centros
Custos Criar uma variante .CC-PROD que contem os Centros de custos diretos de produção
4º PASSO: Transferir a tarifa real calculada nos centros de custos produtivos para as ordens de produção e coletores de custos.
Este processo deve zerar os saldos dos centros de custos de produção direta.
OBS: Por questões de arredondamento, pode sobrar valores residuais (centavos) nos centros de custos. Estes valores precisam
ser transferidos via rateio para um conta de resultado. Este procedimento é detalhado posteriormente.
Transação
Controlling Controlling de Custos de Produtos Contabilidade de Objetos de Custos
Controlling de objeto por ordem Encerramento de período Funções Individuais
Reavaliação de Tarifas reais CON2 – Processamento Coletivo
5º PASSO: Ratear os saldos residuais dos centros de custos produtivos para uma conta de resultado. Este valores são da ordens
de centavos.
Transação Controlling Contabilidade de Centros de Custos Encerramento Período Funções
Individuais Alocação KSU5 – Rateio
Ciclo de Rateio
2º PASSO: Transferir os custos das ordens internas para FI através da liquidação das ordens
Transação Controlling Ordens Internas Encerramento Período Funções Individuais
Apropriação de Custos KO88 – Processamento Individual
Ordens
Os lançamentos que serão efetuados em FI estão relacionados abaixo
Ordem Conta crédito Conta débito
200.000 Transferência Resultado
6º PASSO: Verificar se os centros de custos produtivos estão com os saldos zerados. Neste momento todos os centros de custos
produtivos (diretos e indiretos) deverão estar com os saldos zerados. Os centros de custos administrativos e comerciais somente
terão seus saldos zerados no final do processo em função das alocações para os centros de custos comerciais das amostras.
Transação
Controlling Contabilidade de Centros Custos Sistema Info Relatório para Contabilidade de
Centros de Custos Comparação Planejado/Real S_ALR_87013611 - Centros de custo:
real/planejado/desvio
Grupo de Centros
Custos Variante: .CC-PROD – Centros de custos de produção direta
30.8 Alocar os custos das ordens de produção para os produtos.
1º PASSO: Neste momento as ordens de produção estão com os custos reais lançados. Os custos de materiais já foram lançados
para as ordens através das requisições lançadas no decorrer do período, as produções (entregas para estoque) também já foram
lançadas. Os custos de mão-de-obra já foram ajustados para os valores reais. O primeiro passo para transferência dos custos
para os materiais seria o cálculo do WIP – Material em processo para as ordens de produção e coletores de custos.
OBS 1 : O SAP não efetua nenhum lançamento de WIP através transação, os valores somente são calculados e gravados na
ordem. O lançamento efetivo (contábil) somente será efetuado pela transação de apropriação dos custos.
OBS 2 : Deixar sempre o flag de lista detalhada DESMARCADO por questões de performance. Para visualizar o WIP
calculado. Executar em seguida a relatório (transação KKAQ).
CONTROLADORIA 224 de 325
O SAP calcula o WIP de maneiras diferenciadas para ordens de produção e coletores de custos:
Para os coletores de custos, como são de natureza permanente (produção repetitiva) o sistema trabalha com o custo teórico
para apurar quando do saldo do coletor é WIP e quanto é variação de preço. Estes cálculo pode ser feito com base no custo
standard ou no custo preliminar do coletor. A SAP recomenda trabalhar com o custo preliminar.
OBS : No caso de saldos negativos para os coletores, o sistema irá sempre considerar como variação de preço (não
trabalha com provisão para custos não realizados visto que estamos falando de produção repetitiva) e irá jogar para uma
conta de resultado definida na determinação de contas de MM (transação OBYC – para a operação PRP e PRQ).
No caso das ordens de produção, a determinação do WIP depende do saldo da ordem. Se a ordem estiver encerrada
tecnicamente ou totalmente fornecida, o sistema considera o saldo da ordem como variação. Se a ordem ainda estiver em
aberto, todo o saldo da ordem será WIP. Observe que o lançamento do valor do WIP apurado para uma conta de ativo não
zera o saldo das ordens. Portanto, nem todas as ordens de produção estarão com o saldo zerado no final do período. No
entanto, o total do saldo das ordens deve ser igual ao valor de WIP apurado.
Transação
Controlling Controlling de Custos de Produtos Contabilidade de Objetos de Custos
Controlling de objeto por ordem Encerramento de período Funções Individuais Material
em processo Processamento Coletivo KKAO – Determinar
Parâmetros
Com ordens de produção
Com coletores de custos
Todas as versões de determinação de resultado
Caso ocorram erros no processamento, utilizar as transações para processamento individual (KKAS e KKAX), para analisar
melhor as mensagens de erro.
2º PASSO: O cálculo dos desvios deve ser efetuado após o cálculo do WIP e deve ser feito antes da liquidação quando se
desejar transferir os valores dos desvios apurados para CO-PA. O desvio pode ser calculado para coletores de custos, ordens de
produção e objetos de custo. O R/3 calcula o desvio do objeto por classe de custo, ou por classe de custo e origem do material.
O calculo dos desvios fornecem informações para tomar medidas para melhorias de custos. Os desvios são calculados
periodicamente para os coletores e cumulativamente para as ordens de produção.
Pré-requisitos para cálculo dos desvios:
Estimativa de cálculo de custos teóricos (padrão para as ordens e preliminares para coletores) deve ter Itemização.
Os componentes do material constantes na lista técnica da estimativa de custos usada para o cálculo dos custos teóricos
devem estar atribuídos às operações onde são usadas. Caso contrário, não será possível listar corretamente os desvios e o
refugo quando as operações são confirmadas.
Os objetos para os quais os desvios serão calculados deverão conter uma chaves de desvio válida.
No custeio por ordem, a ordem deve ter o status de LIB (DLV – liberada) ou ENTE (TABG/TECO – tecnicamente
encerrada).
O flag de origem do material na visão de custo 1 dos mestre de materiais deve estar setado para todos os componentes do
material com custo crítico, ou devem ser usados os grupos de origem. Deve forma, é possível determinar quais materiais
causaram quais desvios em cada classe de custos. O flag deve estar setado antes da criação da estimativa de custos padrão
do material.
CONTROLADORIA 225 de 325
OBS: A marcação do flag de origem ou o uso de grupos de origem aumentam o volume de dados e portanto degradam a
performance nas rotinas de encerramento mensal. Recomenda-se, portanto, a marcação deste flag somente para os
materiais que são relevantes para o custo.
Transação para
ordens
Controlling Controlling de Custos de Produtos Contabilidade de Objetos de Custos
Controlling de objeto por ordem Encerramento de período Funções Individuais Desvio
KKS1 – Processamento coletivo.
Parâmetros Com ordens de produção
Todas as versões de determinação de resultado
Transação para
coletores
Controlling Controlling de Custos de Produtos Contabilidade de Objetos de Custos
Controlling periódico de produto Encerramento de período Funções Individuais: Coletores de
Custo de Produto Desvio KKS5 – Processamento coletivo.
Parâmetros Com coletores de custo
Todas as versões de determinação de resultado
3º PASSO: Nesta etapa, liquidação das ordens, é que realmente serão gerados os lançamentos contábeis de variação de preço e
WIP e os custos das ordens encerradas (status ENTE – Encerrada tecnicamente ou FORN – Fornecida) são transferidos aos
materiais.
Transação Controlling Controlling de Custos de Produto Contabilidade de Objeto de custos
Controlling de Objetos por ordem Encerramento Período Funções Individuais
Apropriação de Custos CO88 – Processamento Coletivo
No caso de erro, processar a ordem manualmente para analisar melhor a mensagem de erro (transação para ordens KO88 e para
coletores – informando o número do coletor KO88 ou informando o código do material KK87). Normalmente ocorrem erros
em ordens encerradas cujo valor dos custos incorridos é inferior ao valor fornecido ficando a ordem com saldo credor. Neste
caso, caso não tenha estoque suficiente, o sistema não consegue apropriar a ordem.
Uma das alternativas para resolver problemas como este é reabrir a ordem anulando seu encerramento técnico e desmarcando a
remessa final (transação CO02). Neste caso, o sistema passará a considerar o valor como provisão para custos não realizados.
No entanto, esta alternativa somente adia o problema, devendo, o problema, deve ser passado para a produção fazer o acerto no
mês seguinte.
CONTROLADORIA 226 de 325
Podem ocorrer situações em que o saldo da ordem esteja negativo. Se a ordem estiver encerrada, o sistema tentará jogar este
valor para o material. No entanto, se não houver estoque disponível do material, o valor ficará pendente na ordem e precisará
ser retirado manualmente através de um lançamento em FI – (transação: FB50) transferindo o saldo da ordem para uma conta
de resultado (por exemplo, Ajuste de estoque) ou o procedimento deve ser estornado pela produção. Caso a ordem esteja em
aberto, o sistema irá interpretar como custos não realizados.
4º PASSO Verificar se o saldo das ordens de produção e coletores de custos estão com os saldos zerados. Neste momento
somente as ordens em aberto deverão estar com saldo e o somatório do saldo das ordens deverá ser igual a movimentação
lançada na conta de transferência de despesas para produção em andamento ou na conta de WIP (estoque).
Transação para verificar o
lançamento na conta contábil
Contabilidade Contabilidade Financeira Razão FS10N Saldo ou
Sistema de Informação Contabilidade Contabilidade Financeira Razão
F.08 – Lista de Saldos
Transação para apurar o saldo
das ordens em aberto
Controlling Ordens Internas Sistema Info Outros Relatórios KOC4 –
Análise de Custos
Categoria de Ordens 05 – Coletores de Custos
10 – Ordens de Produção de PP
Verificar período acumulado.
Variante de exibição que lista somente as ordens com saldo.
Alternativa para apurar saldo
das ordens
Controlling Ordens Internas Sistema Info Outros Relatórios
S_ALR_87013015 – Lista: real débito/crédito
Grupo de Ordens Usar a variante .ORD-PROD que contenha todos os tipos de ordnes da
produção
Caso o saldo total das ordens não coincida com o valor do WIP e custos não realizados, confrontar os relatórios do WIP com o
relatório gerado na transação KOC4 e verificar quais as ordens que apresentam o saldo diferente de WIP. Este procedimento
pode ser feito através de planilha eletrônica fazendo uso da função PROCV.
Somente depois de acertado o saldo de todas as ordens deve ser iniciado o processo do cálculo efetivo do custos detalhado a
seguir.
30.9 Efetuar o calculo de Custos reais.
1º PASSO: O R/3 disponibiliza uma transação que contém todos os passos necessários para o cálculo do custos real ficando
apenas a parte dos ajuste dos consumos de materiais para vendas ou para centros de custos do valor standard para o real que
deve ser efetuado pelo programa específico COGS. Todo este procedimento deve ser efetuado em conjunto com a transação
CKM3 que nos permite verificar o que está ocorrendo com o material que apresentar problemas.
Transação Controlling Controlling de Custos de Produto Cálculo de Custos reais / ledger de materiais
Cálculo de Custo real CKMLCP – Processar a execução de cálculo de custos reais.
Execução de
Cálculo Custos
Determinação de tarifa Nível Único
Neste etapa o sistema trata as variações que ocorrem na produção do material referente a divergências entre tarifas reais e
planejadas e nas quantidades de materiais consumidas ou nas alterações do preço standard dos componentes em relação ao
cálculo do preço standard do material principal. Esta variação corresponde exatamente às apropriações que o material irá
receber das suas ordens de produção ou coletores.
Caso seja necessário reprocessar a determinação de nível único é preciso alterar o parâmetro para PROCESSAR DE NOVO.
No entanto, este procedimento pode ser repetido para reprocessar apenas os materiais que apresentam erro. Nesta etapa, como o
CONTROLADORIA 227 de 325
volume de materiais da Santanense é muito grande, pode haver um estouro do log e nem todas as mensagens de erro são
exibidas. Neste caso, é preciso repetir o processo sem marcar o flag para que somente os materiais que apresentaram erros
sejam processados e todas as mensagens de erro posam ser exibidos.
Os erros nesta etapa ocorrem quando, ao tentar calcular as variações do material em relação às variações geradas no processo
produtivo, o sistema encontra uma situação de erro que pode ser:
Valor de custo real unitário negativo – ocorre quando, por exemplo, foram apontadas entregas para estoque sem consumo
ou com um consumo inferior ao real e a ordem foi encerrada tecnicamente ou totalmente fornecida. Neste caso, é precisa
acertar a ordem ou reabri-la para transferir a solução para o próximo período conforme procedimento já descrito.
Sobra valor no estoque mas a quantidade é zero – este situação é bastante específica e precisa ser analisada
individualmente.
Alternativamente, podem ser geradas mensagens de erro ou de alerta para os materiais que sofreram grandes divergências em
relação ao custos real do mês anterior ou ao preço standard atual.
Determinação de tarifa multi-nível
Esta etapa somente pode ser executada após o cálculo de nível único. Nesta etapa o sistema irá ajustar os valores de consumo
de material para a produção, ou seja, irá transferir as variações de nível único para os materiais que forma consumidores.
Assim, cada material passará a ter um valor de custo real.
Nesta etapa podem também ocorrer erros de preço real negativo pois um material consumido pode ter uma variação negativa tal
que torne o material pai negativo. Neste caso, pode-se usar alternativas de isolar os ciclos, trabalhar com uma lista técnica
reduzida, etc. para tentar anular esta diferença. De qualquer forma, através destes procedimentos, as contas transitórias do
ledger não ficarão zeradas necessitando de um ajuste manual. O procedimento ideal é ajustar os consumos incorretos nas
próprias ordens de produção. É bom lembrar que sempre que se alterar uma ordem de produção, ele precisa ser liquidada
novamente.
Também podem ocorrer erros quando o material consume ele mesmo. Quando o total consumido é superior ao total produzido,
o sistema sempre encontra um preço negativo e não consegue efetuar o processo. Neste caso, a única alternativa é estornar o
consumo excessivo. Caso contrário, não será possível efetuar o cálculo.
O sistema apresenta os erros gerados nesta etapa na transação CKM3 através de um botão específico.
Lançamento de Encerramento
Nesta etapa são efetuados os lançamentos contábeis referentes aos cálculos efetuados. Após este procedimento somente deverá
sobrar nas contas do ledger o valor referente às variações de CPV e consumo para centro de custos que serão apropriados no
próximo passo. As contas de estoque deverão estar fechando com o valor apurado no ledger. O procedimento para conferência
está descrito no próximo passo.
Nos parâmetros do Lançamento de Encerramento sempre marcar o flag REAVALIAR OS MATERIAIS. Caso contrário, as
variações entre o valor standard e o real não são levados para as contas contábeis de estoque.
Se for necessário reprocessar os Lançamentos de Encerrramento é preciso alterar o parâmetro para primeiro estornar os
lançamento efetuados e executar o encerramento e novamente alterar os parâmetros para processar novamente.
2º PASSO: Verificar se as contas contábeis do estoque estão fechando com os valores apurados no ledger. Emitir o relatório de
listas de preços de estoque para o período em processamento e conferir com o saldo das contas contábeis no final do mês.
Transação para verificar o
lançamento na conta contábil
Contabilidade Contabilidade Financeira Razão FS10N Saldo ou
Sistema de Informação Contabilidade Contabilidade Financeira Razão
F.08 – Lista de Saldos
Transação para gerar o
relatório
Contabilidade Controlling Controlling de Custo de Produto Cálculo de
Custo real/Ledger Sistema de Informações Lista de Objetos
S_P99_41000062 – Preços e valores de estoque
Parâmetros Variante de Exibição /CLASSE – apresenta os valores sumarizados por classe de
custos
CONTROLADORIA 228 de 325
O relatório apresenta os valores por centro e por classe de custo. É preciso somar os valores de todos os centros para comparar
com as contas contábeis. As contas do estoque são as contas iniciadas com 115. Do total do grupo é preciso retirar a conta de
WIP e do Importação em Andamento. A tabela abaixo apresenta a relação entre Classe de Avaliação de materiais e Conta
contábil.
Classe Conta Descrição
3º PASSO: Para encerrar o processamento do cálculo de custos é preciso executar o programa específico Brasil para levar as
variações de preço para CPV e para consumos para centros de custos, etc. São lançadas as diferenças para todos os consumos
diferente de produção e que constam na tabela específica do Customizing. É preciso determinar uma conta de resultado para
variação de outros consumos (por exemplo, transferências entre códigos de materiais).
Transação SE38 – Editor ABAP
Programa ZSAPRCKML_COGS
Parâmetros Executar inicialmente sem atualizar o banco de dados como execução de teste. Se nenhum erro,
atualizar o banco de dados.
4º PASSO Verificar se o saldo das contas transitórias do ledger de materiais foi zerado. Caso o saldo seja diferente de zero é
preciso analisar os valores que sobraram. Verificar as contas de CPV, de reavaliação de estoque, de saldos de estoque, etc. Se
necessários os lançamentos do COGS e do Ledger podem ser estornados para acertos. Opcionalmente, estes valores podem ser
ajustados diretamente na contabilidade mas, nestes caso, o sistema não conseguirá ver estes ajustes em CO. Isto significa por
exemplo que o saldo da conta de CPV pode não coincidir com o somatórios dos CPV dos materiais calculado com base nas
quantidades faturadas e nos custos reais unitários apurados no ledger.
Transação para
verificar o saldo das
contas
Contabilidade Contabilidade Financeira Razão FS10N Saldo
Ou
Sistema de Informação Contabilidade Contabilidade Financeira Razão F.08 –
Lista de Saldos
30.10 Transferir as despesas administrativas e comerciais dos centros de custos para uma conta de resultado.
1º PASSO: Executar os ciclos de rateio para transferir os custos dos centros de custos administrativos e comerciais para ordens
internas que posteriormente serão liquidadas contra uma conta contábil em FI.
Transação Controlling Contabilidade de Centros de Custos Encerramento Período Funções
Individuais Alocação KSU5 – Rateio
Ciclo de Rateio
2º PASSO: Transferir os custos das ordens internas para FI através da liquidação das ordens
Transação Controlling Ordens Internas Encerramento Período Funções Individuais
Apropriação de Custos KO88 – Processamento Individual
Ordens
CONTROLADORIA 229 de 325
3º PASSO: Verificar se estas ordens internas e os centros de custos administrativos e comerciais estão com os saldos zerados.
Neste momento as ordens de investimento também já deverão estar liquidadas para o ativo. Portanto, nenhuma ordem interna
poderá ter custos.
Transação Controlling Contabilidade de Centros Custos Sistema Info Relatório para
Contabilidade de Centros de Custos Comparação Planejado/Real S_ALR_87013611 -
Centros de custo: real/planejado/desvio
Grupo de Centros
Custos Criar variante de seleção com todos os gru
Transação Controlling Ordens Internas Sistema Info Relatório para Ordens Internas
Comparação Planejado/Real S_ALR_87012993 - Ordem: real/plano/desvio
Ordens
30.11 Bloquear Período
Bloquear as movimentações no período que está sendo encerrado.
Transação Controlling Contabilidade de Centros de Custos Ambiente Bloqueio de Período
OKP1 – Modificar
30.12 Possíveis Erros durante o processamento
Mensagem Descrição Acerto
KM 131 A conta de desvios de produção centro de lucro
não pôde ser determinada
3KEL - Def.deter.conta p/desv.prod.em fornec.a outros
centros custo
Alterar a determinação de contas de desvio de produção
para a classe de avaliação.
M8 395 Atualizar determinação de contas (tabela T030B)
para chaves de lançamento XXX
OBYC – Determinação de Contas de MM
Incluir as contas necessárias
31 Transporte de dados de CO entre mandantes
31.1 Transportar opções para dados mestre
Os objetos dos dados mestre são dependentes da área de contabilidade de custos e/ou do plano de contas.
É possível transportar as seguintes configurações de sistema para dados mestre:
Dados mestre 1
Classes de custo
CONTROLADORIA 230 de 325
Classes de custo (Dados mestre)
Dados de plano de contas
Características de classe de custo
Mix de características
Grupos de classes de custo
Campos dependentes do tempo
Configurações preliminares para classes de custo
Centros de custo
Centros de custo (Dados mestre)
Hierarquia standard
Tipos de centros de custo
Grupos de centros de custo
Campos dependentes do tempo
Centro de custo/Tipo de atividade
Dados mestre 2
Tipos de atividade
Tipos de atividade (dados mestre)
Campos dependentes do tempo
Grupos de tipos de atividade
Índices estatísticos
Índices estatísticos (Dados mestre)
Grupos de índices estatísticos
Ordens
Grupos de ordens
O sistema SAP define os objetos selecionados em uma ordem de correção.
Com as funções do sistema de transporte é possível transferir os dados para o sistema destino.
Nota
O transporte de dados mestre (classes de custo, centros de custo, tipos de atividade, índices estatísticos, ordens) é efetuado
em duas etapas:
a) O sistema elimina os dados mestre que já existem no sistema destino, na mesma área de contabilidade de custos ou
plano de contas.
b) O sistema importa os dados mestre contidos na ordem de ajuste.
Atenção
Se, antes do transporte para o sistema destino, já foram criados dados mestre manualmente ou mediante outro transporte,
estes perdem-se com o transporte.
Uma vez que no sistema destino os dados mestre são eliminados, mas não os dados de movimento, o transporte pode levar
a inconsistências em um sistema destino já preenchido com dados. Por isso, seria necessário efetuar manualmente a
atualização posterior dos dados mestre no sistema destino.
Se se trabalhar com várias áreas de contabilidade de custos que utilizam o mesmo plano de contas e se se pretender
transportar classes de custo, proceder da forma seguinte:
CONTROLADORIA 231 de 325
Atualizar as classes de custo em todas as áreas de contabilidade de custos com este plano de contas.
Transportar, sempre em conjunto, as opções seguintes:
- a parte das classes de custo dependente do plano de contas
- a parte das classes de custo dependente da área de contabilidade de custos para todas as áreas de contabilidade de
custos com este plano de contas
Para ordens, não está prevista qualquer função de transporte standard.
O transporte de centros de custo abrange centros de custo reais e centros de custo esboçados.
Recomendações
Transportar os seguintes objetos, sempre em conjunto, para evitar inconsistências no sistema destino:
Características de classes de custo e mix de características
Hierarq. standard de centros de custo e dados mestre de centros de custo
Tipos de centros de custo e dados mestre de centros de custo
Atividades
1. Determinar que dados se pretende transportar.
2. Efetuar a seleção para o plano de contas correspondente e/ou área de contabilidade de custos.
3. Definir os dados com a função Incluir em ordem em uma ordem de ajuste ou eliminar os dados da ordem de ajuste com a
função Eliminar da ordem.
Nota
Só é possível eliminar a ordem de ajuste desde que esta não tenha ainda sido liberada para uma ordem de transporte.
4. Se as configurações preliminares forem transportadas das classes de custo, é necessário criar e processar uma pasta batch
input, após a importação, no sistema destino para criar classes de custo.
Assegurar que as contas do Razão da contabilidade financeira são criadas no plano de contas do sistema destino.
31.2 Destino consolidação
O destino de transporte indica para onde deve ser importada a ordem de transporte. Existem três possibilidades sintáticas e
funcionais para definir destinos de transporte.
Sintaxe Exemplo Esclarecimento
<SYS> C11 Sistema destino
<SYS>.<CLI> C11.021 Sistema e mandante destino
/<Nome de grupo>/ /EUROPE/ Grupo de Consolidação
A segunda e a terceira forma só podem ser utilizadas se o controle ampliado de transporte estiver ativado.
Em destinos de transporte sem indicação de mandantes destino (primeira forma), apenas no momento de importação, através da
administração de sistema, é determinado para que mandantes os objetos dependentes de mandantes devem ser importados.
Porém, se o mandante destino já tiver sido determinado no destino de transporte, a adminitração de sistema já não tem que ter
em consideração os mandantes destino corretos.
CONTROLADORIA 232 de 325
32 Arquivamento (Archiving)
32.1 Introdução
O Archiving é uma funcionalidade do R/3 que permite a transferência dos dados do R/3 para um outro meio magnético, criando
e gerenciando estes arquivos eliminando arquivos não mais necessários para acesso on-line permitindo a redução de utilização
de espaço em disco e melhorando a performance. Facilita, ainda, a administração do banco de dados, tais como o procedimento
de backup.
Para executar o archiving, o R/3 disponibiliza objetos predefinidos para cada componente com estruturas de dados próprias que
reunem dados extraídos de várias tabelas de forma a garantir tanto a integridade do banco de dados do R/3 com a integridade
dos dados contidos nos arquivos de archiving gerados.. Por exemplo, os documentos de FI são arquivados através do objeto FI-
DOCUMNT que inclui o cabeçalho do documento, os lançamentos dependendo da empresa, documentos de alteração, textos do
SAPscript, entre outros.
O conceito de SAP Data Archiving é baseado no ADK (Archive Development Kit) que fornece a base técnica para a transação
de archiving (Ferramenta Administração SARA – Arquivamento de Dados).
O processo de arquivamento tem três etapas: a criação dos arquivos, o armazenamento do arquivos e a eliminação dos dados.
Inicialmente os dados são gravados em um arquivo seqüencial que serão passados para um sistema de adminstração de arquivos
(ferramenta externa) que trabalha em conjunto com o ArchiveLink (interface do SAP com os sistemas externos). Só
posteriormente, os dados são eliminados do bancos. Isto garante que a segurança dos dados, pois, em caso de problemas no
primeiro passo, os dados permanecem intactos e o processo pode ser reinicializado.
Os programas de archiving podem ser processados em background ou on-line e não há necessidade de derrubar o banco de
dados, ou seja, pode ser feito com o R/3 em processamento.
32.1.1 Porque fazer
As razões são tanto de sistema como legais:
Liberar área em disco e resolver problemas de performance em função do grande volume de dados para as transacionais.
Facilitar a tratamento e atualização dos dados mestre.
Garantir que as regras de retenção legais sejam observadas.
Garantir que os dados sejam disponibilizados posteriormente, por exemplo, em um desenvolvimento de um novo produto.
32.1.2 Pré-requisitos considerados pelo Archiving
Pré-requisitos legais – Os dados precisam ser armazenados de tal forma que possam ser analisados a qualquer momento
no futuro. Em alguns países como os Estados Unidos, informações fiscais devem estar disponíveis para os órgãos
competentes;
Independência de Hardware – como a codificação de campos numéricos, tais como inteiros, depende do hardware usado,
o processo de archiving deve garantir que as informações sobre o hardware sejam adicionadas aos dados de archiving para
que, no futuro, possam ser exibidas por outro hardware;
CONTROLADORIA 233 de 325
Independência da Versão – como a estrutura do dados pode variar de uma versão para outra, as definições dos campos e
estrutura dos registros também devem ser arquivadas para que seja possível acessar os dados arquivados independente da
versão do arquivamento e da versão do R/3 atual;
Dependência de dados – os objetos de archiving são interdependentes e, portanto, é preciso verificar qual a seqüência de
arquivamento deve ser seguida;
Estrutura de negócio da empresa – alguns informações são analisáveis somente conhecendo-se a estrutura
organizacional da empresa, como, por exemplo, a divisão em áreas de vendas. Portanto, estas informações também devem
ser arquivadas.
32.1.3 Conceitos básicos
Armazenamento Ótico – O ArchiveLink pode ser usado para arquivar documentos em um sistema de armazenamento ótico ou
para gravar arquivos históricos. Em sistemas óticos, podem ser arquivados documentos originais escaneados, documentos
outgoing ou relatórios (print lists). Com o ArchiveLink também é possível consultar os documentos armazenados e as listagens.
No entanto, não podem ser analisados utilizando ferramentas do R/3 ou recarregados para o R/3. Mas é possível analisar e
recarregar arquivos de dados que contenham objetos de arquivamento através do Archive Link (Não é válido para todos os
objetos e também só é recomendado se efetuado logo após o arquivamento nos casos de erro no arquivamento. Um
processamento posterior pode gerar, inclusive, erros de duplicidade de informações).
Reorganização – O termo é oriundo do R/2 onde os dados são gravados e recarregados ordenadamente para otimização de
distribuição física dos dados em disco. Durante este processo, os dados desnecessários são freqüentemente arquivados e
eliminados.
Tempo de residência e de retenção – O período de retenção corresponde ao tempo em que os dados permanecerão disponíveis
na base on-line antes de serem arquivados. O período de residência corresponde ao tempo em que os dados precisam estar
disponíveis no banco on-line antes de estarem autorizados a serem marcados para arquivamento. Se, por exemplo, o tempo de
residência é mensal, os dados que estão no sistema por dois meses podem ser arquivados. Dados com menos de três semanas
precisam permanecer no banco.
Backup/Restore – Um backup é uma cópia do banco feita para que seja possível recuperar o banco se necessário (dados
corrompidos). Os backups são feito em períodos regulares de acordo com o procedimento padrão definido. A recuperação dos
dados é denominada restauração. As versões 2.1 e 2.2 do R/3, requer um backup antes do archiving. Esta medida de segurança
não é mais necessária a partir da release 3.0.
32.2 Características
Segurança - Como já foi dito, o processo de Archiving possui dois passos (o terceiro, a gravação dos arquivo de Archiving, é
opcional). No primeiro passo os dados são gravados em arquivos seqüenciais e, no segundo passo, o sistema lê os dados do
arquivo e elimina do banco de dados. Se, por exemplo, o procedimento identificar erros na transferência dos dados da rede
entre o banco de dados e os arquivos seqüenciais, o processo pode ser reiniciado já que as informações ainda estarão no
database. Como isto, torna-se possível fazer o archiving sem a necessidade de fechar o banco de dados e sem a necessidade de
backup. Se os dados forem armazenados em um outro meio magnético, aumenta-se a confiabilidade do processo
Compressão – durante o processamento os dados são automaticamente comprimidos em até 5 vezes. O grau de compressão
depende da quantidade de textos (campos caracter) o objeto contém. Porém, se os dados a serem arquivados estiverem gravados
em cluster tables (já estão comprimidas no BD), nenhum compressão adicional será efetuada.
Redução de espaço – é importante determinar não somente o espaço do BD que será liberado como o espaço necessário para
guardar o Archiving. Para identificar as tabelas envolvidas pode ser usada a opção DB tables da transação de Archiving
SARA (na versão 4.0 apresenta uma lista das tabelas, na versão 4.6 chama a transação db15). A transação DB15 permite ver
as tabelas vinculadas a um objeto e vice-versa. Esta transação é uma função do CCMS (Computer Center Management
Systems). O CCMS também permite verificar informações sobre utilização de espaço em disco e parâmetros de memória. Estas
informações facilitam a identificação de que dados precisam ser arquivados e quais os objetos devem ser usados. Os jobs de
gravação e eliminação podem ser analisados e monitorados durante uma sessão de archiving através do DAM (Data Archiving
Monitor). O DAM é integrado com o alert monitor (SAP CCMS Monitor Templates Data Archiving transação RZ20).
Todos os jobs executados em background no modo de produção geram informações para o alert monitor. Os programas de
gravação e eliminação iniciados no modo diálogo para fins de teste geram informações para o alert monitor, se o programa está
rodando em um servidor onde o monitor de Data Archiving foi gerado.
CONTROLADORIA 234 de 325
Acesso aos dados do Archiving – como os dados foram removidos do BD mas não do componente, os dados ainda
permanecem disponíveis. O gerenciamento do Archiving permite três tipos de acesso:
1. Acesso a um simples objeto (por exemplo, um documento contábil)
2. Analisar um arquivo do Archiving (leitura seqüencial)
3. Recarregar os dados para o DB (só é possível para alguns objetos)
Conversão de arquivos – no acesso ao Archiving, o ADK faz as conversões necessárias automaticamente tanto referente a
alterações na estrutura do BD (tipos e tamanhos de campos, campos novos e eliminados) como formatações específicas do
hardware. Os arquivos do Archiving não são alterados. Caso existam alterações que o ADK não consiga tratar (por exemplo,
campos movidos de uma tabela para outra ou divisão de uma tabela em várias) será necessário um programa específico para
efetuar a conversão permanentemente.
32.3 Procedimento para execução de uma seção de Archiving
O primeiro passo é verificar a Archiving Checklist para garantir a execução de todos os passos do Archiving na seqüência
correta. Antes da primeira sessão de archiving:
1. Verificar as customizações gerais para verificar se ouve alteração nos nomes lógicos dos arquivos.
2. Verificar objetos cross-archiving do Customizing e ver se o Repositório Central de armazenamento mantido usa o Serviço
de Gerenciamento Content (Substitui o Archivelink na versão 4.6C).
Antes de usar um objeto de archiving pela primeira vez, verificar no Customizing:
1. Se o nome do arquivo foi definido corretamente;
2. Se foram atualizadas as variantes do programa de eliminação (variantes são específicas do cliente);
3. Se o tamanho do arquivo foi configurado corretamente;
4. Se o programa de eliminação é executado automaticamente;
5. Se serão criados índices.
Para cada sessão de archiving:
1. Garantir que as atividades sejam coordenadas pelos departamento especializado e o gerente do sistema;
2. Verificar interdependência no gráfico da rede (algum outro objeto deverá ser arquivado primeiro?);
3. Escalonar a sessão de archiving (atualizar variante);
4. Executar o programa de eliminação (se não tiver processamento automático);
5. Se os arquivos forem ser gravados usando o Content Management Service, execute a gravação manualmente;
6. Se a gravação for manual:
6.1. Copiar os arquivos para fita;
6.2. Anote o nome da fita no gerenciador de archive.
32.3.1 Primeiro passo – Geração dos arquivos
DB doR/3
ArquivosArchiving
ProgramaArchiving
O processo de geração do arquivo será finalizado quando todos os dados forem arquivados ou quando for alcançado no
tamanho máximo permitido ou o número máximo de objetos de dados permitido definidos no Customizing. Nos dois últimos
casos, se ainda existirem dados a arquivos, o sistema gera novo arquivo e o passo de eliminação é iniciado (considerando que o
flag foi marcado: iniciar programa de eliminação automaticamente e eliminar antes de gravar). No customizing, podem ser
CONTROLADORIA 235 de 325
definidos parâmetros específicos para cada objeto de archiving: nome lógico do arquivo, tamanho do arquivo de Archiving,
Configuração do programa de eliminação, sistema de arquivo e sistema de gravação, configuração do Postprocessing, seleção
do servidor.
32.3.2 Segundo Passo – Gravação dos arquivos
DB doR/3
ArquivosArchiving
Programa deEliminação
Os arquivos seqüenciais gerados podem ser gravados em diversos meios magnéticos definido conforme a conveniência da
empresa. O gerenciamento da gravação pode ser manual ou através do CMS (Content Management Service) ou sistemas HSM
(Hierarquical Storage Management).
Se o sistema de gravação estiver conectado ao R/3 (CMS) e o processo de geração dos arquivos terminar o.k., o programa de
gravação pode ser iniciado automaticamente.
Usando um sistema HSM os arquivos podem ser gravados usando, também, uma mídia de gravação de terceiros, como, por
exemplo, a MO-disks. Se o caminho para gravação do sistema HSM estiver configurado no Customizing (Transação FILE), não
será necessário usar o ArchiveLink para estabelecer a comunicação com o sistema de archive porque o HSM grava os arquivos
de forma independente. Manualmente, os arquivos podem ser copiados para fita.
32.3.3 Terceiro Passo – Eliminação dos dados
Depois de gravado o primeiro arquivo do Archiving, o sistema de gerenciamento do Archiving gera novo arquivo para
continuar o processo de archiving. Paralelamente, outro programa lê os dados gravados no primeiro arquivo e elimina os dados
do BD. A cada novo arquivo fechado, um programa de eliminação é iniciado, tendo-se, assim, portanto, vários programas
executando simultaneamente. Pode ser configurado para que o programa de eliminação seja executado somente depois que os
arquivos foram gravados e as informações sejam lidas do sistema de gravação.
Para iniciar o programa de eliminação, também podem ser definidos event-controlled que determina os gatilhos para iniciar os
programas. O programa de eliminação, só pode ser executado depois que um arquivo de archiving tenha sido gerado. Quando
todos os jobs de eliminação forem executados com sucesso, o evento do sistema SAP_ARCHIVING_WRITE_FINISHED é
iniciado pelo ADK e pode ser usado como gatilho para procedimentos subseqüentes como um backup, por exemplo.
32.4 Objeto de Archiving e Objeto de Dados
Todo o processamento do archiving será feito por meio de objetos. O objeto de archiving determina quais os dados serão
arquivados e de que maneira, especificando quais os objetos do BD devem se tratados em conjunto como um simples objeto de
archiving e quais precisam ser tratados independentemente. O nome do objeto tem até 10 caracteres. Os objetos de archiving
são definidos na transação AOBJ)
Os programas abaixo precisam ou podem ser associados a um objeto de archiving.
1. Preprocessamento (opcional) – alguns objetos requerem a preparação dos dados (marcação para eliminação);
2. Archive – gera os arquivos de archiving;
3. Eliminação – esta função pode incluir vários processos que são, sempre, dependentes dos arquivos seqüenciais existentes.
Os dados são eliminados do BD, mas em alguns casos, os dados arquivados podem ser apenas marcados para eliminação.
4. Pós-processamento (opcional) – pode ser executada em paralelo com a eliminação. Se os dados não tiverem sido
eliminados pelo programa de eliminação, são eliminados pelo pos-processamento. Este programa também pode executar
outras funções que irão variar conforme o objeto.
CONTROLADORIA 236 de 325
5. Recarga (opcional) – esta função permite retornar com os dados dos arquivos seqüenciais para o BD mas não está
disponível para todos os objetos;
6. Índice (opcional) – esta função gera (ou elimina) índices para acesso direto mas também não está disponível para todos os
objetos.
Um objeto de dados é um objeto de archiving preenchido com dados de uma aplicação. O objeto de archiving somente
descreve a estrutura dos dados enquanto que o objeto de dados contém dos dados reais do BD. O ADK garante que os objetos
de dados são gravados seqüencialmente seguindo a estrutura descrita no objeto de archiving.
Exemplo:
Tempo utilização 13 meses – Banco Oracle
Espaço de Tabelas
Número total 27
Tamanho (KB) 369.428.016
Espaço livre (KB) 83.726.480 22%
Espaço Ocupado (KB) 285.701.536 88%
Crescimento médio mensal estimado (KB) 21.977.041 6,8%
Minimum free / KB 20.368
Max. Autoextensible / KB AutoExtend off
Tables Indexes
Tabelas Índices Total
Total number 13.910 16.275
Total size/KB 163.426.280 117.247.848 280.674.128
More than 1 extent 1.542 2.714
Missing in database 0 0
Missing in R/3 DDIC 0 0
Space-critical objects 0 0
32.4.1 PCA_OBJECT – Registros de totais e partidas individuais no EC-PCA
PCA_OBJECT
Tabela Num. Registros Espaço (KB)
GLPCA PCA: Partidas individuais reais 13.746.193 11.943.296
Média mensal dos 11 primeiros meses 975.582
Movimentação do 11º mês (Implantação efetiva) 1.385.130
Movimentação 12 e 13º mês (parcial) 654.077
GLPCT PCA: Totais 58.002 51.256
GLPCP PCA: Partidas individuais planejadas 9.879 23.136
Total 12.017.688
4,2%
CONTROLADORIA 237 de 325
Objeto Tipo Tablespace Tamanho (KB)
GLPCA TABLE PSAPBTABD 7.002.296
GLPCA~0 INDEX PSAPBTABI 673.376
GLPCA~1 INDEX PSAPBTABI 1.185.296
GLPCA~2 INDEX PSAPBTABI 1.062.456
GLPCA~3 INDEX PSAPBTABI 1.118.736
GLPCA~7 INDEX PSAPBTABI 901.136
Total 11.943.296
GLPCP TABLE PSAPBTABD 10.256
GLPCP~0 INDEX PSAPBTABI 2.576
GLPCP~1 INDEX PSAPBTABI 2.576
GLPCP~2 INDEX PSAPBTABI 2.576
GLPCP~3 INDEX PSAPBTABI 2.576
GLPCP~7 INDEX PSAPBTABI 2.576
Total 23.136
GLPCT TABLE PSAPBTABD 30.736
GLPCT~0 INDEX PSAPBTABI 10.256
GLPCT~1 INDEX PSAPBTABI 5.136
GLPCT~5 INDEX PSAPBTABI 5.136
Total 51.264
32.4.2 CO_ML_BEL – Documentos ledger de material (MLHD/IT/PP/PPF/CR/CRF/CRP)
CO_ML_BEL
Tabela Num. Registros Espaço (KB)
MLCR Documento do ledger de material: moedas 15.537.702 2.862.112
MLCRP Doc.ledger de material: modificações de preço (moedas) 11.308.738 1.973.832
MLPP Documento do ledger de material: períodos contábeis 1.392.672
MLIT Documento do ledger de material: materiais 1.103.408
MLPPF Doc.ledger de material: grupos de campos (períodos contáb.) 606.792
MLHD Documento do ledger de material: cabeçalho 523.328
MLCRF Documento do ledger de material: grupos de campos (moedas) 2.171.442 366.112
Total 8.828.256
3,1%
Crescimento mensal estimado: 679.096
Objeto Tipo Tablespace Tamanho (KB)
MLCR TABLE PSAPBTABD 1.402.896
MLCR~0 INDEX PSAPBTABI 1.459.216
Total 2.862.112
MLCRF TABLE PSAPBTABD 143.376
MLCRF~0 INDEX PSAPBTABI 222.736
Total 366.112
CONTROLADORIA 238 de 325
Objeto Tipo Tablespace Tamanho (KB)
MLCRP TABLE PSAPBTABD 901.136
MLCRP~0 INDEX PSAPBTABI 1.072.696
Total 1.973.832
MLHD TABLE PSAPBTABD 244.576
MLHD~0 INDEX PSAPBTABI 144.616
MLHD~1 INDEX PSAPBTABI 134.136
Total 523.328
MLIT TABLE PSAPBTABD 563.216
MLIT~0 INDEX PSAPBTABI 294.416
MLIT~1 INDEX PSAPBTABI 245.776
Total 1.103.408
MLPP TABLE PSAPBTABD 686.096
MLPP~0 INDEX PSAPBTABI 706.576
Total 1.392.672
MLPPF TABLE PSAPBTABD 225.296
MLPPF~0 INDEX PSAPBTABI 381.496
Total 606.792
32.4.3 CO_ORDER – Ordens c/dados de movimento
CO_ORDER
Tabela Num. Registros Espaço (KB)
COEP Objeto CO: partidas CO referentes ao período 28.681.735 23.352.496
AUSP Valores das modalidades das características 26.768.536 11.505.440
JEST Status individual por objeto 32.685.916 5.478.472
CDCLS Cluster structure for change documents 10.651.014 4.384.368
COSS Objeto CO: totais custos - lançamentos internos 3.887.035 3.655.816
COSP Objeto CO: totais de custos - lançamentos externos 3.521.573 2.357.824
COBK Objeto CO: cabeçalho do documento 6.590.480 2.327.296
STXL STDX linhas file de texto SAPscript 2.752.314 1.854.360
CKIS Itens cálc.custo unitário/especificaç.item custeio-produto 2.708.683 1.766.432
COSB Objeto-CO: totais de desvios/determinações de resultado 2.349.697 1.716.544
STXH STXD cabeçalho file texto SAPscript 3.139.019 808.600
AABLG Cluster for Settlement Document 1.059.280 807.736
JSTO Informações sobre objeto de status 6.498.136 729.688
KSSK Tabela de atribuição: objeto para classe 1.460.355 686.176
ONR00 Nº geral de objeto 7.130.729 673.120
AFKO Dados de cabeçalho da ordem de ordens PCP 476.252 664.088
JCDS Docs.modificação para status de sistema/usuário (tab. JEST) 4.282.328 640.072
INOB Atribuição dum nº interno a um objeto 923.908 627.328
COEPL Objeto CO: partidas indiv.de tipos de atividade por período 1.726.107 589.624
COEPB Objeto CO: partidas individ.desvio/determ.result.por período 2.019.715 542.440
AUFK Dados mestre da ordem 779.105 524.272
CONTROLADORIA 239 de 325
CO_ORDER
Tabela Num. Registros Espaço (KB)
CKIT Textos p/CKIS 2.708.683 492.872
COSBD Obj.CO: totais desvios/provisionam. - dos quais apropriados 1.309.896 391.128
AUAK Cabeçalho de documento para apropriação 1.133.678 332.848
COBRB Regras de repartição de normas de apropriação (apropr.ordem) 851.419 318.768
COKA Objeto CO: dados de controle de classe de custo 1.461.818 233.112
COSL Objeto CO: totais de tipos de atividade 494.487 231.784
COSSD Objeto CO: totais custos internos - destes foram apropriados 502.187 186.912
AFPO Item de ordem 250.271 146.752
COSPD Objeto CO: totais custos externos - dos quais apropriados 482.519 140.832
CKHS Cabeçalho - cálculo de custo unitário (controle + totais) 288.822 106.272
ONROR Índice de nº de objeto ordem 755.632 97.880
COBRA Norma de apropriação para apropriação da ordem 491.051 92.544
AUAI Montantes de apropriação de custos por área de depreciação 3173 88.792
COEPBR Objeto CO: liquidação avaliada de partidas individuais 392.860 74.288
COEJ Objeto CO: partidas individuais referentes ao ano 34.814 41.008
BPEJ Parts.indiv. Valores anuais Obj.controlling 42.232 15.424
COEPD Objeto CO: liquidação não avaliada de part.indiv.com status 61.727 14.808
BPEG Partidas individ.valores totais Obj.controlling 40.604 12.864
BPJA Reg.de totais para valor total anual Obj.controlling 21.704 10.320
COOI Administração de compromissos: itens individuais 14.558 9.648
CABN Característica 10.994 8.920
BPGE Reg.de totais para valor total Obj.controlling 15.063 7.104
SWOR Sistema de classificação: palavras-chave 31.666 6.560
BPTR Dados do objeto Obj.controlling 11.890 6.464
COKP Objeto CO: dados de controle planej.custos primários 13.006 4.512
COEJL Objeto CO: partidas indiv.tipos atividades referentes ao ano 5.903 3.888
COKS Objeto CO: dados de controle de custos secundários planej. 1.047 3.888
COSR Objeto CO: totais de índices estatísticos 2.931 3.888
COEPR Objeto CO: partidas indiv.índices estatísticos - ref.período 11.300 3.728
BPBK Cabeçalho de doc. Obj.controlling 5.042 3.232
CABNT Textos para características 14.339 3.000
CAWNT Textos para valores 14.813 2.704
BPHI Dados relativos a várias hierarquias Obj.controlling 4.690 1.664
BPIJ Índice de objeto de orçamento (orçamento anual) 3.336 1.664
ANLI Tabela conexão: medida de investimento - objeto princ.-> IeA 0 888
CKHT Textos p/CKHS 376 272
COANZ Índice de objetos com (solicitações)adiantamentos 367 272
STXB SAPscript: textos que não têm formato SAPscript 45 136
COFP Linhas de documento (administração de caixa de projetos) 0 96
FMSU FI-FM Registros de totais 0 80
BPIG Índice de objeto de orçamento (orçamento global) 0 64
CONTROLADORIA 240 de 325
CO_ORDER
Tabela Num. Registros Espaço (KB)
COEJR Objeto CO: partidas indiv.índices estatísticos - ref.ao ano 18 48
EBII Fluxo de documentos CO/SD: parte faturada das parts.despesas 0 48
ANIA Simulação de depreciação para projetos de investimento 0 32
ANIB Simulação de depr./projetos de investimento: áreas avaliação 0 32
CKIP Valores periódicos item cálculo de custo unitário 0 32
COKR Objeto CO: dados de controle para grandezas estatísticas 12 32
JCDO Docs.modificação para objeto de status (tabela JSTO) 0 32
RPSCO Banco dados para info de projeto: custos, receitas, finanças 0 32
TPI03 Objetos CO: data do último cálculo de juros 0 32
Total 68.794.392
Percentual 24,5%
COEP
Tabela Num.
Registros
Espaço (KB) Percentual s/
BD
Objeto CO: partidas CO referentes ao período 28.681.735 23.352.496 8,3%
Ordens Internas p/ classe de objeto
CSTIN – Custos Indiretos 5.257.852
INVES – Investimentos 0
PROD – Produção 2.969.234
RESUL – Resultado de Vendas 1.532.505
Total 9.759.591 7.946.172 4,1%
Registros com no. de objeto:
iniciado por OR: 22.736.074 18.511.574
Outros: 4.840.921
Objeto Tipo Tablespace Tamanho (KB)
AABLG TABLE PSAPCLUD 765.480
AABLG~0 INDEX PSAPCLUI 42.256
Total 807.736
CONTROLADORIA 241 de 325
Objeto Tipo Tablespace Tamanho (KB)
AFKO TABLE PSAPBTABD 412.296
AFKO~0 INDEX PSAPBTABI 21.776
AFKO~1 INDEX PSAPBTABI 24.336
AFKO~2 INDEX PSAPBTABI 17.936
AFKO~3 INDEX PSAPBTABI 12.816
AFKO~4 INDEX PSAPBTABI 25.616
AFKO~5 INDEX PSAPBTABI 18.616
AFKO~6 INDEX PSAPBTABI 14.736
AFKO~D INDEX PSAPBTABI 17.296
AFKO~F INDEX PSAPBTABI 12.856
AFKO~P INDEX PSAPBTABI 23.696
AFKO~ZDP INDEX PSAPBTABI 34.576
AFKO~ZDT INDEX PSAPBTABI 27.536
Total 664.088
AFPO TABLE PSAPBTABD 99.856
AFPO~0 INDEX PSAPBTABI 12.208
AFPO~1 INDEX PSAPBTABI 20.496
AFPO~2 INDEX PSAPBTABI 7.096
AFPO~3 INDEX PSAPBTABI 7.096
Total 146.752
ANIA TABLE PSAPSTABD 16
ANIA~0 INDEX PSAPSTABI 16
Total 32
ANIB TABLE PSAPSTABD 16
ANIB~0 INDEX PSAPSTABI 16
Total 32
ANLI TABLE PSAPSTABD 336
ANLI~0 INDEX PSAPSTABI 296
ANLI~A INDEX PSAPSTABI 256
Total 888
AUAI TABLE PSAPBTABD 42.896
AUAI~0 INDEX PSAPBTABI 45.896
Total 88.792
AUAK TABLE PSAPBTABD 215.056
AUAK~0 INDEX PSAPBTABI 38.416
AUAK~A INDEX PSAPBTABI 79.376
Total 332.848
AUFK TABLE PSAPSTABD 325.136
AUFK~0 INDEX PSAPSTABI 38.416
AUFK~A INDEX PSAPSTABI 36.496
AUFK~B INDEX PSAPSTABI 33.936
AUFK~C INDEX PSAPSTABI 32.016
CONTROLADORIA 242 de 325
Objeto Tipo Tablespace Tamanho (KB)
AUFK~D INDEX PSAPSTABI 32.016
AUFK~ZTY INDEX PSAPSTABI 26.256
Total 524.272
AUSP TABLE PSAPBTABD 3.563.536
AUSP~0 INDEX PSAPBTABI 2.414.096
AUSP~1 INDEX PSAPBTABI 3.118.816
AUSP~2 INDEX PSAPBTABI 719.376
AUSP~3 INDEX PSAPBTABI 1.689.616
Total 11.505.440
BPBK TABLE PSAPBTABD 2.576
BPBK~0 INDEX PSAPBTABI 656
Total 3.232
BPEG TABLE PSAPBTABD 5.136
BPEG~0 INDEX PSAPBTABI 2.576
BPEG~1 INDEX PSAPBTABI 2.576
BPEG~2 INDEX PSAPBTABI 2.576
Total 12.864
BPEJ TABLE PSAPBTABD 7.696
BPEJ~0 INDEX PSAPBTABI 2.576
BPEJ~1 INDEX PSAPBTABI 2.576
BPEJ~2 INDEX PSAPBTABI 2.576
Total 15.424
BPGE TABLE PSAPBTABD 2.576
BPGE~0 INDEX PSAPBTABI 1.936
BPGE~1 INDEX PSAPBTABI 1.296
BPGE~2 INDEX PSAPBTABI 1.296
Total 7.104
BPHI TABLE PSAPBTABD 656
BPHI~0 INDEX PSAPBTABI 336
BPHI~1 INDEX PSAPBTABI 336
BPHI~2 INDEX PSAPBTABI 336
Total 1.664
BPIG TABLE PSAPBTABD 16
BPIG~0 INDEX PSAPBTABI 16
BPIG~2 INDEX PSAPBTABI 16
BPIG~3 INDEX PSAPBTABI 16
Total 64
BPIJ TABLE PSAPBTABD 656
BPIJ~0 INDEX PSAPBTABI 336
BPIJ~2 INDEX PSAPBTABI 336
BPIJ~3 INDEX PSAPBTABI 336
Total 1.664
CONTROLADORIA 243 de 325
Objeto Tipo Tablespace Tamanho (KB)
BPJA TABLE PSAPBTABD 2.576
BPJA~0 INDEX PSAPBTABI 2.576
BPJA~1 INDEX PSAPBTABI 1.296
BPJA~2 INDEX PSAPBTABI 1.936
BPJA~3 INDEX PSAPBTABI 1.936
Total 10.320
BPTR TABLE PSAPBTABD 2.576
BPTR~0 INDEX PSAPBTABI 1.296
BPTR~1 INDEX PSAPBTABI 1.296
BPTR~2 INDEX PSAPBTABI 1.296
Total 6.464
CABN TABLE PSAPSTABD 3.280
CABN~0 INDEX PSAPSTABI 600
CABN~1 INDEX PSAPSTABI 840
CABN~2 INDEX PSAPSTABI 800
CABN~3 INDEX PSAPSTABI 800
CABN~4 INDEX PSAPSTABI 400
CABN~5 INDEX PSAPSTABI 400
CABN~6 INDEX PSAPSTABI 400
CABN~7 INDEX PSAPSTABI 400
CABN~B INDEX PSAPSTABI 1.000
Total 8.920
CABNT TABLE PSAPSTABD 1.760
CABNT~0 INDEX PSAPSTABI 760
CABNT~1 INDEX PSAPSTABI 480
Total 3.000
CAWNT TABLE PSAPSTABD 1.152
CAWNT~0 INDEX PSAPSTABI 1.056
CAWNT~1 INDEX PSAPSTABI 496
Total 2.704
CDCLS TABLE PSAPCLUD 3.155.568
CDCLS~0 INDEX PSAPCLUI 1.228.800
Total 4.384.368
CKHS TABLE PSAPBTABD 84.496
CKHS~0 INDEX PSAPBTABI 21.776
Total 106.272
CKHT TABLE PSAPBTABD 176
CKHT~0 INDEX PSAPBTABI 96
Total 272
CKIP TABLE PSAPBTABD 16
CKIP~0 INDEX PSAPBTABI 16
Total 32
CONTROLADORIA 244 de 325
Objeto Tipo Tablespace Tamanho (KB)
CKIS TABLE PSAPBTABD 1.515.536
CKIS~0 INDEX PSAPBTABI 250.896
Total 1.766.432
CKIT TABLE PSAPBTABD 240.656
CKIT~0 INDEX PSAPBTABI 252.216
Total 492.872
COANZ TABLE PSAPBTABD 176
COANZ~0 INDEX PSAPBTABI 96
Total 272
COBK TABLE PSAPBTABD 1.444.016
COBK~0 INDEX PSAPBTABI 476.504
COBK~O INDEX PSAPBTABI 406.776
Total 2.327.296
COBRA TABLE PSAPSTABD 66.168
COBRA~0 INDEX PSAPSTABI 26.376
Total 92.544
COBRB TABLE PSAPSTABD 225.296
COBRB~0 INDEX PSAPSTABI 51.216
COBRB~1 INDEX PSAPSTABI 42.256
Total 318.768
COEJ TABLE PSAPBTABD 30.736
COEJ~0 INDEX PSAPBTABI 2.576
COEJ~1 INDEX PSAPBTABI 7.696
Total 41.008
COEJL TABLE PSAPBTABD 2.576
COEJL~0 INDEX PSAPBTABI 656
COEJL~1 INDEX PSAPBTABI 656
Total 3.888
COEJR TABLE PSAPBTABD 16
COEJR~0 INDEX PSAPBTABI 16
COEJR~1 INDEX PSAPBTABI 16
Total 48
COEP TABLE PSAPBTABD 9.810.016
COEP~0 INDEX PSAPBTABI 1.792.016
COEP~1 INDEX PSAPBTABI 4.838.416
COEP~2 INDEX PSAPBTABI 2.816.016
COEP~3 INDEX PSAPBTABI 2.048.016
COEP~5 INDEX PSAPBTABI 2.048.016
Total 23.352.496
COEPB TABLE PSAPBTABD 326.600
COEPB~0 INDEX PSAPBTABI 96.680
COEPB~1 INDEX PSAPBTABI 119.160
CONTROLADORIA 245 de 325
Objeto Tipo Tablespace Tamanho (KB)
Total 542.440
COEPBR TABLE PSAPBTABD 25.616
COEPBR~0 INDEX PSAPBTABI 26.896
COEPBR~001 INDEX PSAPBTABI 21.776
Total 74.288
COEPD TABLE PSAPBTABD 7.736
COEPD~0 INDEX PSAPBTABI 3.856
COEPD~001 INDEX PSAPBTABI 3.216
Total 14.808
COEPL TABLE PSAPBTABD 268.856
COEPL~0 INDEX PSAPBTABI 124.216
COEPL~1 INDEX PSAPBTABI 196.552
Total 589.624
COEPR TABLE PSAPBTABD 1.936
COEPR~0 INDEX PSAPBTABI 656
COEPR~1 INDEX PSAPBTABI 1.136
Total 3.728
COFP TABLE PSAPBTABD 16
COFP~0 INDEX PSAPBTABI 16
COFP~C INDEX PSAPBTABI 16
COFP~K INDEX PSAPBTABI 16
COFP~M INDEX PSAPBTABI 16
COFP~V INDEX PSAPBTABI 16
Total 96
COKA TABLE PSAPBTABD 99.856
COKA~0 INDEX PSAPBTABI 133.256
Total 233.112
COKP TABLE PSAPBTABD 2.576
COKP~0 INDEX PSAPBTABI 1.936
Total 4.512
COKR TABLE PSAPBTABD 16
COKR~0 INDEX PSAPBTABI 16
Total 32
COKS TABLE PSAPBTABD 2.576
COKS~0 INDEX PSAPBTABI 656
COKS~1 INDEX PSAPBTABI 656
Total 3.888
COOI TABLE PSAPBTABD 5.136
COOI~0 INDEX PSAPBTABI 2.576
COOI~1 INDEX PSAPBTABI 1.936
Total 9.648
COSB TABLE PSAPBTABD 965.296
CONTROLADORIA 246 de 325
Objeto Tipo Tablespace Tamanho (KB)
COSB~0 INDEX PSAPBTABI 399.616
COSB~1 INDEX PSAPBTABI 207.456
COSB~Z1 INDEX PSAPBTABI 144.176
Total 1.716.544
COSBD TABLE PSAPBTABD 161.072
COSBD~0 INDEX PSAPBTABI 230.056
Total 391.128
COSL TABLE PSAPBTABD 125.496
COSL~0 INDEX PSAPBTABI 40.976
COSL~1 INDEX PSAPBTABI 39.056
COSL~Z1 INDEX PSAPBTABI 26.256
Total 231.784
COSP TABLE PSAPBTABD 1.464.336
COSP~0 INDEX PSAPBTABI 483.856
COSP~1 INDEX PSAPBTABI 281.616
COSP~Z1 INDEX PSAPBTABI 128.016
Total 2.357.824
COSPD TABLE PSAPBTABD 71.696
COSPD~0 INDEX PSAPBTABI 69.136
Total 140.832
COSR TABLE PSAPBTABD 2.576
COSR~0 INDEX PSAPBTABI 656
COSR~1 INDEX PSAPBTABI 656
Total 3.888
COSS TABLE PSAPBTABD 1.925.136
COSS~0 INDEX PSAPBTABI 709.136
COSS~1 INDEX PSAPBTABI 302.096
COSS~9 INDEX PSAPBTABI 345.656
COSS~Z1 INDEX PSAPBTABI 143.376
COSS~Z2 INDEX PSAPBTABI 230.416
Total 3.655.816
COSSD TABLE PSAPBTABD 92.176
COSSD~0 INDEX PSAPBTABI 94.736
Total 186.912
EBII TABLE PSAPBTABD 16
EBII~0 INDEX PSAPBTABI 16
EBII~1 INDEX PSAPBTABI 16
Total 48
CONTROLADORIA 247 de 325
Objeto Tipo Tablespace Tamanho (KB)
FMSU TABLE PSAPBTABD 16
FMSU~0 INDEX PSAPBTABI 16
FMSU~1 INDEX PSAPBTABI 16
FMSU~C INDEX PSAPBTABI 16
FMSU~P INDEX PSAPBTABI 16
Total 80
INOB TABLE PSAPBTABD 153.616
INOB~0 INDEX PSAPBTABI 76.816
INOB~1 INDEX PSAPBTABI 92.176
INOB~2 INDEX PSAPBTABI 71.696
INOB~3 INDEX PSAPBTABI 58.896
INOB~4 INDEX PSAPBTABI 48.656
INOB~5 INDEX PSAPBTABI 48.656
INOB~ZOB INDEX PSAPBTABI 76.816
Total 627.328
JCDO TABLE PSAPSTABD 16
JCDO~0 INDEX PSAPSTABI 16
Total 32
JCDS TABLE PSAPBTABD 348.176
JCDS~0 INDEX PSAPBTABI 291.896
Total 640.072
JEST TABLE PSAPBTABD 1.561.640
JEST~0 INDEX PSAPBTABI 2.058.256
JEST~I INDEX PSAPBTABI 1.858.576
Total 5.478.472
JSTO TABLE PSAPBTABD 307.216
JSTO~0 INDEX PSAPBTABI 422.472
Total 729.688
KSSK TABLE PSAPBTABD 133.136
KSSK~0 INDEX PSAPBTABI 158.736
KSSK~1 INDEX PSAPBTABI 84.496
KSSK~2 INDEX PSAPBTABI 89.616
KSSK~3 INDEX PSAPBTABI 46.096
KSSK~4 INDEX PSAPBTABI 174.096
Total 686.176
ONR00 TABLE PSAPBTABD 237.000
ONR00~0 INDEX PSAPBTABI 436.120
Total 673.120
ONROR TABLE PSAPBTABD 31.560
ONROR~0 INDEX PSAPBTABI 34.440
ONROR~A INDEX PSAPBTABI 31.880
Total 97.880
CONTROLADORIA 248 de 325
Objeto Tipo Tablespace Tamanho (KB)
RPSCO TABLE PSAPBTABD 16
RPSCO~0 INDEX PSAPBTABI 16
Total 32
STXB TABLE PSAPSTABD 120
STXB~0 INDEX PSAPSTABI 16
Total 136
STXH TABLE PSAPSTABD 554.520
STXH~0 INDEX PSAPSTABI 254.080
Total 808.600
SWOR TABLE PSAPSTABD 2.720
SWOR~0 INDEX PSAPSTABI 1.840
SWOR~1 INDEX PSAPSTABI 2.000
Total 6.560
TPI03 TABLE PSAPSTABD 16
TPI03~0 INDEX PSAPSTABI 16
Total 32
32.4.4 CO_KSTRG – Objeto de custo: dados mestre e dados movimento
CO_KSTRG
Tabela Num. Registros Espaço (KB)
COEP Objeto CO: partidas CO referentes ao período 28.681.735 23.352.496
COSS Objeto CO: totais custos - lançamentos internos 3.887.035 3.655.816
COSP Objeto CO: totais de custos - lançamentos externos 3.521.573 2.357.824
COBK Objeto CO: cabeçalho do documento 6.590.480 2.327.296
STXL STDX linhas file de texto SAPscript 2.752.314 1.854.360
CKIS Itens cálc.custo unitário/especificaç.item custeio-produto 2.708.683 1.766.432
COSB Objeto-CO: totais de desvios/determinações de resultado 2.349.697 1.716.544
STXH STXD cabeçalho file texto SAPscript 3.139.019 808.600
AABLG Cluster for Settlement Document 1.059.280 807.736
ONR00 Nº geral de objeto 7.130.729 673.120
COEPL Objeto CO: partidas indiv.de tipos de atividade por período 1.726.107 589.624
COEPB Objeto CO: partidas individ.desvio/determ.result.por período 2.019.715 542.440
CKIT Textos p/CKIS 2.708.683 492.872
COSBD Obj.CO: totais desvios/provisionam. - dos quais apropriados 1.309.896 391.128
AUAK Cabeçalho de documento para apropriação 1.133.678 332.848
COBRB Regras de repartição de normas de apropriação (apropr.ordem) 851.419 318.768
COKA Objeto CO: dados de controle de classe de custo 1.461.818 233.112
COSL Objeto CO: totais de tipos de atividade 494.487 231.784
COSSD Objeto CO: totais custos internos - destes foram apropriados 502.187 186.912
COSPD Objeto CO: totais custos externos - dos quais apropriados 482.519 140.832
CKHS Cabeçalho - cálculo de custo unitário (controle + totais) 288.822 106.272
COBRA Norma de apropriação para apropriação da ordem 491.051 92.544
CONTROLADORIA 249 de 325
CO_KSTRG
Tabela Num. Registros Espaço (KB)
AUAI Montantes de apropriação de custos por área de depreciação 3173 88.792
COEPBR Objeto CO: liquidação avaliada de partidas individuais 392.860 74.288
COEJ Objeto CO: partidas individuais referentes ao ano 34.814 41.008
COEPD Objeto CO: liquidação não avaliada de part.indiv.com status 61.727 14.808
COOI Administração de compromissos: itens individuais 14.558 9.648
COKP Objeto CO: dados de controle planej.custos primários 13.006 4.512
COEJL Objeto CO: partidas indiv.tipos atividades referentes ao ano 5.903 3.888
COKS Objeto CO: dados de controle de custos secundários planej. 1.047 3.888
COSR Objeto CO: totais de índices estatísticos 2.931 3.888
COEPR Objeto CO: partidas indiv.índices estatísticos - ref.período 11.300 3.728
COKL Objeto CO: dados de controle - tipo de atividade 2.661 3.232
CKHT Textos p/CKHS 376 272
STXB SAPscript: textos que não têm formato SAPscript 45 136
CKPE Hierarquia obj.custo CO-PC: objetos individuais 0 80
CKPH Registro mestre nº identificação objeto de custo 0 48
COEJR Objeto CO: partidas indiv.índices estatísticos - ref.ao ano 18 48
EBII Fluxo de documentos CO/SD: parte faturada das parts.despesas 0 48
CKIP Valores periódicos item cálculo de custo unitário 0 32
CKPHT Textos para CKPH 0 32
COKR Objeto CO: dados de controle para grandezas estatísticas 12 32
COSLD Obj.CO: totais de tipos de atividade - dos quais apropriados 0 32
ONRHP Índice de nºs objetos hierarquia de produção por processos 0 32
Total 43.231.832
Objeto Tipo Tablespace Tamanho (KB)
CKPE TABLE PSAPSTABD 16
CKPE~0 INDEX PSAPSTABI 16
CKPE~1 INDEX PSAPSTABI 16
CKPE~2 INDEX PSAPSTABI 16
CKPE~3 INDEX PSAPSTABI 16
Total 80
CKPH TABLE PSAPSTABD 16
CKPH~0 INDEX PSAPSTABI 16
CKPH~1 INDEX PSAPSTABI 16
Total 48
CKPHT TABLE PSAPSTABD 16
CKPHT~0 INDEX PSAPSTABI 16
Total 32
COKL TABLE PSAPBTABD 2.576
COKL~0 INDEX PSAPBTABI 656
Total 3.232
CONTROLADORIA 250 de 325
Objeto Tipo Tablespace Tamanho (KB)
COSLD TABLE PSAPBTABD 16
COSLD~0 INDEX PSAPBTABI 16
Total 32
ONRHP TABLE PSAPBTABD 16
ONRHP~0 INDEX PSAPBTABI 16
Total 32
32.4.5 CO-COSTCTR
CO_COSTCTR
Tabela Num. Registros Espaço (KB)
COEP Objeto CO: partidas CO referentes ao período 28.681.735 23.352.496
CDCLS Cluster structure for change documents 10.651.014 4.384.368
COSS Objeto CO: totais custos - lançamentos internos 3.887.035 3.655.816
COSP Objeto CO: totais de custos - lançamentos externos 3.5213573 2.357.824
COBK Objeto CO: cabeçalho do documento 6.590.480 2.327.296
CDHDR Cabeçalho do documento de modificação 10.685.780 1.943.176
STXL STDX linhas file de texto SAPscript 2.752.314 1.854.360
CKIS Itens cálc.custo unitário/especificaç.item custeio-produto 2.708.683 1.766.432
COSB Objeto-CO: totais de desvios/determinações de resultado 2.349.697 1.716.554
STXH STXD cabeçalho file texto SAPscript 3.139.019 808.600
ONR00 Nº geral de objeto 7.130.729 673.120
COEPL Objeto CO: partidas indiv.de tipos de atividade por período 1.726.107 589.624
COEPB Objeto CO: partidas individ.desvio/determ.result.por período 2.019.715 542.440
CKIT extos p/CKIS 2.708.683 492.872
COKA Objeto CO: dados de controle de classe de custo 1.416.818 233.112
COSL Objeto CO: totais de tipos de atividade 494.487 231.784
CKHS Cabeçalho - cálculo de custo unitário (controle + totais) 288.822 106.272
COEJ Objeto CO: partidas individuais referentes ao ano 34.814 41.008
BPEJ Parts.indiv. Valores anuais Obj.controlling 42.232 15.424
BPJA Reg.de totais para valor total anual Obj.controlling 21.704 10.320
COOI Administração de compromissos: itens individuais 14.558 9.648
COST Objeto CO: totais de tarifas 7.214 7.728
COEJT Objeto CO: partidas individuais de tarifas referentes ao ano 8.494 7.088
BPTR Dados do objeto Obj.controlling 11.890 6.464
COEPT Objeto CO: partidas individuais de tarifas refer.ao período 20.364 6.008
COKP Objeto CO: dados de controle planej.custos primários 13.006 4.512
COEJL Objeto CO: partidas indiv.tipos atividades referentes ao ano 5.903 3.888
COKS Objeto CO: dados de controle de custos secundários planej. 1.047 3.888
COSR Objeto CO: totais de índices estatísticos 2.931 3.888
COEPR Objeto CO: partidas indiv.índices estatísticos - ref.período 11.300 3.728
BPBK Cabeçalho de doc. Obj.controlling 5.042 3.232
COKL Objeto CO: dados de controle - tipo de atividade 2.661 3.232
CONTROLADORIA 251 de 325
CO_COSTCTR
Tabela Num. Registros Espaço (KB)
BPHI Dados relativos a várias hierarquias Obj.controlling 4.690 1.664
CSSL Centro de custo / tipo de atividade 1.503 352
ONRKS Índice de nº de objeto centro de custos 1.275 280
CKHT Textos p/CKHS 376 272
ONRKL Índice de nº de objeto centro de custo/tipo de atividade 773 272
STXB SAPscript: textos que não têm formato SAPscript 45 136
BPPE Reg.de totais para valores periódicos Obj.controlling 0 80
BPEP Partidas individ.valores periódicos Obj.controlling 0 64
COEJR Objeto CO: partidas indiv.índices estatísticos - ref.ao ano 18 48
CKIP Valores periódicos item cálculo de custo unitário 0 32
COKR Objeto CO: dados de controle para grandezas estatísticas 12 32
Total 47.169.434
Objeto Tipo Tablespace Tamanho (KB)
BPEP TABLE PSAPBTABD 16
BPEP~0 INDEX PSAPBTABI 16
BPEP~1 INDEX PSAPBTABI 16
BPEP~2 INDEX PSAPBTABI 16
Total 64
BPPE TABLE PSAPBTABD 16
BPPE~0 INDEX PSAPBTABI 16
BPPE~1 INDEX PSAPBTABI 16
BPPE~2 INDEX PSAPBTABI 16
BPPE~3 INDEX PSAPBTABI 16
Total 80
CDHDR TABLE PSAPBTABD 1.024.240
CDHDR~0 INDEX PSAPBTABI 918.936
Total 1.943.176
COEPT TABLE PSAPBTABD 3.216
COEPT~0 INDEX PSAPBTABI 856
COEPT~1 INDEX PSAPBTABI 1.936
Total 6.008
COEJT TABLE PSAPBTABD 5.136
COEJT~0 INDEX PSAPBTABI 656
COEJT~1 INDEX PSAPBTABI 1.296
Total 7.088
COST TABLE PSAPBTABD 5.136
COST~0 INDEX PSAPBTABI 1.296
COST~1 INDEX PSAPBTABI 1.296
Total 7.728
CSSL TABLE PSAPSTABD 176
CONTROLADORIA 252 de 325
Objeto Tipo Tablespace Tamanho (KB)
CSSL~0 INDEX PSAPSTABI 176
Total 352
ONRKL TABLE PSAPBTABD 176
ONRKL~0 INDEX PSAPBTABI 96
Total 272
ONRKS TABLE PSAPBTABD 184
ONRKS~0 INDEX PSAPBTABI 96
Total 280
32.4.6 COPA2_MANN – COPA contábil, área de resultado MANN
COPA2_MANN
Tabela Num. Registros Espaço (KB)
CKHS Cabeçalho - cálculo de custo unitário (controle + totais)
CKHT Textos p/ CKHS
CKIP Valores periódicos item cálculo de custo unitário
CKIS Itens cálc. custo unitário / especificaç. item custeio-produto
CKIT Textos p/ CKIS
COBK ObjetoCO: cabeçalho do documento
COEJ ObjetoCO: partidas individuais referentes ao ano
COEP ObjetoCO: partidas CO referentes ao período
COEPBR ObjetoCO: liquidação avaliada de partidas individuais
COEPD ObjetoCO: liquidação não avaliada de part. indiv. com status
COKA ObjetoCO: dados de controle de classe de custo
COKP ObjetoCO: dados de controle planej. custos primários
COKS ObjetoCO: dados de controle de custos secundários planej.
COOI Administração de compromissos: itens individuais
COSP ObjetoCO: totais de custos - lançamentos externos
COSPD ObjetoCO: totais custos externos - dos quais apropriados
COSS ObjetoCO: totais custos - lançamentos internos
COSSD ObjetoCO: totais custos internos - destes foram apropriados
EBII Fluxo de documentos CO/SD: parte faturada das parts. despesas
STXB SAPscript: textos que não têm formato SAPscript
STXH STXD cabeçalho file texto SAPscript
STXL STDX linhas file de texto SAPscript
32.4.7 COPA1_MANN - COPA baseada em cálc. custos, área de resultados MANN
COPA2_MANN
Tabela Num. Registros Espaço (KB)
CE1MANN Área de Resultado Mann 1.131.251 816.704
CE3MANN Área de Resultado Mann 442.740 179.248
CE2MANN Área de Resultado Mann 0 64
CONTROLADORIA 253 de 325
COPA2_MANN
Tabela Num. Registros Espaço (KB)
CEALE01 Distribuição CO-PA: referência de part. indiv. na distribuição 0 48
CE4MANN Área de Resultado Mann 191.653 69.200
Total 996.064
0,35%
Crescimento mensal estimado: 76.620 KB
Objeto Tipo Tablespace Tamanho (KB)
CE1MANN TABLE PSAPBTABD 573.456
CE1MANN~0 INDEX PSAPBTABI 120.336
CE1MANN~1 INDEX PSAPBTABI 74.256
CE1MANN~2 INDEX PSAPBTABI 48.656
Total 816.704
CE2MANN TABLE PSAPBTABD 16
CE2MANN~0 INDEX PSAPBTABI 16
CE2MANN~1 INDEX PSAPBTABI 16
CE2MANN~2 INDEX PSAPBTABI 16
Total 64
CE3MANN TABLE PSAPBTABD 102.416
CE3MANN~0 INDEX PSAPBTABI 48.656
CE3MANN~2 INDEX PSAPBTABI 28.176
Total 179.248
CEALE01 TABLE PSAPPOOLD 16
CEALE01~0 INDEX PSAPPOOLI 16
CEALE01~1 INDEX PSAPPOOLI 16
Total 48
CE4MANN TABLE PSAPBTABD 40.976
CE4MANN~0 INDEX PSAPBTABI 10.288
CE4MANN~1 INDEX PSAPBTABI 17.936
Total 69.200
32.4.8 CO_CCTR_ID – Centro de custo – dados reais
CO_CCTR_ID
Tabela Num. Registros Espaço (KB)
COBK Objeto CO: cabeçalho do documento
COEP Objeto CO: partidas CO referentes ao período
COEPL Objeto CO: partidas indiv.de tipos de atividade por período
COEPR Objeto CO: partidas indiv.índices estatísticos - ref.período
COEPT Objeto CO: partidas individuais de tarifas refer.ao período
COSL Objeto CO: totais de tipos de atividade
COSP Objeto CO: totais de custos - lançamentos externos
CONTROLADORIA 254 de 325
CO_CCTR_ID
Tabela Num. Registros Espaço (KB)
COSR Objeto CO: totais de índices estatísticos
COSS Objeto CO: totais custos - lançamentos internos
COST Objeto CO: totais de tarifas
32.4.9 CO_CCTR_PL – Centro de .custo – dados planejados
CO_CCTR_PL
Tabela Num. Registros Espaço (KB)
CKHS Cabeçalho - cálculo de custo unitário (controle + totais)
CKHT Textos p/CKHS
CKIP Valores periódicos item cálculo de custo unitário
CKIS Itens cálc.custo unitário/especificaç.item custeio-produto
CKIT Textos p/CKIS
COBK Objeto CO: cabeçalho do documento
COEJ Objeto CO: partidas individuais referentes ao ano
COEJL Objeto CO: partidas indiv.tipos atividades referentes ao ano
COEJR Objeto CO: partidas indiv.índices estatísticos - ref.ao ano
COEJT Objeto CO: partidas individuais de tarifas referentes ao ano
COKL Objeto CO: dados de controle - tipo de atividade
COKP Objeto CO: dados de controle planej.custos primários
COKR Objeto CO: dados de controle para grandezas estatísticas
COKS Objeto CO: dados de controle de custos secundários planej.
COSL Objeto CO: totais de tipos de atividade
COSP Objeto CO: totais de custos - lançamentos externos
COSR Objeto CO: totais de índices estatísticos
COSS Objeto CO: totais custos - lançamentos internos
COST Objeto CO: totais de tarifas
STXB SAP script: textos que não têm formato SAP script
STXH STXD cabeçalho file texto SAP script
STXL STDX linhas file de texto SAP script
32.4.10 CO_CCTR_EP – Centro de custo - partidas individuais
CO_CCTR_EP
Tabela Num. Registros Espaço (KB)
BPBK Cabeçalho de doc. Obj.controlling
BPEJ Parts.indiv. Valores anuais Obj.controlling
BPEP Partidas individ.valores periódicos Obj.controlling
COBK Objeto CO: cabeçalho do documento
COEJ Objeto CO: partidas individuais referentes ao ano
COEJL Objeto CO: partidas indiv.tipos atividades referentes ao ano
COEJR Objeto CO: partidas indiv.índices estatísticos - ref.ao ano
CONTROLADORIA 255 de 325
CO_CCTR_EP
Tabela Num. Registros Espaço (KB)
COEJT Objeto CO: partidas individuais de tarifas referentes ao ano
COEP Objeto CO: partidas CO referentes ao período
COEPB Objeto CO: partidas individ.desvio/determ.result.por período
COEPL Objeto CO: partidas indiv.de tipos de atividade por período
COEPR Objeto CO: partidas indiv.índices estatísticos - ref.período
COEPT Objeto CO: partidas individuais de tarifas refer.ao período
32.4.11 CO_ITEM – Partidas individuais de CO
CO_ITEM
Tabela Num. Registros Espaço (KB)
COBK Objeto CO: cabeçalho do documento
COEJ Objeto CO: partidas individuais referentes ao ano
COEJL Objeto CO: partidas indiv.tipos atividades referentes ao ano
COEJR Objeto CO: partidas indiv.índices estatísticos - ref.ao ano
COEP Objeto CO: partidas CO referentes ao período
COEPB Objeto CO: partidas individ.desvio/determ.result.por período
COEPL Objeto CO: partidas indiv.de tipos de atividade por período
COEPR Objeto CO: partidas indiv.índices estatísticos - ref.período
EBII Fluxo de documentos CO/SD: parte faturada das parts.despesas
32.4.12 CO_ALLO_ST – Doc. Completamente estornados de rateio, distribuição, ...
CO_ALLO_ST
Tabela Num. Registros Espaço (KB)
COEP Objeto CO: partidas CO referentes ao período 23.681.735 23.352.496
COBK Objeto CO: cabeçalho do documento 6.590.480 2.327.296
COEPL Objeto CO: partidas indiv.de tipos de atividade por período 1.726.107 589.624
COEJ Objeto CO: partidas individuais referentes ao ano 34.814 41.008
COEJL Objeto CO: partidas indiv.tipos atividades referentes ao ano 5.903 3.888
T811D Nºs documentos de alocação 901 304
Total 26.314.616
Objeto Tipo Tablespace Tamanho (KB)
T811D TABLE PSAPPOOLD 136
T811DS TABLE PSAPPOOLD 16
T811D~0 INDEX PSAPPOOLI 136
T811DS~0 INDEX PSAPPOOLI 16
Total 304
32.5 Administração do Archiving
Todas as funções relacionadas ao arquivamento de dados estão na transação SARA – Administração do Archive. A definição
do objeto de archive determina quais as funções estarão disponíveis nesta transação para cada objeto. As funções possíveis são:
CONTROLADORIA 256 de 325
Arquivar – permite escalonar o programa para gerar os arquivos seqüenciais;
Eliminação – permite escalonar o programa para eliminar dados do DB a partir dos arquivos seqüenciais gerados;
Análise – permite escalonar o programa para analisar os dados do archiving. Neste processo, os dados são lidos
seqüencialmente apresentando informações elementares, tais como, o número do item, cliente e dada da ordem. É possível
executar uma análise para uma ou várias seções de archiving. Tem todos os objetos têm a função de análise.
Índice – permite gerar e excluir índices para os arquivos do archiving existentes. Os índices precisam ser gerados quando
for necessário consultar documentos individuais pertencentes a vários objetos de archiving;
Sistema de Gravação (Storage System) – permite transferir os arquivos gerados para um sistema de gravação conectado e
recuperar arquivos gravados do sistema de gravação;
Gerenciamento – permite acompanhar as seções de archiving, apresentando e analisando informações de gerenciamento
específicas do objeto.
Preprocessamento – permite escalonar programa para preparar os objetos de dados para arquivamento, como, por
exemplo, marcando para eliminação;
Pos-processamento – permite escalonar programa para execução de operações após a seção de archiving, tais como,
atualizar estatísticas.
Outras funções – dependendo da ação selecionada, é possível acessar outras funções pelo menu Goto: Gráfico da rede,
recarregar, customizing, ver job, gerenciamento, pesquisar arquivos de archiving, tabelada do DB, AIS (archiving
Information System).
32.5.1 Archive Development Kit (ADK)
O ADK é a ferramenta que fornece todas as funções para arquivamento e recuperação de dados arquivados. O ADK executa
ajustes de dependência de hardware automaticamente, tais como, página de código, formato de número, e alterações estruturais
necessárias quando os arquivos do archiving são gerados. Também converte, temporariamente, os dados arquivados na versão
2.1 do R/3.
CONTROLADORIA 257 de 325
32.5.2 Autorizações
Um objeto de autorização (S_ARCHIVE) controla o acesso aos programas para um objeto de archiving. O ADK verifica as
autorizações para gravar, eliminar, ler e recarregar. As autorizações possíveis para cada objeto de archiving e componentes (tais
como FI, BC) são:
Permissão total
Alterar modo no gerenciamento do archive – manutenção de notas;
Leitura e análise de archives e consulta modo no gerenciamento do archive.
Também podem existir verificações de autorização adicionais de acesso para componentes específicos.
32.5.3 Gráfico da Rede
O gráfico da rede apresenta as dependências entre objetos de archiving e escalonamentos de seções de archiving. No geral, não
podem ser arquivados dados de objeto de archiving que tenham precedentes até que o precedente tenha sido processado. A rede
mostra os objetos precedentes. Um nó corresponde a um objeto e mostra: o nome do objeto, o nome do componente, descrição,
data do último archiving (verde – se archiving e eliminação ok; amarelo: se archiving ok e eliminação não ok ou archiving
processando e vermelho – archiving não processado)
CONTROLADORIA 258 de 325
Modificação de conta (account grouping) por tipo de movimento
O agrupamento de contas é uma subdivisão da transação/evento para a determinação de contas. Durante uma movimentação de
mercadorias, por exemplo, a contra partida para o lançamento do estoque (Transação GBB) pode ser feita em diferentes contas,
dependendo do tipo de movimento.
Tipo de Movimento Account grouping Conta
561 - Init. entry of stock bal. BSA 399999
201 - GI for cost center VBR 400000
Configurações padrão – o agrupamento do sistema padrão está ativo somente para a trasação GBB (contra partida da entrada
de estoque). Recomenda-se o uso das configurações padrão. Mas podem ser criados agrupamentos personalizados quando, por
exemplo, se deseja lançar as saídas de mercadoria para centros de custos e para ordens (tipo de movimento 261), em contas de
consumo em separado (tipo de movimento 201). Associa-se, por exemplo, o agrupamento ZZZ ao tipo de movimento 201 e o
agrupamento YYY para o tipo de movimento 261. Na configuração dos lançamentos automáticos, associa-se as contas
diferentes aos agrupamentos. Os agrupamentos para as transações PRD e KON são pre-definidas.
GBB (offsetting entry for inventory posting) – Overview of account groupings GBB
PRD (price differences) – Overview of account groupings PRD
KON (consignment liabilities) – Overview of account groupings KON
33 Arquivamento de CO - Controlling
33.1 Objetos de CO
Para o arquivamento de CO é importante analisar todas as funcionalidades que estão implantadas na empresa bem como o
período da sua implantação. Isto é importante, principlamente, na análise do crescimento das tabelas.
Funcionalidades Período Implantação
Centros de Custos 14 meses
Ordens Internas 14 meses
Planejamento Centro de Custo 14 meses
Planejamento Ordens Internas 14 meses
Planejamento de COPA 14 meses
Planejamento Elemento PEP 14 meses
ABC não implantado
Custos de produto 14 meses
Ledger de Materiais não utiliza
Objeto de Custo não utiliza
COPA baseado em contas não implantado
COPA baseado em custos 14 meses
Centros de Lucro não implantado
Os objetos de arquivamento disponíveis para o componente de CO estão relacionados abaixo. No entanto, é importante
salientar que objetos de arquivamento de outros módulos também arquivam dados de CO pois, ao contrário de FI, as partidas
individuais de CO são arquivadas juntamente com os objetos aos quais estão relacionados. Isto significa que objetos de SD
(Vendas e Distribuição), PP (Produção), PS (Projetos), PM (Manutenção) também irão arquivar dados de CO e, muitas vezes,
irão arquivar a maior parte dos dados.
CONTROLADORIA 259 de 325
Área Objetos de CO Descrição
Dem.Resultados COPAX_XXX Dados de demonstração de resultados
Centros de Custos CO_CCTR_PL Dados planejados do centro de custo
CO_CCTR_ID Dados reais do centro de custo
CO_CCTR_EP Partidas individuais do centro de custo
CO_COSTCTR Dados gerais centro de custo (inclusive dados mestre)
Custo Produto CO_COPC Estimativas de custos de produto
CO_KSTRG Objetos de custo
CO_BASEOBJ Componente
Ordens Internas CO_ORDER Dados mestres e transacionais de ordens
CO_KABR Documentos de liquidação
Ledger Materiais CO_ML_DAT Dados do ledger de materiais
CO_ML_BEL Documentos do ledger de materiais
CO_ML_IDX Índices do ledger de materiais
Geral CO_ITEM Partidas Individuais
Alocação CO_ALLO_ST Alocações canceladas
Classe de Custos CO_CEL_RCL Razão de reconciliação (razão de classe de custos)
Centro Lucro PCA_OBJECT Reg. totais e partidas individuais de Centro de Lucro
33.2 Tabelas de crescimento expressivo em CO
As tabelas relacionadas abaixo são tabelas que, normalmente, possuem uma grande quantidade de volume de dados.
Obviamente, isto poderá variar de instalação para instalação dependendo das funcionalidades implantadas. Esta relação serve
apenas como parâmetros. A tabela relaciona, também, os objetos de CO que arquivam dados destas tabelas. No entanto, é bom
lembrar que objetos de outros módulos também arquivam dados destas tabelas e precisam ser considerados na análise de
arquivamento de objetos de CO.
Tabela Descrição Objeto
COSB Totais desvios/determinações resultado CO-ORDER; CO_COSTCTR; CO_KSTRG
COSS Registros de Totais - lançamentos
internos
COPA1_RCOS; CO_CCTR_ID; CO_CCTR_PL;
CO_COSTCTR;
CO-ORDER; CO_KSTRG
COSP Registros de totais - lançamentos
externos
COPA1_RCOS; CO_CCTR_ID; CO_CCTR_PL;
CO_COSTCTR;
CO-ORDER; CO_KSTRG
COEP Partidas CO referentes ao período COPA1_RCOS; CO_ALLO_ST; CO_CCTR_EP;
CO_CCTR_ID; CO_COSTCTR; CO_ITEM;
CO_KSTRG; CO-ORDER
CKIS Itens cálc.custo unitário/espec.item
custeio-produto
COPA2-RCOS; CO_CCTR_PL; CO_COSTCTR;
CO_COPC; CO_KSTRG; CO_ORDER
KEKO Calc.custos produto - inf. de cabeçalho CO_COPC
KEPH Elementos cust.produção - custeio prod. CO_COPC
CE1RCOS Dem.Result (custos) - part.indi. reais COPA1_RCOS
CE2RCOS Dem.Result (custos) - part.indi.planej. COPA1_RCOS
COBK Cabeçalho do documento de CO COPA1_RCOS; CO_ALLO_ST; CO_CCTR_EP;
CO_CCTR_ID; CO_COSTCTR; CO_ITEM;
CO_KSTRG; CO-ORDER
COFP Linhas documento (adm.caixa projetos) CO-ORDER; PS_PROJECT
CKMI1 Índice doc. contábeis para material CO_ML_IDX
CONTROLADORIA 260 de 325
Tabela Descrição Objeto
CKIT Textos p/CKIS COPA2-RCOS; CO_CCTR_PL; CO_COSTCTR;
CO_COPC; CO_KSTRG; CO_ORDER
COSL Objeto CO: totais de tipos de atividade CO_CCTR_ID; CO_CCTR_PL; CO_COSTCTR; CO-
ORDER; CO_KSTRG
COSSD Tot.cust.internos - destes foram aprop. COPA2-RCOS; CO_KSTRG; CO_ORDER
AABLG Cluster para documento de liquidação CO_KABR; CO_KSTRG; CO_ORDER
COEPL Partidas indiv.de tipos de atividade por
período
CO_ALLO_ST; CO_CCTR_EP; CO_CCTR_ID;
CO_COSTCTR; CO_ITEM; CO_KSTRG; CO-ORDER
CDHDR Cabeçalho documento modificação CO_COSTCTR; CO_ORDER
CDCLS CDPOS - item cabeçalho modificação
PCDPOS -
CO_COSTCTR; CO_ORDER
Como já foi mencionado, os documentos de CO são armazenados juntamente com o objeto de CO. Os principais objetos de
custos de CO quando à quantidade, normalmente, são ordens de produção e documentos de vendas. Portanto, as tabelas COSB,
COSS, COSP, COEP, CKIS, CKIT, KEKO e COFP, normalmente, são arquivadas pelos objetos de Produção (PP_ORDER),
manutenção (PM_ORDER), projetos (PS_PROJECT) e vendas (SD_VBAK).
33.3 Banco de dados lógico dos objetos de CO
Banco de dados lógicos correspondem às estruturas de tabelas que serão usadas por cada Objeto para geração dos arquivos de
dados para arquivamento.
Objeto Descrição Banco Dados lógico Programa Análise
CO_ORDER Ordens internas ODK RKAARCS1
CO_CCTR_EP Partidas individuais de Centro Custo CEK RKSREP01
CO_CCTR_ID Dados reais de Centro Custo CIK RKSRID01
CO_CCTR_PL Dados planejados de Centro Custo CPK RKSRPL01
CO_COSTCTR Dados gerais de Centro Custo CRK RKSRCC01
CO_ALLO_ST Alocações Estornadas SAK RKSRSA01
CO_ITEM Partidas individuais de CO KOB1
CO_KABR Documento Apropriação AUK
CO_BASEOBJ Componentes BKK
CO_ML_DAT Registros Ledger de Materiais SAPRCKMP
CO_ML_BEL Documentos Ledger de Materiais SAPRCKMX
33.4 Análise da tabela de partidas individuais de CO (COEP)
Esta tabela contém todas as partidas individuais de CO para todos os objetos de custos e está sempre entre as maiores tabelas da
base de dados. Os tipos de objeto que podem ser encontrados nesta tabela estão relacionado abaixo. É importante analisar o
conteúdo desta tabela para verficar qual o objeto ou objetos, sejam de CO ou não, são os mais indicados, ou seja, os mais
significativos, para redução dos dados desta tabela.
Tipo de Objeto Objeto de Arquivamento
KS Centro de Custos
KL Centro de Custos/Tipo de Atividade
BP Processo empresarial (ABC) (CO_PROCESS)
IV Imóveis IS-RE: contrato de aluguer (RE_RNTL_AG)
OR, OP Ordens (CO_ORDER e PP_ORDER)
EO Demonstração de Resultados (COPA2_XXX)
HP Objetos de Custo (CO_KSTRG)
CONTROLADORIA 261 de 325
Tipo de Objeto Objeto de Arquivamento
VB documentos de vendas (SD_VBAK)
PR, NV, NP Projeto (PS_PROJECT)
AO Documentos de Conciliação
Através dos objetos de CO somente poderão ser eliminados registros de Centro de Custos, Demonstração de Resultados,
Objetos de Custos e Ordens Internas relacionadas na tabela abaixo:
Categoria da Ordem Descrição
01 Ordens internas CO
02 Ordens de provisão (delimitação)
03 Modelos de ordens
04 Ordem de produção de CO
05 Coletores de custo, run schedule planning
06 Ordens de QM
As classes de objetos dentro da COEP são:
Classe de Objeto Descrição
CSTIN Custos Indiretos
INVES Investimentos
PROD. Produção
RESUL Resultado, Vendas
A SAP disponibilizou programas para facilitar a análise desta tabela. O programa RARCCOA1 gerar os dados necessários para
análise das seguintes tabelas:
Tabela Descrição
COEP Partidas CO - reais
COEJ Partidas CO - planejadas
COSP Totais de custos - lançamentos externos
COSS Totais de custos - lançamentos internos
COST Registros de totais - tarifas
O programa RARCCOA2 mostra o resultado da análise comparando quanto que cada um dos objetos abaixos eliminam dados
destas tabelas:
Objeto Tipo Objeto Arquivado Descrição
PP_ORDER OR e OP Ordem de Produção
CO_ORDER OR e OP Ordem Interna de CO
PS_PROJECT PR e NV Projetos e Diagramas de Rede
CO_COSTCTR KS e KL Centros de Custos
CO_ITEM AO Partidas Individuais de CO
COAP2_XXXX EO Demonstração de Resultados baseado em Conta
Embora o programa não mencione, outros objetos também eliminam dados nestas tabelas.
33.5 Considerações sobre a Tabela COFP
A tabela COFP é uma tabela de aplicação (dados mestre e movimento). As operações de CO que atualizam a tabela COFP
(dados extraídos da tabela TJ01 - Operações empresarias) estão relacionadas abaixo. A maioria das operações desta tabela é da
operação KAFM (dados financeiros) cujos documentos de referência são da catgoria F (Contabilidade Financeira).
CONTROLADORIA 262 de 325
Operação
empr.
Texto Oper.
Adm.
Status
Atribui
nº doc.
CO
Inf. bloq.
período
CO
Prim./sec
./ AIA
Categoria
valor
KAFM Dados financeiros X
KAVM Compens.adiantam.c/ref.pedido
KAVO Compens.adiantam.s/ref.pedido
KAZM Adiantamento com ref.de pedido
KAZN Compens.adiantam.c/ref.pedido
KAZO Adiantamento X X Prim real
KAZV Compensação de adiantamento
PSFP Progr.faturamento p/elem.PEP X Prim planej
SDOR Criar ordem do cliente X P Prim
SDQU Criar cotação X P Prim
33.6 Considerações sobre a tabela COBK
A tabela COBK contém os cabeçalhos dos documentos de CO. Os itens destes documentos são armazenadas nas tabelas de
partidas individuais (COEP, COEJ, COEPR, etc.). Ao contrário de FI, as partidas individuais de CO não são arquivadas por
documentos e, sim, por objeto de custo. Analogamente, os objetos de arquivamento de CO são definidos por tipo de objeto e a
exclusão de registros nas tabelas de partidas individuais é feita por tipo de objeto. A tabela COBK somente terá um registro
eliminado quando todos as partidas individuais deste documento tenham sido eliminadas. Assim, por exemplo, um documento
que tenha duas linhas como uma alocação de custos de centro de custos para uma ordem somente terá o cabeçalho eliminado
depois de executado o arquivamento das partidas individuais de centros de custos e as partidas individuais da ordem.
Em função disto, o número de registros apontados para exclusão pelos programas de arquivamento executado em teste nem
sempre corresponde ao real. A determinação exata do número de registros que serão eliminados desta tabela é difícil.
Os documentos arquivados nesta tabela podem tem documentos de referência de 4 diferentes categorias:
Categoria Descrição
A Apropriação
F Contabilidade financeira
K Contabiblidade de custos
R Documento de contabilidade
33.7 Considerações sobre compactação
As informações de compactação de ordens para o Sistemas de Informação de CO-PC (Controlling de Custos de Produtos) são
armazenadas nas seguintes tabelas. Dependendo da hierarquia definida, o volume desta tabelas pode aumentar
consideravelmente. No entanto, os dados desta hierarquia não são arquivados por nenhum objeto devendo ser eliminada pela
própria função de geração da hierarquia (transação OKTO) quando não for mais necessário. É importante, portanto, que, na
definição desta hierarquia , somente as características realmente necessárias sejam definidas.
Tabela Descrição Estrutura
COSB Registros Totais - desvio de resultados COSBA
COSP Registros Totais - lançamentos externos COSPA
COSS Registros Totais - lançamentos internos COSSA
COSL Registros Totais - tipo de atividade COSLA
CONTROLADORIA 263 de 325
33.8 Objetos de Ordens Internas
33.8.1 Objeto: CO_ORDER - Ordens Internas
O objeto CO_ORDER permite arquivar todos os dados mestres e transacionais que atendam certas especificações para Ordens
Internas usando o banco de dados lógico ODK.
33.8.1.1 Tabelas envolvidas
Tabela Descrição
AABLG Cluster for Settlement Document
AFKO Dados de cabeçalho da ordem de ordens PCP
AFPO Item de ordem
ANIA Simulação de depreciação para projetos de inve
ANIB Simulação de depr./projetos de investimento: á
ANLI Tabela conexão: medida de investimento - objet
AUAI Montantes de apropriação de custos por área de
AUAK Cabeçalho de documento para apropriação
AUFK Dados mestre da ordem
AUSP Valores das modalidades das características
BPBK Cabeçalho de doc. Obj
BPEG Partidas individ.valores totais O
BPEJ Parts.indiv. Valores anuais O
BPGE Reg.de totais para valor total Obj
BPHI Dados relativos a várias hierarquias Obj
BPIG Índice de objeto de orçamento (orçamento globa
BPIJ Índice de objeto de orçamento (orçamento anual
BPJA Reg.de totais para valor total anual Obj
BPTR Dados do objeto Obj
CABN Característica
CABNT Textos para características
CAWNT Textos para valores
CDCLS Cluster structure for change documents
CDHDR Cabeçalho do documento de modificação
CKHS Cabeçalho - cálculo de custo unitário (control
CKHT Textos p/CKHS
CKIP Valores periódicos item cálculo de custo unitário
CKIS Itens cálc.custo unitário/especificaç.item custeio-produto
CKIT Textos p/CKIS
COANZ Índice de objetos com (solicitações)adiantamentos
COBK Objeto CO: cabeçalho do documento
COBRA Norma de apropriação para apropriação da ordem
COBRB Regras de repartição de normas de apropriação (apropr.ordem)
COEJ Objeto CO: partidas individuais referentes ao ano
COEJL Objeto CO: partidas indiv.tipos atividades referentes ao ano
COEJR Objeto CO: partidas indiv.índices estatísticos - ref.ao ano
COEP Objeto CO: partidas CO referentes ao período
COEPB Objeto CO: partidas individ.desvio/determ.result.por período
CONTROLADORIA 264 de 325
Tabela Descrição
COEPBR Objeto CO: liquidação avaliada de partidas individuais
COEPD Objeto CO: liquidação não avaliada de part.indiv.com status
COEPL Objeto CO: partidas indiv.de tipos de atividade por período
COEPR Objeto CO: partidas indiv.índices estatísticos - ref.período
COFP Linhas de documento (administração de caixa de projetos)
COKA Objeto CO: dados de controle de classe de custo
COKP Objeto CO: dados de controle planej.custos primários
COKR Objeto CO: dados de controle para grandezas estatísticas
COKS Objeto CO: dados de controle de custos secundários planej.
COOI Administração de compromissos: itens individuais
COSB Objeto-CO: totais de desvios/determinações de resultado
COSBD Obj.CO: totais desvios/provisionam. - dos quais apropriados
COSL Objeto CO: totais de tipos de atividade
COSP Objeto CO: totais de custos - lançamentos externos
COSPD Objeto CO: totais custos externos - dos quais apropriados
COSR Objeto CO: totais de índices estatísticos
COSS Objeto CO: totais custos - lançamentos internos
COSSD Objeto CO: totais custos internos - destes foram apropriados
EBII Fluxo de documentos CO/SD: parte faturada das parts.despesas
FMSU FI-FM Registros de totais
INOB Atribuição dum nº interno a um objeto
JCDO Docs.modificação para objeto de status (tabela JSTO)
JCDS Docs.modificação para status de sistema/usuário (tab. JEST)
JEST Status individual por objeto
JSTO Informações sobre objeto de status
KSSK Tabela de atribuição: objeto para classe
ONR00 Nº geral de objeto
ONROR Índice de nº de objeto ordem
RPSCO Banco dados para info de projeto: custos, receitas, finanças
STXB SAPscript: textos que não têm formato SAPscript
STXH STXD cabeçalho file texto SAPscript
STXL STDX linhas file de texto SAPscript
SWOR Sistema de classificação: palavras-chave
TPI03 Objetos CO: data do último cálculo de juros
33.8.1.2 Critérios de seleção
Os objetos de CO são subdividos em diversos tipos. As ordens são do tipo OR e OP e se subdividem em diversos subtipos
dentro do R/3.
Tipo Subtipo Descrição
OR,OP 10 Ordens de produção (PP_ORDER)
OR, OP 20 Diagrama de Rede (PS_PROJECT)
OR,OP 30 Ordens de manutenção (PM_ORDER)
OR,OP 40 Ordens de processo (PR_ORDER)
VB Ordens de vendas (SD_VBAK)
As categorias de ordem que são arquivadas por este objeto estão relacionadas abaixo. Correspondem às ordens internas de CO.
CONTROLADORIA 265 de 325
Categoria Descrição
01 Ordens internas CO
02 Ordens de provisão (delimitação)
03 Modelos de ordens
04 Ordem de produção de CO
05 Coletores de custo, run schedule planning
06 Ordens de QM
Além das restrições internas já definidas pelo sistema, alguns outros critérios de seleção padrão estão disponíveis disponíveis
para seleção das ordens a arquivar.
Critério de Seleção De Até
Tipo de ordem
Área de contabilidade de custos
Número da ordem
Data da última modificação
Controle de Processo Execução de Teste
Arquivar
Arquivar e Eliminar
Protocolo por Ordem
Controle de Processo: Existem trÊs alternativas possíveis para o controle de processo.
Execução de teste significa que nenhum arquivo será gerado. Somente serão selecionados os dados e emitido relatório
resumo relacionando os dados que seriam arquivados caso o processamento fosse efetuado de forma definitiva. Esta
alternativa é interessante para permitir analisar os dados a serem arquivados antes do arquivamento efetivo já, no caso deste
objeto, não está disponível a opção de Recarga.
Arquivar esta alternativa permite gerar o arquivo com os dados mas sem a eliminação dos dados do banco de dados. Será
preciso disparar o programa de deleção para eliminar os dados posteriormente. Mes mo que esta opção tenha sido escolhida,
o programa de deleção irá afetar os dados arquivados. Portanto, o sistema irá assumir a variante de teste do programa de
eliminação.
Arquivar e eliminar esta altermativa gera o arquivo e limpa os dados da base. O sistema irá executar a variante de
produção neste caso.
Se a eliminação de dados for bloqueada pela variante do programa de gravação, o programa de deleção não será nunca iniciado.
No entanto, a variante de execução em teste do programa de deleção é usada para este fim. Este variante é determinada no
Customizing de Arquivamento (transação SM30 com a view V_ARC_USR).
Protocolo: indica se deseja a emissão de log mais detalhado. No caso de ordens, lista todos os dados arquivados e as ordens
eliminadas. No caso de documentos de liquidação, lista todos os documentos arquivados e eliminados. No caso de Centros de
Custos, lista todos os centros de custos arquivados e eliminados.
33.8.1.3 Tempos de retenção
Somente serão arquivadas as ordens que atenderem a estes critérios, respeitarem os tempos de retenção 1 e 2 definidos no
cadastro de tipos de ordem, estiverem marcadas para eliminação.
As ordens internas possuem uma marcação para eliminação e um código de eliminação. Os dois indicadores são marcados por
transações. A marcação para eliminação pode ser alterada na transação de manutenção de dados mestre. Para conseguir marcar
uma ordem para eliminação, a ordem deve estar encerrada e o tempo de retenção 1 deve ter sido atingido. Assim, o tempo de
retenção 1 deve ser selecionado de forma a evitar uma eliminação indevida. Os dois tempos de retenção são definidos no tipo
de ordem. Para encerrar uma ordem (exceto as estatísticas) o saldo deve ser zero.
Ao contrário da marcação para eliminação, o código de eliminação não pode ser desmarcado. A marcação das ordens pode,
também, ser feita de forma coletiva (transação KOLV - Ativar marcação para eliminação/código de eliminação).
CONTROLADORIA 266 de 325
Tempo de Retenção 1 - determina o intervalo de tempo (em meses do calendário) que deve transcorrer entre a marcação
para eliminação e a marcação do código de eliminação.
Tempo de Retenção 2 - determina o intervalo de tempo (em meses do calendário) que deve transcorrer entre a marcação do
código de eliminação e o arquivamento efetivo.
33.8.2 Objeto: CO_KABR - documentos de apropriação
Este objeto permite arquivar e eliminar documentos de liquidação independentemente dos emissores da apropriação. Os
documentos de liquidação são criados durante as liqüidações e durante cálculo de provisões (delimitação) de documentos de
CO e FI. A eliminação dos documentos é por período, começando a partir do período mais antigo. Portanto, devem ser
eliminados todos ou nenhum dos documentos para um emissor dentro de um período. Também, somente serão eliminados
documentos de um período se todos os documentos de períodos anteriores estiverem arquivados.
Os documentos de apropriação serão armazenados juntamente com os objetos de apropriação através de outros objetos. A maior
parte das apropriações, normalmente, referem-se às ordens de produção. No arquivamento de ordens internas, os documentos
de liquidação referente às ordens também serão arquivados independentemente do tempo de retenção definido.
33.8.2.1 Tabelas Envolvidas
Tabelas envolvidas
Tabela Pool/Cluster
AUAA Documento de apropriação: segmento receptor AABLG
AUAB Documento de apropriação: regras de repartição AABLG
AUAO Segmento de documento: objetos CO a serem apropriados AABLG
AUAS Documento de apropriação: segmento de totais AABLG
AUAV Segmento de documento: operações AABLG
AUAI Montantes de apropriação de custos por área de depreciação
AUAK Cabeçalho de documento para apropriação
33.8.2.2 Critérios de seleção
Critério de Seleção De Até
Tipo de objeto emissor de apropriação (ver tabela abaixo)
Área de Contabilidade de Custos
Data lançamento (serão arquivados os documentos lançados até esta data).
Controle de Processo Execução de Teste
Arquivar
Arquivar e Eliminar
Protocolo por Documento
Tipo de Objeto Documento de liquidação arquivado
VBP Documentos de liquidação de ordens de vendas (itens de documentos de vendas)
AUF Documentos de liquidação de ordens internas
PSP Documentos de liquidação de projetos
Controle de Processo: Existem trÊs alternativas possíveis para o controle de processo.
Execução de teste significa que nenhum arquivo será gerado. Somente serão selecionados os dados e emitido relatório
resumo relacionando os dados que seriam arquivados caso o processamento fosse efetuado de forma definitiva. Esta
alternativa é interessante para permitir analisar os dados a serem arquivados antes do arquivamento efetivo já, no caso deste
objeto, não está disponível a opção de Recarga.
CONTROLADORIA 267 de 325
Arquivar esta alternativa permite gerar o arquivo com os dados mas sem a eliminação dos dados do banco de dados. Será
preciso disparar o programa de deleção para eliminar os dados posteriormente. Mes mo que esta opção tenha sido escolhida,
o programa de deleção irá afetar os dados arquivados. Portanto, o sistema irá assumir a variante de teste do programa de
eliminação.
Arquivar e eliminar esta altermativa gera o arquivo e limpa os dados da base. O sistema irá executar a variante de
produção neste caso.
Se a eliminação de dados for bloqueada pela variante do programa de gravação, o programa de deleção não será nunca iniciado.
No entanto, a variante de execução em teste do programa de deleção é usada para este fim. Este variante é determinada no
Customizing de Arquivamento (transação SM30 com a view V_ARC_USR).
Protocolo: indica se deseja a emissão de log mais detalhado. No caso de ordens, lista todos os dados arquivados e as ordens
eliminadas. No caso de documentos de liquidação, lista todos os documentos arquivados e eliminados. No caso de Centros de
Custos, lista todos os centros de custos arquivados e eliminados.
33.8.2.3 Tempos de retenção
Opcionalmente, pode ser considerado também o período de retenção. O tempo de retenção é definido no perfil de liquidação
(definido nos parâmetros de liquidação para as regras de apropriação). Se for informado um tempo inferior a três meses, o
sistema assumirá, automaticamente, três meses. Este mesmo procedimento é considerado para documentos gerados em
liquidações automáticas que possuem um tempo de retenção fixo de 3 meses. O tempo de retenção se inicia na data do
lançamento que, normalmente, corresponde ao último dia do período em que a liquidação ocorreu.
Opcionalmente, pode ser considerado também o período de retenção. O tempo de retenção é definido no perfil de liquidação. O
perfil de liquidação é definido nos parâmetros de liquidação para as regras de apropriação. Se for informado um tempo inferior
a três meses, o sistema assumirá, automaticamente, três meses. Este mesmo procedimento é considerado para documentos
gerados em liquidações automáticas. Eles possuem um tempo de retenção fixo de 3 meses. O tempo de retenção se inicia na
data do lançamento que, normalmente, corresponde ao último dia do período em que a liquidação ocorreu.
A data de lançamento (AUAK-BUDAT) de uma liquidação é um critério decisivo para o arquivamento do documento de
liquidação. O documento só pode ser arquivado se a data de lançamento:
for maior que o tempo de retenção (TKB1-RESAU) informado no perfil de apropriação. O tempo de retenção é informado
em meses e não em períodos de lançamento.
Deve ser posterior à data do último lançamento.
deve ser superior a três meses
Para que uma liquidação possa ser estornada e reprocessada os documentos de liquidação precisam estar na base on-line. Por
questões de consistência e integridade de dados, o sistema irá garantir que:
todos os documentos de liquidação de um emissor dentro de um período seja arquivado em conjunto. Os documentos não
serão arquivados caso qualquer um dos documentos de liquidação do emissor nãoi tenho ultrapassado o tempo de retenção.
Os documentos são arquivados por período começando pelo mais antigo, ou seja, os documentos de um determinado
emissor em um determinado período, somente serão arquivados se os documentos de liquidações de todos os períodos
anteriores já tiverem sido arquivados.
33.8.3 Recuperação de dados
Nenhum programa de leitura destas informações está disponível no SAP.
33.9 Objetos de Arquivamento de Centros de Custos
Para a Contabilidade de Centros de Custos, existem quatro objetos disponíveis que devem ser escolhidos de acordo com os
critérios definidos para arquivamento dos dados (tempo de retenção, dados a arquivar). No caso da Cosipa, recomenda-se o
arquivamento dos dados de centros de custos para redução das tabelas de lançamentos de CO (COEP principalmente).
CONTROLADORIA 268 de 325
33.9.1 Tabelas envolvidas
Abaixo, estão relacionadas as tabelas da base de dados tratadas por cada um dos objetos.
Tabela Descrição CO_CCTR_ID CO_CCTR_PL CO_CCTR_EP CO_COSTCTR
COBK Cabeçalho do documento x x x x
COEJT Part.indiv. Planej. Tarifas - val.anuais x x x
COEJR Part.indiv. Planej. Ind.estat - val.anuais x x x
COEJL Part.indiv. Planej. Tipo ativ. - val.anuais x x x
COEJ Part.indiv. Planej. - val.anuais x x x
COEPT Part.indiv. Reais tarifas - val.período x x x
COEPR Part.indiv. Reais Ind.estat. - val.per. x x x
COEPL Part.indiv. Tipos atividade - val.período x x x
COEP Part.indiv. Reais - val.período x x x
COEPB Part.indiv. Desvio / De.Res. - val.per. x x
BPEP Part.individuais - valores periódicos x x
BPEJ Part.individuais - valores anuais x x
BPBK Cabeçalho de documento x x
COST Reg.Totais - tarifas (real/planej) x x x
COSR Reg.Totais - índices estat. (real/planej) x x x
COSL Reg.Totais - tipos ativ. (real/planej) x x x
COSS Reg.Totais - lanç. internos (real/planej) x x x
COSP Reg.Totais - lanç. externos (real/planej) x x x
STXL Linhas file de texto SAP script x x
STXH Cabeçalho file texto SAP script x x
STXB SAP Script: textos s/formato SAP Script x x
COKS Dados controle - custos sec. planej. x x
COKR Dados controle - índice estat. planej. x x
COKP Dados controle - custos primários planej. x x
COKL Dados controle - tipo de atividade planej. x x
CKHS Cabec. - calc.cust.unit. (controle + totais) x x
CKHT Textos p/CKHS x x
CKIS It. calc.custo unit./esp. item custeio-prod. x x
CKIT Textos p/CKIS x x
CKIP Item cálculo custo unitário - val.per. x x
ONR00 Nº geral de objeto x
ONRKS Índice nº de objeto centro de custos x
ONRKL Índice nº objeto c.custo/tipo atividade x
CSSL Centro de custo / tipo de atividade x
COSB Reg.Totais - desvios/det. de resultado x
COOI Adm. compromissos: itens individuais x
COKA Dados de controle de classe de custo x
CDHDR Cabeçalho do documento de modificação x
CDCLS Cluster structure for change documents x
BPTR Dados do objeto x
BPHI Reg.Totais planej. - valores anuais x
BPPE Reg.Totais - val.periódicos x
BPJA Dados relativos a várias hierarquias x
O único objeto de Centro de Custos que arquiva dados da tabela COSB, que normalmente, é um tabela de grande volume de
dados é o CO_COSTCTR. No entanto, está tabela só terá informações de Centro de Custos se estiver sendo calculado os
CONTROLADORIA 269 de 325
desvios para centros de custos. Mesmo assim, a maior parte destes dados normalmente se deve a ordens de produção e serão
arquivados via objeto de arquivamento de PP (PP_ORDER).
As tabelas CDHDR e CDPOS que contêm o cabeçalho e os itens dos documentos de modificação também somente são tem
seus dados de centros de custos armazenados pelo CO_COSTCTR. No entanto, estas tabelas são atualizadas por todos os
módulos do R/3 e, normalmente, o volume dos dados referentes a centros de custos fica em torno de 10%.
Sob esta perspectiva, poderão ser usados os objetos CO_CCTR_ID e CO_CCTR_PL para armazenar os dados se centros de
custos reais e planejados em separado ou o objeto CO_CCTR_EP para armazenar somente as partidas individuais (reais e
planejadas). Os objetos CO_CCTR_ID e o CO_CCTR_PL, além das partidas individuais, arquiva também os registros de totais.
Através da utilização destes objetos, é possível definir-se tempos de retenção das informações diferentes para dados reais e
planejados.
Normalmente, o volume de dados correspondente a centros de custos na tabela de partidas individuais de CO (COEP) é
expressivo, principalmente quando se usa muitas alocações. Isto sempre justifica a análise de arquivamento de informações de
centros de custos.
Na tabela de partidas individuais por tipo de atividade (COEPL), 100% dos dados são de centros de custos.
33.9.2 Critérios de seleção
Todos os objetos de centro de custos permitem arquivar e eliminar dados selecionados por mandante, área de contabilidade de
custos, ano fiscal e grupo de centros de custos.
Critério de Seleção De Até
Área de Contabilidade de Custos
Exercício (Ano fiscal)
Grupo de Centro de Custos (opcional)
Controle do Processo Execução de teste
Arquivar
Arquivar e Eliminar
Controle de Processo: Existem trÊs alternativas possíveis para o controle de processo.
Execução de teste significa que nenhum arquivo será gerado. Somente serão selecionados os dados e emitido relatório
resumo relacionando os dados que seriam arquivados caso o processamento fosse efetuado de forma definitiva. Esta
alternativa é interessante para permitir analisar os dados a serem arquivados antes do arquivamento efetivo já, no caso deste
objeto, não está disponível a opção de Recarga.
Arquivar esta alternativa permite gerar o arquivo com os dados mas sem a eliminação dos dados do banco de dados. Será
preciso disparar o programa de deleção para eliminar os dados posteriormente. Mes mo que esta opção tenha sido escolhida,
o programa de deleção irá afetar os dados arquivados. Portanto, o sistema irá assumir a variante de teste do programa de
eliminação.
Arquivar e eliminar esta altermativa gera o arquivo e limpa os dados da base. O sistema irá executar a variante de
produção neste caso.
33.9.3 Recuperação de dados
Todos os relatórios do sistema de informações de centros de custos permitem o acesso a dados arquivados. Através a opção
“Fonte de Dados” da barra de ferramentas, o usuário poderá solicitar que os dados sejam extraídos de um extrato de relatório já
gravado anteriormente, da base de dados on-line ou de um arquivo gerado pelo processo de arquivamento.
Estão disponíveis os arquivos gerados pelos objetos CO_CCTR_ID (dados reais), CO_CCTR_PL (dados planejados) e
CO_COSTCTR (dados gerais). Os arquivos gerados pelo objeto de partidas individuais CO_CCTR_EP não podem ser
acessados por estes relatórios.
No entanto, somente poderão ser acessados dados de arquivos gerados por um mesmo objeto. Assim, se os dados reais e
planejados forem arquivados por objetos diferentes, não poderão ser visualizados no mesmo relatório. Para consultar executar
relatórios comparativos de dados reais e planejados será preciso arquivá-los em conjunto através do objeto CO_COSTCTR.
CONTROLADORIA 270 de 325
33.9.4 Objeto: CO_CCTR_EP - partidas individuais de centros de custos
Este objeto permite arquivar e eliminar todas ou algumas das partidas individuais dos centros de custos. Os registros de totais
também serão arquivados de forma a manter a integridade entre os objetos mas não serão eliminados do banco de dados do R/3.
No caso do planejamento, os valores de cada período planejado são armazenados em um mesmo registro de dados. Portanto, só
é possível arquivar todos os períodos já que o registro inteiro será arquivado. Neste caso, o sistema irá desconsiderar o intervalo
de períodos definido nos critérios de seleção.
No caso de lançamentos reais, as partidas individuais são armazenados em registros individuais podendo ser delimitados
através do parâmetro intervalo de períodos.
É bom lembrar que as alocações planejadas ou reais (rateios, distribuição, transferências periódicas e alocação indireta de
atividade) e as reavaliações planejadas não poderão ser repetidas após o arquivamento das partidas individuais.
33.9.4.1 Banco de Dados lógico: CEK (transação OKEM)
Banco de dados CEK
Tabela Descrição Tab.BD
1. CSKS Registro mestre de centros de custo CSKS
1.1.BPTR1 Dados de objeto Controle BPTR
1.1.1.BPJA1 Reg.Totais valor anual Controle BPJA
1.1.1.1.BPVJ1 Tabela gerada para a visão BPVJ1 BPVJ1
1.1.2.BPPE1 Reg.Totais val. periódicos Controle
1.1.2.1.BPVP1 Tabela gerada para a visão BPVP1 BPVP1
1.2.COSP1 Reg.Totais - lançamentos externos COSP KS
1.2.1.COVP11 Part.Ind. por período e CabeçDoc. COEP KS
1.2.2.COVJ11 Part.Ind. por ano e cabeç.doc. COEJ KS
1.3.COSS1 Reg.Totais - lançamentos internos COSS KS
1.3.1.COVP12 Part.Ind. por período e CabeçDoc. COEP KS
1.3.2.COVJ12 Part.Ind. por ano e cabeç.doc. COEJ KS
1.4.COSR1 Reg.Totais - índices estatísticos COSR KS
1.4.1.COVPR1 Part.Ind. - índices estatísticos - per. COEPR KS
1.4.2.COVJR1 Part.Ind. - índices estatísticos - por ano COEJR KS
1.5.COSB1 Reg.Totais - desvios/delimitações COSB KS
1.5.1.COVPB1 Part.Ind. - desvio/delimitação per. COEPB KS
1.6.CSSL Centro de custo / tipo de atividade CSSL KL
1.6.1.COSP2 Reg.Totais - lançamentos externos COSP KL
1.6.1.1.COVP21 Part.Ind. por período e CabeçDoc. COEP KL
1.6.1.2.COVJ21 Part.Ind. por ano e cabeç.doc. COEJ KL
1.6.2.COSS2 Reg.Totais - lançamentos internos COSS KL
1.6.2.1.COVP22 Part.Ind. por período e CabeçDoc. COEP KL
1.6.2.2.COVJ22 Part.Ind. por ano e cabeç.doc. COEJ KL
1.6.3.COSL2 Reg.Totais - tipos de atividade COSL KL
1.6.3.1.COVPL2 Part.Ind. tipos atividade por período COEPL KL
1.6.3.2.COVJL2 Part.Ind. tipos atividade por ano COEJL KL
1.6.4.COSR2 Reg.Totais - índices estatísticos COSR KL
1.6.4.1.COVPR2 Part.Ind. índices estatísticos - per. COEPR KL
CONTROLADORIA 271 de 325
Banco de dados CEK
Tabela Descrição Tab.BD
1.6.4.2.COVJR2 Part.Ind. índices estatísticos - por ano COEJR KL
1.6.5.COSB2 Reg.Totais - desvios/delimitações COSB KL
1.6.5.1.COVPB2 Part.Ind. - desvio/delimitação per. COEPB KL
1.6.6.COST2 Reg.Totais - tarifas COST KL
1.6.6.1.COVPT2 Part.Ind. tarifas refer.ao per. COEPT KL
1.6.6.2.COVJT2 Part.Ind. tarifas refer.ao ano COEJT KL
33.9.4.2 Critérios de seleção
Critério de Seleção De Até
Área de Contabilidade de Custos
Exercício (Ano fiscal)
Período (opcional)
Versão (opcional)
Categoria de Valor (real, palnejado, teórico, etc.)
Grupo de Centro de Custos (opcional)
Controle do Processo Execução de teste
Arquivar
Arquivar e Eliminar
Através das categorias de valores é possível arquivar em separado, dados reais (categorias 03,04,09 e 11) e planejados
(categorias 01,02, 08 e 10). Assim, é possível estabelecer tempos de permanência dos dados direfente para dados reais e
planejados, se for o caso.
A versão refere-se aos dados planejados. A definição dos tempos de retenção dos centros de custos é que iria definir os critérios
de seleção exercício e período.
33.9.4.3 Recuperação dos dados
O programa de leitura do CO_CCTR_EP (RKSARCS1) apenas relaciona as partidas individuais para cada um dos centros de
custos relacionados. As informações podem ser manipuladas como um relatório normal de centro de custos.
33.9.5 Objeto: CO_CCTR_ID - dados reais de centros de custos
Este objeto permite arquivar e eliminar todos os lançamentos reais. As categorias de valores reais para restrição são:
04 - reais;
03 - decomposição por tipo de atividade;
09 - correção p/volume negócios internos entre centros de custos e
11 - dados estatísticos.
Se a empresa não estiver trabalhando com o planejamento, o arquivamento de dados reais é equivalente ao arquivamento de
dados gerais, exceto que o intervalo de validade dos centros de custos permanecem inalterados.
CONTROLADORIA 272 de 325
33.9.5.1 Banco de Dados lógico: CIK
Banco de Dados CIK
Tabela Descrição Tab.BD
1. CSKS Registro mestre de centros de custo
1.1. COSP1 RegTotai - lançamentos externos COSP KS
1.1.1. COVP11 Part.Indiv. - p/período e CabeçDoc. COEP KS
1.2. COSS1 Reg.Totais - lançamentos internos COSS KS
1.2.1. COVP12 Part. Indiv - p/período e CabeçDoc. COEP KS
1.3. COSR1 Reg.Totais - índices estatísticos COSR KS
1.3.1. COVPR1 Part.Indiv.índices estatísticos - per. COEPR KS
1.4. CSSL Centro de custo / tipo de atividade CSSL KL
1.4.1. COSP2 Reg.Totais - lançamentos externos COSP KL
1.4.1.1. COVP21 Part.Indiv. p/ período e CabeçDoc. COEP KL
1.4.2. COSS2 Reg.Totais - lançamentos internos COSS KL
1.4.2.1. COVP22 Part.Indiv. p/ período e CabeçDoc. COEP KL
1.4.3. COSL2 totais de tipos de atividade COSL KL
1.4.3.1. COVPL2 Part. Indiv.tps.atividade por período COEPL KL
1.4.4. COST2 totais de tarifas COST KL
1.4.4.1. COVPT2 partida individual tarifas refer.ao per. COEPT KL
1.4.5. COSR2 totais de índices estatísticos COSR KL
1.4.5.1. COVPR2 partida indiv.índices estatísticos - per. COEPR KL
33.9.5.2 Critérios de seleção
Critério de Seleção De Até
Área de Contabilidade de Custos
Exercício (Ano fiscal)
Grupo de Centro de Custos
Controle do Processo Execução de teste
Arquivar
Arquivar e Eliminar
33.9.5.3 Recuperação dos dados
O programa de leitura do CO_CCTR_ID (RKSARCS1) apenas relaciona as partidas individuais para cada um dos centros de
custos relacionados. As informações podem ser manipuladas como um relatório normal de centro de custos.
33.9.6 Objeto: CO_CCTR_PL - dados planejados de centros de custos
Este objeto é usado para eliminar dados de outras versões diferente da versão zero que não são mais necessárias. A seleção
pode ser restrita a uma única versão de planejamento ou a várias versões. As categorias de valores planejados para restrição
são:
01 - planejados;
02 - decomposição de tipo de atividades;
08 - correção p/volume negócios internos entre centros de custos e
CONTROLADORIA 273 de 325
10 - estatísticos.
A versão zero não deve ser aquivada durante um ano fiscal porque impossibilitaria a execução de algumas transações de
lançamentos reais e reavaliações.
33.9.6.1 Banco de dados lógico: CPK
Banco de dados CPK - dados planejados
Tabela Descrição Tab.BD
1. CSKS Registro mestre de centros de custo CSKS
1.1.COKA1 Dados Controle Classe custos COKA KS
1.2.COKP1 Dados Controle Planejamento primário COKP KS
1.2.1.HEAD11 SAPscript: cabeçaçho de texto KS
1.2.1.1.LINE11 SAPscript: linhas de texto KS
1.2.2.CKHS1 Cabec: calc.cust.unit (controle+totais) CKHS KS
1.2.2.1.CKHT1 Textos para CKHS CKHT KS
1.2.2.2.HEAD12 SAPscritp: cabeçalho de texto KS
1.2.2.2.1.LINE12 SAPscript: Linhas de texto KS
1.2.2.3.CKIS1 Pos.calc.cust.unit/espec.item geraç. CKIS KS
1.2.2.3.1.CKIT1 Textos para CKIS CKIT KS
1.2.2.4.CKIP1 Val.per.item calc.custo unitário CKIP KS
1.3.COSP1 Reg.Totais - lançamentos externos COSP KS
1.3.1.COVJ11 Part.Ind. por ano e cabeç.doc. COEJ KS
1.4.COKS1 Dados Controle planej. secundário COKS KS
1.4.1.HEAD13 SAPscript: cabeçalho de textos KS
1.4.1.1.LINE13 SAP script: linhas de texto KS
1.5.COSS1 Reg.Totais - lançamentos internos COSS KS
1.5.1.COVJ12 Part.Ind. por ano e cabeç.doc. COEJ KS
1.6.COKR1 Dados Controle indices estatítiscos COKR KS
1.6.1.HEAD14 SAPscript: cabeçalho de textos KS
1.6.1.1.LINE14 SAP script: linhas de texto KS
1.7.COSR1 Reg.Totais - índices estatísticos COSR KS
1.7.1.COVJR1 Part.Ind. - índices estatísticos - por ano COEJR KS
1.8.CSSL Centro de custo / tipo de atividade CSSL KL
1.8.1.COKA2 Dados Controle Classe custos COKA KL
1.8.2.COKP2 Dados Controle Plano primário COKP KL
1.8.2.1.HEAD21 SAPscript: cabeçaçho de texto KL
1.8.2.1.1.LINE21 SAPscript: linhas de texto KL
1.8.3.COSP2 Reg.Totais - lançamentos externos COSP KL
1.8.3.1.COVJ21 Part.Ind. por ano e cabeç.doc. COEJ KL
1.8.4.COKS2 Dados Controle plano secundário COKS KL
1.8.4.1.HEAD22 SAPscript: cabeçalho de textos KL
1.8.4.1.1.LINE22 SAP script: linhas de texto KL
1.8.5.COSS2 Reg.Totais - lançamentos internos COSS KL
CONTROLADORIA 274 de 325
Banco de dados CPK - dados planejados
Tabela Descrição Tab.BD
1.8.5.1.COVJ22 Part.Ind. por ano e cabeç.doc. COEJ KL
1.8.6.COKL2 Dados Controle tipo atividade COKL KL
1.8.6.1.HEAD23 SAPscript: cabeçalho de textos KL
1.8.6.1.1.LINE23 SAP script: linhas de texto KL
1.8.7.COSL2 Reg.Totais - tipos de atividade COSL KL
1.8.7.1.COVJL2 Part.Ind. tipos atividade por ano COEJL KL
1.8.8.COST2 Reg.Totais - tarifas COST KL
1.8.8.1.COVJT2 Part.Ind. tarifas refer.ao ano COEJT KL
1.8.9.COKR2 Dados Controle indices estatítiscos COKR KL
1.8.9.1.HEAD24 SAPscript: cabeçalho de textos KL
1.8.9.1.1.LINE24 SAP script: linhas de texto KL
1.8.10.COSR2 Reg.Totais - índices estatísticos COSR KL
1.8.10.1.COVJR2 Part.Ind. índices estatísticos - por ano COEJR KL
33.9.6.2 Critérios de seleção
Critério de Seleção De Até
Área de Contabilidade de Custos
Exercício (Ano fiscal)
Versão
Grupo de Centro de Custos
Controle do Processo Execução de teste
Arquivar
Arquivar e Eliminar
33.9.6.3 Recuperação dos dados
O programa de leitura do CO_CCTR_ID (RKSARCS1) apenas relaciona as partidas individuais para cada um dos centros de
custos relacionados. As informações podem ser manipuladas como um relatório normal de centro de custos.
33.9.7 Objeto: CO_COSTCTR - dados gerais de centros de custos
Este objeto permite arquivar e eliminar todos dos dados dos centros de custos. Não é possível restringir a um único centro de
custos. Se todos os dados de um centro de custo forem eliminados, o ano fiscal arquivado é removido do intervalo de validade
do centro de custos. O centro de custos somente deve ser arquivado se não for mais necessário para lançamentos e avaliações.
Dados arquivados não poderão mais ser usados para análises comparativas.
33.9.7.1 Banco de dados lógico: CRK
Banco de dados CRK - dados gerais
Tabela Descrição Tab.BD
1. CSKS Registro mestre de centros de custo CSKS
1.1.CSKT Textos de centros de custos CSKT
1.2.CDHDR Cabeçalho Documento Modificação CDHDR
CONTROLADORIA 275 de 325
Banco de dados CRK - dados gerais
Tabela Descrição Tab.BD
1.2.1.CDPOS Item Documento Modificação CDPOS
1.3.THEAD SAPscript: cabeçalho de texto
1.3.1.TLINE SAPscript: linhas de texto
1.4.BHHI1 Dados p/todas as hierarquias Controle
1.5.BPTR1 Dados de objeto Controle BPTR
1.5.1.BPJA1 Reg.Totais valor anual Controle BPJA
1.5.1.1.BPVJ1 Tabela gerada para a visão BPVJ1 BPVJ1
1.5.2.BPPE1 Reg.Totais val. periódicos Controle
1.5.2.1.BPVP1 Tabela gerada para a visão BPVP1 BPVP1
1.6.COKA1 Dados Controle Classe custos COKA KS
1.7.COKP1 Dados Controle Planejamento primário COKP KS
1.7.1.HEAD11 SAPscript: cabeçaçho de texto KS
1.7.1.1.LINE11 SAPscript: linhas de texto KS
1.7.2.CKHS1 Cabec: calc.cust.unit (controle+totais) CKHS KS
1.7.2.1.CKHT1 Textos para CKHS CKHT KS
1.7.2.2.HEAD12 SAPscritp: cabeçalho de texto KS
1.7.2.2.1.LINE12 SAPscript: Linhas de texto KS
1.7.2.3.CKIS1 Pos.calc.cust.unit/espec.item geraç. CKIS KS
1.7.2.3.1.CKIT1 Textos para CKIS CKIT KS
1.7.2.4.CKIP1 Val.per.item calc.custo unitário CKIP KS
1.8.COSP1 Reg.Totais - lançamentos externos COSP KS
1.8.1.COVP11 Part.Ind. por período e CabeçDoc. COEP KS
1.8.2.COVJ11 Part.Ind. por ano e cabeç.doc. COEJ KS
1.8.3.COVO1 Par.Ind. comprimisso (s/cabec.doc) COOI KS
1.9.COKS1 Dados Controle planej. secundário COKS KS
1.9.1.HEAD13 SAPscript: cabeçalho de textos KS
1.9.1.1.LINE13 SAP script: linhas de texto KS
1.10. COSS1 Reg.Totais - lançamentos internos COSS KS
1.10.1.COVP12 Part.Ind. por período e CabeçDoc. COEP KS
1.10.2.COVJ12 Part.Ind. por ano e cabeç.doc. COEJ KS
1.11. COKR1 Dados Controle indices estatítiscos COKR KS
1.11.1.HEAD14 SAPscript: cabeçalho de textos KS
1.11.1.1.LINE14 SAP script: linhas de texto KS
1.12. COSR1 Reg.Totais - índices estatísticos COSR KS
1.12.1.COVPR1 Part.Ind. - índices estatísticos - per. COEPR KS
1.12.2.COVJR1 Part.Ind. - índices estatísticos - por ano COEJR KS
1.13. COSB1 Reg.Totais - desvios/delimitações COSB KS
1.13.1.COVPB1 Part.Ind. - desvio/delimitação per. COEPB KS
1.14. CSSL Centro de custo / tipo de atividade CSSL KL
1.14.1.COKA2 Dados Controle Classe custos COKA KL
CONTROLADORIA 276 de 325
Banco de dados CRK - dados gerais
Tabela Descrição Tab.BD
1.14.2.COKP2 Dados Controle Plano primário COKP KL
1.14.2.1.HEAD21 SAPscript: cabeçaçho de texto KL
1.14.2.1.1.LINE21 SAPscript: linhas de texto KL
1.14.3.COSP2 Reg.Totais - lançamentos externos COSP KL
1.14.3.1.COVP21 Part.Ind. por período e CabeçDoc. COEP KL
1.14.3.2.COVJ21 Part.Ind. por ano e cabeç.doc. COEJ KL
1.14.4.COKS2 Dados Controle plano secundário COKS KL
1.14.4.1.HEAD22 SAPscript: cabeçalho de textos KL
1.14.4.1.1.LINE22 SAP script: linhas de texto KL
1.14.5.COSS2 Reg.Totais - lançamentos internos COSS KL
1.14.5.1.COVP22 Part.Ind. por período e CabeçDoc. COEP KL
1.14.5.2.COVJ22 Part.Ind. por ano e cabeç.doc. COEJ KL
1.14.6.COKR2 Dados Controle indices estatítiscos COKR KL
1.14.6.1.HEAD24 SAPscript: cabeçalho de textos KL
1.14.6.1.1.LINE24 SAP script: linhas de texto KL
1.14.7.COSR2 Reg.Totais - índices estatísticos COSR KL
1.14.7.1.COVPR2 Part.Ind. índices estatísticos - per. COEPR KL
1.14.7.2.COVJR2 Part.Ind. índices estatísticos - por ano COEJR KL
1.14.8.COKL2 Dados Controle tipo atividade COKL KL
1.14.8.1.HEAD23 SAPscript: cabeçalho de textos KL
1.14.8.1.1.LINE23 SAP script: linhas de texto KL
1.14.9.COSL2 Reg.Totais - tipos de atividade COSL KL
1.14.9.1.COVPL2 Part.Ind. tipos atividade por período COEPL KL
1.14.9.2.COVJL2 Part.Ind. tipos atividade por ano COEJL KL
1.14.10.COSB2 Reg.Totais - desvios/delimitações COSB KL
1.14.10.1.COVPB2 Part.Ind. - desvio/delimitação per. COEPB KL
1.14.11.COST2 Reg.Totais - tarifas COST KL
1.14.11.1.COVPT2 Part.Ind. tarifas refer.ao per. COEPT KL
1.14.11.2.COVJT2 Part.Ind. tarifas refer.ao ano COEJT KL
CONTROLADORIA 277 de 325
33.9.7.2 Critérios de seleção
Critério de Seleção De Até
Área de Contabilidade de Custos
Exercício (Ano fiscal)
Grupo de Centro de Custos
Controle do Processo Execução de teste
Arquivar
Arquivar e Eliminar
33.9.7.3 Recuperação dos dados
O programa de leitura do CO_CCTR_ID (RKSARCS1) apenas relaciona as partidas individuais para cada um dos centros de
custos relacionados. As informações podem ser manipuladas como um relatório normal de centro de custos.
33.10 Objeto: CO_ALLO_ST - Alocações estornadas
Este objeto permite arquivar e eliminar todas as alocações de centro de custo que foram estornadas (incluindo rateios,
distribuições, transferências periódicas e alocação indireta de atividade) a nível de mandante, área de contabilidade de custos e
ano fiscal. Se uma dada alocação é executada freqüentemente, é gerado um grande volume de dados especialmente no caso de
distribuição. Os documento (original e de estorno) associados ao estorno e os itens destes documentos podem ser eliminados
através deste objeto. A seleção pode limitar a um simples ciclo ou a múltiplos ciclos.
Os dados abordados por este objetos não constituem informações relevantes para a empresa. São gerados, na verdade, apenas
por uma definição de procedimento do sistema.
Este deve ser o primeiro objeto a ser executado uma vez que irá eliminar movimentações que seriam arquivadas por outros
objetos (ligados a CO) sem necessidade. Assim, por exemplo, se o objeto de arquivamento de centro de custo for executado
antes deste, todas as alocações estornadas serão alocadas também por ele.
33.10.1 Banco de dados lógico SAK
Banco de dados lógico SAK - Documentos de Alocação completamente estornados
T811D T - T811D Nºs documentos de alocação
COVP11 T - COVP11 Objeto CO: partida individual por período e cabeçalho de documento
COVJ11 T - COVJ11 Objeto CO: partida individual por ano e cabeçalho de documento
COVPL1 T - COVPL1 Objeto CO: partida individual tipos de atividade por período
COVJL1 T - COVJL1 Objeto CO: partida individual tipos de atividade por ano
Tabela T811D
Campo Chave Catg. Tam. Dec. Descrição
MANDT CLNT C 3 Mandante
TAB CHAR C 30 Nome da tabela
CYCLE CHAR C 10 Ciclo de rateio / distribuição
SDATE DATS D 8 Data de início
GJAHR NUMC N 4 Exercício contábil
PERIO NUMC N 3 Período contábil
DPOS NUMC N 4 Nº seqüencial documento de alocação
DOCNR CHAR C 10 Nº documento
ADATE DATS D 8 Data de execução
RDOC CHAR C 10 Nº documento de estorno alocações
CONTROLADORIA 278 de 325
Tabela T811D
Campo Chave Catg. Tam. Dec. Descrição
RDATE DATS D 8 Data de estorno alocação
REVERSED CHAR C 1 Código: documento estornado?
ETAB CHAR C 30 Nome do banco de dados físico
BISPE NUMC N 3 Período contábil
Tabela COVP11
Campo Chave Catg. Tam. Dec. Descrição
MANDT CLNT C 3 Mandante
KOKRS CHAR C 4 Área de contabilidade de custos
BELNR CHAR C 10 Nº documento
BUZEI NUMC N 3 Linha de lançamento
K_GJAHR NUMC N 4 Exercício contábil
K_VERSN CHAR C 3 Versão
K_VRGNG CHAR C 4 Operação CO
K_TIMESTMP DEC P 9 Momento da criação (Greenwich Meantime)
PERIO NUMC N 3 Período
WTGBTR CURR P 8 2 Valor total em moeda de transação
WOGBTR CURR P 8 2 Valor total em moeda do objeto
WKGBTR CURR P 8 2 Valor total em moeda da área de contabili
WKFBTR CURR P 8 2 Valor fixo em moeda da área de contabilid
PAGBTR CURR P 8 2 Desvio de preço total em moeda da área co
Tabela COVJ11
Campo Chave Catg. Tam. Dec. Descrição
MANDT CLNT C 3 Mandante
KOKRS CHAR C 4 Área de contabilidade de custos
BELNR CHAR C 10 Nº documento
BUZEI NUMC N 3 Linha de lançamento
PERBL NUMC N 3 Bloco de períodos
K_GJAHR NUMC N 4 Exercício contábil
K_VERSN CHAR C 3 Versão
K_VRGNG CHAR C 4 Operação CO
K_TIMESTMP DEC P 9 Momento da criação (Greenwich Meantime)
WTG001 CURR P 8 2 Valor total em moeda de transação
WTG002 CURR P 8 2 Valor total em moeda de transação
WTG003 CURR P 8 2 Valor total em moeda de transação
WTG004 CURR P 8 2 Valor total em moeda de transação
WTG005 CURR P 8 2 Valor total em moeda de transação
Tabela COVPL1
Campo Chave Catg. Tam. Dec. Descrição
MANDT CLNT C 3 Mandante
KOKRS CHAR C 4 Área de contabilidade de custos
BELNR CHAR C 10 Nº documento
CONTROLADORIA 279 de 325
Tabela COVPL1
Campo Chave Catg. Tam. Dec. Descrição
BUZEI NUMC N 3 Linha de lançamento
K_GJAHR NUMC N 4 Exercício contábil
K_VERSN CHAR C 3 Versão
K_VRGNG CHAR C 4 Operação CO
K_TIMESTMP DEC P 9 Momento da criação (Greenwich Meantime)
PERIO NUMC N 3 Período
MEINH UNIT C 3 Unidade de Atividade
LSTBTR QUAN P 8 3 Volume de atividade
MEINB UNIT C 3 Unidade de Atividade lançada
LSBTR QUAN P 8 3 Volume de atividade segundo documento
KAPBTR QUAN P 8 3 Capacidade
Tabela COVJL1
Campo Chave Catg. Tam. Dec. Descrição
MANDT CLNT C 3 Mandante
KOKRS CHAR C 4 Área de contabilidade de custos
BELNR CHAR C 10 Nº documento
BUZEI NUMC N 3 Linha de lançamento
PERBL NUMC N 3 Bloco de períodos
K_GJAHR NUMC N 4 Exercício contábil
K_VERSN CHAR C 3 Versão
K_VRGNG CHAR C 4 Operação CO
K_TIMESTMP DEC P 9 Momento da criação (Greenwich Meantime)
MEINH UNIT C 3 Unidade de Atividade
LST001 QUAN P 8 3 Volume de atividade
LST002 QUAN P 8 3 Volume de atividade
LST003 QUAN P 8 3 Volume de atividade
LST004 QUAN P 8 3 Volume de atividade
33.10.2 Critérios de Seleção
Critério de Seleção De Até
Área de Contabilidade de Custos
Exercício (Ano fiscal)
Ciclo
Controle do Processo Execução de teste
Arquivar
Arquivar e Eliminar
Controle de Processo: Existem três alternativas possíveis para o controle de processo.
Execução de teste significa que nenhum arquivo será gerado. Somente serão selecionados os dados e emitido relatório
resumo relacionando os dados que seriam arquivados caso o processamento fosse efetuado de forma definitiva. Esta
alternativa é interessante para permitir analisar os dados a serem arquivados antes do arquivamento efetivo já, no caso deste
objeto, não está disponível a opção de Recarga.
Arquivar esta alternativa permite gerar o arquivo com os dados mas sem a eliminação dos dados do banco de dados. Será
preciso disparar o programa de deleção para eliminar os dados posteriormente. Mes mo que esta opção tenha sido escolhida,
CONTROLADORIA 280 de 325
o programa de deleção irá afetar os dados arquivados. Portanto, o sistema irá assumir a variante de teste do programa de
eliminação.
Arquivar e eliminar esta altermativa gera o arquivo e limpa os dados da base. O sistema irá executar a variante de
produção neste caso.
33.10.3 Recuperação dos dados
No caso deste objetos, as informações aqui arquivadas não terão necessidade de recuperação. O programa de leitura do
CO_ALLO_ST (RKSRSA01) apenas relaciona os registros de dados arquivados.
33.11 Objetos: CO_ITEM - partidas individuais de CO
Este objeto permite arquivar e eliminar partidas individuais de CO mesmo sem a eliminação do objeto de custos. Este objeto de
arquivamento é útil no caso de problemas de espaço em disco, como as tabelas COEP ou COBK, devido a ordens de longo
prazo ou algo semelhante, pois, no arquivamento dos objetos de CO (ordens, centros de custos, etc.), também são arquivadas as
partidas individuais a ele relacionadas.
Os registros de totais não poderão ser sumarizados e o sistema não irá arquivar partidas individuais referentes a:
adiantamentos (categorias de valor 12 - adiantamentos como despesa; 58 - solicitações de adiantamento, 59 - adiantamentos
de compensação bancária, 61 - adiantamentos e 63 - adiantamentos planejados);
medidas de investimentos que foram armazenadas como partidas individuais e
partidas individuais do período corrente.
Na criação do Archive, o sistema bloqueia todos os períodos para os quais partidas individuais de CO devem ser arquivadas
para garantir que nenhum lançamento seja efetuado durante o processamento.
33.11.1 Dependências
Antes de usar o objeto de CO_ITEM é importante definir os tempos de retenção e os relacionamentos com outras áreas do R/3.
No caso de relatórios, é importante lembrar que será perdida a vinculação com o documento original de FI se a partida
individual for eliminada do R/3. Embora os dados arquivados ainda permanecem disponíveis, o acesso é limitado.
VENDAS: Se estiver usando faturamento relacionado a recursos, as partidas individuais das ordens de vendas não poderão
ser eliminadas até que não se deseja mais emitir faturas e outros despesas do período relevante. Os documentos de
faturamento relacionados e as requests também devem estar encerradas. Não será mais possível alterar documentos de
faturamento e requests que aumentam as despesas que ocorreram em períodos já arquivados, principalmente no caso de
cancelamentos.
PROJETOS: Para projetos de investimentos (elementos PEP com perfil de investimento), os juros são calculados com base
nas partidas individuais. Conseqüentemente, não será possível arquivar partidas individuais antes do arquivamento do
elemento PEP. Para os demais projetos e ordens em projetos, o sistema somente necessita das partidas individuais para a
primeira execução de cálculo de juros. Por outro lado, é necessário manter todas as partidas individuais para o ano fiscal
corrente.
DOCUMENTOS DE FI: o sistema não considera os documentos de FI no arquivamento e eliminação das partidas
individuais de CO. Portanto, é importante considerar os tempos de retenção dos documentos de FI na definição dos tempos
de retenção das partidas individuais de CO.
MEDIDAS DE INVESTIMENTOS: partidas individuais de medidas de investimentos não podem ser excluídas antes da
exclusão do objeto correspondente. O sistema garante esta integridade. No entanto, é possível marcar o indicador não
arquivar, para um determinado tipo de ordem por questões de performance.
CUSTOS INDIRETOS, PROVISÕES DE CENTROS DE CUSTOS: Não será possível calcular custos indiretos ou
provisões de objetos arquivados. Não podem ser recalculados custos indiretos que foram calculado em períodos arquivados.
CONTROLADORIA 281 de 325
33.11.2 Tabelas envolvidas
Tabela Descrição
COBK Cabeçalho de Documentos
EBII Fluxo de documentos CO/SD: parte faturada das parts.despesas
COEP Partidas individuais de CO - por período
COEPB Partidas individuais de CO - por período - desvios
COEPL Partidas individuais reais - tipo atividade
COEPR Partidas individuais reais - índices estatítiscos
COEJ Partidas individuais planejadas - ano
COEJL Partidas individuais planejadas - tipo atividade - ano
COEJR Partidas individuais planejadas - índices estatísticos - ano
Estas tabelas também são arquivadas por outros objetos abaixo relacionados de acordo com o tipo de objeto:
Objeto Dados arquivados
CO_ORDER Dados transacionais com ordens internas
CO_ALLO_ST Documentos de alocação estornados
CO_COSTCTR Dados gerais de centros de custos
CO_CCTR_ID Dados reais de centros de custos
CO_CCTR_EP Partidas individuais de centros de custos
PP_ORDER Ordens de produção
PS_PROJECT Projetos _ estruturas operativas
CO_KSTRG Objetos de custos (mestre e transacionais)
COPAn_xxxx Demonst. resultados: baseado em contas e em custos
PM_ORDER Ordens de manutenção
PR_ORDER Ordens de processo
33.11.3 Preparação para o arquivamento
No Customizing, são feitas as configurações para arquivamento das partidas individuais de CO.
Controlling Controlling Geral Arquivamento Preparar arquivamento de partidas individuais de CO:
Modificar tempo de retenção para as partidas individuais de CO
Modificar tamanho do bloco para eliminação de partidas individuais de CO
A execução do arquivamento é feita na Contabilidade de classe de custos. Os tipos de objetos também podem ser restringidos
explicitamente na execução do arquivamento.
Uma partida individual é arquivada somente quando o tempo de retenção foi ultrapassado (contado a partir do período de
lançamento). Períodos especiais não são considerados. Os documentos lançados em períodos especiais são associados ao último
período do ano fiscal
CONTROLADORIA 282 de 325
33.11.3.1 Critérios de seleção
Critério de Seleção De Até
Área de Contabilidade de Custos
Período ATÉ (opcional) xxxxxxxxx
Exercício ATÉ (Ano fiscal) xxxxxxxxx
Versão (opcional)
Categoria de Valor (real, palnejado, teórico, etc.)
Tipo de Objeto
Tipo de Subobjeto
Controle do Processo Execução de teste
Arquivar
Arquivar e Eliminar
Protocolo por Documento
Só podem ser especificados período e exercício fim, pois o sistema só permite a exclusão das partidas individuais de um
período se os períodos anteriores já tiverem sido arquivados.
Através das categorias de valores é possível arquivar em separado, dados reais (categorias 03,04,09 e 11) e planejados
(categorias 01,02, 08 e 10). Assim, é possível estabelecer tempos de permanência dos dados direfente para dados reais e
planejados, se for o caso.
A versão refere-se aos dados planejados. A definição dos tempos de retenção dos centros de custos é que iria definir os critérios
de seleção exercício e período.
As partidas individuais poderão ser arquivadas separadamente por tipo de objeto e é até recomendável para agilizar a
recuperação de dados (se necessário).
Objetos que geram partidas individuais em CO
ORC AO Objeto de reconciliação
PEM BP Processo empresarial
ORS AO Objeto de resultado
OCS HP Objeto de custo
CCS KS,KL Centro de custo
DRD PR Diagrama de rede
ORD OR, OP Ordem
PEP NV, NP Elemento PEP
IDV VB Item do documento de vendas
ULI IV Administração de imóveis - unidade de liquidação
ED. IV Administração de imóveis - edifícios
CAD IV Administração de imóveis - contrato de administração
TRR IV Administração de imóveis - terrenos
UAL IV Administração de imóveis - unidade de locação
CAL IV Administração de imóveis - item contrato de aluguel
UEC IV Administração de imóveis - unidade econômica
33.12 Custo de Produtos
33.12.1 Objeto: CO_COPC - Estimativa de custos de produto
Este objeto permite arquivar e eliminar as estimativas de custos de produto geradas para atualização de preço padrão, geradas
no cadastramento de documentos de vendas ou em cálculos preliminares de custos individuais. As estimativas de custos podem
CONTROLADORIA 283 de 325
ser arquivadas independentes de qualquer outro arquivamento e também não existe nenhuma configuração de customizing
necessária para este objeto.
Este objeto trata, além dos dados básicos para a estimativa de custo, a decomposição de custos conforme o esquema de
elementos definindo na variante de cálculo de custos, a itemização de custo de produto, a itemização de classe de custos e o log
caso um destes itens seja armazenado juntamente com a estimativa de custos.
No arquivamento todos os dados são transferidos para o archiving com exceção da itemização de classe de custos que será
simplesmente eliminada sem arquivamento.
Por questões de integridade, o sistema não irá permitir o arquivamento das estimativas de custos marcadas e liberadas para
atualização do preço standard que estão vinculadas ao mestre de materiais.
33.12.2 Objeto: CO_KSTRG - Objetos de custo
Este objeto permite arquivar e eliminar dados mestre e transacionais dos objetos de custos e dos nós da hierarquia de objetos de
custos.
Os objetos de custos são as unidades de atividade de negócio cujos custos são associados de acordo com a origem do custo. São
identificados através de um ID ou através de objetos de outros componentes, tais como ordens de produção ou itens de ordens
de vendas. Os objetos de custos podem ser usados em:
No ABC, itens de custos utilizam ID de objetos para lançamentos de custos indiretos que primeiro são lançados em centros
de custos ou processos empresariais e depois lançados nos objetos de custo.
Em bens e Serviços Intagíveis, itens de custos utilizam ID de objetos para demonstração dos custos.
No Controlling periódico de produtos, pode ser criada uma hierarquia de objeto de custos para entrar com custos reais que
não podem ser associados individualmente para um material ou uma ordem. Os custos associados aos nós podem ser
distribuídos diretamente para objetos individuais no último nível da hierarquia no encerramento do período (tais como
coletores de custos) ou podem ser apropriados diretamente para a conta de diferença de preço.
Podem ser criados ID de objetos no Sistemas de Informação de Controlling de Custo de produtos para grupos de produtos
de CO. Pode ser criado um ID para cada grupo e associá-los ao ID dos materiais. Os custos dos materiais associados
aparecem sumarizados em relatórios do Sistema de Informação por grupo de produto.
33.12.3 Objeto: CO_BASEOBJ - Componente
Este objeto permite arquivar os componentes incluindo os dados mestre, cabeçalho e itens do cálculo de custos e todos os textos
relacionados.
33.13 Objetos de arquivamento do Ledger de Materiais
33.13.1 Objeto CO_ML_DAT
33.13.1.1 Tabelas envolvidas
Tabela Descrição
CKMLCR Ledger de material: Regs.totais do período - valores
CKMLPP Ledger de material: Regs.totais do período - quantidades
CONTROLADORIA 284 de 325
33.13.1.2 Critérios de Seleção
Critério de Seleção De Ate
Exercício (Ano fiscal)
Período
Número do material
Área de avaliação
Tipo de avaliação
Gerar Arquivo
Eliminação em teste
A área de avaliação corresponde ao nível organizacional em que o material está sendo valorizado podendo ser a nível de centro
ou a nível de empresa (mesma valorização para todos os centros).
O tipo de avaliação aplica-se nos casos de split valuation. O tipo de avaliação determina quais os tipos de valorização são
permitidas para o material. Se, por exemplo, um material é valorizado de acordo com sua origem (tipo B), podem ser definidos
os países de origem possível como tipo de valorização.
33.13.1.3 Recuperação de dados
O SAP disponibiliza o programa SAPRCKMP para recuperação dos dados. Este objeto permite também a recarga dos dados
arquivados.
33.13.2 Objeto CO_ML_BEL
33.13.2.1 Tabelas envolvidas
Tabela Descrição
MLHD Documento do ledger de material: cabeçalho
MLIT Documento do ledger de material: materiais
MLPP Documento do ledger de material: períodos contábeis
MLPPF Documento do ledger de material: grupos de campos (períodos contáb.
MLCR Documento do ledger de material: moedas
MLCRF Documento do ledger de material: grupos de campos (moedas)
MLCRP Documento do ledger de material: modificações de preço (moedas)
33.13.2.2 Critérios de Seleção
Critério de Seleção De Ate
No. documento
Ano civil
Data do documento
Gerar Arquivo
Eliminação em teste
33.13.2.3 Recuperação de dados
O SAP disponibiliza o programa SAPRCKMX para recuperação dos dados. Este objeto permite também a recarga dos dados
arquivados.
CONTROLADORIA 285 de 325
33.13.3 Objeto: CO_ML_IDX - Docs.entrs.índice p/o material: ledger de material
Este objeto permite arquivar e eliminar os índices do ledger de materiais para o componente de CO Custeio real/Ledger de
materiais. Contém entradas que permite analisar as transações para o material e a apresentação dos documentos.
33.13.3.1 Tabelas Envolvidas
A única tabela arquivada por este objeto é a CKMI1 (índices para documentos contábeis por material). Mesmo que o Ledger de
Materiais não esteja ativado, esta tabela é atualizada sempre após a execução de um processo movimentação de mercadorias
relevante para FI. Ela contém a quantidade e o valor do estoque.
Caso os documentos de FI estejam agregados a nível de materiais, não serão gerados registros de movimentação de mercadorias
na tabela BSIM (Índice secundário documentos para o material) que permite analisar o fechamento das contas transitórias. Com
isto, não é possível consultar partidas individuais de materiais e calcular o valor do estoque de um material usando os
documentos de FI. Esta análise é particularmente importante no caso da análise de inconsistências entre MM e FI. Se a
agregação estiver ativada, o relatório de inconsistências em MM usa a tabela CKMI1.
Como pré-requisito para arquivamento desta tabela é essencial que seja verificado a existência de inconsistências (através do
programa RM07MMFI) e removê-las. A remoção de inconsistências após o arquivamento é consideravelmente difícil.
33.13.3.2 Critérios de seleção
Critério de Seleção
Período ?
Exercício (Ano fiscal) ?
Gerar Arquivo
Eliminação em teste
As informações do Ledger de Materiais podem ser eliminados período a período. O sistema irá arquivar todos os períodos
anteriores até o período especificado. A única tabela arquivada por este objeto é a tabela CKM1 - Índice do Ledger de Materiais
cujos dados estã orelacionados abaixo
33.13.3.3 Recuperação de dados
O SAP não tem nenhuma alternativa disponível para acessar os dados arquivados desta tabela. Sendo esta tabela uma tabela de
índice, não faz muito sentido acessar os dados nela contidos separadamente. No entanto, este objeto permite a recarga., ou seja,
os dados podem retornar para a base de dados on-line do R/3, caso seja necessário.
33.14 Obejtos de arquivamento de Classes de custo
33.14.1 Objeto: CO_CEL_RCL - Ledger de Reconciliação
Este objeto permite arquivar e eliminar as partidas individuais e os registros de totais do Ledger de Reconciliação (razão de
classe de custos). O arquivamento das partidas individuais não é permitido. O Ledger de Reconciliação e arquivado
principalmente por razões legais (período de retenção) e não por considerações de utilização de espaço de memória.
Tabelas Envolvidas
COFIP Partidas individuais planejadas do Ledger de Reconciliação
COFIS Partidas individuais reais do Ledger de Reconciliação
COFIT Registro de totais do razão de reconcialiação.
Estas tabelas também são arquivadas pelos objetos do Special_Ledger. Como esta funcionalidade (Ledger de Reconciliação)
não está implantada, este objeto não será usado.
CONTROLADORIA 286 de 325
33.15 Objetos de Arquivamento de Centros de Lucro
33.15.1 Objeto: PCA_OBJECT - Centro de Lucro
Este objeto permite arquivar e eliminar partidas individuais e registros de totais do Centro de Lucro (reais e planejadas).
33.16 Objetos de arquivamento de COPA
Na criação de uma área de resultados, o sistema automaticamente gera dois objetos de arquivamento (COPA1_XXXX para
Demonstração de Resultados baseado em custos e COPA2_XXXX para Demonstração de Resultados baseado em contas).
33.16.1 Objeto: COPA1_XXXX - Demonstração de Resultados baseado em custos
Para COPA baseado em custos podem ser arquivados os dados das tabelas CE1XXXX - partidas individuais reais; CE2XXXX -
partidas individuais planejadas; CE3XXXX - registros de totais e CEALE01 - distribuição. Opcionalmente, a tabela de registros
de totais poderá não ser arquivada (parâmetro do programa de arquivamento) já que seu volume de dados é bem inferior às
partidas individuais, permanecendo disponível para consultas on-line.
A tabela de objetos de resultados (CE4XXXX) não tem objeto de arquivamento. A tabela CEALE01 é usada para efetuar
distribuição de dados quando se possui mais de um ambiente do R/3 (mais de uma sistema) o que não é o caso da Cosipa. As
tabelas CE1RCOS e CE2RCOS apresentaram um crescimento significativo na avaliação técnica do banco de dados da Cosipa o
que recomenda a utilização deste objeto para arquivamento.
33.16.1.1 Tabelas envolvidas
COPA1_RCOS Demonstração de Resultados baseado em custos
Tabela Descrição
CE1RCOS Demons.Result (custos) - part.individuais reais
CE2RCOS Demons.Result (custos) - part.individuais planejadas
CE3RCOS Demons.Result (custos) - registros de totais (reais e planejados)
CEALE01 Distribuição CO-PA: referência de part.indiv.na distribuição
33.16.1.2 Critérios de seleção
Critério de Seleção De Até
Exercício (Ano fiscal)
Período
Planejado ou Real
Versão
Tipo de Operação
Gerar Arquivo
Eliminação em teste
Só partidas individuais
Os parâmetros período/exercício deverão ser usados para definir o tempo de permanência dos dados. Os dados reais podem ser
armazenados em separado dos dados planejados, se necessário. A versão é usada somente para os dados reaus. O tipo de
operação permite separar os tipos de lançamentos existentes em COPA (ver tabela abaixo).
Operação Descrição
CONTROLADORIA 287 de 325
Operação Descrição
A Entrada de ordem de clientes
B Classificação contábil direta
C Apropriação de ordem ou projeto
D Alocação de Centros de custos
F Documentos de faturamento
G Estipul.rel.cliente
H Índices estatísticos
Gerar Arquivo: se não for selecionado indica execução em teste.
Eliminação teste: se for selecionado o programa de deleção será executado somente em teste (parâmetro válido somente se o
programa de deleção é iniciado automaticamente).
Somente partidas individuais: se for selecionado, os registros de totais (a nível de segmento). Não faz sentido arquivar
registros de totais de períodos do exercício corrente visto que estes ainda estão sofrendo alterações.
33.16.1.3 Recuperação dos dados
Não existem relatórios disponíveis no SAP para ler informações de COPA. Recomenda-se, se necessário, o uso de printlists
com as informações que efetualmente possam ser consultadas no futuro.
34 Arquivamento de PP: Produção
34.1 Objeto: PP_ORDER - Ordem de Produção
Este objeto permite arquivar e eliminar ordens de produção incluindo as operações, os componentes de material, os recursos e
as ferramentas de produção, as caracteristicas de inspeção e seus valores, os pontos de Trigger, as confirmações, as
movimentações de mercadorias com erros e os textos.
Este objeto de arquivamento pode ser executado independentemente de outro objeto qualquer.
Uma vez que o tamanho de uma ordem de produção pode variar de forma significativa entre as empresas, é difícil estimar
quanto tempo demora um processo de arquivamento.
Quando o flag de eliminação for setado, todos as solicitações de capacidade remanescentes para a ordem são eliminadas, ou
seja, todas as reservas em aberto são marcadas para eliminação.
34.1.1 Tabelas envolvidas
Archive Descrição Tabela BD
AFFLD Diálogo p/ seqüências de ordens internas AFFL Seqüencia de ordens internas
AFPOD Diálogo para item de ordem AFPO Item da ordem
AFRUD Diálogo para confirmações de ordens AFRU Confirmações da ordem
AFVGD Diálogo para Operação da ordem AFVC Operações da Ordem
------------- Cluster para Documentos de Liquidação AABLG
AUAA Documento apropriação: segmento receptor AABLG- AUAA Documento apropriação: segmento receptor
AUAB Documento apropriação: regras repartição AABLG- AUAB Documento apropriação: regras repartição
AUAK Cabeçalho de documento para apropriação AUAK Cabeçalho de documento para apropriação
AUAO Seg.doc.: obj.CO a serem apropriados AABLG- AUAO Seg.doc: objetos CO a serem apropriados
AUAS Documento apropriação: segmento de totais AABLG- AUAS Documento apropriação: segmento de totais
AUAV Segmento de documento: operações AABLG- AUAV Segmento de documento: operações
CONTROLADORIA 288 de 325
Archive Descrição Tabela BD
AUSP Valores modalidades das características AUSP Valores modalidades das características
CABN Característica CABN Característica
CABNT Textos para características CABNT Textos para características
CAUFVD Estrutura diálogo p/cabec.ordens e itens CAUFV Visão cabeçalhos de ordens PCP/RK
CAWNT Textos para valores CAWNT Textos para valores
CDHDR Cabeçalho do doc. modificação CDHDR
CDPOS Item doc.modificação CDCLS-CDPOS Cluster structure para doc. alteração
FMSU FI-FM Registros de totais FMSU FI-FM Registros de totais
IOMAMO Estr.BD p/doc. movimentos mercadorias
JEST Status individual por objeto JEST Status individual por objeto
JSTO Informações sobre objeto de status JSTO Informações sobre objeto de status
SWOR Sistema de classificação: palavras-chave SWOR Sistema de classificação: palavras-chave
COBK Cabeçalho do documento de CO COBK Cabeçalho do documento de CO
COBRA Norma apropriação p/apropriação ordem COBRA Norma apropriação p/apropriação ordem
COBRB Regras repartição normas apropriação COBRB Regras repartição normas apropriação
COEP Partidas Individuais CO reais - período COEP Partidas Individuais CO reais - período
COEPL Part.ind. - tipos de atividade por período COEPL Part.ind. - tipos de atividade por período
COFP Linhas documento (adm.caixa projetos) COFP Linhas documento (adm.caixa projetos)
COKA Dados controle de classe de custo COKA Dados controle de classe de custo
COSB Reg.Totais desvios/determ. resultado COSB Reg.Totais desvios/determ. resultado
COSL Reg.Totais - tipos de atividade COSL Reg.Totais - tipos de atividade
COSP Reg.Totais - lançamentos externos COSP Reg.Totais - lançamentos externos
COSPD RegTotais externos. - dos quais apropr. COSPD RegTotais - cust.ext. - dos quais apropr.
COSS Reg.Totais - lançamentos internos COSS Reg.Totais - lançamentos internos
COSSD Re.Totais internos - dos quais apropr. COSSD Re.Totais internos - dos quais apropr.
AFAB Diagrama rede - relações de dependência
AFFH Atribuição de MAP a ordem de trabalho
AFFT Especificações de ordem e processo
AFFV Valores especificação de ordem e processo
AFFW Mov.mercadoria errôneos das confirmações
AFIH Cabeçalho de ordem manutenção
AFKO Dados cabeçalho da ordem de ordens PCP
AFVU Estrutura BD dos campos usuário operação
AFVV Estrutura BD oper. qtdes/datas/valores
AFWI Mov. registrados posteriormente p/confirmações
AUAI Montantes apropr.csts p/área depreciação
AUFK Dados mestre da ordem
BPBK Cabeçalho de documento
BPEG Part.ind. - valores totais
BPEJ Part.ind. - valores anuais
BPEP Partidas individuais - valores periódicos
BPGE Registro de totais para valor total
BPHI Dados relativos a várias hierarquias
BPIG Índice obj.orçamento (orçamento global)
BPIJ Índice obj.orçamento (orçamento anual)
BPJA Reg.totais para valor total anual
CONTROLADORIA 289 de 325
Archive Descrição Tabela BD
BPPE Reg.totais para valores periódicos
BPTR Dados do objeto
CKHS Cabec calc.custo unitário (controle + totais)
CKHT Textos p/CKHS
CKIP Val.periódicos item cálculo de custo unitário
CKIS It. cálc.custo unit./espec.item custeio-prod.
CKIT Textos p/CKIS
COCH Adm. batch - cabec.prescrição controle
COCHP Folha-PI: cabec.prescrição de controle
COCOA Adm. batch - tabela atribuição operação
COEJ Partidas individuais referentes ao ano
COEJL Part.ind..tipos ativ. referentes ao ano
COEJR Partidas ind.índices estatísticos - ref.ano
COEPB Part.ind.desvio/determ.result.por per.
COEPBR Liquidação avaliada partidas individuais
COEPD liquidação não avaliada part.ind.c/status
COEPR Part.ind.índices estatísticos - ref.período
COER Valor da ordem cliente: receita
COES Part.indiv.valor da ordem do cliente
COFIV Folha PI: assinatura para o desvio
COFMA Folha PI: atrib. msg à espec.processo
COFT Adm.batch - presc.contr.esp..processo
COFTP Folha-PI: especificações de processo
COFV Adm.battch - prescr.contr.carac.espec.
COFVP Folha-PI: caract.espec. processo
COKL dados controle - tipo de atividade
COKP dados controle planej.custos primários
COKR dados controle p/grandezas estatísticas
COKS dados controle custos sec. planejados
COMEP Folha-PI: características de mensagem
COMER Protocolo processo - caract. mensagem
COMHP Folha-PI: cabeçalho de mensagem
COMHR Protocolo processo - dados cabec msg
COMQ Mem.intermed. p/msg prod.mat. p/QM
COOI Adm. compromissos: itens individuais
COSBD Reg.tot.desvios/provis. - d.quais apropr.
COSLD Reg.totais tipos ativ. - dos quais apropr.
COSR REg totais de índices estatísticos
COTRP Folha PI: text parâm. processo (versões)
COVLP Folha PI: valores de variável atuais
EBAN Requisição de compra
EBII Fluxo doc CO/SD: parte fat. parts despesas
EBKN ClsContáb de requisição de compra
EVFG PS EV, grau de finalização
EVOF Parâmetro objeto PS análise de evolução
ILOA Loc. e class.contábil referente ao objeto PM
INOB Atribuição dum nº interno a um objeto
CONTROLADORIA 290 de 325
Archive Descrição Tabela BD
JCDO Docs.modif. p/objeto status (tabela JSTO)
JCDS Docs.modificação para status de sistema/usuário (tab. JEST)
KALC Fórmulas calc. quantidade de material_
KALT Cabeçalho de cálculo de qtd.de material
KSSK Tabela de atribuição: objeto para classe
MCAFKOV Versões dados cabeçalho de ordens PCP
MCAFPOV Versões item de ordem
MCAFVGV Versões operação ordem
MCKALKW Versões repres. detalh.do item de custos
MLST Marco
MLTX Denominação do marco
ONR00 Nº geral de objeto
ONROF Índice de nº de obj. mat.aux. prod. ordem
ONROK Índice de nº obj componente mat./reserva
ONROR Índice de nº de objeto ordem
ONROS Índice de nº de objeto sequência trab.ordem
ONROV Índice de nº de obj. oper. trab.ordem
PSTX Textos PS (cabeçalho)
RESB Reserva / necessidades dependentes
RKPF Cabeçalho do documento da reserva
RPSCO BD p/ info projeto: custos, receitas, finanças
RSADD Campos adicionais para reserva
RSDB Índice RESB p/elem. de suprimento direto
STXB SAPscript: text sem formato SAPscript
STXH STXD cabeçalho file texto SAPscript
STXL STDX linhas file de texto SAPscript
TC71 Assinatura eletrônica
TC71D Documento assinado para assinatura
TC74 Assinatura eletrônica para folha PI
TPI03 Objetos CO: data do último cálculo de juros
VSPSTX_CN Versão: textos PMS (cabeç.)
CONTROLADORIA 291 de 325
34.1.1.1 Critério de seleção
Critério de Seleção De Até
Número da ordem
Tipo de ordem
Centro
Material
Planejador (MRP controller)
Programador Produção (Production Scheduler)
Texto breve para o arquivamento (nota)
Opções
Número máximo de ordens
Tamanho do bloco de ordens
Criar file de arquivamento
Programa deleção executado em teste
Além de atender aos critérios acima, serão selecionadas as ordnes que for da categoria 10 (ordem de produção), estiver marcada
para eliminação e tiver o tempo de retenção 2 expirado.
Como é possível gerar um arquivamento sem executar o programa de eliminação, corre-se o risco de arquivar a mesma ordem
mais de uma vez. Para minimizar esta possibilidade de erro, o sistema lista todos os arquivos gerados pendentes de deleção
antes de permitir iniciar outro processo de arquivamento.
34.1.2 Tempos de Retenção
Para o arquivamento de ordens de produção são verficados 2 tempos de retenção. A atualização destes tempos é definida a nível
de tipo de ordem no Customizing (Produção Ordem de Produção Dados Mestre Ordem OPJH - Definir Tipo de
Ordem).
Tempo de retenção 1 (meses do calendário) - a reorganização de um objeto tais como, ordem, projeto, normalmente,
requer três passos: marcar para eliminação (pode ser desmarcado); marcar código de eliminação (não pode ser desmarcado)
e arquivamento (gravar o objeto em um arquivo sequencial e eliminar fisicamente da base de dados on-line). O tempo de
retenção 1 determina o intervalo de tempo em meses do calendário que deve trasncorrer entre a marcação para eliminação e
a marcação do código para eliminação.
Tempo de retenção 2 - o tempo de retenção 2 determina o intervalo de tempo que deve trascorrer entre a marcação do
código para eliminação e a eliminação física.
O marcação para eliminação pode ser efetuada individualmente para cada ordem ou coletivamente através da execução de um
job. Se o tempo de retenção 1 for zero, o código de deleção é automaticamente ativado (considerando que o código de deleção
foi selecionado na tela de parâmetros).
Para que uma ordem possa ser marcada para eliminação
as ordens ou requisições de compras cadastradas manualmente para a ordem de produção devem ser eliminadas
anterioremente
o saldo da ordem deve ser zero, ou seja, nenhum custo foi apropriado para a ordem ou a ordem já foi liquidada.
os itens em aberto da ordem devem ser eliminados
os lotes de inspeção (se a ordem tiver) deve ter o status (usage decision made) setado com “Completion of all inspections”,
ou seja, o processo de inspeção deve ser sido encerrado.
as movimentações de mercadorias com erro devem ser totalmente processadas.
A ordem pode ser marcada para a eliminação mesmo que esteja com o status de parcialmente confirmada ou parcialmente
entregue. Neste caso, o sistema apenas envia uma mensagem de alerta.
CONTROLADORIA 292 de 325
34.1.3 Recuperação de dados
Para a recuperação de uma ordem de produção está disponível uma consulta no SAP através do programa PPARCHR1. O
programa lista a ordem na tela e permite visualizar detalhes da ordem. Os dados apresentados irá variar conforme o perfil geral
do sistema de informação de ordem escolhido. O perfil define os objetos (oerações ,componentes, etc.). Contém todos os perfis
necessário para trabalhar com o sistemas de informação. O perfil é criado no Customizing mas pode ser alterado no Sistema de
Informação durante um processamento através da função “Objeto display”.
O perfil controle quais os objetos serão apresentados, até que nível estes objetos serão expandidos, como os objetos serão
exibidos na lista e na lista de detalhamento do objeto. Isto é definido para cada objeto através do perfil individual de cada
objeto.
Dentro da lista de ordens apresentadas podem ser consultadas informações sobre o status individual da ordem, dados de CO
(Análise de Custos), e informações gerais do cabeçalho da ordem.
Informações disponíveis
Chave de determinação de resultados, Grupo processamento, Nº endereço, data última modificação, usuário da última
modificação, Nº modificação, Prioridade, Status do usuário, Código da ordem, Tipo de ordem, Dados explosão lista,
Ordem, Categoria de ordem, Chave de desvio, Motivo do cálculo, Programação por pausa(*), Diferença confirmação
disponível, Função confirmaçõa disponível, Empresa, Chave coletor custos, Esquema distribuição, Nº sequencial,
Planejador MRP, Data de entrada, Criado por, Classe participação, Responsável pelo controle da produção, Chave de
prazos, Horizonte liberação, Data de liberação real, Liberação planejada, Data de liberação, Liberação programada,
Quantidade da ordem, Total do refugo, Data fim confirmação, Conclusão base programada, Data conclusão programada,
Data fim real, Data de conclusão base, Data conclusão (programada), Divisão, Data confirmada, Base do início
programada, Data início programada, Data início real, Base do início, Data início (programada), Quantidade fornecida,
Refugo confirmado, Qunatidade confirmada, Classe JIB/JIBE, JIB/JIBE subclasse A, Orig. Cost Object, Esquema de
cálculo de custos, Ordem do cliente, Item da ordem do cliente, Variante de cálculo de custos reais, Variante de cálculo de
custos planejados, Área de contabilidade de custos, Classe de custos de apropriação, Destinação dos custos, Texto breve,
Tipo verificação disponível, Ordem principal, Marcação p/ eliminação, Idioma texto descritrivo, Material, Texto breve
material, Ordem superior, ID planejamento 1, ID planejamento 2, Entr.def./exc.prev., Mensagens verificação disponível,
Código classificação contábil, Nenh.custo planejado, Nenhuma reserva/requ, Joint venture object, Nº de modificação ro,
Roteiro válido desde, Data de explosão, Grupo plan.trabalho, Routing group cnt., Utilização roteiro, Material roteiro,
Grupo roteiro, Categoria roteiro, Roteiro tamanho de l, Roteiro tamanho de l, Centro planej., Data fim básica, Data início
básica, Elemento PEP, Centro de lucro, Rede de ordens, Lote de controle, Tipo de custos, Código de redução, Ordem de
referência, Resultado verif.disp, Nível de revisão, Qtd.proces.posterior, Reserva, Ordem restauração, Nº de confirmação, Nº
modificação LisTécnica, Ordem produção repetitiva, Qtd.de base LisTéc., Área controlling, LisTéc.válida desde, Perfil de
produção, Float after prod., Data margem segurânç, LisTéc.tamanho de lo, LisTéc.tamanho de lo, Estoque especial,
Esquema de status, alternativa LisTéc., Utilização LisTéc., LisTéc.material, Nº lista técnica, Status list.téc., Ctg.lista
técnica, Status do sistema, Tipo de programação, Programado em, Custos estimados,Qtd.confirmada, Joint venture,
Margem antecipação, Marg.antecipação do, Centro, Chave de sobretaxas
(*) Programação por pausa: indicador usado para determinar se deve ser considerado o tempo exato de um parada. Se este
flag por selecionado, não será mais possível o tempo calculado ocorra durante um tempo de parada.
34.1.3.1 Perfil para sistema de apropriação de ordens
Customizing Produção Ordem de Produção Sistema de Informação Definir perfis para sistema de informação
ordens
Um perfim geral controla quais e como (layout) as informações serão apresentadas para cada ordem no sistema de informação.
O perfil geral contém diversos perfis individuais. Cada perfil individual contém parâmetros para montar a lista dos objetos e os
detalhes a serem exibidos para cada objeto.
Para cada perfil deve ser definidos quais os objetos serão lidos do banco de dados, quais os objetos serão apresentados e até que
nível os objetos devem ser expandidos na lista. Os objetos possíveis estão relacionados abaixo. Os perfis individuais são
definidos na transaão SVMC do Customizing.
Cabeçalho da ordem Defime
os campos a serem apresentados (usando o perfil de campo) na
CONTROLADORIA 293 de 325
listagem e no detalhamento,
a classificação (usando um perfil de classificação),
o agrupamento dos dados (usando um perfil de agrupamento)
filtros do usuário (usando variantes)
largura das colunas,
filtros de status (usando um perfil de seleção)
Itens
Documentos de Movimentação de mercadorias
Sequência das ordens
Operação/suboperação
Componentes
Ponto evento
Meios auxiliares de produção
Necessidade capacidade
Confirmações
Movimentos mercadorias automáticos
Movimentos de mercadorias automáticos com erro
Requisições compra
Pedidos
Podem ser selecionadas a exibição de todas as ordens, ou seja, as ordens de produção e as ordens planejadas, ou somente as de
produção ou somente as planejadas.
Sínteses de Objetos - listagem com informações de roteiros, planos de inspeção, lista de tarefas de manutenção, redes, etc.. No
Customizing, podem ser definids os objetos a serem apresentados em uma lista assim como o layout de sua exibição.
34.1.3.2 Definir variantes de síntese para síntese de objetos
Customizing Produção Ordem de Produção Dados mestre Ordem OPKN - Definir variantes de síntese para
síntese de objetos.
Este função permite definir as variantes para sínteses de objetos na exibição de ordens de produção. As listas são criadas por
meio de uma técinca denominadas “Variable lists”. Para cada síntese criada, é criada um variante de síntese onde são
especificados quais objetos deverão ser exibidos (operações , seqüências, etc.) e quais os campos por objeto deverão ser
exibidos (datas, quantidades, etc.). A seqüência na qual os objetos individuaus aparecerão na síntese, é predefinida pela
aplicação.
34.1.3.3 Perfis para lista de efetuação do picking
Através deste perfil pode ser definido como os componentes serão agrupados, como serão classificados, pode ser definod um
filtro específico para o usuário, um perfil de seleção e uma seleção de campos. O perfil standard é 0 “00002” mas pode ser
alterado se neces´saior.
Pode ser especificado um layout para cada versão impressa de um pick list para cada centro através de perfis de impressão
distintos. Este perfis são criados no Customizing para Planejamento de necessidades (definir layout para pick list). O perfil
padrão é o “FAKOMM” para o centro “0001”.
35 Arquivamento de SD - Vendas e Distribuição
Os documentos do módulo de SD podem ser arquivados independentemento de outros programas de arquivamento. Antes do
arquivamento, o sistema verifica onde os dados estão sendo usados e, encontrando dependências, o arquivamento não é
permitido.
CONTROLADORIA 294 de 325
Por exemplo, para arquivar um cliente (dados mestre), o sistema automaticamente verifica se o cliente pertence a uma
hierarquia de clientes ou se existem segmentos Bpara SD ou FI. Neste caso, o arquivamento não será possível.
Documentos de alteração e textos são arquivados juntamente com os documentos de vendas. Eles não influenciam no
arquivamento do documento de vendas. Dois fatores determinam se um documento de vendas poder ser arquivado ou não:
o status de processamento geral do documento - documentos marcado com concluído (significa que o campo GBSTK na
tabela VBUK tem o conteúdo C ou branco) podem ser arquivados
o tempo de retenção
35.1 Objeto SD_VBAK - Documentos de Vendas
35.1.1 Tabelas envolvidas
Tabela Descrição
AUSP Valores das características
CMFK Storage structure for the error log header
CMFP Storage structure for errors collected
FMSU Registros de totais de FI-FM
FPLA Billing plan
FPLT Billing plan: Dates
INOB Link between internal number and object
JCDO Change documents for status object (table JSTO)
JCDS Change documents for system/user statuses (table JEST)
JEST Individual status per object
JSTO Status object information
KANZ Assignment of sales order items - costing objects
KEKO Product Costing - Header
KEPH Product costing: Cost components for cost of goods manufacture
KNKO Assignment of a costing number to a config. object
KOCLU Cluster for conditions in Purchasing and Sales
KSSK Allocation table: Object to class
NAST Output status
SADR Address administration: Company data
VBAK Sales document: Header data
VBAP Sales document: Item data
VBEH Schedule line history
VBEP Sales document: Schedule line data
VBEX Sales and distribution document: Export control: Data at item level
VBFCL Sales document flow cluster
VBLB Sales document: Delivery schedule data
VBSN Change status relating to scheduling agreements
VBUK Sales and distribution document: Header status and administrative data
VBUP Sales and distribution document: Item status
VBUV Sales document: Incompletion log
VEDA Contract data
As seguintes classes de arquivamento também são arquivadas
CONTROLADORIA 295 de 325
Tabelas da classe de arquivamento K_TOTAL
Tabela Descrição
AABLG Cluster for settlement document
AUAI Settlement amounts per depreciation area
AUAK Document header for settlement
BPBK Document header - Controlling obj.
BPEG Line item total values - Controlling obj.
BPEJ Line item annual values - Controlling obj.
BPEP Line item period values - Controlling obj.
BPGE Totals record for totals value - Controlling obj.
BPHI Cross-hierarchy data - Controlling obj.
BPIG Budget object index (overall budget)
BPIJ Budget object index (annual budget)
BPJA Totals record for annual total value - Controlling obj.
BPPE Totals record for period values - Controlling obj.
BPTR Object data - Controlling obj.
COBK CO Object: Document header
COBRA Settlement rule for order settlement
COBRB Distribution rules settlement rule order settlement
COEJ CO object: Year-related line items
COEJL CO Object: Line items for activity types (by year)
COEJR CO Object: Statistical key figure line itrms (by year)
COEP CO Object: Period-related line items
COEPB CO Object: Line items variance/period-based results analysis
COEPBR CO Object: Valuated line item settlement
COEPD CO Object: Line item settlement, not valuated, with status
COEPL CO Object: Line items for activity types (by period)
COEPR CO Object: Statistical key figure line items (by period)
COER Sales order value revenue
COES CO Object: Line items for sales order value
COFP Document lines (cashflow)
COKA CO Object: Cost element control data
COKL CO Object: Activity type control data
COKP CO Object: Primary planning control data
COKR CO Object: Statistical key figure control data
COKS CO Object: Control data for secondary planning
COOI Open item management: Line items
COSB CO Object: Total variances/results analyses
COSBD CO Object: Total of variances/accruals, of which settled
COSL CO Object: Activity type totals
COSLD CO object: Activity type totals - of which settled
COSP CO Object: Cost totals - external postings
COSPD CO Object: Settled primary cost totals
COSR CO Object: Statistical ratio totals
COSS CO Object: Cost totals - internal postings
COSSD CO Object: Settled secondary cost totals
EBII CO/SD document flow: Billed portions of resource items
RPSCO Project info database: Costs, revenues, finances
CONTROLADORIA 296 de 325
Tabelas da classe de arquivamento K_TOTAL
Tabela Descrição
TPI03 CO Objects: Date of last interest run
Tabelas da classe de arquivamento K_TEXT
Tabela Descrição
STXB SAPscript: Texts in non-SAPscript format
STXH STXD SAPscript text-file header
STXL STXD SAPscript text-file lines
Tabelas da classe de arquivamento CHANGEDOCU
Tabela Descrição
CDHDR Cabeçalho de documentos de modificação
CDCLS Estrutura para documentos de modificação
Tabelas da classe de arquivamento K_UNITCOST
Tabela Descrição
CKHS Header - Unit costing (control + totals)
CKHT Texts for CKHS
CKIP Unit costing: Period costs line item
CKIS Unit costing: Items / product costing: Itemization
CKIT Texts for CKIS
Tabelas da classe de arquivamento CU_CONFIG
Tabela Descrição
AUSP Characteristic values
INOB Link between internal number and object
KSSK Allocation table: Object to class
35.1.2 Funções e relatórios disponíveis
Função Programa
Archiving S3VBAKWR
Deleting S3VBAKDL
Analyze S3VBAKAU
Check S3VBAKPT
Reloading Data S3VBAKRL
35.1.3 Objetos de autorização necessários
Objeto Descrição
V_VBAK_AAT Sales document type
V_VBAK_VKO Sales area (sales organization, distribution channel, division)
CONTROLADORIA 297 de 325
35.1.4 Dependências
As deliveries devem ser arquivadas antes dos documentos de vendas devido à vinculação gerada pelo fluxo de documentos. O
documentos precisam ser eliminados de trás para frente. Não existem dependência com os documentos de faturamento, ou seja,
os documentos de vendas podem ser arquivados mesmo que as notas fiscais permaneçam na base, o que, aliás, é comum de
acontecer.
Através da função KKAC é possível verificar os relacionamentos entre as ordens de vendas (make-to-order) com as ordens de
produção por ela geradas. No entanto, não existe uma dependência direta. O sistema permite a eliminação das ordens de vendas
mesmo que estejam vinculadas a ordens de produção. O vínculo permanece em PP.
35.1.5 Recuperação de Dados de Custos
Relatórios detalhados do Sistema de Informação de CO_PC: A categoria de relatórios PC01 DETAILREPORT contém
relatórios que fornecem dados especiais para objetos de cálculos de custos individuais (como ordens, cálculo de custos e itens
de documento de vendas). Por exemplo, o relatório de comparação de custos planejados/reais para uma ordem em particular, é
encontrado na categoria PC01 DETAILREPORT.
Os relatórios são agrupados por conteúdo na categoria de relatórios PC01 DETAILREPORT. Por exemplo, na árvore de
aplicação do componente Controlling de produtos periódico, esta categoria de relatórios é subdividida de acordo com o tipo de
objeto a ser analisado. Dentro de um determinado tipo de objeto, os relatórios são subdivididos em relatórios para análise de
desvios, material em processo, custos planejados e custos reais. Nesses cabeçalhos o usuário encontrará os relatórios
correspondentes ou outras subdivisões.
Na árvore de Controlling de produtos por ordem de cliente, estão disponíveis os seguintes relatórios detalhados.
CK86 - Lista técnica multinível avaliada ordem do cliente (programa RKKBKIS1) - mostra o custo do material vendida
expandido pela lista técnica apontando, nível a nível os custos de material e atividades.
SART - Elementos de custo
SART - Repres.classe custo
Especificação do item
KKB1 - Especificação item flexível
SART - Itens do cálculo
SART - Classes de custo / item de cálculo de custos
SART - Classes de custos / grupos de origem
SART - Operações / itens de cálculo de custos
36 Tabelas do Banco de Dados
36.1 Categoria de uma tabela ou estrutura
A categoria de uma tabela determina a reprodução, no BD, da descrição lógica de tabela definida no ABAP Dictionary. As
tabelas podem ser: transparente, estrutura ou estrutura append. Para fins internos como, por exemplo, gravar dados de controle
ou textos contínuos, existem ainda: tabela pool, cluster e estrutura gerada de visão.
36.1.1 Tabela Transparente
Existe uma tabela física no BD para uma tabela transparente tendo o mesmo nome físico e lógico (ABAP Dictionary).
Armazena dados empresariais de de aplicação.
CONTROLADORIA 298 de 325
36.1.2 Estrutura
É composta por componentes (campos) tipificados: categoria elementar, categoria estruturada, categoria de tabela ou tipo de
referência. As estruturas são utilizadas, em particular, para definir os dados na interface de pools de módulos e telas, assim
como para atribuir o tipo aos parâmetros de módulos de função. A definição central de estruturas utilizadas várias vezes, torna
possível a sua modificação central, que é depois efetuada pelo ABAP Dictionary ativo em todas as posições em questão. Os
programas ABAP ou as máscaras de tela que utilizam uma estrutura, são ajustadas automaticamente no caso da estrutura ser
modificada.
36.1.3 Categoria de tabela
Categoria que descreve a estrutura e as caracteristicas funcionais de uma tabela interna no ABAP. Pode ser utilizada de forma
análoga no ABAP na definição de objetos de dados e categorias para categorias propostas ou definidas diretamente no ABAP.
No ABAP Dictionary é possível utilizar categorias de tabela na definição de estruturas (categorias estruturadas) e outras
categorias de tabela:
Um componente de uma estrutura pode possuir como categoria uma categoria de tabela. Desta forma é definida uma
categoria estruturada com um componente que é uma tabela.
Uma categoria de tabela pode ser utilizada como tipo de linha de outra categoria de tabela. Isto define uma tabela de
tabelas.
Uma categoria de tabela descreve as seguintes características de uma tabela interna:
As estrutura e as características de categoria de dados da linha de tabela são definidas através do tipo de linha. O tipo de
linha determina a estrutura das linhas em uma tabela interna desta categoria e pode ser transferido por uma categoria já
existente ou ser entrado diretamente. Existem as seguintes possibilidades para o tipo de linha:
Definição da categoria de linha através da entrada direta da categoria
As categorias de dados, o número de posições e, se necessário, as casas decimais são indicadas diretamente. Desta
forma é definida uma tabela com linhas não estruturadas.
Indicação de um elemento de dados
A tabela definida tem linhas não estruturadas que possuem as características (categoria de dados, número de posições,
casas decimais, etc.) do elemento de dados indicado (categoria elementar).
Indicação de uma estrutura (tabela, visão)
As linhas da tabela definida desta forma são estruturadas segundo a definição da estrutura indicada (categoria
estruturada). Os componentes da linha de tabela possuem as características (categoria de dados, número de posições,
etc.) dos componentes na estrutura.
Uma tabela de banco de dados ou uma visão possui sempre uma estrutrua e, desta forma, é implicitamente uma
categoria estruturada. Assim, é possível utilizar as tabelas e as visões como tipo de linha de uma categoria de tabela.
Indicação de uma categoria de tabela
As linhas da tabela definida desta forma são tabelas estruturadas segundo a categoria de tabela indicada.
Indicação de um tipo de referência
Desta forma é definida uma tabela cujas linhas possuem o tipo de referência indicado (referência a uma classe ou
interface ou referência genérica a DATA).
A definição de chave descreve como está estruturada a chave da tabela.
Através do tipo de chaveErro! Indicador não definido. se determina, se a chave é unívoca, ou seja, se todos os registros da
tabela se distinguem na chave.
O tipo de acesso indica de que forma é acessada a tabela e como são administrados internamente os seus registros.
As categorias de uma tabela range constituem uma forma especial destas categorias gerais de tabela.
36.1.4 Estrutura Append
Uma Estrutura Append define uma seção de campos, que pertencem de forma fixa a outra tabela ou estrutura, mas que são
tratados como um objeto próprio na administração de correções. As estruturas append têm por função suportar as modificações.
CONTROLADORIA 299 de 325
É possível utilizar as estruturas append para ampliações que não estão previstas no standard (desenvolvimentos especiais,
versões localizadas, anexação de campos definidos pelo usuário a tabelas standard SAP).
Uma estrutura append está atribuída a uma única tabela. No entanto, podem existir várias estruturas append para uma tabela. Se
uma estrutura append for criada ou modificada, na sua ativação também é reativada a tabela (append) que lhe está atribuída, e
as modificações passam também aí a ser efetivas.
Uma estrutura append permite as seguintes ampliações de uma tabela ou estrutura:
Anexar campos novos
Anexar chaves externas para campos do append
Anexar conexões de ajuda para pesquisa a campos do append
A anexação de uma estrutura append ou a inserção de campos em uma estrutura append existente, não leva à conversão da
tabela. Os campos da estrutura append são anexados à tabela de banco de dados.
As estruturas append são criadas pelo cliente no conjunto de nomes do cliente, e estão assim protegidas contra sobregravação
durante a mudança de release. Na mudança de release, são importadas as novas versões das tabelas standard, e os campos
contidos nas estruturas append são anexados às novas tabelas standard.
Nota: Só é possível criar estruturas append para tabelas e estruturas transparentes. Para as tabelas transparentes que contêm um
campo comprido, não é possível anexar campos através de uma estrutura append. Para além disso, não podem ser criadas
estruturas append para tabelas e estruturas da base central do sistema R/3.
36.1.5 Tabela Pool
É possível utilizar as tabelas pool para arquivar dados de controle (por exemplo, seqüências de telas, parâmetros de programa
ou dados temporários). É possível agrupar várias tabelas pool em um pool de tabela. Ao pool de tabela corresponde uma tabela
física no banco de dados, na qual estão arquivados todos os registros das tabelas pool atribuídas.
36.1.6 Tabela Cluster
Em tabelas cluster é possível arquivar textos continuos como, por exemplo, documentação. É possível agrupar várias tabelas
cluster em um cluster de tabela. Nesta categoria de tabela, são agrupadas várias linhas lógicas de diferentes tabelas em um
registro físico. Desse modo, é possível uma gravação por objeto ou um acesso por objeto. Como condição prévia para o
agrupamento de tabelas em clusters, é necessário que exista uma correspondência pelo menos entre partes da sua chave. Várias
tabelas cluster são gravadas em uma tabela correspondente no banco de dados.
36.1.7 Estrutura gerada de visão
Uma estrutura é gerada para uma visão aquando da ativação. Esta estrutura serve de interface para o ambiente de tempo de
execução. Em regra, não é exibida no ABAP Dictionary.
36.2 Categorias definidas pelo usuário no ABAP Dictionary
No ABAP Dictionary, é possível definir categorias opcionais definidas pelo usuário. Estas podem ser utilizadas no ABAP ,
analogamente às categorias ABAP propostas (por exemplo, C ou I), ou categorias definidas localmente em programas ABAP,
na definição de Objetos de dados e categorias.
No ABAP Dictionary, é possível definir os seguintes tipos de categorias:
Categorias elementares As Categorias elementares não têm estrutura. Descrevem as características de categoria de dados (entre outras,
categoria de dados ABAP Dictionary, número das posições) e informações relevantes para a tela (entre outras, título)
de objetos de dados não estruturados (variáveis/campos).
Categorias estruturadas As Categorias estruturadas descrevem a estruturação e as características funcionais de objetos de dados estruturados
opcionais, ou seja, de estruturas de dados com os componentes de uma categoria opcional.
Um componente pode ser um campo com uma categoria elementar, ou novamente uma estrutura. Uma tabela também
pode entrar em uma estrutura como componente.
CONTROLADORIA 300 de 325
Uma tabela de banco de dados tem sempre um estrutura e é, desse modo, implicitamente uma categoria estruturada.
Porém, os campos de uma tabela de banco de dados só podem ter uma categoria elementar.
Categorias de tabela As Categorias de tabela descrevem a estruturação e as características funcionais de tabelas internas no ABAP. As
respetivas linhas podem ter um tipo de linha opcional. As categorias de tabela com tipo de linha elementar podem ser
definidas tal como as categorias de tabela multidimensionais (categorias de tabela com uma categoria de tabela como
tipo de linha) ou categorias de tabela através de estruturas com componentes em forma de tabela.
É possível combinar opcionalmente as possibilidades de formação de categoria através de categorias estruturas e categorias de
tabela. Desse modo, é possível definir de forma global no ABAP Dictionary categorias complexas opcionais, e as utilizar em
programas ABAP. A interface para a utilização em programas ABAP, constitui o Objeto de tempo de execução da categoria
ABAP Dictionary (nametab). O objeto de tempo de execução, permite um acesso de máxima performance às informações
relevantes para categoria de forma comprimida.
A definição central de categorias utilizadas várias vezes no ABAP Dictionary, também permite a sua modificação central. Por
meio do ABAP Dictionary ativo , estas modificações são efetuadas em todos os pontos em questão. Os programas ABAP são
ajustados, por exemplo, na regeração, às definições de categoria modificadas. Se uma categoria for modificada, todos os objetos
(por exemplo, categorias ou tabelas) que a utilizam na ativação, são ajustados automaticamente à modificação.
Todas as categorias ABAP Dictionary estão em um Conjunto de nomes comum . Por isso, um elemento de dados, por exemplo,
não pode ter o mesmo nome que uma estrutura. Porém, pode existir a igualdade de nomes entre uma categoria definida em um
programa ABAP, e uma categoria ABAP Dictionary.
Para utilizar as categorias em programas ABAP, existe a seguinte Regra de ocultação:
Em caso de igualdade de nomes, as categorias locais ocultam as categorias dos grupos de categorias, e as categorias definidas
de forma global no ABAP Dictionary.
36.3 Tipos de dados e tipos de objetos
Em ABAP, existe uma distinção conceitual entre tipos de dados e objetos de dados:
Os tipos de dados são simplesmente descrições do tipo do objeto de dados, não necessitando de espaço adicional de memória.
Define as propriedades técnicas dos objetos de dados deste tipo podendo ser parte integrante do ABAP ou definido pelo
usuário.
Já os objetos de dados são exemplos concretos de tipos de dados. Cada objeto de dados tem um tipo particular e requer espço
memória. São definidos estaticamente com um comando de definição de dados ou dinamicamente com um comando
operacional. O comando de definição de dados prototípico é DATA. Existem vários outros como CONSTANTS, STATICS,
TABLES, PARAMETERS, SELECT-OPTIONS, RANGES e CONTROLS.
No ABAP, as informações do tipo pertencentes a um objeto de dados é separada do objeto de dados. Então, o ambiente de
testes de sintáxe, geração e execução sempre tem acesso a todas as informações de tipo para cada obejto de dados. At runtime,
the inseparable connection between the data type and the data object means that all type-specific operations can access all the
type information even with untyped formal parameters and field symbols. Data types and data objects have their own name
ranges. The same ID can be used both as the name of a data type and the name of a data object. The same shadowing rules
govern data types and data objects: Locally defined types and objects shadow global types and objects of the same name.
36.4 Classe de entrega
A classe de entrega controla o transporte de dados da tabela, no caso de instalação, mudança de release, cópia de mandante, e
no caso de transporte entre sistemas de cliente. A classe de entrega também é considerada na Atualização ampliada de tabela.
Existem as seguintes classes de entrega:
A: Tabela de aplicação (dados mestre e de movimento)
C: Tabela de cliente, os dados são atualizados exclusivamente pelo cliente.
L: Tabela para arquivar dados temporários.
G: Tabela de cliente, a SAP pode inserir registros novos, mas não pode sobregravar ou eliminar aqueles que já
existem.
CONTROLADORIA 301 de 325
E: Tabela de sistema com conjuntos de nomes próprios para entradas de cliente. É necessário que o conjunto de nomes
de cliente seja definido na tabela TRESC.
S: Tabela de sistema, as modificações de dados têm o status de modificações de programa.
W: Tabela de sistema (por exemplo, tabela do ambiente de desenvolvimento), cujos dados são transportados por
objetos de transporte próprios (por exemplo, R3TR PROG, R3TR TABL, etc).
36.4.1 Comportamento na cópia de mandante
Só são copiados os dados de tabelas dependentes de mandante.
Classes C, G, E, S: Os registros da tabela são copiados para o mandante de destino.
Classes W, L: Os registros da tabela não são copiados para o mandante de destino.
Classe A: Os registros só são copiados para o mandante de destino, se tal for pretendido de forma explícita (opção de
parâmetro). Em regra, um transporte destes dados não é apropriado mas, no entanto, é suportado de modo a permitir a
transferência de todo um ambiente de mandante.
36.4.2 Comportamento no caso de instalação, mudança de release e importação de idioma
Existe aqui uma distinção quanto ao comportamento de tabelas dependentes de mandante e ao de tabelas independentes de
mandante.
36.4.3 Tabelas dependentes de mandante
Classes A e C: Os dados são só importados para o mandante 000. Os registros existentes são sobregravados.
Classes E, S e W: Os dados são importados para todos os mandantes. Os registros existentes são sobregravados.
Classe G: No mandante 000 são sobregravados os registros existentes. Em todos os outros mandantes são inseridos
novos registros, mas os registros já existentes não são sobregravados.
Classe L: Não são importados dados.
36.4.4 Tabelas independentes de mandante
Classes A, L e C: Não é efetuada qualquer importação de dados.
Classes E, S, e W: São importados dados. Os registros existentes com a mesma chave são sobregravados.
Classe G: São inseridos registros que não existem, sem que sejam sobregravados registros existentes.
36.4.5 Comportamento no caso de transporte entre sistemas de cliente
Os registros de tabelas da classe de entrega L não são importados para o sistema de destino. Os registros das classes de entrega
A, C, E, G, S e W são importados para o sistema de destino (no caso de tabelas dependentes de mandante, isto é efetuado para o
mandante de destino indicado no transporte).
36.4.6 Utilização da classe de entrega na atualização ampliada de tabela
A classe de entrega também é analisada na Atualização ampliada de tabela (SM30). A interface de atualização gerada para uma
tabela, executa as seguintes verificações:
Para as tabelas das classes de entrega W e L, não é possível qualquer transporte dos dados entrados, através da
conexão para transporte da interface de atualização gerada.
Aquando da entrada dos dados, é efetuada a verificação de se estes violam o conjunto de nomes definido na tabela
TRESC para a tabela. Se os dados violarem o conjunto de nomes, a entrada é rejeitada.
CONTROLADORIA 302 de 325
37 Tabelas do módulo de CO
Nome Descrição
T003O Tipo de Ordens
ARCU_COIT1 Tempo de retenção para partidas individuais de CO
ARCU_COIT2 Tamanhos de blocos ao eliminar partidas individuais de CO (arquivamento)
TKSB0 Controle de transação CO
TKVS Versões CO
CKPHS Controle de tipo de objeto de custo
AUFK Dados mestre da ordem
AUFLAY0 Tabela de entidades: layout das ordens
AUFLAY1 Layouts das ordens
AUFLAY2 Nomes de tabelas da atualização de dados mestre de o
TKO03 Status da ordem
BPTR Dados de Objeto
COKA Dados de Controle de Classe de custos - guarda informações de qtde ativ, unidade de
medida e mix características para cada relação classe de custos/ centro de custos/tipo de
atividade/ exercício.
37.1 Tabelas de Compactação de Ordens
Tabelas de Compactação de Ordens 4.0B
Nome Descrição
TKKR0 Compactação de hierarquia (cabeçalho)
TKKR1 Compactação de hierarquia (campos)
TKKR2 Compactação de hierarquia: tratamento de files de reg.totais
TKKR3 Compactação de hierarquia (textos de cabeçalho)
TKKRA Tipos de hierarquia
TKKRB Textos de tipos de hierarquia
37.2 Tabelas de Compactação de COPA
Tabelas de Compactação de COPA 4.0B
Nome Descrição
TKETR Níveis de compactação: catálogos
TKETRL Níveis de compactação: entrada de catálogo, cabeçalho
TKETRLF Níveis de compactação: entrada de catálogo, características
TKETRLG Nív.compact.: entrada de catálogo, cabeçalho (objs.gerados)
TKETRLGX Nív.compact.: entrada de catálogo, cabeçalho (objs.gerados)
TKETRLT Níveis de compactação: entrada de catálogo, texto.
TKETRLX Níveis de compactação: entr.de catálogo, descrições índice
TKETRREF Nív.compactação: utilização de campos da estrut.referência
TKETRTR Níveis compactação: nº transformação <-> valor característ.
37.3 Controlling de Custos Indiretos
KBAS Controlling de Custos Indiretos
Tabela Descrição
TKA01 Área de Contabilidade de Custos
CONTROLADORIA 303 de 325
KBAS Controlling de Custos Indiretos
Tabela Descrição
TKA02 Área de Contabilidade de Custos Determinação
KAPS Bloqueios de Períodos de CO
CSKS Centro de Custos dados mestre
CSKT Centro de Custos textos
CSSK Centro de Custos / Classe de Custos
CSSL Centro de Custos / Tipo de Atividade
COKEY Chave CO subnúmeros
CSKU Classe de Custos textos
CSKB Classe de Custos (dados dependentes da Área de Contabilidade de Custos)
CSKA Classe de Custos (dados dependentes do Plano de Contas)
TKA03 Índices Estatísticos
ARCU_COIT2 Tamanho de blocos ao eliminar partidas individuais de CO (arquivamento)
ARCU_COIT1 Tempo de retenção para partida individual de CO
CSLA Tipo de Atividade dados mestre
CSLT Tipo de Atividade textos
TKVS Versões de CO
TKA09 Versões de CO Opções básicas
TKA09V Versões de CO operações próprias de uma versão delta
TKA07 Versões de CO Parâmetros dependentes do exercício
37.3.1 Tabela BPTR - dados de objeto
Objeto Descrição
E Objeto individual
Objeto de nó
A Objeto de arquivo
B Transporte - programa de investimentos
C Previsão - programa de investimentos
D Objeto dummy
N Valores atuais - programa de investimentos
1 Valores da ordem: aditivos, previstos
3 Valores da ordem: aditivos, não previstos
4 Valores da ordem: eliminados, aditivos
5 Valores da ordem: eliminados, aditivos, outra unid.organiz.
6 Valores da ordem: não aditivos, previstos
7 Valores da ordem: eliminados, não aditivos, outra unid.org.
8 Valores da ordem: não aditivos, não previstos
9 Valores da ordem: eliminados, não aditivos
P Item de projeto
K Centro de custo
CONTROLADORIA 304 de 325
37.3.2 Tabela ARCU_COIT1 Tempo de Retenção para partidas individuais de CO
Tabela ARCU_COIT1 Tempo de Retenção para partidas individuais de CO
Tipo de Obejto Descrição
VV
CAD Administração de imóveis - contrato de administração
ED. Administração de imóveis - edifícios
CAL Administração de imóveis - item contrato de aluguel
TRR Administração de imóveis - terrenos
ULI Administração de imóveis - unidade de liquidação
UAL Administração de imóveis - unidade de locação
UEC Administração de imóveis - unidade econômica
AMO Administração de modificações
AFÍ Amostra física
AAF Área administração financeira
B6 Aval/fianças (reporting)
CDV Cabeçalho do documento de vendas
CCP Cálculo de custos do produto
CVM Carteira valores mobil.
CAS Caso
CCS Centro de custo
TAT Centro de custo/tipo de atividade
CLU Centro de lucro
CFI Centro financeiro
COP Coletor custos produção
COM Componente de material / reserva
CFM Confirmação da ordem
CRA Conta do Razão
DPR Conta do Razão (diferença de preço)
DPI Definição de programa de investimento
DRD Diagrama de rede
PEP Elemento PEP
PES Elemento PEP standard
EQU Equipamento
IMO Imobilizado
IAS Item de manutenção
IOR Item de ordem
IDV Item do documento de vendas
PGI Item programa de investimento
B5 Letra de câmbio (reporting)
ROB Ligação de objetos
LIN Local de instalação
PTR Local de instalação de referência
LCT Lote de controle
LTP Lote parcial
MAT Material
MAP Meios auxiliares de produção ordem
MOC Modelo de certificado
CONTROLADORIA 305 de 325
Tabela ARCU_COIT1 Tempo de Retenção para partidas individuais de CO
Tipo de Obejto Descrição
OTM Nº temporário do objeto
NCC Necessidade de capacidade
NÓH Nós de hierarquia
HPE Nós processo empresarial
IQU Nota QM
IQM Notas QM - medidas
IQI Notas QM - medidas imediatas
OBC Objeto coletivo (reporting)
OCM Objeto de compactação
OCS Objeto de custo
ORC Objeto de reconciliação
ORS Objeto de resultado
OPE Operação
OPR Operação de diagrama de rede
OOP Operação de ordem planejada
ORD Ordem
ORP Ordem de produção repetitiva
PLM Plano de manutenção
PSE Prestações de serviços
FM Previsão de tesouraria
PEM Processo empresarial
PRJ Projeto
PRS Projeto standard
QMI Registro info QM
RD Relação de dependência
SCM Sede comercial
STO Sequência trab.ordem
SIN Solicitação de investimento
COF Tesouraria - comércio financeiro
DER Tesouraria - derivados
DIV Tesouraria - divisas
EMP Tesouraria - empréstimo
OCC Tesouraria - operações de conta-corrente
TÍT Tesouraria - título negociável
CSJ Valores sem juros
VSI Variante solicitação de investimento
PRV Versões definição de projeto
VDR Versões diagrama de rede
VPE Versões elementos PEP
VIO Versões item de ordem
VNC Versões necessidade de capacidade
VOR Versões operação
VSO Versões ordem
VRD Versões relação de dependência
VR Versões reserva
VST Versões sequência de trabalhos ordem
CONTROLADORIA 306 de 325
37.4 Contabilidade de Centro de Custo
37.4.1 Contabilidade de custos Alocações RK-S
KALC Contabilidade de custos Alocações RK-S
Tabela Descrição
T811C Ciclos de alocação
T811D Números de documentos de alocação
T811DS Alocação: nºs documento de segmento Reverse/Rebook
T811F Tabela de elementos de alocação
T811G Grupos de campos para ciclo de alocação
T811H Alocação: descrição de campo de dados
T811I Alocação informações para campo-chave
T811IA Customizing de alocação
T811J Alocação informações para grupos de campos
T811K Campos-chave para alocação
T811L Texto descritivo - rateio/distribuição
T811M Alocações: textos para grupos de campos
T811P Ciclo grupo de execuções
T811PT Ciclo grupo de execuções textos
T811R Alocação tabela para classificação contábil do recebedor
T811S Segmentos de alocação
T811T Informação de tabelas para alocação
T811X Valores fixos de seleção para alocação
KSDI Integração CO/SD
Tabela Descrição
EBES Código de faturamento de partidas de despesa
EBII Fluxo de documentos CO/SD: parte faturada das parts.despesas
TEBCO Interface CO/SD: determinação do número do artigo do CO
TVFA Código de faturamento para part.despesas
TVFAT Código de faturamento para part.despesas: textos
KV Análise de desvios RK-S/RK-K
Tabela Descrição
TKV01 Chave de desvio centros de custos/cálculo de custos
TKV02 Denominação chave de desvio
TKV14 Denominação da variante de avaliação para refugo e WIP
TKV06 Denominação de variantes de desvio
TKV08 Denominação versões de custos teóricos
TKV04 Denominação versões de desvio
COEPB Objeto CO: partidas individ.desvio / determ.result.por período
COSB Objeto-CO: totais de desvios / determinações de resultado
TKV10 Textos de versões teóricas
TKV05 Variantes de desvio
TKV13 Variantes de desvio
TKV07 Versões de custos teóricos
CONTROLADORIA 307 de 325
KV Análise de desvios RK-S/RK-K
Tabela Descrição
TKV09 Versões de custos teóricos
TKV03 Versões de desvio
37.5 Tabela de Desvios - COSB
TABELA COSB
Campo Descrição
LEDNR Ledger
OBJNR Nº objeto
GJAHR Exercício contábil
WRTTP Categoria de valor (ver tabela abaixo)
VERSN Versão
ABKAT Categoria
KSTAR Classe de custo
HRKFT CO chave subnº
VRGNG Operação
PAROB Objeto do parceiro
BEKNZ Código de débito / crédito
AWKUS Excesso / não alcançado
TWAER Moeda da transação
PERBL Bloco de períodos
WTG001 a 16 Valor/moed.transação
WOG001 a 16 Valor/moeda do objeto
WKG001 a 16 Valor/moeda da ACC
WKF001 a 16 Valor Fixo /moeda ACC
FTG001 a 16 Valor externo / Moeda transação
FOG001 a 16 Valor externo / moeda objeto
FKG001 a 16 Valor externo /moeda ACC
FKF001 a 16 Valor externo fixo / moeda ACC
ZLNID ID da linha
37.5.1 Categorias de valores da tabela COSB
Tabela COSB
Categoria de
Valor
Descrição
61 Adiantamentos
63 Adiantamentos Alocações
12 Adiantamentos como despesa
59 Adiantamentos compensação bancária
6A Adiantamentos planejados
94 Administração orçamento: orçamento estatístico
93 Administração orçamento: plano financeiro
99 Administração orçamento: resultado
80 Bloqueio de recursos
55 Compensação bancária (obrigação pagto.)
CONTROLADORIA 308 de 325
Tabela COSB
Categoria de
Valor
Descrição
21 Compromisso da requisição de compra
23 Compromisso da reserva
83 Compromisso de receita
26 Compromisso do acordo de preço fixo
22 Compromisso do pedido
24 Compromisso manual
31 Desvios
34 Determ.resultado: custos de vendas do faturam.por recursos
32 Determ.resultado: determin.result., determin.WIP
33 Determ.resultado: em crédito e em débito
49 Determ.resultudo planej.: determ.resultado, determ.WIP
71 Disponib. Recursos financeiros: obrigações
60 Documento pré-editado
65 Engajamento fundos
82 Engajamento preliminar fundos
19 Entrada de ordens/carteira de ordens
54 Faturas (obrigação de pagamento)
95 Lançamentos CO reais
46 Liberação recursos financeiros
88 Liberação recursos financeiros marcada
92 Liberação recursos financeiros marcada p/obrigações
87 Liberação recursos financeiros reserv.
91 Liberação recursos financeiros reservada p/obrigações
72 Liberação recursos financeiros: obrigações
56 Obrigação de pagamento definível pelo usuário(oper.finan.70)
53 Obrigação pagamento.definível pelo usuário (oper.financeira 50)
41 Orçamento
4B Orçamento saldos
77 Orçamento de obrigações: pedidos
76 Orçamento de obrigações: pedidos montante bloqueado CCN
75 Orçamento de obrigações: reserva de recursos montan.bloq.CCN
69 Orçamento de obrigações: reservas de recursos
4A Orçamento de pagamentos estatístico
37 Orçamento de programa p/investim.efetivos
42 Orçamento disposto
45 Orçamento liberado
36 Orçamento p/ investimentos efetivos
47 Orçamento programa
43 Orçamento recursos financeiros
86 Orçamento recursos financeiros marcado
90 Orçamento recursos financeiros marcado p/obrigações
85 Orçamento recursos financeiros reservado
89 Orçamento recursos financeiros reservado p/obrigações
70 Orçamento recursos financeiros: obrigações
4C Orçamento recursos financeiros: orçamento gastos p/item receita
CONTROLADORIA 309 de 325
Tabela COSB
Categoria de
Valor
Descrição
67 Outros documentos estatísticos
68 Outros documentos não estatísticos
57 Pagamentos
62 Pagamentos planejados
73 Pedido: montante bloqueio CCN
51 Pedidos (obrigação de pagamento)
01 Planej.
10 Planej. estatístico
52 Planej. requisições para fase utilização
08 Planej.: correção para volum.negócios inter.entre centros custo
02 Planej.: decomposição em tipos de atividade
38 Plano de programa para investimentos efetivos
40 Plano de solicitação para investimentos efetivos
9B Plano financeiro estatístico
35 Plano para investim.efetivos
48 Plano progr.
25 Plano residual ordens/diagrs.rede previstos (comprom.ordem)
39 Plano solicit.
04 Real
11 Real estatístico
09 Real: correção p/volume negócios inter.entre centros custo
03 Real: decomposição em tipos de atividade
44 Recursos financeiros disponíveis
30 Refugo
50 Requisições de compra (obrigação de pagtos.)
84 Reserva de pagamento
81 Reserva de recursos
98 Reserva de recursos (CO)
74 Reserva de recursos: mont.bloq.CCN
9A Resultado estatístico do cálculo
97 Sobretaxa p/requisição compra
96 Sobretaxa para pedidos
58 Solicitações de adiantamento
05 Teórico
06 Teórico (WIP)
07 Teórico: decomposição em tipos de atividade
66 Transferência de resultado
64 Transferências de pagamento
28 Valor da cotação cliente
29 Valor da ordem cliente
CONTROLADORIA 310 de 325
37.5.2 Categorias de desvio/determ.resultados da tabela COSB
Tabela COSB
Categoria Descrição
CSCL Custos calculados
CVVF Custos vol.de vendas, ativação facultativa
CVVN Custos vol.de vendas, ativação não permitida
CVVO Custos vol.de vendas, ativação obrigatória
DSES Desvio de estrutura
DSPR Desvio de preço de input
DSQA Desvio de quantidade alocada
DSQT Desvio de quantidade de input
DSCF Desvio de tamanho de lote
DSTC Desvio de taxa de câmbio
DSPI Desvio preço interno
DSRS Desvio residual
DSIN Desvio residual de input
WIPF Mat.em processo, ativação facultativa
WIPN Mat.em processo, ativação não permitida
WIPO Mat.em processo, ativação obrigatória
ODDR Outros dados de det.result.
PLES Parte lucro no estoque
PRPI Provisões p/risco perda, lnçto.estoque ativ.não perm.
PCRN Provisões para comissão/reclam.(grp.ativ.não permit.)
PCRF Provisões para comissão/reclamação (grp.ativ.facult.)
PCRO Provisões para comissão/reclamação (grp.ativ.obrig.)
PCFF Provisões para custos em falta (grp.ativ.facult.)
PCFN Provisões para custos em falta (grp.ativ.não permit.)
PCFO Provisões para custos em falta (grp.ativ.obrigat.)
PRPE Provisões para risco de perda
RECA Receita calculada
REFG Refugo
37.6 Demonstração de Resultados
KE Demonstração de resultados e de segmento de mercado
Tabela Descrição
TKEB Administração de áreas de resultado (depend.mandante)
TKEBB Administração de áreas de resultado (independ.mandante)
TKEB1 Administração de programa
CESETS Administração de set em report painter
T258M Atribuição de campos de qtd.SD aos campos de qtd.CO-PA
TKEVA04 Atribuição de elementos de cálc.custos a campos valor COPA
T258K Atribuição de elementos de cálculo custo a campos de valor
TKB9C Atribuição de esquema de demonstração de resultados
T258W Atribuição de estruturas DDIC às estruturas CO-PA
TKB9F Atribuição de grupos classes custo para campos valores CO-PA
T258I Atribuição de tipos de condição aos campos de valor CO-PA
CONTROLADORIA 311 de 325
KE Demonstração de resultados e de segmento de mercado
Tabela Descrição
TKEBL Atribuição ledger - área do resultado
TKEVA01 Avaliação - controle
TKEWP Campos de valor CO-PA
TKESD Catálogo de campos base CO-PA: dependências de característ.
TKES Catálogo de campos de base CO-PA (campos fixos)
TKEFE Catálogo de campos, atribuição à área de resultado
COVAD Catálogo de variantes
TGFT Categorias de fluxo monetário
TMFT Categorias de fluxos quantitativos
T821S Chave de distribuição
T821V Chave de distribuição de usuário
TKES4 CO estrutura de linhas/colunas: páginas lógicas
T258F CO-PA controle de acesso ao cálculo de custo do produto
TKENCD CO-PA netchange - definições
TKENCDT CO-PA netchange - definições
TKEP2 CO-PA planejamento - campos especiais
TKEBPSF CO-PA Processamento em massa: campos de tela
TKEBPFM CO-PA Processamento em massa: módulos de função
TKEBPFL CO-PA processamento em massa: parâmetros
TKEP1 CO-PA tabela de planejamento - campos especiais
TKEGC CO-PA: administração de coding gerado (obsoleto)
TKENCF CO-PA: características de modificações de atribuição
TKEPD CO-PA: catálogo de TeDins - planejamento
TKETRND CO-PA: fast rollup de níveis compactação: parâm.espec.DBMS
TBVZ CO-PA: índice de relatórios (obsoleto !)
CEERROR CO-PA: registros AE incorretos do SD
TKEPC CO-PA: sequência de reavaliação / textos
TKEPA CO-PA: sequências de reavaliação
TKEPB CO-PA: sequências de reavaliação / fatores de reavaliação
TKEA1 CO-PA: tab.controle p/administração tabs.derivação geradas
TKEA2 CO-PA: tab.controle p/administração tabs.derivação geradas
TKEB3 CO-PA: tabela de administração para autorizações de objeto
TKEZU CO-PA: tabela de atribuição para características PA
TKEIF CO-PA: tabela de comunicação dentro de CO-PA
TBVZT CO-PA: textos de índice de relatórios (obsoletos!)
TKESK CO: arquivo de índices para estruturas de linhas/colunas
CEFORMF CO: determinação de conteúdo de um elem.de estr.linha/coluna
CEFORMA CO: estrutra de linhas/colunas - histórico de modificação
CEFORMW CO: textos de variáveis da estrutura de linhas/colunas
CEFORMV CO: variáveis da estrutura de linhas/colunas
TKENR Conjuntos de nomes para objetos de desenvolvimento CO
GLTPC Contabilidade de centro de lucro
TKEVG Controle de demonstração do resultado por operações
TKEPDARK Controle de funções ocultas
T237A Controle de saída para T237
TKEVA10 Controle de transferência de SD para COPA
CONTROLADORIA 312 de 325
KE Demonstração de resultados e de segmento de mercado
Tabela Descrição
TKEOE Controle para estruturação de objeto de resultado
TKEPSV COPA estrutura de planejamento - administração de status
TKENCGT COPA: grupos de netchange - textos
TKENCG COPA: netchange - grupos
T258Z Definição do grupo de atribuições
TKEBT Denominação da área da demonstração do resultado
T258T Denominação do grupo de atribuições
TKELT Denominação para Ledger do resultado
TKEDR Derivação de característica: estratégias
TKEDRT Derivação de característica: estratégias, textos
TKEDRS Derivação de característica: etapas
TKEDRSF Derivação de característica: etapas, campos
TKEDRST Derivação de característica: etapas, textos
T237 Descrição de estruturação de relatório
T258A Determinação do esquema cálc.custos para acesso às condições
CEALE01 Distribuição CO-PA: referência de part.indiv.na distribuição
TKB9A Esq.de atribuição para apropriação na demons.de resultados
TKB9E Esquema de demons.de resultados para apropriação de custos
TKEVA02 Estratégias de avaliação (CO-PA)
TKEVAS Estratégias de avaliação COPA
TERKR Estruturas de demonstração do resultado
TKEBS Estruturas de linhas/colunas
TKES1 Estruturas de linhas/colunas
TKEPLEXIT Exits do cliente para o planejamento CO-PA
T821T G/L descrição de chave de distribuição
TKEP7 Grupo de características
TKEP8 Grupo de características - estruturação de linhas
TKEP9 Grupo de características - tabela de texto
CEP01 Itens individuais - dados reais
TKEL Ledger de resultado
TKENC6 Modif.atribuição CO-PA: bloqueio só de exec.modif.exclusivas
TKENC3 Modificações de atribuição CO-PA: condições de seleção
TKENC1 Modificações de atribuição CO-PA: execuções de modificação
TKENC2 Modificações de atribuição CO-PA: ordens de modificação
TKENC5 Modificações de atribuição CO-PA: protocolos de execução
TKENC4 Modificações de atribuição CO-PA: regras de conversão
TKB9G Origem esquema da demonstração de resultados
TKEPP51 Planejam.O-PA: suplem.específ.aplic.de perfis planej.(TKA51)
TKEPSA Planstructure attributes
TKEBF Programas das rotinas FORM p/módulo de leitura de texto CO
TKEAS Regras de derivação CO-PA: tabela de controle
CEFORMC RPT: histórico das modificações de formato para elementos
TKEVA03 Seleção de cálculo de custos
TKEVA03A Seleção de cálculo de custos - artigo
TKEVA03M Seleção de cálculo de custos - tipo de material
TKEBA Status da área de resultado (depend.mandante)
CONTROLADORIA 313 de 325
KE Demonstração de resultados e de segmento de mercado
Tabela Descrição
TKEBC Status de tradução da área de resultado
TKEPE Tab.administ.para transferência de dados planej.CO-PA em SOP
TVGAI Tab.de intervalo de numeração para obj.interv.num.COPA_IST
TVGAP Tab.interv.de numeração para objeto de interv.num.COPA_PLAN
COVAL Tabela de administração para protocolos
TKEVAA Tabela de administração para reavaliação periódica em COPA
T258E Tabela de administração para transferência de dados externa
TKEIG Tabela de características CO-PA
K9001 Tabela de derivação para regra de derivação A01
CEST4 Tabela de objeto (CO-PA)
TKEDRX Tabela de sistema índice
T237T Tabela de texto para T237
T239T Tabela de texto para T239
TKES5 Tabela de texto para TKES4
T25B3 Tabela de texto para valores de característica
T25D8 Tabela de texto para valores de característica
T25T Tabela de texto para valores de característica
TKES2 Tabela de textos para estrutura de linhas/colunas
TKEAT Tabela de textos para TKEAS
T239 Tabela de variantes de relatórios
CEFORME Tabela para a descrição de estrutura de elementos
CEFORMS Tabela para a descrição de FORM de estruturação
CEFORMT Tabela para arquivo de textos de elementos FORM CO-PA
CEPRINT Tabela para descrição de instrução de impressão FORMs CO-PA
T2513 Tabelas para valores de características
T2538 Tabelas para valores de características
TKEDP Tabelas SAP como ajuda à entrada p/def.característica (CO)
TKESW Texto para variáveis globais
TMFTT Textos breves para categorias de fluxo de quantidade
TGFTT Textos breves para categorias de fluxo monetário
TVGAT Textos breves para tipos de operações
TKEPLEXITT Textos da tabela TKEPLEXIT
TKEB2 Textos de relatório
TKVST Textos de versão CO
TKEVAST Textos para estratégia de avaliação COPA
TERKT Textos para estruturas de demonstração de resultado
TKEVAKT Textos para seleção de cálculo de custos COPA
TKEPT Textos para tabelas SAP (ajuda de entrada p/def.caracterís.)
COVAT Textos para variantes
TVGA Tipos de operação para CO-PA
TVGAR Tps.operações da demonstração resultado (atualm.não utiliz.)
T255 Valores para a característica "&"
COVA Variantes: tabela cluster
TKES3 Variáveis de texto para a definição da estrut.linh./colunas
TKESV Variáveis globais
OBYC Determinação de Contas de materiais
CONTROLADORIA 314 de 325
38 Tabelas de Materiais
MARA Material (dados gerais)
MARC Material (dados de centro)
MARD Material (dados de depósito)
MBEW avaliação de material
MVKE (dados de venda) material
MLAN indicador de imposto material
MLGN dados de material / sistema de depósito
MLGT dados de material / tipo de depósito
MAKT textos breves de material
MARM unidades de medida / material
MAW1 dados mestre específicos adminmercadorias
MABW administração desvios de material Retail
MEAN EAN / material
MAEX dados de importação/exportação
EORD lista de opções de fornecimento
EQUK quotas (cabeçalho)
EQUP quotas (item)
MAPR índices de material para a previsão
PROF registros info
PRON mensagens de previsão
PROW valores de previsão
MVER valores de consumo de material
MKAL versões de produção
QMAT parâmetros tipo verifdepsdo material
MAPE dados de controle de exportação
MALG atribuição de módulos layout a materiais
MAMT texto mestre de material por unidade de medida
MLEA ENAs específicos do fornecedor
Apêndice A - Transações do R/3
Componente Código Descrição
Archive SARA Archiving
Archive SE16 Data browser das tabelas - permite pesquisar as tabelas por aplicativo do SAP.
Archive OABJ Definição de objetos de arquivamento
Archive SE11 Dicionário de dados
Archive DB20 Estatística de tabelas – número de registros
Archive DB02 Estatística de tabela – ocupação espaço disco
Archive DB15 Relação Objetos de Archiving x Tabelas
Basis SE80 Abap Development Workbench
CO OKO6 Esquema de apropriação de custos
CO OKO7 Perfil de apropriação custos
CO CKMS Produrar documentos do ledger de materiais
CONTROLADORIA 315 de 325
Componente Código Descrição
CO SAPRCKMS Pesquisar documentos de alteração de preço
FI FS10 Consulta Saldo da conta contábil
MM MM03 Consulta materiais
PM OIOA Tipo de ordem de PM
PP OPJH Tipo de ordem PP
Abap SE38 Execução de programas
SE10 Liberar ordem de transporte (request)
SCC1 Transferir ordem de transporte entre mandantes de desenvolvimento.
Archive SM30 Criação de variantes de programas de deleção de objetos de arquivamento
PP OPJH Definir tipo de ordem de produção (atualizar tempos de retenção ordens PP)
PP KKAC Relação entre ordem de cliente e ordem de vendas
PP CO26 Relaciona as ordens de produção
CO-SD CK87 Consulta Lista técnica avaliada da ordem de cliente
PP MM60 Lista de materiais
SE16 Liberar Request
SE10 Consultar Request
PP MMSC Vincula material a depósito
MM OBYC Determinação de Contas de MM
Apêndice B - Notas Relacionadas
Número Descrição
367588 Nota para atualização do programa ZSAPRCKML_COGS para permitir estornar o lançamento efetuado pelo
COGS e reprocessar.
361236 Descreve o procedimento para processar períodos anteriores do ledger.
386601 Descreve como processar o programa ZSAPRCKML_COGS em períodos anteriores.
Nota 85708 - Perguntas e respostas sobre arquivamento de CO_OM
Version 0004 from 03.11.1998
Set by SAP AG on 27.11.1998
Administrator SAP AG
Symptom
Open questions regarding documentation on archiving in Overhead Cost Controlling. The documentation contradicts (at least in
parts) the functions.
Solution
This note will answer some of your questions:
Why is data deleted during archiving although “Archive and delete” or “Delete archived data”?
If you deactivate the deletion of data via the variant of the write program when scheduling an archiving run, the deletion
program is nevertheless started. However, the test run variant of the deletion program is used to do this. This variant is
determined in the general archive Customizing. (Transaction SM30 with view V_ARC_USR.) The following problems can
now occur:
CONTROLADORIA 316 de 325
The test run variant of the deletion program is set to 'Archive and delete' or 'Test run' is set to inactive. This should not happen.
In this case change the variant so that the flag 'Test run' is always set to active.
For the cost center archiving, a program error exists in the maintenance levels of Releases 3.0C to 3.0F, 3.1G and 3.1H, which
causes data to be deleted if the flags 'Test run' or 'Archive' are active. In addition, variants were delivered for which the flag
'Archive' is active. Refer also to Note 84061.
In the maintenance levels of Releases 3.0C to 3.0F and 3.1G, the texts are displayed incorrectly in the cost center archiving for
the variants. This can create the impression that data is deleted although deletion has been deactivated.The problem only occurs
when displaying variants. In the change mode, everything is displayed correctly. Also read Note 69489.
When starting the write program you selected 'Archive' or you deactivated 'Delete archived data'. Is it possible to delete data so
created in the archives from the database afterwards?
This is never possible. The F1 help for flag 'Archive' is incorrect for cost center archiving in Release 3.0 and 3.1. An exception
is to archive the settlement documents (archiving object CO_KABR). As of Release 3.0E, data which was archived with
'Archiving without deletion' cannot be deleted from the database later on.
What is the difference between 'Archive' and 'Archive and delete' if the deletion run still deletes data?
The difference between 'Archive' and 'Archive and delete' consists in the fact that the delete program runs in the test run for
'Archive', meaning the data to be archived is not immediately deleted. For 'Archive and delete', the delete program is started
with the productive run variant, hence data is deleted automatically from the database directly after creating the archive files.
When you define archiving objects, the system saves which files (tables) belong to this archiving object and which tables are to
be deleted. Why then is data also deleted from tables which are not listed here?
When archiving and deleting, only the program logic of the write and deletion program determines from which tables to delete
something.The information stored in the definition of the archiving object is not taken into account by the programs.
From which tables are entries deleted ?
The following list indicates which tables are deleted from which archiving object:
CO_COSTCTR: CSKS, CSKT, CDHDR, CDPOS, STXH, STXL, STXB, BPHI, BPTR, BPJA, BPEJ, BPBK, BPPE, BPEP,
COKA, COKP, CKHS, CKHT, CKIS, CKIT, CKIP, COSP, COEP, COBK, COEJ, COOI, COKS, COSS, COKR, COSR,
COEPR, COEJR, COSB, COEPB, CSSL, COKL, COSL, COEPL, COEJL, COST, COEPT, COEJT, ONR00, ONRKS,
ONRKL
CO_CCTR_ID: COSP, COEP, COBK, COSS, COSR, COEPR, COSL, COEPL, COST, COEPT
CO_CCTR_PL: COKP, STXH, STXL, STXB, CKHS, CKHT, CKIS, CKIT, CKIP, COSP, COEJ, COBK, COKS, COSS,
COKR, COSR, COEJR, COKL, COSL, COEJL, COST, COEJT
Up to and including Release 4.5A you may find that the archiving object CO_CCTR_PL also deletes entries from table
COKA.This is caused by an error.You can find more detailed information on this in Note 61352.
CO_CCTR_EP: BPEJ, BPBK, BPEP, COEP, COBK, COEJ, COEPR, COEJR, COEPB, COEPT, COEJT
CO_ALLO_ST: T811D, COEP, COBK, COEJ, COEPL, COEJL
CO_ORDER: AUFK, AFKO, AFPO, CDHDR, CDPOS, STXH, STXL, STXB, JSTO, JEST, JCDO, JCDS, COBRA,
COBRB, BPHI, BPTR, BPGE, BPEG, BPBK, CKHS, CKHT, CKIS, CKIT, CKIP, BPJA, BPEJ, BPIG, BPIJ, COKA, COKP,
COSP, COEP, COBK, COEPD, COEPBR, EBII, COEJ, COOI, COSPD, COKS, COSS, COSSD, COKR, COSR, COEPR,
COEJR, COSL, COEPL, COEJL, COSB, COEPB, COSBD, ANIA, ANIB, ANLI, FMSU, COFP, RPSCO, TPI031, AUAK,
AUAA, AUAB, AUAO, AUAS, AUAI, AUAV, KSSK, AUSP, ONR00, ONROR
CO_KABR: AUAK, AUAA, AUAB, AUAO, AUAS, AUAI, AUAV
Valid releases
R/3 standard 45A - 45B
40A - 40B
300 - 31I
CONTROLADORIA 317 de 325
Nota 200513 - Considerações sobre deleção da tabela COBK - Cabeçalho de documentos de CO.
Version 0002 from 14.02.2000
Set by SAP AG on 14.02.2000
Administrator SAP AG
Symptom
You archive or delete CO line items (table COEP, COEJ, etc). The system deletes less items from table COBK than expected,
or it deletes no entries from table COBK.
Solution
Table COBK contains the document headers of cost accounting. The line items are stored in table COEP, COEJ, COEPR, and
so on. If you have identified an item in table COBK that should have been deleted, analyze the corresponding document with
the aid of program RKABSHOW. The program needs the controlling area (COBK-KOKRS) and the document number
(COBK-BELNR). Consider the following information for the analysis.
As opposed to financial accounting, CO line items are not archived by document but by cost-object. Thus, it may happen that
many line items (for example, COEP) have been deleted, but no item has been deleted from table COBK.
Example: When you carry out a posting between a cost center and an order, the system generates a document with two lines.
One of these lines belongs to the order, the other line belongs to the cost center. During archiving with archiving object
CO_ORDER, PP_ORDER, PM_ORDER, or PR_ORDER, the line belonging to the order is archived and deleted. The
document header is retained. So the database now only contains the document header and the line belonging the cost center. If
the cost center is archived with CO_COSTCTR, the line item belonging to the cost center is archived and also the document
header is deleted. For all other object types (for example, sales order items, reconciliation objects, and so on) and in particular
for archiving object CO_ITEM, this mechanism works exactly the same way. Also with CO_ITEM the system always archives
the line items for a controlling object (for example, an order ) in a data object. For information purposes, the document header
data is always on the archive even if they are not deleted.
A document header is deleted if its last line is deleted. This is why documents with incorrect lines may be retained. (For further
information refer to Note 200480.) Document headers which have no lines or the lines if which have not been deleted with the
standard methods, also remain on the database. Similar problems may occur with documents, which contain lines that have
been sent by ALE (Application Link Enabling). For these documents Release 4.5B contains deletion program RKADELIT. For
further information refer to the program documentation of this program. (Only use this program if you use ALE!)
If you execute an archiving deletion program in test run the number of deleted COBK items may be displayed. This number
may deviate from the number of items acutally deleted in update run. Due to the logic described above, it is very complicated to
determine the exact number of items deleted in advance. The number may also vary between test and update run if in the
meantime other deletion runs (also for other archiving objects) have been carried out.
Nota 32236 - quantidade ou valor de estoque incorreto no mestre de materiais
Version 0054 from 16.01.2001
Status Für Kunden freigegeben
Set by SAP AG on 16.01.2001
Language EN
Component MM-IM
Symptom
When you enter a goods movement, the system generates one of the following error messages:
o M7308 Stock value and qty are unrealistic: & / & -> see long text
o M7309 Stock value is negative: & -> see long text
o M7310 Valuated stock is negative: & -> see long text
o M7314 Valuated stock becomes negative: & -> see long text
CONTROLADORIA 318 de 325
The messages are only displayed in Release 3.0 or later. However, the symptoms (negative stocks, stock inconsistencies) can
appear as early as Release 2.2. The stock tables are not consistent within themselves. Differences occurred between the material
valuation and FI.
Cause and preconditions
These messages are generated if the system finds a data inconsistency when reading material master data, that is, the stock
quantity or the stock value is already inconsistent prior to the goods movement. You have inconsistencies in your tables, for
example, in the comparison of the stock quantity in the stock overview (taking into account all valuated stocks) with the stock
in the accounting view of the material master. You get differences with report RM07MMFI.
Solution
The inventory postings (material documents and accounting documents) for the material must be checked by SAP Support. This
requires several check reports which need to be imported from sapserv3, sapserv4, sapserv5, sapserv6 or sapserv7. To do this
refer to Note 13719.
1. Report RM07MMFI must be present in your system. If it is not, implement it as specified in Note 198596.
2. Using Transaction SE11, check whether the current version of tables MMINKON and MMINKON_UP exist. In the current
version, field CANCEL_YR is present in table MMINKON_UP. If they do not exist, the table must be imported using the
following transports and then activated:
For Release 3.x: ALRK299731 in directory "general/R3server/abap/note.0032236"
For Release 4.x: ALRK299728 in directory "general/R3server/abap/note.0032236"
When you import tables MMINKON and MMINKON_UP, the following data elements must be active:
BWTAR_D, CHARG_D, FELD_30, F_SPLIT, LFDNR_MM, LFYEAR, LGORT_D, MMINKON_K, NEW_VALUE,
NEW_VAL_C, OLD_VALUE, OLD_VAL_C, PROG_KEY, TABN_30, VERS_MM, WERKS_D, XMBEW_FI,
XMBEW_MM, XMSEG_MM
3. Import the following check reports from the command file ALRK301841 in directory "general/R3server/abap/note.0032236"
in your system:
MBFIRST, MBQUANT, MBVALUE, MBSTOCK, MBLABST, MBMISSFI, MBFIRST, MBANEKBE, MBCKBSEG,
MBENQMAT, MBGENKAL, RM07MR51, RM07MB51, MBTRAME, RM07REUS, RM07APP1, MBSEGBSX,
RM07AUTH, RM07UPLD, MBINKON, RM07COMP, RM07HIST, MBUPDATE, MBSTART and MBSHOWUP.
Make sure that the current version 'Version 00011' has been implemented in your system. The versions in format ##/## (for
example 10/00) are older than version 00011. In order to check the versions in your system, start report MBFIRST for a
company code. The version will be the first thing displayed in the list output. If this is not the case, this means you have an
earlier version.
Attention:
During the import, there might be several error messages in the transport log due to lines that are too long (section for 72
characters). This effect is well-known and SAP is working on a solution. However, the programs are available and thus the
transport was successful.
If you encounter problems during import, make sure that you have the latest transport of R/3 trans in your system. If this is not
the case, import the current R/3 trans or kernel (see Notes 60928, 126776 and the notes referred to in these notes).
Some check reports are also able to make hard updates on the database, provided the update parameters are set. These updates
are all executed without the material being blocked and should under no circumstances be performed without prior arrangement
with our support department (2nd Level Support).
If you have already archived material documents or accounting documents in your system, or if you use the aggregation of
posting lines for your stock accounts, report this to the Hotline Services as some of the check reports are based on these
documents and can no longer be run after the documents have been archived or the posting lines aggregated.
For more information on the corrections which might have been implemented, refer to Note 34440.
We recommend that you do not enter any more movements for this material. However, if this cannot be avoided, then the error
message can be issued as a warning message. To do this, you have to make an entry for the respective error message in table
T160M. If you make an entry in table T160M and then carry out the "absolutely necessary" material movement, you have to
delete the entry from table T160M again.
Example:
CONTROLADORIA 319 de 325
Version Ap Msg Cat Message text
00 M7 308 Stock value and qty are unrealistic: & / &
Bear in mind that the "Cat." column must be empty. The version is contained in standard system 00, but can be defined user-
specifically with parameter ID MSV. If you still have the reports in your system from an earlier version of the transport, and
these are within the customer name range, see Note 304670.
Valid releases Note is release independent
Reference to related notes
Number Short text
0034440 Procedure for correcting the material master
0060928 Transports between Release 3.0/3.1 and 4.0
0067261 IS-OIL: Reports to analyze and correct stock quantities in IS-OIL systems
0076926 Check list f. material inconsistencies (value, qty)
0098942 TD Multipe material documents in one LUW
0116601 Inconsistencies between MM and FI
0161724 Incorrect update of material document
0198596 Fast MM-FI balance comparison (replacemnt RM07MBST)
0212707 IS-OIL: Reports to analyze and correct stock quantities in IS-OIL systems
0304670 Renaming consistency analysis tools of the stock
0313803 RM07APP1: Routine GET_RELEASE does not exist
0357468 Changing valuation type via goods movement
0368185 MIRO:Incnsistncy posting matl items to prior period
References to Support Packages
Software component Release Package name
SAP Application 45B SAPKH45B32
Apêndice A - Traduções
Controlling Area Área de Contabilidade de Custos
Number Ranges for Controlling Documents Intervalos de numeração para documentos CO
Prepare Application Components
1. General Controlling
a) Cost Element Accounting
b) Cost Center Accounting
c) Activity-Based Costing
d) Internal Orders
2. Product Cost Controlling
3. Profitability Analysis
4. Profit Center Accounting
Componentes da Aplicação
1. Controlling de custos indiretos
a) Contabilidade de classes de custo e classes de receitas
b) Contabilidade de centro de custo
c) Custeio baseado na atividade
d) Ordens de custos indiretos
2. Controlling de custos do produto
3. Demonstração de Resultados e Contabilidade Segmentos Mercado
4. Contabilidade de centro de lucro
Authorizations and Profiles Autorizações e Perfis
Role (Activity Group) Função (Grupo de Atividade)
CONTROLADORIA 320 de 325
Apêndice B - Conceitos Gerais de Gestão de Negócio
ALIANÇA ESTRATÉGICA – Associação entre várias empresas integrando recursos, competências e tecnologias para
desenvolver uma atividade específica ou criar sinergias de grupo visando um novo mercado (geográfico ou setorial) e aquisição
de novas competências. Inclui, basicamente, são: fusão ou aquisição; internacionalização; ou celebração de alianças estratégicas
com um ou vários parceiros. As alianças tanto podem efetuar-se entre empresas que atuam em ramos de atividade diferentes
como entre concorrentes. Distinguem-se das joint-ventures, em que os parceiros partilham a propriedade de uma nova empresa.
ANÁLISE DE PARETO – Criada no século XIX pelo economista italiano Vilfredo Pareto, defende que cerca de 80% dos
lucros de uma empresa são derivados de 20% dos seus produtos;
ANÁLISE DE VALOR – metodologia de gestão criada nos anos 50 pelo americano Lawrence Miles que consiste na
decomposição de um produto ou serviço em suas funções principais para identificar alternativas apropriadas para reduzir os
custos de produção. Analisa detalhadamente o valor agregado pela empresa em cada uma das diferentes etapas de produção
(mercadoria ou serviço): concepção, fabricação, venda, distribuição e serviço aos clientes. Este conceito deu origem às noções
de cadeia de valor, de valor agregado ao produto ou serviço e de shareholder value (valor para o acionista) cuja autoria pertence
a Alfred Rappaport.
ANÁLISE ESTRUTURAL DE INDÚSTRIAS – Michael Porter propõe um modelo de análise de indústrias baseado na
identificação das cinco seguintes forças: (1) Ameaça de novas entradas - Existem barreiras à entrada de novos competidores?;
(2) Rivalidade entre os concorrentes - Há guerras de preços, de publicidade ou de produtos? ; (3) Existência de produtos
substitutos - Há uma ameaça de substituição por produtos ou serviços que satisfaçam as mesmas necessidades?; (4) Poder de
negociação dos clientes - Qual o seu poder para influenciar as variações de preço dos produtos ou serviços?; (5) Poder de
negociação dos fornecedores - Qual o seu poder de negociação para elevar os preços ou reduzir o nível de qualidade oferecido?
ANÁLISE SWOT – metodologia criada por Kenneth Andrews e Roland Christensen, (Harvard Business School), que estuda a
competitividade de uma organização segundo quatro variáveis: strengths (forças), weaknesses (fraquezas), opportunities
(oportunidades) e threats (ameaças). Mede as forças e fraquezas da empresa, as oportunidades e ameaças do mercado e o grau
de adequação entre elas. Quando os pontos fortes de uma organização estão de acordo com os fatores críticos de sucesso para
satisfazer as oportunidades de mercado a empresa será, por certo, competitiva no longo prazo.
BENCHMARKING – segundo o IBC (International Benchmarking Clearinghouse), o benchmarking é um processo sistemático
e contínuo medição e comparação das práticas de uma organização com as das líderes mundiais, obtendo informações para
melhoria do desempenho. Ou seja, é uma técnica de observação e adaptação das melhores práticas das melhores empresas, que,
no entanto, não deve ser confundida com a espionagem industrial. A Rank Xerox é considerada a empresa pioneira na aplicação
do benchmarking.
BRAINSTORMING – técnica de reunião de grupo, criada por Osborn em 1963, que visa ajudar os participantes a vencer suas
limitações, estimulando a criatividade podendo durar alguns minutos ou várias horas, dependendo das pessoas envolvidas e da
dificuldade do tema. Em regra, as reuniões não costumam ultrapassar os 30 minutos. O brainstorming tem quatro regras de
ouro: nunca critique uma sugestão; encoraje as idéias bizarras; prefira a quantidade à qualidade; e não respeite a propriedade
intelectual. Além de zelar para que todos os participantes (geralmente entre 6 e 12 pessoas) cumpram as regras, o líder da
sessão deve manter um ambiente relaxante e propício à geração de novas idéias.
BRAND MANAGEMENT (Gestão de marcas) – desenvolvimento sistemático do valor de uma marca criando uma identidade
largamente reconhecida pelo mercado alvo a atingir. A partir dos anos 80, as empresas começaram a considerar a imagem da
marca como um ativo estratégico das empresas (algumas atribuem-lhe um valor nas suas demonstrações financeiras). A
atribuição de um nome ou uma marca a um produto designa-se branding.
BREAK-EVEN – análise simples e eficaz para simular e medir a rentabilidade (ou prejuízo) de uma empresa ou de uma
operação financeira a fim de determinar o break-even point (ponto morto das vendas), no qual o valor das receitas da empresa
(lucro de vendas) é igual aos seus custos totais (somatório dos custos fixos e variáveis). Outro conceito relevante é o da margem
de contribuição (ponto em que as receitas igualam os custos variáveis).
CADEIA DE VALOR – série de atividades relacionadas e desenvolvidas pela empresa para satisfazer as necessidades dos
clientes, desde as relações com os fornecedores e ciclos de produção e venda até a fase da distribuição para o consumidor final
interligando os elos dessa cadeia de atividades. Esta é uma metodologia usada pela consultora McKinsey, sistematizada e
popularizada por Michael Porter, que permite decompor as atividades (divididas em primárias e de suporte) que formam a
cadeia de valor. Segundo Porter, existem dois tipos possíveis de vantagem competitiva (liderança de custos ou diferenciação)
em cada etapa da cadeia de valor.
CICLO DE VIDA DO PRODUTO – (Fase 1) Introdução – O produto foi lançado no mercado e o crescimento das vendas é
lento; (Fase 2) Crescimento – Há uma explosão da procura, uma melhoria dos lucros e o produto tende a massificar-se.
Chegam novos competidores; (Fase 3) Maturidade – O ritmo de crescimento das vendas dá sinais de abrandamento. É uma
CONTROLADORIA 321 de 325
fase em que as empresas tendem a entrar em guerras de preço e publicidade; (Fase 4) Declínio – A procura entra em
derrapagem, os lucros sofrem uma rápida erosão em direção ao ponto zero. Grande parte dos competidores começa a abandonar
o mercado.
CORE COMPETENCE – conceito que surgiu em 1990 e corresponde a uma competência estratégica (por exemplo, um
conhecimento técnico ou uma tecnologia específica) que se constitui num diferencial que distingue uma empresa das rivais. É o
caso da competência da Sony em técnicas de monitorização, ou da Honda na criação de motores. Poucas empresas consegue
uma liderança mundial, em mais de cinco ou seis competências estratégicas.
DOWNSIZING - Nos anos 80, a velocidade e a flexibilidade eram os dois requisitos-chave para competitividade, e as grandes
empresas cresceram de forma desordenada através da diversificação para novos negócios gerando estruturas gigantescas. Na
década seguinte, foram forçadas a reestruturar-se num processo designado downsizing (um termo importado da informática) de
redução radical de tamanho, geralmente através do delayering (redução dos níveis hierárquicos) ou da venda de negócios não
estratégicos ganhando flexibilidade e reduzindo processos burocráticos se aproximando do mercado e dos clientes.
EMPOWERMENT - conceito de gestão associado ao trabalho de Rosabeth Moss Kanter, que diz que as empresas que dão mais
poder e autonomia aos seus trabalhadores são mais competitivas a longo prazo. O caso clássico da aplicação radical do
empowerment é o da empresa brasileira Semco, liderada por Ricardo Semler.
EXCELÊNCIA – Conceito criado em 1982 por Peters e Waterman, definindo oito características para excelência: inclinação
para a ação; proximidade do cliente; autonomia individual; apostar nas pessoas; criação de valores; manter-se no que se
domina; simplicidade formal; e existência em simultâneo de rigidez e flexibilidade.
FRANCHISING - Um método popular que permite tanto a uma empresa alargar a sua base de clientes sem a necessidade de
investimento em capital (franqueador) e quanto a um candidato a empresário criar um negócio sem constituir uma empresa de
raiz (franquiado). Um negócio torna-se franchising quando o franquiado paga direitos de entrada e royalties (geralmente uma
percentagem fixa do volume de negócios) pela utilização da marca, produto ou serviço. Em contrapartida, recebe apoio do
franqueador e o direito a distribuir o produto ou serviço numa área determinada.
GLOBALIZAÇÃO – A tecnologia da informação deram origem a uma verdadeira aldeia global. Para os gestores, o termo
significa a integração mundial das atividades de uma organização. É uma etapa mais avançada da internacionalização, em que
os processos são organizados à escala global, como se o mundo fosse um único país. A globalização diz respeito a todas as
funções da empresa, mas muitas vezes é apenas limitada ao marketing. Nesta área, Theodore Levitt foi o primeiro a alertar para
a homogeneidade global das preferências dos consumidores.
HORIZONTAL ORGANIZATION (Flat Organization) – minimiza o número de níveis hierárquicos aproximando-se dos
clientes e aproximando os funcionários dos tomadores de decisão objetivando agilizar a tomada de decisão. Os empregados,
sentindo-se menos vigiados, revelam maior empenho e criatividade. Este tipo de organização favorece a criação de estruturas
matriciais, mais leves e flexíveis, em que existe uma maior descentralização das responsabilidades.
JUST-IN-TIME – técnica de gestão e controle de estoque, criada na Toyota em 1960, que visa acabar com o estoque
intermediário (estoque zero) e que contribuiu, fortemente, para o milagre industrial japonês. A idéia base é bastante simples:
cada etapa do ciclo de produção só deve solicitar novas encomendas à etapa anterior na medida que precisar delas. Implica
igualmente numa redução do número de fornecedores. Richard Schonberger foi o primeiro autor a divulgar a metodologia just-
in-time nos Estados Unidos.
LEAN PRODUTION – conjunto de técnicas desenvolvidas nos anos 70 por fabricantes japoneses, como a Toyota e a
Matsushita, para reduzir os custos de produção e aumentar a competitividade. Foi popularizado através do estudo sobre a
indústria automóvel do MIT, que investigou as causas associadas à superioridade dos nipônicos nos domínios da produtividade,
flexibilidade, rapidez e qualidade. O conceito de lean prodution é baseado em quatro princípios: trabalho de equipe;
comunicação; uso eficiente de recursos e eliminação de desperdícios; e melhoria contínua (Kaisen).
LEI DE PARKINSON - primeiro livro humorístico sobre gestão. Eis duas das suas leis: "O trabalho expande-se na exata
medida do tempo disponível para ser feito"; "Quanto menor o interesse do assunto, maior é a discussão";
MANAGEMENT BY OBJECTIVES – MBO (Gestão por Objetivos) - criada por Peter Drucker nos anos 50, descreve um
sistema de gestão em que os trabalhadores e os gestores estratégicos definem, em conjunto, o objetivo final do trabalho, a forma
de realização e de avaliação e o tempo necessário à concretização. É uma técnica popular em todo o mundo. Há, no entanto, três
críticas clássicas à sua aplicação: os gestores tendem a definir metas pouco ambiciosas ou irrealistas; os objetivos raramente
resultam de um processo participativo e descentralizado; e não promove o trabalho de equipe.
MATRIZ BCG – método analíticos pioneiro e simples (e, por isto mesmo, popular), desenvolvido pelo Boston Consulting
Group, de apoio à tomada de decisões estratégicas relativas ao port-fólio (carteira) de negócios ou produtos. Sua aplicação
constitui-se na construção de uma matriz, cujo eixo horizontal é a quota de mercado relativa (alta à esquerda e baixa à direita) e
CONTROLADORIA 322 de 325
o eixo vertical é a taxa de crescimento do mercado (elevada em cima e reduzida em baixo). A matriz dá origem a quatro
quadrantes: interrogações (question-marks); estrelas (stars); vacas leiteiras (cash-cows); e cães (dogs).
OUTPLACEMENT – técnica de RH que visa auxiliar os trabalhadores dispensados na reinserção profissional no mercado,
criada em função das grandes reestruturação das empresas (grande volume de demissões). Algumas empresas prestam os
serviços de aconselhamento financeiro e recrutamento e seleção através de departamentos internos e outras terceirizam.
OUTSOURCING – conceito oriundo da informática, que propõe a terceirização dos serviços não estratégicos da empresa
(serviços que não produzem valor agregado aos clientes) visando redução de custos e concentração dos esforços dos executivos
nas core competence (competências estratégicas) da empresa. Tem maior potencial de aplicação em indústrias dinâmicas, em
que as pressões para cortes nos custos são mais intensas, nomeadamente nos grupos empresariais que pretendem seguir uma
estratégia de integração vertical das suas atividades.
PENSAMENTO ESTRATÉGICO - As décadas de 70 e 80 foram a época áurea o planeamento estratégico. Na prática, a
maioria desses planos acabou por fracassar. Henry Mintzberg diagnosticou os motivos. Segundo o canadiano, o excesso de
análise cria uma espécie de paralisia. Por outro lado, considera que não se deve separar o planejamento da ação. Enquanto
planear é um exercício analítico, a estratégia baseia-se na criatividade, intuição e capacidade de síntese. Para designar esta
última atitude propõe, em alternativa, o termo "pensamento estratégico".
PENSAMENTO LATERAL – conceito criado por Edward de Bono, que consiste na geração de novas idéias e no abandono das
obsoletas visando aumentar a criatividade e os recursos estratégicos da organização. Estimula o cérebro através de atitudes de
quebra dos princípios estabelecidos e encarando a realidade de modo diferente. Estimula o pensamento lateral (descontínuo e
destinado à geração de idéias) para gerar novas idéias e o vertical (contínuo e orientado para as desenvolver) para desenvolvê-
las.
PLANEJAMENTO POR CENÁRIOS – técnica desenvolvida por Peter Schwartz, que permite prever a situação do mercado a
longo prazo utilizada pela Shell para se preparar para a crise do petróleo de 1973. Os cenários não são previsões; são um
conjunto de hipóteses alternativas sobre o futuro, preparando a empresa para a ocorrência de cada uma dessas hipóteses e
exercitando os gestores na reflexão das estratégias de longo prazo.
PRINCÍPIO DE PETER - Defende que qualquer trabalhador acabará por ser promovido até ao limite máximo do seu nível de
incompetência. Foi criado em 1969 por Laurence J. Peter.
PROJECT MANAGEMENT – baseia-se na formação de equipes temporárias e multi-disciplinares constituída por empregados
provenientes de diferentes setores da empresa, com especializações e competências diversas, para realização de um projeto
validado pela direção geral. A equipe deve possuir um gerente ligado diretamente à direção geral. Os membros são desligados,
total ou parcialmente, mas apenas de uma forma temporária, do seu serviço de origem.
RISK MANAGEMENT (Gestão do risco) – análise e controle ideal dos riscos de uma empresa visando minimizá-los
otimização a relação qualidade/custo dos diferentes seguros da companhia. O método inclui todos os tipos de riscos clássicos
(caso da segurança de pessoas e bens) e também alguns cuja freqüência ou amplitude cresceu nos últimos anos, tais como riscos
de cópias, os ligados ao meio ambiente ou as despesas médicas dos empregados.
SINERGIA – conceito, introduzido por Igor Ansoff no livro Corporate Startegy, que visa provar que duas empresas juntas
valem mais do que a soma das duas separadas. Se não existir sinergia (ou se for negativa) não valerá a pena concretizar-se uma
fusão ou aquisição. O conceito pode ser aplicado em outras áreas, como alianças estratégicas, joint-ventures, acordos de
cooperação, relações das empresas com fornecedores ou clientes e equipes de trabalho multi-disciplinares.
TIME BASED COMPETITION – conceito criado por George Stalk e Thomas Hout, do Boston Consulting Group, que visa a
redução do tempo de resposta às evoluções do mercado, fornecendo, ao cliente, o que ele quer, no momento em que o deseja. O
poder de reação da companhia deve ser estimulado em todos os campos: produtos; produção; distribuição; e serviço.
TRADE MARKETING – otimização da relação entre o produtor e o distribuidor. O conceito surgiu no início dos anos 90
devido à importância crescente dos intermediários (atacadistas e varejistas) na distribuição. A relação entre produtores e
distribuidores é, em regra, conflituosa. O objetivo do trade marketing é encontrar formas para que ambos tirem o máximo
partido de um acordo de colaboração. Propõe a criação de uma parceria de longo prazo entre produtores e distribuidores em
áreas como trocas de informação, oferta do produto com a marca do distribuidor e publicidade ou promoções conjuntas.
VANTAGEM COMPETITIVA – conceito criado por Michael Porter que demonstra que as empresas bem sucedidas obedecem
a padrões definidos de comportamento resumido em três estratégias genéricas que são as fontes de vantagem competitiva sobre
os concorrentes: (1) Liderança baseada no fator custo - Possuir custos mais baixos do que os rivais; (2) Diferenciação - Criar
um produto ou serviço que é visto na indústria como único; ou (3) Focalização - Combinar as duas estratégias direcionando-as
para um alvo específico.
X, Y, Z - Nascidas no final dos anos 50, as teorias X e Y são duas visões opostas sobre a natureza humana e a forma de gerir a
força de trabalho. Foram criadas pelo psicólogo Douglas McGregor, do MIT. A teoria X assume que os indivíduos não gostam
CONTROLADORIA 323 de 325
de trabalhar, a menos que sejam obrigados coercivamente a fazê-lo. A teoria Y defende que as pessoas têm auto-realização no
trabalho e que cumprem melhor as suas tarefas se não forem vigiadas por terceiros. A teoria Z, de William Ouchi, é uma
variante da teoria Y. Defende que os trabalhadores têm um grau de envolvimento similar ao dos gestores quando existe um
sistema de recompensas e incentivos eficaz.
Apêndice C - Conceitos Gerais do R/3
Workbench (ABAP BC-DWB)
Workbench (ABAP BC-DWB) é um ambinete de desenvolvimento gráfico integrado do R/3 que permite o desenvolvimento,
modificação e gerenciar aplicações cliente-servidor escritas em ABAP. O Workbench pode ser usado para:
Escrever códigos em ABAP
Desenhar telas
Criar interfaces de usuário
Testar aplicações para performance e erros
Usar funções predefinidas
Acessar objetos de desenvolvimento
Criar e acessar informações do banco de dados
Variant (Variante)
Conjunto de parâmetros predefinidos para ser usado em relatórios, cálculos, layout de telas e relatórios (Costing Variant,
Seletion Variant, Display Variant, etc.). Termo muito usado dentro do R/3. Uma variante de exibição (display variant)
corresponde a novas formas de visualizar um relatório já montado alterando colunas, tamanho de colunas, etc. Já uma variante
de seleção corresponde ao conjunto dos parâmetros necessários para a geração do relatório definidos quais os dados serão
apresentados e não como serão exibidos.
Business Scenario (Cenário de Negócio)
Conjunto de processos de negócio relacionados a uma área organizacional da empresa com objetivos semelhantes, tais como,
compras, serviços, preparação de balanço patrimonial (balance sheet), produção, administração de pessoal, etc.
Unidade Organizacional
Cada uma das áreas da empresa constituída por razões legais ou qualquer outra. Exemplo: empresa (company code), escritórios
de vendas, centros de lucro.
Master Data (dados mestre)
Correspondem ao cadastros básicos do sistema necessários para a operação diária do sistema. São informações válidas por um
longo período de tempo, tais como, o cadastro de clientes, fornecedores, materiais, plano de contas, etc. Difere das demais
informações que são dados transacionais, registrados periodicamente no sistema, tais como, lançamentos contábeis, faturas,
movimentações de estoque, etc.
Transaction (transação)
Cada uma das funções do R/3 que executa um processo de negócio, tais como, criação de uma ordem de venda, registro de um
recebimento de cliente, etc.
CONTROLADORIA 324 de 325
Documento
Registro de informações gerado a cada transação do R/3 recebendo um número único de identificação. Cada um dos módulos
do R/3 tem os seus documentos e uma mesma transação pode gerar documentos em diversos módulos. Por exemplo, o registro
de um pagamento gera um documento em FI-AP correspondente ao pagamento (razão auxiliar), um documento em FI-GL
correspondente ao lançamento no razão geral. Uma requisição de material gera um documento em MM, em FI e também em
CO referente ao custo gerado. Na maior parte dos casos, a numeração destes documentos é automática pelo sistema e o
intervalo de numeração é parametrizável pelo usuário. O R/3 mantém um registro do vínculos entre estes documentos de forma
a permitir visualizar todas as transações dentro do sistema. É importante lembrar que nem todas as transações geram
documentos em FI (exemplo: ordens de compra) já que não correspondem a um fato contábil.
Um documento pode ser no máximo 999 itens. Em alguns casos, esta restrição pode obrigar a dividir um lançamento em dois.
Tipo de documento
Os documentos são classificados por tipo que controla o cabeçalho do documento e diferencia as transações (fatura de clientes,
pagamentos de fornecedores, etc.) Os tipos de documentos são definidos a nível de CLIENT sendo válidos para todas as
empresas.
Os tipos de documentos são definidos, principalmente, para controlar o intervalo de numeração e os tipos de conta permitidas
para lançamento. Além disto, controla os field status para campos de cabeçalho (text e Reference Number) e se as faturas são
lançadas com o net method (pelo valor líquido). Normalmente é utilizado numeração automática de documentos (intervalo
interno) sendo o número real do documento lançado no campo Reference. No caso de geração de documentos no contas a
receber pelo SD, o número da nota fiscal é armazenado automaticamente pelo R/3 neste campo. Caso a empresa prefira definir
o número de cada documento, o intervalo de numeração deve ser definido como externo. Desta forma, a cada geração de
documento, será solicitado que o usuário informe o número. Embora chame de número, este campo pode ser alfanumérico.
Alguns dos tipos de documentos padrões já fornecidos são:
Documento Descrição
AB General Documents - liberados para todos os tipos de contas
DR Customer Invoices - liberados para contas de clientes (D) e do G/L (S)
DG Customer Credit Memo - notas de crédito de clientes
DZ Customer Payments
SA G/L account postings
KR Vendor invoices
KG Vendor Credit Memos
KZ Vendor Payments
KN Vendor net invoices and credit memos
RV para faturas de clientes geradas pelo SD billing documents
RE para faturas de fornecedores geradas pelo MM billing documents
ZP usado pelo programa de pagamento para lançamentos automáticos.
O intervalo de numeração de documentos pode ser definido ano a ano ou pode ser definido como sendo válido até um ano fiscal
futuro. No primeiro caso, os documentos serão reinicializados ano a ano. No segundo caso, a numeração continua a seqüência
do ano anterior. Quando alcançar o final do intervalo, o R/3 automaticamente volta para o início do intervalo. Recomenda-se
reinicializar ano a ano para evitar que acha um reinício de numeração no meio do ano.
O R/3 permite efetuar cópia de intervalo de numeração de documentos para facilitar o processo. Mais de um tipo de documento
pode ser vinculado ao mesmo intervalo de numeração.
Os tipos de documentos serão associados às transações de forma que, dependendo da transação selecionada pelo usuário, um
tipo de documento automaticamente será selecionado para a geração do documento e para a definição do layout da tela.
Tipo de Conta
Os tipos de contas permitidos na definição dos tipos de documentos são:
CONTROLADORIA 325 de 325
Tipo Descrição
A – Assets contas de razão auxiliar do ativo fixo (código de identificação do ativo)
K – Vendor contas do razão auxliar de fornecedores (código de identificação do fornecedor)
D – Customer contas do razão auxiliar de clientes (código de identificação do cliente)
M – Material contas do material ledger (o material ledger não é considerado pelo R/3 como um razão auxiliar, as suas
contas estão cadastradas no razão geral da empresa)
S – G/L Account razão geral da empresa.
Reports
Programa para geração de relatórios.
Enjoy SAP
Até as versões anteriores, o desenvolvimento do R/3 esteve muito mais voltado para a melhoria das funcionalidades e
aplicabilidades do sistema. Na versão 4.6, toda a interface com o usuário foi otimizada visando minimizar erros, reduzir tempos
de treinamentos e tornar o sistema mais amigável. Para este trabalho for criado o projeto Enjoy SAP que reuniu, através de
concurso, uma série de sugestões de melhorias sugeridas pelos próprios usuarios do R/3.
Change & Transport System (BC-CTS)
Transferências de componentes do R/3 de um sistema para outro. Os componentes a serem transportados são especificados em
uma lista de objeots de uma ordem (solicitação) de transporte (transport request). Cada transporte consistem de um processo de
exportação e um processo de importação. O porcesso de exportação lê os objeots do sistema de origem e armazena em um
arquivo no sistema operacional. O processo de importação lê os objetos do arquivo gerado e grava no banco de dados do
sistema de origem. O sistema mantém um log de todas as ações durante a exportação e a importação.
Um ordem de transporte (request) é um documento paracopiar correções entre diferentes tipos de sistema. Uma ordem de
transporte contém as correções de release. Quando uma request é liberada, o transporte é executado. Por exemplo, podem ser
transportadas correções de um sistema integrado para um sistema de consolidação.
Transport Organizer
Ferramenta que prepara e administra os transportes. Estes transporte correspodem ao final do processo de distribuição de
trabalhos de desenvolvimento no grupo de sistema que iniciou com o Transport Organizer.
Um grupo de sistemas engloba todos os sistemas R/3 conectados por uma rota de transporte. Um grupo de sistemas (unidade
lógica) pode incluir para grupos de transportes (unidades técnicas) ou domínios de transportes (unidades administrativas).
Um domínio de transporte agrupa sistemas com as mesmas configurações no CTS. Todos os sistemas R/3 são gerenciados em
conjunto pelo TMS (Sistema de Gerenciamento de Transporte).