In the lessons where you created the BalanceOfMaterials and CostOfMaterials registers, we deliberately skipped over discussion of register types available in 1C:Enterprise. Now it is time for a few words on the subject.
Accumulation registers can serve as balance or turnover registers.
The registers that you already have in your tutorial configuration, BalanceOfMaterials and CostOfMaterials, are balance registers.
You can remember that during the creation of the Materials report in the query wizard you saw three virtual tables generated for a register of this type: the balance table, the turnovers table, and the combined balance and turnovers table.
A turnover accumulation register is very similar to the balance register that you are familiar with, except that the idea of balance is meaningless here. A turnover register only accumulates turnovers and ignores balances entirely. Therefore, the only virtual table the platform generates for this register type is a turnover table. A turnover register is absolutely similar to a balance register in every other respect.
We should mention one distinctive feature in the design of accumulation registers, which is directly related to the ability to get balances. When you create a turnover accumulation register, it is easy to determine which data should serve as register dimensions, and you can assign any data you want to be a register dimension.
The situation is entirely different for an accumulation register that supports accumulation of balances. When selecting dimensions, you should remember that the register has two record directions: receipt and expense. When you specify dimensions, choose data for which both types of register records are totally possible.
For example, if materials are recorded by material type and warehouse, material type and warehouse can obviously be dimensions since both receipt and expense of materials are always made with a reference to a specific material type and a specific warehouse. But if you also need to record materials by vendor, your implementation should be based on the specific accounting procedures used within the company.
Probably a vendor is always specified for material receipts, while for expenses a vendor is most certainly missing. In the majority of scenarios this information is not needed at all.
Therefore, a vendor should be included as an attribute of an accumulation register instead of a dimension.
However, in scenarios where a vendor is certainly specified when materials are expended, adding a vendor register dimension makes sense.
In other words, resources of each balance accumulation register dimension must support changes in both directions: receipt and expense. Resources that support only receipt or only expense are not allowed.
Neglecting this principle of accumulation register design leads to inefficient use of system resources, which impacts the applied solution performance.
This principle is less important for register attributes. Entities that are represented by register attributes can be both only received or only expended.