SAP Profitability Management Re-alignment function alters the definitions of profitability segments in the database. Its primary use is for restating historic data so that it makes sense in the context of the current market situation.However, it can also be used to correct mistakes in CO-PA and populate characteristics that have recently been added to an operating concern on historic summary records. Since realignments alter the definitions of profitability segments, a realignment affects all the historic data in the CO-PA data structures. Realignments in effect create new definitions for sales channels, and it is not possible to execute drill-down reports under the "old" perspective after a realignment has been conducted (though it is possible to display line items under either the old or new perspectives).
Realignment is an excellent tool, but it needs to be understood that realignment affects the entire COPA summary database. Ideally, the person or persons conducting realignments should have a working understanding of derivation logic to avoid making mistakes. Realignments can be reversible, but achieving the desired results with reversal is only possible under ideal conditions.The realignment interface is entirely on the user side of CO-PA. Realignment is conducted by executing a realignment run, which is first defined with one or more realignment orders or requests. Each of these determines how selected profitability segments, as determined by selection criteria, should be modified (as determined by a conversion rule).
With selection criteria, characteristic values are specified to pinpoint the profitability segments that are to be changed. With conversion rules, it is specified whether characteristic values in the selected profitability segments are changed via overwrite to some specified value, or are rederived based on any new values and current derivation logic, or are fixed, and do not change at all.
Realignments in Operation
Realignments can be executed in test mode before they are run to actually change the database. The test monitor is a flexible tool which can be used to illustrate exactly what the effects of the realignment will be, and why. It is highly recommended that this be used extensively when learning the tool.Realignments can be executed online or in the background from the transaction screen. Multiple realignments can run at once, unless two or more specify that characteristics are to receive fixed values. To avoid discrepancies, these types of realignments must be run in sequence.Reversing a realignment using the restore function has the effect of restoring the definitions of the profitability segments which were changed to the definitions prior to that time. Reversal is only possible if the definition of the realignment run has been preserved (has not been deleted). Realignments affect both costing-based and account-based profitability analysis, since both these submodules share the profitability segment definitions in the database.Realignments invalidate both frozen data and data in summarization levels, meaning that both these items have to be constructed again from scratch after a valid realignment run.
Customizing Monitor
The Customizing monitor offers three important analysis options: the first two represent new functions in Release 4.6.Overview of Organizational Structures: This is where the organizational structures for the current operating concern are displayed.
Where -Used List: This provides you with an overview of those areas where a characteristic or value field is used in CO-PA Customizing. You can obtain this overview for the current client or for all the system’s clients. By double -clicking, you can access the corresponding maintenance transaction directly from the overview and then delete, for example, the characteristic or value field in question. For information on the Analysis Options available in value field analysis, valuation analysis, and derivation analysis, see the more detailed documentation in the IMG.
Authorization Concept
The authorization concept in the R/3 system can be described briefly as follows:
ŸSAP delivers certain authorization objects with the standard system. These authorization objects consist of up to 10 fields, each of which represents an element which is to be protected (such as “Operating concern”, “Form”, “Activity”, etc.)/Authorizations are defined by the system owners against these authorizations objects. Authorizations contain specific combinations of values that are to be allowed for the fields of an object during a transaction that accesses that object.
Authorizations are grouped into simple profiles which are either assigned to users directly, or to other complex profiles (which can likewise be assigned to users or other complex profiles). These frequently represent a collection of all the authorizations an individual needs in order to perform his or her job.A user can have more than one assigned profile. This means that it is possible to define profiles as a set of duties, and then to assign those profiles to all persons by the duties they perform or are responsible for.
Authorization Objects in CO-PA
Profitability Analysis uses standard R/3 functionality for authorizations. A number of pre-defined authorization objects for CO-PA are delivered with the system, which can be used to generate authorizations and profiles which can be used to restrict access rights to configuration functions and user functions in CO-PA.For example, in most implementations, most CO-PA users will be restricted to entering plan data and executing reports. Cost accountants may be allowed to perform cost center assessments and other allocations to CO-PA. Special support personnel may be allowed to make direct entries, update derivation rule entries, and perform realignments of CO-PA data.
To restrict on the data level in CO-PA, it is necessary to create custom authorization objects against particular characteristics, value fields, and key figures. The default settings for an operation concern dictate that all data is unprotected (freely accessible) on the data level until a custom authorization object is created on a field or combination of fields.For example, an authorization object might be created to control access to sales employee information in CO-PA, or to control access to commissions or product cost information in CO-PA.Different authorization objects are necessary for controlling plan data and actual data. To control on the same level in each, two authorization objects need to be created.
The R/3 system delivers the standard profile K_RKE_ALL which contains full authorizations for all delivered CO-PA authorization objects, meaning that a user with this profile can perform any function in CO-PA, if no custom authorization objects have been created. If objects have been created, then authorizations for those have to be created and added to this or another assigned profile.
External Data Transfer to CO-PA
Data can be uploaded directly into costing-based CO-PA through the external data upload feature. This might be necessary if a company is not implementing the SD module but wants sales details in CO-PA to take advantage of the module's mulch-dimensional reporting capabilities. It might also be used to load historic data in CO-PA, or to load data for company divisions which are not up on R/3. With this feature, data is uploaded directly from text file on the operating system level directly into the costing-based CO-PA transaction data tables. The feature does not simulate the manual line item create feature. The records in the text file must be of a consistent format, where each field is allocated a fixed number of characters, and where records are not separated by characters or carriage returns.
Uploading data via the external data interface requires defining the structure of the file to be uploaded and assigning the fields of that structure to the fields of the operating concern. The fields are mapped to each other through the aid of assignment groups; this allows different mappings for data being uploaded in the same structure.The configuration described above is performed in customizing, but the upload itself is conducted on the user side of CO-PA. The upload feature is available for both planning and actual data, but these must be uploaded separately. During the upload, derivation, valuation, and validation occur just as it would for any other transaction transmitting data into CO-PA.
Any records which do not pass the validation checks are written to an error file, which can be corrected, and then that file can be uploaded into CO-PA. Each file can only be uploaded into COPA once, since the system keeps track of the files in order to ensure that data is not duplicated. Multiple files can be uploaded into CO-PA at the same time for maximum performance.
Archiving and Deleting CO-PA Data
Profitability Analysis uses standard R/3 functionality for archiving and deleting. In SAP, archiving refers to the copying of data from R/3 datatables to an archive file, and deleting refers to removing of data from R/3 datatables. Therefore, it is possible to archive without deletion, or to archive with deletion. For the latter, archiving and deleting can be configured to function separately or together. In Profitability Analysis, line items can be archived/deleted for selected periods (except the current period), but summary records can only be archived/deleted by the year. Actual and plan data is archived/deleted separately, as is data in account-based CO-PA and costing-based CO-PA. Records can be archived/deleted by record type as well.
Incidentally, there are standard functions in the Implementation Guide for reorganizing, or deleting, other types of data and other items in CO-PA, such as frozen data, report definitions, form definitions, planning layouts, line item layouts, etc. Note that deleting frozen data does not delete the transaction data in the standard tables, but only deletes the stored frozen data against specific reports.
SAP Enhancement Concept
The R/3 enhancement tool is used to add customized functionality to SAP's standard business applications. Through enhancements, customers can implement their own functions without modifying standard SAP code. Each enhancement has a specific purpose.Enhancements are beneficial because they provide the exits and entrances at the appropriate places in R/3 along with the necessary data that may be used, manipulated and returned. Enhancements also isolate custom functions so they will not harm SAP transactions nor upgrades.To use enhancements, the custom functions must be programmed into the enhancements. The enhancements must be assigned to enhancement projects. And each project must be activated for all of the functionality contained in the related enhancements to take effect.
CO-PA Enhancement Overview
With enhancement COPA0001, it is possible to program steps for determining characteristic values during derivation. The programmed steps in this enhancement can be given step IDs and sorted with the other derivation steps. For example, this enhancement might be used to determine the value for a special user-defined characteristic, which is determined by complex logic not achievable through derivation rules.
With enhancement COPA0002, it is possible to program steps for calculating or retrieving special values during valuation. Separate calculations can be defined for planned and actual data. Calculations are assigned user exit numbers which must be placed in active CO-PA valuation strategies for the calculations to occur during the posting of data. For example, this enhancement might be used to zero out the values that are being passed to Profitability Analysis for certain products that should not appear in standard sales and marketing reports (such as 'dummy' products for freight, documentation, services, etc.).
With enhancement COPA0003, it is possible to program the characteristic group that should be used whenever a manual assignment to a profitability segment is necessary, using more detailed criteria than strictly the transaction code (standard CO-PA configuration). This means the same transaction could require the specification of values for different characteristics when different situations arise. For example, this enhancement might be used so that the characteristic group is determined by the account number that is being posted to, such that product-related accounts might have the product number as a required field in the profit segment, and customer-related accounts might need customer.
Related Posts
No comments :
Post a Comment