Business Patterns CX_ACCOUNTING_AREA

Company codes - CX_ACCOUNTING_AREA


Company codes are required to be able to plan on time, for example, for external warehouses, independent of the local warehouse stock.

All logistical and MRP movements and quantities are recorded in sub-monitors, separated by company code.

It is therefore possible to view the entire process per company code.

A company code can be attached to any business object, such as a warehouse or a cost center. When a document is posted, the system determines whether a company code must be used for posting. If this is the case, the company code is posted to separately in addition to the global posting.

The company code, which can be created via the master data, must be assigned to an object (warehouse) for which it is to apply.

Usually these are warehouses that are to be managed via a separate company code, perhaps independently of the actual warehouse/stock.
On the company code, you can specify whether the stock quantity or the requirements should appear in the total account of the part or not (common or separate parts planning - stock/requirements lists)

Technical conception:

There will be a new class CX_ACCOUNTING_AREA with another new account class CX_AREA_ACCOUNT, which can be attached to any business object via the slot clearingObjects. It is structured using class CX_ACCOUNTING_AREA_CHART

CX_STOCK::clearingObjects -> CX_ACCOUNTING_AREA::monitors -> CX_AREA_ACCOUNT

Every document in ClassiX will have the possibility to be directly valid for a company code (via a slot areaAccount). If no company code is specified, the document is only posted to the global part monitors. If a follow-on document is created for a document with company code, the company code is copied directly to the follow-on document. The entire planning process is therefore contained in one company code.

If the company code is assigned to a warehouse in which the "no MRP" indicator is set, the transaction data is not posted on the global monitors, but only on the company code monitors.

The CX_AREA_ACCOUNT then has two CX_LOG_CUBE as submonitors for each part that is posted via it. The submonitor, which points with the other dimension to the CX_STOCK_ACCOUNT of the part, displays the minimum and maximum stocks of the part for this company code. The posted stocks are also recorded here, which enables separate stock information for the company code. However, there does not have to be a direct link to the warehouse, since the company code can also be linked to an object other than the warehouse.

The second CX_LOG_CUBE submonitor points with the other dimension to the CX_DISPO_ACCOUNT of the part and thus forms a subset of the posted requirements and requirement coverage, only for this company code.

The logistics account is enhanced so that it can also work with the CX_LOG_CUBEs that were created between the company code and the logistics account of a part. Here, the min-max stocks and even the staging types and logistics indicators can be managed separately for the company code. This is realized by internally wrapping the connection via DimensionByCondition("type(this)=CX_STOCK_ACCOUNT") on the CX_LOG_CUBE. If the connection is not yet wrapped when such a CX_LOG_CUBE is saved, this is done the first time the connection is saved.

Also the connection from the Logcube to the dispatcher account is wrapped.

For the clear management of the whole parts of the company code, there will be an overview list containing all CX_LOG_CUBEs of the company code that have already been posted once and thus created. If you want to set up a part company code before the first posting, for example, to specify the minimum and maximum stock levels, you can generate these using part selection.

Via this list it is also possible to see which stocked part needs to be replenished. Above the list, there are buttons that allow you to reorder via a purchase order or requirement coverage request or to replenish via a warehouse order for this company code.

In a further step, the B&B list will offer the option of evaluating these only for a specified (OBox) company code. Similarly, the MRP account could display only the relevant data per selectable company code. This is because the structure of the MRP and warehouse accounts (except for the owner pointer) is the same as the underlying CX_LOG_CUBES.

The indicator whether to post to the global accounts is not in stock, this is determined by the company code.

On the lowest nodes of the hierarchically arranged company codes, there is an indicator that is binary coded and controls how far above it the documents are also registered. 0 = not at all 1 = only in the linked company code. 3 = in the linked company code and the higher-level company code...