Academia CO

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


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


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


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


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


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


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


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


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.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.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.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.7 Objeto: CO_COSTCTR - dados gerais de centros de custos .............................................................................. 274 32.9.7.1 Banco de dados lógico: CRK......................................................................................................................................... 274



32.10 OBJETO: CO_ALLO_ST - ALOCAÇÕES ESTORNADAS ............................................................................................. 277


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.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.3 Objeto: CO_ML_IDX - Docs.entrs.índice p/o material: ledger de material ...................................................... 285 32.13.3.1 Tabelas Envolvidas ........................................................................................................................................................ 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



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.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


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


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).


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.


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


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.


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.


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


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).


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.


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


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.


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.


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.


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;


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


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


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.


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


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.


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


Fornecimento – aumenta o valor de remessas em curso; aumenta o valor do docuemento de faturamento pendente



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


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:


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.


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.


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.


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.


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.


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.


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.


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


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.

SAPEVENT:DOCU_LINK/DS:SIMG.OHIX0003



SAPEVENT:DOCU_LINK/DS:SIMG.CATS0502


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"


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


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).


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.


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:


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


É 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)


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


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.


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,


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.


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


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.


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).


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


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.


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.


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)


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


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..


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,


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.


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


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.


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


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á


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.


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:


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. (*)



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.


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


Á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.




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:


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


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.


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


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.


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.


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


E 03 – Controlling de estoques


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.


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.


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.

sapevent:DOCU_LINK/DS:SIMG.OLIS_MCU


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.


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.


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:


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

sapevent:DOCU_LINK/DS:SIMG.SIMG_CFMENUOLMCAPP1


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).


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.

sapevent:DOCU_LINK/DS:SIMG.SIMG_CMMENUOLMCFORM

sapevent:DOCU_LINK/DS:SIMG.SIMG_CMMENUOLMCBED

sapevent:DOCU_LINK/DS:SIMG.SIMG_CFMENUOLMCOMOG


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.


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



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.


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


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.


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.


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.


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:


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


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


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.


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


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)


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.


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.


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)


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.


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


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).


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.


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.


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


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 predefinida.

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


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'.


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'.


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.


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.


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.


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:


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.

.


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.


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


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.


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.


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.


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 (*).


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


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..


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


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


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


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


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.


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


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:


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.


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


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


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.



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


21.4.4.1.1 Pasta Cabeçalho do Segmento


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%.



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.


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


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:


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


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



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.



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.


Moeda Definir o código da moeda na qual os

montantes fixos serão definidos.



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.



tarifas fixas serão definidas.

Ordem/Centro de

Custo.... Tarifa


todos os emissores selecionados pelos



informadas as tarifas fixas de cada

emissor na moeda informada na

campo anterior.

Antes de entrar


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.



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






Ordem/Centro de

Custo.... Montante


todos os receptores selecionados pelos



informados os montantes fixos de cada

receptor na moeda informada na

campo anterior.

Antes de entrar


definir os

receptores.




Ordem/Centro de

Custo....

Quota/percent


todos os receptores selecionados pelos



informados os percentuais ou as

quotas fixos de cada receptor na

moeda informada na campo anterior.

Antes de entrar


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.


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.


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).


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.


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,


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.


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.


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)


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


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.


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


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).


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. (*)



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.


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.



Á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.




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


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


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


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.




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


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:


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


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).


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.




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.


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


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


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


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


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


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




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


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


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


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.

00000126.chm::/AE78C539C54C11D1A68C0000E83235D4/content.htm

/8AA5A9A54ADC11D189740000E8322D00/content.htm


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.


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;


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.)


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


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


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.


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.

sapevent:DOCU_LINK/DS:SIMG.SIMG_PP3ORKKOKG1

sapevent:DOCU_LINK/DS:SIMG.SIMG_PP3ORKKOKG9

sapevent:DOCU_LINK/DS:SIMG.SIMG_CFMENUORKKOSP3


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.


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.


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:


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 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


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.



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.


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.


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.


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


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.

sapevent:DOCU_LINK/DS:SIMG.SIMG_ORKKBEWWIPPER


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

sapevent:DOCU_LINK/DS:RELN.40C_CO_PC_MISCHABWEI

/0851457E43B511D182B30000E829FBFE/content.htm


(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


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 é


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

sapevent:DOCU_LINK/DS:RE.RMMMPERI

sapevent:DOCU_LINK/DS:SIMG.SIMG_CFMENUOLMSOMSY

sapevent:DOCU_LINK/DS:SIMG.SIMG_CFMENUOLMSOMSY


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


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.


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.


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.


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.


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.).


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.


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


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


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)


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


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.


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


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


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


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.


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.


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????????


É 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.


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


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;


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.


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.


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

sapevent:DOCU_LINK/DS:SIMG.SIMG_CFMENUORK10KE4



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



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.


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


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.

sapevent:DOCU_LINK/DS:SIMG.SIMG_WF0900

sapevent:DOCU_LINK/DS:SIMG.SIMG_WF0900


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.


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.


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

/CC36428394F311D2B47A006094B9B0A5/content.htm


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.

/EB1376C143C411D1896F0000E8322D00/content.htm

/EB13769A43C411D1896F0000E8322D00/content.htm

/73EB2211626D11D2B445006094B9B0A5/content.htm




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.




/EB13770243C411D1896F0000E8322D00/content.htm

/EB13719E43C411D1896F0000E8322D00/content.htm



/EB1371AB43C411D1896F0000E8322D00/content.htm


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


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


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


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


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



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


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).


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).


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


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


Contabilidade de Centros de Custos Comparação Planejado/Real S_ALR_87013611 –


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).



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.


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


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).


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 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.


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 de objeto por ordem Encerramento de período Funções Individuais Desvio

KKS1 – Processamento coletivo.

Parâmetros Com ordens de produção


Transação para

coletores


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


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.


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


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


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.


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


Apropriação de Custos KO88 – Processamento Individual

Ordens


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 -


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


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


Centro de custo/Tipo de atividade

Dados mestre 2

Tipos de atividade

Tipos de atividade (dados mestre)


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:


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.


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;


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.


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


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.


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%


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~7 INDEX PSAPBTABI 901.136

Total 11.943.296

GLPCP TABLE PSAPBTABD 10.256

GLPCP~0 INDEX PSAPBTABI 2.576





Total 23.136

GLPCT TABLE PSAPBTABD 30.736

GLPCT~0 INDEX PSAPBTABI 10.256



Total 51.264

32.4.2 CO_ML_BEL – Documentos ledger de material (MLHD/IT/PP/PPF/CR/CRF/CRP)

CO_ML_BEL


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


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



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


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


CO_ORDER


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


CO_ORDER


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


AABLG TABLE PSAPCLUD 765.480

AABLG~0 INDEX PSAPCLUI 42.256

Total 807.736



AFKO TABLE PSAPBTABD 412.296

AFKO~0 INDEX PSAPBTABI 21.776







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




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



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~2 INDEX PSAPBTABI 719.376


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



Total 12.864

BPEJ TABLE PSAPBTABD 7.696

BPEJ~0 INDEX PSAPBTABI 2.576



Total 15.424

BPGE TABLE PSAPBTABD 2.576

BPGE~0 INDEX PSAPBTABI 1.936



Total 7.104

BPHI TABLE PSAPBTABD 656

BPHI~0 INDEX PSAPBTABI 336



Total 1.664

BPIG TABLE PSAPBTABD 16

BPIG~0 INDEX PSAPBTABI 16



Total 64

BPIJ TABLE PSAPBTABD 656

BPIJ~0 INDEX PSAPBTABI 336



Total 1.664



BPJA TABLE PSAPBTABD 2.576

BPJA~0 INDEX PSAPBTABI 2.576




Total 10.320

BPTR TABLE PSAPBTABD 2.576

BPTR~0 INDEX PSAPBTABI 1.296



Total 6.464

CABN TABLE PSAPSTABD 3.280

CABN~0 INDEX PSAPSTABI 600








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



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





Total 23.352.496

COEPB TABLE PSAPBTABD 326.600

COEPB~0 INDEX PSAPBTABI 96.680

COEPB~1 INDEX PSAPBTABI 119.160



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



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~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



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~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





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



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




COSP Objeto CO: totais de custos - lançamentos externos 3.521.573 2.357.824






AABLG Cluster for Settlement Document 1.059.280 807.736




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



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


COBRA Norma de apropriação para apropriação da ordem 491.051 92.544


CO_KSTRG


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


COEPD Objeto CO: liquidação não avaliada de part.indiv.com status 61.727 14.808







COKL Objeto CO: dados de controle - tipo de atividade 2.661 3.232



CKPE Hierarquia obj.custo CO-PC: objetos individuais 0 80

CKPH Registro mestre nº identificação objeto de custo 0 48


EBII Fluxo de documentos CO/SD: parte faturada das parts.despesas 0 48


CKPHT Textos para CKPH 0 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


CKPE TABLE PSAPSTABD 16

CKPE~0 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



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



CDCLS Cluster structure for change documents 10.651.014 4.384.368


COSP Objeto CO: totais de custos - lançamentos externos 3.5213573 2.357.824


CDHDR Cabeçalho do documento de modificação 10.685.780 1.943.176








CKIT extos p/CKIS 2.708.683 492.872





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


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






BPBK Cabeçalho de doc. Obj.controlling 5.042 3.232

COKL Objeto CO: dados de controle - tipo de atividade 2.661 3.232


CO_COSTCTR


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


ONRKL Índice de nº de objeto centro de custo/tipo de atividade 773 272


BPPE Reg.de totais para valores periódicos Obj.controlling 0 80

BPEP Partidas individ.valores periódicos Obj.controlling 0 64




Total 47.169.434


BPEP TABLE PSAPBTABD 16

BPEP~0 INDEX PSAPBTABI 16



Total 64

BPPE TABLE PSAPBTABD 16

BPPE~0 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



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


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


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


COPA2_MANN


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


CE1MANN TABLE PSAPBTABD 573.456

CE1MANN~0 INDEX PSAPBTABI 120.336



Total 816.704

CE2MANN TABLE PSAPBTABD 16

CE2MANN~0 INDEX PSAPBTABI 16



Total 64




Total 179.248

CEALE01 TABLE PSAPPOOLD 16

CEALE01~0 INDEX PSAPPOOLI 16

CEALE01~1 INDEX PSAPPOOLI 16

Total 48




Total 69.200

32.4.8 CO_CCTR_ID – Centro de custo – dados reais

CO_CCTR_ID


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


CO_CCTR_ID


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


CKHS Cabeçalho - cálculo de custo unitário (controle + totais)

CKHT Textos p/CKHS


CKIS Itens cálc.custo unitário/especificaç.item custeio-produto

CKIT Textos p/CKIS


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.





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


BPBK Cabeçalho de doc. Obj.controlling

BPEJ Parts.indiv. Valores anuais Obj.controlling

BPEP Partidas individ.valores periódicos Obj.controlling






CO_CCTR_EP


COEJT Objeto CO: partidas individuais de tarifas referentes ao ano


COEPB Objeto CO: partidas individ.desvio/determ.result.por período



COEPT Objeto CO: partidas individuais de tarifas refer.ao período

32.4.11 CO_ITEM – Partidas individuais de CO

CO_ITEM










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







T811D Nºs documentos de alocação 901 304

Total 26.314.616


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:


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.


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)


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.


Á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


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)


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).


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


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


CKIS Itens cálc.custo unitário/especificaç.item custeio-produto

CKIT Textos p/CKIS

COANZ Índice de objetos com (solicitações)adiantamentos


COBRA Norma de apropriação para apropriação da ordem

COBRB Regras de repartição de normas de apropriação (apropr.ordem)







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



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



COSPD Objeto CO: totais custos externos - dos quais apropriados



COSSD Objeto CO: totais custos internos - destes foram apropriados


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



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.



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).


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



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










eliminação.



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).


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


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.



Exercício (Ano fiscal)

Grupo de Centro de Custos (opcional)

Controle do Processo Execução de teste

Arquivar

Arquivar e Eliminar









eliminação.




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.


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.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.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


Banco de dados CEK


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





Período (opcional)

Versão (opcional)

Categoria de Valor (real, palnejado, teórico, etc.)

Grupo de Centro de Custos (opcional)


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.


33.9.5.1 Banco de Dados lógico: CIK

Banco de Dados CIK


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





Grupo de Centro de Custos


Arquivar

Arquivar e Eliminar


O programa de leitura do CO_CCTR_ID (RKSARCS1) apenas relaciona as partidas individuais para cada um dos centros de


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


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



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.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.6.COKR1 Dados Controle indices estatítiscos COKR KS



1.7.COSR1 Reg.Totais - índices estatísticos COSR 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.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



Banco de dados CPK - dados planejados



1.8.6.COKL2 Dados Controle tipo atividade COKL KL







1.8.9.COKR2 Dados Controle indices estatítiscos COKR KL









Versão



Arquivar

Arquivar e Eliminar




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



1.1.CSKT Textos de centros de custos CSKT

1.2.CDHDR Cabeçalho Documento Modificação CDHDR




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.3.COVO1 Par.Ind. comprimisso (s/cabec.doc) COOI KS

1.9.COKS1 Dados Controle planej. secundário COKS KS



1.10. COSS1 Reg.Totais - lançamentos internos COSS KS



1.11. COKR1 Dados Controle indices estatítiscos COKR KS



1.12. COSR1 Reg.Totais - índices estatísticos COSR KS

1.12.1.COVPR1 Part.Ind. - índices estatísticos - per. COEPR 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




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.4.COKS2 Dados Controle plano secundário COKS KL






1.14.6.COKR2 Dados Controle indices estatítiscos COKR KL




1.14.7.1.COVPR2 Part.Ind. índices estatísticos - per. COEPR KL


1.14.8.COKL2 Dados Controle tipo atividade COKL KL




1.14.9.1.COVPL2 Part.Ind. tipos atividade por período COEPL 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.1.COVPT2 Part.Ind. tarifas refer.ao per. COEPT KL









Arquivar

Arquivar e Eliminar




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


Tabela T811D


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



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






PERBL NUMC N 3 Bloco de períodos





WTG001 CURR P 8 2 Valor total em moeda de transação





Tabela COVPL1






Tabela COVPL1







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






PERBL NUMC N 3 Bloco de períodos





MEINH UNIT C 3 Unidade de Atividade

LST001 QUAN P 8 3 Volume de atividade




33.10.2 Critérios de Seleção




Ciclo


Arquivar

Arquivar e Eliminar

Controle de Processo: Existem três alternativas possíveis para o controle de processo.









eliminação.



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.



Tabela Descrição

COBK Cabeçalho de Documentos


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





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


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


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


Tabela Descrição

CKMLCR Ledger de material: Regs.totais do período - valores

CKMLPP Ledger de material: Regs.totais do período - quantidades


33.13.1.2 Critérios de Seleção

Critério de Seleção De Ate


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


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



O SAP disponibiliza o programa SAPRCKMX para recuperação dos dados. Este objeto permite também a recarga dos dados

arquivados.


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.


Critério de Seleção

Período ?

Exercício (Ano fiscal) ?

Gerar Arquivo


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


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.


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.


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




Período

Planejado ou Real

Versão

Tipo de Operação

Gerar Arquivo


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


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.


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.


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



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


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



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



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



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ç.)


34.1.1.1 Critério de seleção


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.



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


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.


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


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


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


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)


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.


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.

SAPEVENT:DOCU_LINK/DS:TX.DDDOC_KEYKIND


É 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.


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.


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.


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


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


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


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


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


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


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


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.)


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


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


37.5.2 Categorias de desvio/determ.resultados da tabela COSB

Tabela COSB


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



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



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)



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


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


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:


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


Nota 200513 - Considerações sobre deleção da tabela COBK - Cabeçalho de documentos de CO.

Version 0002 from 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


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


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:


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)


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


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


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


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.


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:


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).