Текущее время: Чт, апр 25 2024, 01:25

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по исходящим поставкам - сюда



Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу Пред.  1, 2
Автор Сообщение
 Заголовок сообщения:
СообщениеДобавлено: Вт, сен 14 2004, 12:12 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Вт, авг 17 2004, 08:58
Сообщения: 288
Откуда: Москва
Note 41103 INFO: CO account assignment logic
Symptom
This note describes the CO account assignment logic as of release 3.0.

Account assignment logic for actual postings was changed between Release 2.2 and Release 3.0. In general, more account assignments are possible in Release 3.0 than in Release 2.2.

The account assignment logic from Release 3.0 also applies to the following Releases 4.xx.

Additional key words
CO interface, FB01, VF01


Cause and prerequisites
Solution
Account Assignment Logic as of Release 3.0
1. Account assignment objects in Controlling are orders, cost centers, projects, cost objects, networks, special make-to-order sales orders, and profitability segments. As of Release 4.5A, activity types (together with cost centers) can be assigned to an account, as of Release 4.6A business processes can be used as account assignment objects. From a point of view CO, profit centers are objects which can be posted to in in addition to one of the above-mentioned account assignment objects. They may also be derived from these objects.
2. Each document line item in which the account is created as a cost or revenue element must contain an actual account assignment object. For example, is not allowed to make an account assignment to only a statistical project.
3. In addition to the actual object, as many statistical account assignment objects as required are possible. For example, costs may be posted, in addition to a cost center, onto a statistical order and a statistical project.
4. More than one actual account assignment object in a document line item is not allowed. The sole exception is the cost center entered together with another actual CO account assignment object. In this case, the additional object is posted as actual and the cost center is updated statistically.
5. Each type of object can only be used once per document line item. For instance, posting two orders in a document line item is not possible.
6. Revenues can only be posted to cost centers statistically. If the cost element is of the type "Revenue element", the cost center is treated as a statistical account assignment object. In addition to the cost center, an actual object is required that can carry revenues, such as a profitability segment. The SAP System can automatically derive such an object if the settings are maintained for this purpose.
Differences from Release 2.2
More account assignments are possible as of 3.0 than in 2.2. For example, the posting of a cost center in addition to a further actual CO account assignment object is a new functionality, as are statistical projects. Also as of 3.0, auxillary account assignments are updated in line items so that you can display them in the line item report.
In some cases, postings that were possible in 2.2 appear to contradict the above rule. The cases are described below and a solution given for each one.

1. In 2.2, revenues could be posted solely to cost centers. To retain this functionality as of 3.0, the SAP System can automatically derive a profitability segment even if Profitability Analysis is not active. This must be prepared first in customizing.
Procedure: Post as required. Error message KI166 is displayed; go to the long text display. Place the cursor on the word "Message control" and press F2 to proceed as described in the error message long text.
Remark: If you use the new functionality for account-based Profitability Analysis as of 3.0, it is not possible at all to post revenues solely to cost centers.
2. In 2.2, revenues could be posted solely to profit centers. To retain this functionality as of 3.0, the SAP System can automatically derive a profitability segment even if Profitability Analysis is not active. The derivation is connected to a warning message that can be deactivated in customizing.
Procedure: Post as required. Error message KI166 is displayed; go to the long text display. Place the cursor on the word "Message control" and press F2 to proceed as described in the error message long text.
Remark: If you use the new functionality for account-based Profitability Analysis as of 3.0, it is not possible at all to post revenues solely to profit centers.
3. In 2.2, revenues could be posted without entering a CO account assignment object or a profit center. This is no longer possible as of 3.0. Make sure that you really want to use the account as a cost element. If so, the automatic account assignment (Transaction OKB9) can be used to store assignments per revenue element so that the SAP System will make the assignments itself.
4. In 2.2, automatic account assignment could be used for revenue elements to store a cost center or order that would be posted extra to the profitability segment for billings from SD. As of 3.0, the posting to the profitability segment is enough to satisfy the rules described above and the SAP System does not attempt to derive a cost center or an order in addition to the business segment. You can reconstruct the 2.2 functionality by installing the standard substitution described in Note 28068 using customizing.
Remark: It is no longer allowed to derive an actual order in addition to a profitability segment. Instead, use a cost center and/or a statistical order.
Updating During Account Assignments to Profitability Segments
If costing-based Profitability Analysis is active, and not the account- based PA, CO-PA is not updated at account level. In order to ensure account reconciliation between FI and CO, as of 3.0 CO also automatically updates the cost element along with a highly summarized profitability segment (which only has the characteristics company code, business area, plant, and profit center). This ensures the reconciliation between FI and CO by account.

Source code corrections


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, сен 14 2004, 12:16 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Вт, авг 17 2004, 08:58
Сообщения: 288
Откуда: Москва
Note 83702 INFO: Acct assignmt logic sales order proc. - REM
Symptom
You are not sure how the CO account assignment logic works and how you can influence the account assignment logic when you process a sales order in the case of 'Sale from stock' or 'Repetitive manufacturing'.

Additional key words
VL01, VL02, KI235, PAOBJNR, profitability segment, reconciliation object, goods issue, billing document, Intercompany

Cause and prerequisites
This note is intended to give an overview of the functions, known problems and solutions available in the area 'CO account assignments in sales order processing for repetitive manufacturing'.

Solution
The basics of the CO account assignment logic of the R/3 System as of Release 3.0 are explained in Note 41103.

General notes on the account assignment logic:
Compliance with the principles of the account assignment logic is checked in the CO interface.
A line item is relevant to cost accounting if the G/L account of the line item has been created as a cost element (Transaction KA03) in CO-OM.
As soon as a line item is relevant to cost accounting, it MUST contain a CO account assignment object.
An account assignment object can be put into the line item relevant to cost accounting by the application which creates the document before the CO interface is called. For example: if a sales order item in SD is assigned to a profitability segment or a project, then this account assignment object is transferred from SD to the CO interface when you create a CO document.
In the CO interface, further account assignment objects can be put into the line item by:
a) an appropriate substitution (Transaction OKC9),
b) an automatic account assignment (Transaction OKB9) and
c) a default account assignment from the cost element master
(Transaction KA02)
Options b) and c) are only checked each if no other account assignment object is contained in the line item; b) has a higher priority than c) here. You can store the condition(s) for a substitution in the definition of the substitution (Transaction OKC9).
In Note 28068, you find a description of how to include a CO account assignment object in a line item via substitution in addition to the profitability segment. Note 44381 contains an explanation of a substitution which ensures that the profitability segment is removed from a line item.
If a line item relevant to cost accounting contains a profitability segment (technical field name: PAOBJNR) and if only the imputed Profitability Analysis is active, the system automatically determines a reconciliation object, which is then taken for an 'actual' CO account assignment object. (see Note 41014)
If the CO interface finds that a line item relevant to cost accounting does not contain a CO account assignment object, error message KI235 is output (see for example Note 80466).
Caution: Make sure that you to check whether the corrections fromNotes 49823 and 68227 have already been implemented in your system.
General notes on 'Sales order processing':
Sales order processing for 'Sale from stock' on the CO side is generally projected into Profitability Analysis (provided that CO-PA is active in the controlling area affected): Transaction KEKK, table field TKA00-ERGBR)
Under certain preconditions (see below), a profitability segment (VBAP-PAOBJNR) is determined for every single item relevant for billing (VBAP-FKREL) by creating a sales order. This profitability segment is then transferred to the CO documents created in the course of sales order processing.
In SD Customizing, you can define in Transaction OVF3 that, depending on the (not empty) order reason, a cost center is put into the header data for the sales order (VBKD-KOSTL). This cost center is also transferred to the respective follow-on documents. Depending on whether the cost center is the only CO object in the line item, the posting to it is made as actual posting (value type 04) or 'statistically' (value type 11) (see Note 41103).
When creating the sales order, in costing-based Profitability Analysis, the expected revenues can be updated according to SD pricing on the sales order and the respective costs of sales can be updated according to CO-PA valuation strategy under transaction type 'A' (if TKA00-KAEIN = 'x', Transaction KEKK). This is referred to as transferring the incoming sales order.
When posting the goods issue for the delivery, stock reduction of finished products is updated as costs of sales in account-based Profitability Analysis. This posting is irrelevant for costing-based Profitability Analysis.
When the billing documen is released to accounting, the revenues are posted in account-based Profitability Analysis. In costing-based Profitability Analysis, the revenues are posted again according to SD pricing o the billing document and the costs of sales according to the CO-PA valuation strategy, this time under transaction type 'F'.
Case distinction:
Below, 3 constellations are distinguished and the

account assignment logic is explained for the case of an intercompany sale and for the case of NON-intercompany sale.

It is an intercompany business if the sales organization and the delivering plant from the sales order are assigned to different company codes.

Case 1: Only the costing-based Profitability Analysis is

active, the incoming sales order is NOT updated in

Profitability Analysis (TKA00-ERGBR='2' TKA00-KAEIN=' ').

Case 2: Only the costing-based Profitability Analysis is

active, the incoming sales order is updated in

Profitability Analysis (TKA00-ERGBR='2' TKA00-KAEIN='X').

Case 3: Account-based and costing-based Profitability

Analysis are active. Whether the incoming sales order is

updated in Profitability Analysis, is not relevant in this

case. (TKA00-ERGBR='4')

Case 1: costing-based Profitability Analysis
When creating the sales order, no profitability segments are assigned to the order items.
A cost center existing in the header data would be posted as actual when posting the goods issue.
When billing, revenues and costs of sales are updated in costing-based Profitability Analysis. In CO-OM, the revenues are assigned as actual to the reconciliation object for the profitability segment, and, if required, they are assigned statistically to the cost center from the business data.
In the Intercompany case, an external and an inter-company billing document should be created in SD. In costing-based Profitability Analysis, line items are created for both billing documents. The characteristics in the profitability segment for the 'external' line item contain the data of the selling organization. The characteristics for the 'intercompany' line item contain the data on the delivering organization. The CO-OM line items are supplied with account assignment objects analogously to the non-Intercompany sale.
Case 2: Costing-based Profitability Analysis and transfer incoming orders
When creating the sales order, the items relevant for billing are in each case assigned to a profitability segment. In costing-based Profitability Analysis, line items are created for incoming orders. (CO-PA record type "A")
In the Intercompany case, the line items are to be assigned to the incoming orders of the selling organization. To do this and to make sure that the line item consistently contains characteristics from sales view only, you have to carefully read and implement Note 121859. Before implementing Note 121859 and AFTER implementing Note 114958 the incoming sales order is consistently posted in the selling (!) organization. Carefully read both notes and the related notes to determine whether the system reacts as expected with your release Hot Package level.
The profitability segment from the order items is transferred to the goods issue document. Since account-based Profitability Analysis is not active, a reconciliation object is assigned as actual to an account, the cost center from the sales order header is only assigned statistically.
Billing behaves in the same way as in case 1.
Case 3: Costing-based and account-based Profitability Analysis
The system behaves in the same way as in case 2. The account-based profitability segment now replaces the reconciliation object. A reconciliation object is now no longer determined and the account-based profitability segment is always the 'actual' account assignment object.
Caution: In Release 3.1H or after you have implemented Note 80867, no document is created in account-based Profitability Analysis if both forms of Profitability Analysis are active. Note 84432 corrects this error. In Release 3.1H this problem is corrected via Hot package 02.
In the Intercompany case, Note 70159 is also of special interest this regard.
Source code corrections


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, сен 14 2004, 12:17 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Вт, авг 17 2004, 08:58
Сообщения: 288
Откуда: Москва
Note 28068 Simultaneous posting from SD to CO-PA and CO-CCA

Symptom
Up to and including Release 2.2, invoices from SD could be posted simultaneously to CO-PA and also cost element by cost element to CO-CCA or CO-OPA. Either the automatic account assignment (transaction OKB9) or the default assignment in the cost element master record is used for posting to the CO-CCA and/or CO-OPA applications.
In Release 3.0, posting by cost elements to cost centers or to orders only functions when CO-PA is not active. If CO-PA is active, normally only the profitability segment will be posted to, even though a flexible assignment, cost center + profitability segment, is in principle possible.

Additional key words
Transaction VF02, VF04

Cause and prerequisites
Solution
The functionality possible up to Release 2.2 can be accessed as of Release 3.0 using a standard substitution. This substitution is delivered by SAP and the customer only needs to activate it.

If you have not used a substitution before, proceed as follows: Transaction OKC9, Function "New entries". Enter your controlling areas. In the column "Callup point", enter "0001" each time; in the column "Substitution" enter "0_SCO10" each time (please take note of the '0' and 'O'), and in the column "Activation level" enter a "1" each time. After you save this, you have restored the 2.1/2.2 functionality.

If you presently use substitutions, you will recognize this in transaction OKC9 because at least some of your controlling areas are already assigned to substitutions with other names and an activation level "1" or "2". You must change the already existing substitutions for these controlling areas. To do so use the menu options, Environment -> Substitution. Enter the name of your substitution. On the next screen select step 001 and push the function button "Insert entry". On the next screen select "Only exit" and hit 'Enter'. Leave the block 'Prerequisite' empty for the substitution step to be changed and enter the value "SCO10" in the field "Substitution exit" in the "Substitutions (if prerequisite is met)" block. Finally, push F3 until you are prompted to save and then save the change.

Important: In Release 2.2, it was also possible to post on a real order

in addition to posting into CO-PA via the automatic account assignment

determination. This is not possible as of 3.0, under any circumstances,

because the data cannot be properly updated on two account assignment

objects. For this reason, you need to enter a statistical order or a

cost center during the automatic account assignment determination.

The cost center is then statistically posted as of 3.0 according to the

account assignment method (see also Note 41103).

Source code corrections

In Releases 3.0FCS and 3.0A, the substitution exits cited are not yet available. Therefore, instead of above described procedure, please make following modification. Once 3.0B is installed, you should cancel this modification and replace it with the standard substitution.

Program: LKAIPF20
Routine: ACCOUNT_ASSIGNMENT_SUBST
form account_assignment_subst using aas_kstar aas_katyp aas_vrgng_typ

aas_cobl
structure cobl.

data: ld_flag type c,
ld_prctr like cobl-prctr,
ld_bukrs like t001-bukrs.

check not ( aas_katyp is initial ).
check aas_vrgng_typ = con_vorgn_typ_ext.
perform account_assignment_clear.
perform account_assignment_fill using aas_cobl.
gd_acc_list-co_kaerg
= '0'.

"<--- INSERT
perform account_assignment_test using ld_flag.
...


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, сен 14 2004, 12:18 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Вт, авг 17 2004, 08:58
Сообщения: 288
Откуда: Москва
Note 44381 Profitability Segment Not Required in SD Postings

Symptom
Providing CO-PA is active, when posting costs generated in SD, the profitability segment derived from the customer and the article is set in each accounting-relevant line.

This is wrong in some cases because an additional cost center to be posted is only posted with costs statistically.

Examples:

1. During goods issue, the goods issue value should be assigned to a cost center.
2. This is then apportioned to CP-PA credited so as to be able to carry outa reconciliation between billed good issues and the overal goods issues. In this way it is possible to summarize how many goods issues
3. were posted without billing document
4. To settle shipping costs, post costing-based shipping costs (posted to profitability segment) to reserves (posted to cost center via automatic account assignment) during billing. For this end, the R/3 System creates the reserve account as a profit and loss account and makes it a cost element. Receiving the shipping invoice debits the same cost center. The cost center balance should be settled in Profitability Analysis.
Note that you cannot really post revenues to cost centers. Posting is always made using statistical value type 11.

Other terms
OKB9, OKC9, CO-interface, account_assignment_logic, COBL, HKONT, PAOBJNR, VL01


Solution
Check whether the accounts in question must post to a profitability segment or not. If not, define a substitution in CO customizing for which the profitability segment is initialized for this account

( Field <COBL> $HKONT )
meaning that it is filled with the fixed value 0000000000.

Alternatively, extend your chart of accounts to enable the solution using substitution.

Important note
In any case, substitution must be defined in a way that the profitability segment is initialized in special cases only. The restriction to certain accounts makes sense to prevent the profitability segment from being lost during revenue postings. We recommend you to restrict substitution as far as possible, e.g. using a query on the billing process (AWTYP = 'VBRK' and VORGN = 'SD00').

In this connection please also refer to Notes 167246 and 392273.

The correct definition of substitution is the customer's responsibility. If you have any questions please contact your CO consultants. In case of errors resulting from an incorrectly defined substitution, SAP may offer support only as charged consulting service.


Repairs in the Code

n.a.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, сен 14 2004, 13:41 
Ассистент
Ассистент
Аватара пользователя

Зарегистрирован:
Пн, сен 13 2004, 15:52
Сообщения: 25
Откуда: Москва
Конечно, очень интересно. :!:


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 20 ]  На страницу Пред.  1, 2

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB