Academia CO

CONTROLADORIA 1 de 325

164

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 TOO L 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 ............................................................................................................ 49 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 ............................................................................................................................................................ 50 12.8 CONCEITOS GERAIS DE CO ............................................................................................................................................ 50 12.9 COMPONENTES DO R/3 .................................................................................................................................................. 52

12.9.1 FI – Contabilidade Financeira (Financial Accounting) ....................................................................................... 52 12.9.2 TR – Tesouraria (Treasury) .................................................................................................................................. 52 12.9.3 CO – Controlling .................................................................................................................................................. 53 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) ....................................................................................................................... 55 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) ......................................................................... 56 14.2 CONTABILIDADE DE OBJETOS DE CUSTO (COST OBJECT CONTROLLING) ...................................................................... 56

14.2.1 Controlling de Objeto por ordem (Product cost controlling by order) ................................................................. 57 14.2.2 Controlling periódico de objeto (Product cost controlling by period) ................................................................. 58 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) .................................................................................... 60 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 ............................................................... 61

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 ...................................................................................................... 63 16.4 CONCILIAÇÃO DE CO COM FI ........................................................................................................................................ 63 16.5 TRANSFERÊNCIA DE VALORES NO PLANEJAMENTO DE CENTROS CUSTOS / ORDENS INTERNAS ..................................... 64

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

17.1 VISÃO GERAL ................................................................................................................................................................ 68 17.2 REPORT WRITER/ REPORT PAINTER............................................................................................................................... 68

17.2.1 Criar relatório ...................................................................................................................................................... 69 17.3 GRUPO DE RELATÓRIOS ................................................................................................................................................. 69 17.4 ABAP LIST VIEWER (ALV) .......................................................................................................................................... 70 17.5 CONFIGURAÇÕES DO USUÁRIO / GERENCIAMENTO DE EXTRATOS ................................................................................. 70 17.6 RELATÓRIOS DRILLDOWN ............................................................................................................................................. 71 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 ............................................................................................................................................ 90 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) ..................................................................................................................... 94

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 ANALYSI S) ............................................................. 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.2 Critérios de seleção ................................................................................................................................................................ 266 32.8.2.3 Tempos de retenção ................................................................................................................................................................ 267

32.8.3 Recuperação de dados ........................................................................................................................................ 267 32.9 OBJETOS DE ARQUIVAMENTO DE CENTROS DE CUSTOS .............................................................................................. 267

32.9.1 Tabelas envolvidas .............................................................................................................................................. 268 32.9.2 Critérios de seleção ............................................................................................................................................ 269 32.9.3 Recuperação de dados ........................................................................................................................................ 269 32.9.4 Objeto: CO_CCTR_EP - partidas individuais de centros de custos ................................................................... 270

32.9.4.1 Banco de Dados lógico: CEK (transação OKEM) ............................................................................................................... 270 32.9.4.2 Critérios de seleção ................................................................................................................................................................ 271 32.9.4.3 Recuperação dos dados .......................................................................................................................................................... 271

32.9.5 Objeto: CO_CCTR_ID - dados reais de centros de custos ................................................................................. 271 32.9.5.1 Banco de Dados lógico: CIK ................................................................................................................................................. 272 32.9.5.2 Critérios de seleção ................................................................................................................................................................ 272 32.9.5.3 Recuperação dos dados .......................................................................................................................................................... 272

32.9.6 Objeto: CO_CCTR_PL - dados planejados de centros de custos ....................................................................... 272 32.9.6.1 Banco de dados lógico: CPK ................................................................................................................................................. 273 32.9.6.2 Critérios de seleção ................................................................................................................................................................ 274 32.9.6.3 Recuperação dos dados .......................................................................................................................................................... 274

32.9.7 Objeto: CO_COSTCTR - dados gerais de centros de custos .............................................................................. 274 32.9.7.1 Banco de dados lógico: CRK ................................................................................................................................................. 274 32.9.7.2 Critérios de seleção ................................................................................................................................................................ 277 32.9.7.3 Recuperação dos dados .......................................................................................................................................................... 277

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


32.10.1 Banco de dados lógico SAK ................................................................................................................................ 277 32.10.2 Critérios de Seleção ............................................................................................................................................ 279 32.10.3 Recuperação dos dados ...................................................................................................................................... 280

32.11 OBJETOS: CO_ITEM - PARTIDAS INDIVIDUAIS DE CO ............................................................................................. 280 32.11.1 Dependências ...................................................................................................................................................... 280 32.11.2 Tabelas envolvidas .............................................................................................................................................. 281 32.11.3 Preparação para o arquivamento ....................................................................................................................... 281

32.11.3.1 Critérios de seleção ................................................................................................................................................................ 282 32.12 CUSTO DE PRODUTOS .............................................................................................................................................. 282

32.12.1 Objeto: CO_COPC - Estimativa de custos de produto ....................................................................................... 282 32.12.2 Objeto: CO_KSTRG - Objetos de custo .............................................................................................................. 283 32.12.3 Objeto: CO_BASEOBJ - Componente ................................................................................................................ 283

32.13 OBJETOS DE ARQUIVAMENTO DO LEDGER DE MATERIAIS ....................................................................................... 283 32.13.1 Objeto CO_ML_DAT .......................................................................................................................................... 283

32.13.1.1 Tabelas envolvidas ................................................................................................................................................................. 283 32.13.1.2 Critérios de Seleção ................................................................................................................................................................ 284 32.13.1.3 Recuperação de dados ............................................................................................................................................................ 284

32.13.2 Objeto CO_ML_BEL .......................................................................................................................................... 284 32.13.2.1 Tabelas envolvidas ................................................................................................................................................................. 284 32.13.2.2 Critérios de Seleção ................................................................................................................................................................ 284 32.13.2.3 Recuperação de dados ............................................................................................................................................................ 284

32.13.3 Objeto: CO_ML_IDX - Docs.entrs.índice p/o material: ledger de material ...................................................... 285 32.13.3.1 Tabelas Envolvidas................................................................................................................................................................. 285 32.13.3.2 Critérios de seleção ................................................................................................................................................................ 285 32.13.3.3 Recuperação de dados ............................................................................................................................................................ 285

32.14 OBEJTOS DE ARQUIVAMENTO DE CLASSES DE CUSTO .............................................................................................. 285 32.14.1 Objeto: CO_CEL_RCL - Ledger de Reconciliação ............................................................................................ 285

32.15 OBJETOS DE ARQUIVAMENTO DE CENTROS DE LUCRO ............................................................................................ 286 32.15.1 Objeto: PCA_OBJECT - Centro de Lucro .......................................................................................................... 286

32.16 OBJETOS DE ARQUIVAMENTO DE COPA .................................................................................................................. 286 32.16.1 Objeto: COPA1_XXXX - Demonstração de Resultados baseado em custos....................................................... 286

32.16.1.1 Tabelas envolvidas ................................................................................................................................................................. 286 32.16.1.2 Critérios de seleção ................................................................................................................................................................ 286 32.16.1.3 Recuperação dos dados .......................................................................................................................................................... 287

33 ARQUIVAMENTO DE PP: PRODUÇÃO ................................................................................................................. 287

33.1 OBJETO: PP_ORDER - ORDEM DE PRODUÇÃO ........................................................................................................... 287 33.1.1 Tabelas envolvidas .............................................................................................................................................. 287

33.1.1.1 Critério de seleção .................................................................................................................................................................. 291 33.1.2 Tempos de Retenção ........................................................................................................................................... 291 33.1.3 Recuperação de dados ........................................................................................................................................ 292

33.1.3.1 Perfil para sistema de apropriação de ordens ....................................................................................................................... 292 33.1.3.2 Definir variantes de síntese para síntese de objetos ............................................................................................................. 293 33.1.3.3 Perfis para lista de efetuação do picking ............................................................................................................................... 293

34 ARQUIVAMENTO DE SD - VENDAS E DISTRIBUIÇÃO ..... ............................................................................... 293

34.1 OBJETO SD_VBAK - DOCUMENTOS DE VENDAS ........................................................................................................ 294 34.1.1 Tabelas envolvidas .............................................................................................................................................. 294 34.1.2 Funções e relatórios disponíveis......................................................................................................................... 296 34.1.3 Objetos de autorização necessários .................................................................................................................... 296 34.1.4 Dependências ...................................................................................................................................................... 297 34.1.5 Recuperação de Dados de Custos ....................................................................................................................... 297

35 TABELAS DO BANCO DE DADOS .......................................................................................................................... 297

35.1 CATEGORIA DE UMA TABELA OU ESTRUTURA .............................................................................................................. 297 35.1.1 Tabela Transparente ........................................................................................................................................... 297 35.1.2 Estrutura ............................................................................................................................................................. 298 35.1.3 Categoria de tabela ............................................................................................................................................ 298 35.1.4 Estrutura Append ................................................................................................................................................ 298 35.1.5 Tabela Pool ......................................................................................................................................................... 299 35.1.6 Tabela Cluster..................................................................................................................................................... 299


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 Get) que permite configurar o front-end individualmente para cada usuário personalizando 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 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 cadastros 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 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(Auto m.queue syncronous processing)

2.1.4.6 Exibição de performance (Performance displa y)

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 anali sys)

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 too l 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 – MATERIAL 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 mais 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 nenhum 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 Struct ure)

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 dois centros com o mesmo CGC e um 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, um 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-s pecific 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 Accounti ng)

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 Contr ol 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 Bus iness 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 – Fi nancial 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 (Cont rollling 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 as 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 às 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á igual à moeda da empresa.

Todas as transações de apropriação de custos internos 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 do 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 efetuar a atribuição, é 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 devem ser o mesmo no que se 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 a Área da Contabilidade de Custos com a Área de Administração Financeira, primeiro, é preciso atribuir as empresas 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 desempenho 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) no qual o sistema irá armazenar os dados já que serão criados um grupo distinto de tabelas para cada uma das Áreas de Resultado definidas. O sistema automaticamente gera outros objetos relacionados 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ócio vinculado à 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 Distributio n)

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 Channe l)

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

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 Organiz ation)

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 (Main tenance 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 Su b-Areas)

11.2.9.3 Grupo de Empregados (Employee Groups)

11.2.9.4 Sub-Grupo de Empregados (Employee Sub-Grou ps)

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 Sys tem)

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.


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 Administr açã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 (Gera l) 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


COMPONENTES DE CO

Pergunta Componente

As áreas onde os custos indiretos ocorrem estão trabalhando eficientemente?

Cost Center Accounting

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

Quais custos ocorrem dentro da organização? CR-EA (Custos e Receitas - Elementos de custo)

Como manter os custos indiretos sobre controle? OM

As áreas onde os custos indiretos ocorrem estão trabalhando eficientemente? CCA – contabilidade de centro de custo

Quão alto estão os custos das atividades da empresa? Estão seguindo o orçamento? OO

Como associar custos indiretos considerando fontes reais de custos e como otimizar processos internos? ABC custeio baseado na atividade

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 visualizar melhor as variações no custo em função de quantidade e de preço também a nível de matéria-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: Ordens 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 Acc ounting)

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 deteriminar 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 Con trolling)

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 (Inves tment 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 Sta te 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 & Reven ue 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 um 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 C osting)

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 nenhum 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 Co ntrolling)

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 dos 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 produto para estoque, automaticamente 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. Os 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 partir da 4.5.

Existem três diferentes formas para apuração dos custos: Por Ordem, 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 cos t 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 cos t 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 no nível de produto (um coletor por material) ou no 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 periódico 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 co st 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 uma 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 (A ctual Costing / Material Ledger)

Este 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édio 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 estraté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. Em 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 pelos 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. Existem 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 do 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 num 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á os valores das despesas estão nos centros de custos e serão alocados aos objetos de resultados.

15.2 Demonstração de Resultados (Profitability Anal ysis)

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 na 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, nenhuma distinção é feita em 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 no cadastramento.

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 custos 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 internas 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 máster data). 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 vinculada a um centro 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

No nível de Área de Contabilidade de Custos pode ser definido se 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 entanto, 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 uma 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 uma sociedade integrada sujeita a impostos de vendas. Se necessário, definir regras lógicas para os lançamentos 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 information system, pode ser verificado os saldos contábeis entre CO e FI para um período particular usando relatórios de conciliação. Nestes 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çamentos 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 diferentes 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, defina suas próprias classes de custos para preços fixos.

16.5 Transferência de valores no planejamento de Ce ntros 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 (em 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 Ex tratos

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.

F Análise de Documentos

Estrutura de informação utilizada para a exibição de dados do documento. Estas estruturas de informação estão sujeitas a várias medidas de performance devido ao volume de dados esperado (por exemplo: planejamento não permitido). Além disso, são possíveis outras funções na análise standard (por exemplo: análise total de documentos). Área de implementação: análise do cesto de compras - IS-R.

T Transferência para SAP-BW

Estrutura de informação especial para a transferência ao Business Information Warehouse (BW) que não pode ser utilizada no reporting. Estas estruturas de informação estão sujeitas a diversas medidas de performance devido ao volume de dados esperado (por exemplo planejamento não permitido).

A utilização dos tipos acima mencionados depende da aplicação nas quais elas devem ser criadas:

Tipo Aplicação todas (standard)

C 01 – SD 03 – Controlling de estoques 40 – Administração de mercadorias

D 03 – Controlling de estoques 40 – Administração de mercadorias

E 03 – Controlling de estoques 40 – Administração de mercadorias

F 40 – Administração de mercadorias

Ao ser criada uma estrutura de informação própria do usuário através do atributo Planejamento possível , decidir se esta é relevante para o planejamento SIL ou não. Um estrutura de informação do tipo 'C' ou do tipo 'F' não pode ser marcada como relevante para o planejamento.

É importante considerar, porém, se a estrutura de informação a ser criada deve ser utilizada no planejamento, pois uma estrutura de informação que não pode ser incluída no planejamento aumenta consideravelmente a velocidade da análise no momento do reporting. No caso de uma estrutura de informação não relevante para o planejamento, ocorre na tabela uma conversão dos campos de chave atuais, de modo que os campos não relevantes (SSOUR, campos de período não necessários) sejam posicionados ao final dos campos de chave.

Isto agiliza a procura no banco de dados. Se a estrutura de dados definida pelo usuário deve ser preenchida com dados, o índice primário verifica a respectiva chave de tabela. A versão 000 é sempre utilizada como critério de procura. O mandante é sempre a primeira posição na chave de tabela; caso contrário, toda tabela no ABAP Dictionary será interpretada como independente do mandante. As características são diretamente posicionadas na chave de tabela após os mandantes.

As seções da chave de tabela apresentam-se da seguinte maneira:


Mandante - Característica - Versão - ...

Ao ativar a atualização, a chave de tabela é novamente convertida, de modo que o período selecionado para a atualização apareça primeiro.

Exemplo:

Mandante - Mês - Características - Versão - ...

A fim de evitar uma perda acidental dos dados, a conversão dos campos de chave de uma estrutura de informação não relevante para o planejamento só deve ocorrer se a respectiva tabela do banco de dados não contiver nenhum dado. Observar o seguinte:

• Uma estrutura de informação relevante para o planejamento só pode ser definida e atualizada com um período (dia, semana, mês ou período contábil) em todos os mandantes de um sistema.

• A modificação do período leva a uma conversão dos campos de chave e só pode ser executada se nenhum dos clientes não possuírem mais dados na tabela do banco de dados.

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.

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

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 da s 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 Gr upo 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

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.

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 Stat us)

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

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

PlanejamentoEstratégico

SOP

MPS

Análise derecursos críticos

Análise da cargabruta

MRP

CRP

Programaçãoe Controle de

Fábrica

Programaçãoe Controle de

Compras

• Contabilização• Custeio• Fluxo de Caixa Previsto X

realizado

NÍVELESTRATÉGICO

NÍVELTÁTICO

NÍVELOPERACIONAL

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

Uma 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-int egrated 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 da 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 restringindo 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 avali açã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 p reç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ços é 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, um 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' . Para este tipo de condição não é necessária nenhuma seqüência de acesso.

H

Preço Interno avaliação de Centro de Lucro Semelhante a anterior só que aqui, como montante base utiliza-se a avaliação de centro de lucro do ledger de materiais. Por motivos técnicos, estes tipos de condição têm de ser criados com a categoria de condição 'H' , regra de cálculo 'C' e classe de condição 'B' . Para este tipo de condição não é necessária nenhuma seqüência de acesso.

As seguintes categorias de condição apenas são aplicáveis para condições básicas da perspectiva legal:

Categoria Utilização

G

Preço Interno – (de acordo com o controle de preços) Tipos de condição, nos quais o preço-padrão (controle de preço 'S' ) ou preço médio móvel (controle de preço 'V' ) são determinados a partir do mestre de materiais de acordo com o controle de preço. Para este tipo de condição não é necessária nenhuma seqüência de acesso.

S

Preço interno – Standard tipos de condição, nos quais o preço-padrão é determinado a partir do mestre de materiais independentemente do controle de preço. Para este tipo de condição não é necessária nenhuma seqüência de acesso.

T

Preço interno - Média móvel Tipos de condição, nos quais o preço médio móvel é determinado a partir do mestre de materiais independentemente do controle de preço. Para este tipo de condição não é necessária nenhuma seqüência de acesso.

b) Regra de cálculo – A regra de cálculo determina o modo como o sistema calcula preços e sobretaxas ou deduções para um tipo de condição. Este cálculo pode ser efetuado na contabilidade de centros de lucro de forma percentual (Regra de cálculo A), quantidade (C) ou montante fixo (B).

c) Classe de condição – A classe de condição determina se o tipo de condição será usado para o cálculo de um acréscimo (sobretaxas) e deduções (A) ou preços (B).

d) Fator de referência – O fator de referência determina o modo como o sistema interpreta a escala de um tipo de condição podendo ser uma escala de valores (B ) ou de quantidade (C) ou além da configuração global (' ').

e) sinal +/- - determina se o valor deve ser positivo (acréscimo) ou negativo (deduções).

f) verificação escala –controla se os montantes escalonados que devem ser indicados de forma crescente ou decrescente.

g) regra de arredondamento Regra segundo a qual o sistema arredonda o valor de condição durante a determinação do preço. Neste caso, o último dígito será arredondado. As opções padrões disponíveis são Comercial (acima de 5 arredonda para cima e abaixo de 5 arrendonda para baixo), Arrrendondamente sempre para cima ou sempre para baixo.

h) conversão de moeda O campo controla a conversão de moedas se a moeda de condição divergir da moeda do documento. O sistema multiplica o montante proveniente do registro de condição pela quantidade do item para calcular o valor da condição de um documento. Este código controla se o sistema efetua a conversão de moedas antes ou depois da multiplicação. Se o usuário marcar este campo, o sistema converterá o valor da condição para a moeda do documento depois da multiplicação. Se este campo não for preenchido, o sistema converterá o valor da condição para moeda do documento antes da multiplicação.

Sistemas standard – Como standard são fornecidos vários tipos de condição, que podem ser utilizados também para a definição de esquemas de cálculo. Normalmente os requisitos de uma determinação do preço interno podem ser satisfeitos mediante os sistemas standard.

Mediante clique duplo na área de tela superior esquerda as opções para cada tipo de condição são exibidas na área direita da tela. Mediante saltar -> vista detalhada é possível visualizar os respectivos dados de controle e opções adicionais.

São fornecidos os seguintes tipos de condição:


Tipo DESCRIÇÃO CATEG

ORIA REGRA

CLASSE

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 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 é dependente 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 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 estará 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 no nível de centro de custo/ classe de custo. Se nehuma unidade for informada, no primeiro planejamento, poderá ser 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. Estes materiais podem ser armazenadas individualmente em CO, mas não em nível de classe de custo. Neste caso, a unidade do material será usada no custeio.

Ainda pode ser informado valores padrões 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 classe 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 no 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 reduz 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ório de todos os centros de custo da Controlling 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 categorias dos Centros de Custos 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 no 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 no 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 todss 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 entanto, 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 tempo, defina selection variant que somente irá conter 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 que estarã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 são 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 a 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 em 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 planejados 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, como 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. Somente é possível alterar categorias de atividades não-alocáveis ou categorias de alocação (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 baseado na quantidade e 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 figure s)

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 índices estatísticos podem ser fixos (categoria 01) ou totais (categoria 02). Um índice fixo, significa que seu valor é constante ao 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 recurso para uma 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 um 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 uma 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 (R eposting 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 (Reposti ng 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 Activ ity 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 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 o custo total ou somente a parte variável. Se os emissores e os receptores participam da pre-distribuição e foram feitos lançamentos reais ou estatísticos para o receptor, o sistema irá calcular somente os custos variáveis. 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 (Acti vity 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 (estornar) a alocação.

A transferência 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, pode 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 se 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étodo Iterativo

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


Moeda Definir o código da moeda na qual os tarifas fixas serão definidas.

Ordem/Centro de Custo.... Tarifa

O sistema irá listar, automaticamente, todos os emissores selecionados pelos critérios definidos na pasta Emissor/Receptor para que sejam informadas as tarifas fixas de cada emissor na moeda informada na campo anterior.

Antes de entrar nesta tela é preciso definir os emissor.

21.4.4.1.4 Pasta Base de Refer.Receptora

Da mesma forma que a pasta anterior. Esta tela também irá variar conforme a regra definida para os receptores. Abaixo são apresentadas as telas para partes variáveis, montantes fixos, percentagens ou quotas fixas.



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

O sistema irá listar, automaticamente, todos os receptores selecionados pelos critérios definidos na pasta Emissor/Receptor para que sejam informados os montantes fixos de cada receptor na moeda informada na campo anterior.

Antes de entrar nesta tela é preciso definir os receptores.



Ordem/Centro de Custo.... Quota/percent

O sistema irá listar, automaticamente, todos os receptores selecionados pelos critérios definidos na pasta Emissor/Receptor para que sejam informados os percentuais ou as quotas fixos de cada receptor na moeda informada na campo anterior.

Antes de entrar nesta tela é preciso definir os receptores.

21.4.4.1.5 Pasta Fator ponderação rec.

Esta pasta somente fica disponível se for selecionada o opção de regra de receptor partes variáveis. Nela podem ser atribuídos fatores a serem aplicados às bases de referência encontradas antes do cálculo dos valores a alocar.


21.4.4.2 Transferência Periódica (Periodic Repostin g)

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 os 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 acordo com o percentual determinado usando a alocação de atividade teórico = real. Este valor apurado é atualizado como sendo a quantidade 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 somente os primários. Como serão gravados poucos registros de totais, o rateio tem uma performance melhor que a distribuição e a 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 conter todas 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 A ctivity 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 (Se gment 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 utiliza 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 objeto 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 re avaliaçã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 (Var iances)

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.




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

AlmoxarifadoS: 600 h

ManutençãoS: 450 hE: 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 Figu res)

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 do 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 é 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 c ustos (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.


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. (PROCURAR O QUE É ESSE STATUS NO SPRO)

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. (O QUE SÃO ESSAS DATAS ?) 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: (CRIAR UMA NOVA CHAVE)

• 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. (VER ONDE RELACIONA ESTA CHAVE COM A ORDEM)

• 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 resultad o

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 custo teórico pode ser calculado para coletores, ordems de produção com estutrutra 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.


• 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 res ultado

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 uma hierarquia de objeto de custos, executar a distribuição de custos antes do cálculo do WIP.

Somente as ordens 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 calculada 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 estim ativa 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.


• O roteiro corrente para a versão de produção e a estimativa de custos standard para o material acessam a mesma lista técnica, têm o mesmo tipo e grupo de roteiros mas têm um número de grupo de roteiro diferente e uma estrutura de pontos de contagem também diferentes. Pode ser usado o gerenciamento de erros definidos pelo usuário para garantir que o WIP e o desvio de refugo sejam calculados atingindo valores que podem não estar corretos.

• O roteiro corrente para a versão de produção e a estimativa de custos standard para o material acessam a mesma lista técnica, têm o mesmo tipo e um grupo de roteiros diferentes. Não é possível calcular WIP. Para evitar esta situação e a situação anterior, é recomendado trabalhar com a estimativa de custos preliminar do coletor.

26.6.11 Atualização do WIP

O WIP é atualizado para o coletor ou a ordem de produção em classes de custos secundárias da categoria 31. Estas classes de custos são denominadas classes 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 considerados 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álculo 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 custos 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 custos 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 os desvios 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 reaisRefugo

Material em processoCsts.de controle

Custos teóricos Csts.reais alocados

Desvio total

Desvio de preço de inputDesvio de quant.de input

Desvio de estruturaDesvio residual de input

Desvio preço internoDesvio de preço mistoDesvio 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.


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


(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


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 pr ofiles)

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 definidas 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 recursos 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 importantes 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 a 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 da 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 atividades executadas, este representam oportunidade de simplificação do trabalho e redução do custo. Nesta forma, o objetivo é conseguir que a maior parte dos trabalhos 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 dos 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 Analysi s)

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

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 d e 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álc uo 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 Val ores

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

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 custo s (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 reai s

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



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 dia s 5.000,-

Entrada a 22/02 10.000,-

=> movimento ponderado: 10.000,- * 7 dias / 28 dia s 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.


Empresa

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


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.


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.


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

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

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ístico s

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

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

Índice estatístico

Transação

Controlling→ Contabilidade Centros de Custos → Encerramento do Período → Funções Individuais → Transferências → KVA5 - Índices estatísticos independentes da atividade SIL Lançamentos reais

E

Controlling→ Contabilidade Centros de Custos → Encerramento do Período → Funções Individuais → Transferências → KDA5 - Índices estatísticos dependentes da atividade SIL Lançamentos reais

Índice estatístico


30.4 Alocar os custos de energia elétrica para os c entros 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 mai s 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 ).

Transação Controlling→ Contabilidade de Centros de Custos → Encerramento Período → Funções Individuais → KSII – Determinação de Tarifa

Grupos de Centros Custos

3º PASSO: Transferir o valor da tarifa real calculada para as ordens de manutenção de forma a transferir todos os custos reais dos centros de custos para as ordens zerando o saldo dos centros de custos. Definir uma variante de seleção contendo todas as ordens de manutenção, restauração e reforma para cada unidade fabril.

Neste momento, algum dos centros de custos ainda poderá estar com saldo caso esteja recebendo custos de alguma ordem de manutenção. Neste caso, o saldo será zerado somente após a liquidação das ordens (próximo passo).

Transação Controlling→ Ordens Internas → Encerramento Período → Funções Individuais → Reavaliação de Tarifas reais → KON2 – Processamento Coletivos

Variantes de seleção

4º PASSO: Liquidar as ordens de manutenção para transferir os saldo das ordens para os centros de custos de custos que receberam o serviço prestado. Após este processamento, todos os centros de custos de manutenção e as ordens de manutenção deverão estar com o saldo zerados. O procedimento deverá ser refeito caso ainda haja saldo. O próximo item mostra como verificar o saldo dos centros de custos e das ordens.

Transação Controlling→ Ordens Internas → Encerramento Período → Funções Individuais → Apropriação de Custos → KO8G – Processamento Coletivo

Variantes de Seleção

5º PASSO: Verificar se o saldo das ordens de manutenção estão com os saldos zerados. Neste momento todas as ordens deverão estar com os saldos zerados com exceção das ordens de restauração em aberto. As ordens de restauração são liquidadas para estoque e o seu saldo somente será zerado depois que a ordem estiver encerrada tecnicamente. O próximo passo detalha como retirar o valor referente a estas ordens das contas de despesas de forma a permitir o fechamento do balanço.

Caso alguma ordem de manutenção permaneça com saldo, executar a liquidação individual para verificar melhor a mensagem de erro e definir o procedimento a ser adotado para correção do problema (transação: KO88).

Transação Controlling→ Ordens Internas → Sistema Info → Relatórios para Ordens Internas → Outros Relatórios → KOC4 – Análise de Custos

Categoria de Ordens 30 (com exceção das ordens de restauração)

Consultar período acumulado (janeiro até ano corrente).

Variante de exibição Criar uma variante de exibição que liste apenas as ordens de apresentarem saldo diferente se zero.

6º PASSO: No caso das ordens de restauração, o sistema não calcula WIP porque não são ordens de produção. No entanto, contabilmente o procedimento deveria ser o mesmo. Portanto, o lançamento destes casos deve ser manual. Na implantação, foi sugerido que se trabalhasse de forma que ordens de restauração não passassem em aberto de um mês para outro. Verificar o saldo das ordens de restauração em aberto e Transferir os valores referente a estas ordens das contas de despesas através de uma conta de transferência via lançamento manual em FI.

OBS 1 : As contas de WIP (estoque) e a conta de transferência de WIP normalmente estão configuradas para só aceitar lançamentos automáticos. Antes de efetuar o lançamento, portanto, é preciso desbloquear estas contas e bloqueá-las novamente após o lançamento (transação: FS00 – pasta Entrada/banco/juros).


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.



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



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


Transação Controlling→ Contabilidade de Centros de Custos → Encerramento Período → Funções Individuais → KSII – Determinação de Tarifa

Grupos de Centros Custos

Criar uma variante .CC-PROD que contem os Centros de custos diretos de produção

4º PASSO: Transferir a tarifa real calculada nos centros de custos produtivos para as ordens de produção e coletores de custos. Este processo deve zerar os saldos dos centros de custos de produção direta.

OBS: Por questões de arredondamento, pode sobrar valores residuais (centavos) nos centros de custos. Estes valores precisam ser transferidos via rateio para um conta de resultado. Este procedimento é detalhado posteriormente.

Transação Controlling→ Controlling de Custos de Produtos → Contabilidade de Objetos de Custos → Controlling de objeto por ordem → Encerramento de período → Funções Individuais → Reavaliação de Tarifas reais → CON2 – Processamento Coletivo

5º PASSO: Ratear os saldos residuais dos centros de custos produtivos para uma conta de resultado. Este valores são da ordens de centavos.


Ciclo de Rateio

2º PASSO: Transferir os custos das ordens internas para FI através da liquidação das ordens

Transação Controlling→ Ordens Internas → Encerramento Período → Funções Individuais → Apropriação de Custos → KO88 – Processamento Individual

Ordens

Os lançamentos que serão efetuados em FI estão relacionados abaixo

Ordem Conta crédito Conta débito

200.000 Transferência Resultado

6º PASSO: Verificar se os centros de custos produtivos estão com os saldos zerados. Neste momento todos os centros de custos produtivos (diretos e indiretos) deverão estar com os saldos zerados. Os centros de custos administrativos e comerciais somente terão seus saldos zerados no final do processo em função das alocações para os centros de custos comerciais das amostras.

Transação Controlling→ Contabilidade de Centros Custos → Sistema Info → Relatório para Contabilidade de Centros de Custos → Comparação Planejado/Real→ S_ALR_87013611 - Centros de custo: real/planejado/desvio


Variante: .CC-PROD – Centros de custos de produção direta

30.8 Alocar os custos das ordens de produção para o s 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→ Controlling de Custos de Produtos → Contabilidade de Objetos de Custos → Controlling de objeto por ordem → Encerramento de período → Funções Individuais → Material em processo → Processamento Coletivo → KKAO – Determinar

Parâmetros

Com ordens de produção

Com coletores de custos

Todas as versões de determinação de resultado

Caso ocorram erros no processamento, utilizar as transações para processamento individual (KKAS e KKAX ), para analisar melhor as mensagens de erro.

2º PASSO: O cálculo dos desvios deve ser efetuado após o cálculo do WIP e deve ser feito antes da liquidação quando se desejar transferir os valores dos desvios apurados para CO-PA. O desvio pode ser calculado para coletores de custos, ordens de produção e objetos de custo. O R/3 calcula o desvio do objeto por classe de custo, ou por classe de custo e origem do material. O calculo dos desvios fornecem informações para tomar medidas para melhorias de custos. Os desvios são calculados periodicamente para os coletores e cumulativamente para as ordens de produção.

Pré-requisitos para cálculo dos desvios:

• Estimativa de cálculo de custos teóricos (padrão para as ordens e preliminares para coletores) deve ter Itemização.

• Os componentes do material constantes na lista técnica da estimativa de custos usada para o cálculo dos custos teóricos devem estar atribuídos às operações onde são usadas. Caso contrário, não será possível listar corretamente os desvios e o refugo quando as operações são confirmadas.

• Os objetos para os quais os desvios serão calculados deverão conter uma chaves de desvio válida.

• No custeio por ordem, a ordem deve ter o status de LIB (DLV – liberada) ou ENTE (TABG/TECO – tecnicamente encerrada).

• O flag de origem do material na visão de custo 1 dos mestre de materiais deve estar setado para todos os componentes do material com custo crítico, ou devem ser usados os grupos de origem. Deve forma, é possível determinar quais materiais causaram quais desvios em cada classe de custos. O flag deve estar setado antes da criação da estimativa de custos padrão do material.


OBS: A marcação do flag de origem ou o uso de grupos de origem aumentam o volume de dados e portanto degradam a performance nas rotinas de encerramento mensal. Recomenda-se, portanto, a marcação deste flag somente para os materiais que são relevantes para o custo.

Transação para ordens

Controlling→ Controlling de Custos de Produtos → Contabilidade de Objetos de Custos → Controlling de objeto por ordem → Encerramento de período → Funções Individuais → Desvio → KKS1 – Processamento coletivo.

Parâmetros Com ordens de produção


Transação para coletores

Controlling→ Controlling de Custos de Produtos → Contabilidade de Objetos de Custos → Controlling periódico de produto → Encerramento de período → Funções Individuais: Coletores de Custo de Produto → Desvio → KKS5 – Processamento coletivo.

Parâmetros Com coletores de custo


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


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


30.10 Transferir as despesas administrativas e come rciais 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.


Ciclo de Rateio

2º PASSO: Transferir os custos das ordens internas para FI através da liquidação das ordens

Transação Controlling→ Ordens Internas → Encerramento Período → Funções Individuais → Apropriação de Custos → KO88 – Processamento Individual

Ordens


3º PASSO: Verificar se estas ordens internas e os centros de custos administrativos e comerciais estão com os saldos zerados. Neste momento as ordens de investimento também já deverão estar liquidadas para o ativo. Portanto, nenhuma ordem interna poderá ter custos.

Transação Controlling→ Contabilidade de Centros Custos → Sistema Info → Relatório para Contabilidade de Centros de Custos → Comparação Planejado/Real→ S_ALR_87013611 - Centros de custo: real/planejado/desvio


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

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 (M LHD/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 d ados 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 resultad o 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 planej ados

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

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 C O (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

Atribuinº 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)


Data lançamento (serão arquivados os documentos lançados até esta data).

Controle de Processo • Execução de Teste

• Arquivar


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






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.


Área de Contabilidade de Custos Exercício (Ano fiscal)

Grupo de Centro de Custos (opcional)

Controle do Processo • Execução de teste

• Arquivar







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


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

Tabela Descrição Tab.BD 1. CSKS Registro mestre de centros de custo

1.1. COSP1 RegTotai - lançamentos externos COSP KS

1.1.1. COVP11 Part.Indiv. - p/período e CabeçDoc. COEP KS

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

1.2.1. COVP12 Part. Indiv - p/período e CabeçDoc. COEP KS

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

1.3.1. COVPR1 Part.Indiv.índices estatísticos - per. COEPR KS

1.4. CSSL Centro de custo / tipo de atividade CSSL KL

1.4.1. COSP2 Reg.Totais - lançamentos externos COSP KL

1.4.1.1. COVP21 Part.Indiv. p/ período e CabeçDoc. COEP KL

1.4.2. COSS2 Reg.Totais - lançamentos internos COSS KL

1.4.2.1. COVP22 Part.Indiv. p/ período e CabeçDoc. COEP KL

1.4.3. COSL2 totais de tipos de atividade COSL KL

1.4.3.1. COVPL2 Part. Indiv.tps.atividade por período COEPL KL

1.4.4. COST2 totais de tarifas COST KL

1.4.4.1. COVPT2 partida individual tarifas refer.ao per. COEPT KL

1.4.5. COSR2 totais de índices estatísticos COSR KL

1.4.5.1. COVPR2 partida indiv.índices estatísticos - per. COEPR KL




Grupo de Centro de Custos


• Arquivar



O programa de leitura do CO_CCTR_ID (RKSARCS1) apenas relaciona as partidas individuais para cada um dos centros de custos relacionados. As informações podem ser manipuladas como um relatório normal de centro de custos.

33.9.6 Objeto: CO_CCTR_PL - dados planejados de cen tros 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




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




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


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


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


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




Área de Contabilidade de Custos Período ATÉ (opcional) xxxxxxxxx

Exercício ATÉ (Ano fiscal) xxxxxxxxx

Versão (opcional)

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

Tipo de Objeto

Tipo de Subobjeto


• Arquivar


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

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

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

Exercício (Ano fiscal) Período Número do material Área de avaliação Tipo de avaliação Gerar Arquivo Eliminação em teste

A área de avaliação corresponde ao nível organizacional em que o material está sendo valorizado podendo ser a nível de centro ou a nível de empresa (mesma valorização para todos os centros).

O tipo de avaliação aplica-se nos casos de split valuation. O tipo de avaliação determina quais os tipos de valorização são permitidas para o material. Se, por exemplo, um material é valorizado de acordo com sua origem (tipo B), podem ser definidos os países de origem possível como tipo de valorização.

33.13.1.3 Recuperação de dados

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

33.13.2 Objeto CO_ML_BEL


Tabela Descrição

MLHD Documento do ledger de material: cabeçalho

MLIT Documento do ledger de material: materiais

MLPP Documento do ledger de material: períodos contábeis

MLPPF Documento do ledger de material: grupos de campos (períodos contáb.

MLCR Documento do ledger de material: moedas

MLCRF Documento do ledger de material: grupos de campos (moedas)

MLCRP Documento do ledger de material: modificações de preço (moedas)

33.13.2.2 Critérios de Seleção

Critério de Seleção De Ate

No. documento Ano civil Data do documento Gerar Arquivo Eliminação em teste


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 m aterial: 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 Eliminação em teste

As informações do Ledger de Materiais podem ser eliminados período a período. O sistema irá arquivar todos os períodos anteriores até o período especificado. A única tabela arquivada por este objeto é a tabela CKM1 - Índice do Ledger de Materiais cujos dados estã orelacionados abaixo


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



Exercício (Ano fiscal)

Período

Planejado ou Real

Versão

Tipo de Operação

Gerar Arquivo Eliminação em teste Só partidas individuais

Os parâmetros período/exercício deverão ser usados para definir o tempo de permanência dos dados. Os dados reais podem ser armazenados em separado dos dados planejados, se necessário. A versão é usada somente para os dados reaus. O tipo de operação permite separar os tipos de lançamentos existentes em COPA (ver tabela abaixo).

Operação Descrição


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

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.


É 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 Dict ionary

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 si stemas 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 ta bela 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 arquivamen to 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 incorre to 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).

Academia CO

Documents

Transcript of Academia CO