How to use a plan of characteristics types in a request for a storage system. Basics of organizing the 1C accounting subsystem plan for types of characteristics get the value

How are records usually kept in a commercial enterprise?

In the first few years, everyone is chasing profit: to buy more, to sell quickly, no one is yet interested in the hanging stock of goods in stores and warehouses. The volume of the database is growing by leaps and bounds, because... While the order of the goods being capitalized is chaotic.

For example, yesterday you bought a red chair, today you bought a green chair, at first they enter the data into the database: 1) old position - red chair; 2) new position - green chair. But after inventory, there is always a re-grading of goods, and here they come to the option of creating a new position, without a specific description in the name of the product of its special properties, i.e. they enter the product as, for example, simply “Chair”, and mark the two previous product positions for deletion.

After some time, there is a limited amount of free working capital. Here the question arises: which products were in greater demand in order to invest in them, and not in the hanging product.

That is, again you need to know additional product characteristics, but you need to enter these characteristics into the database no longer in a chaotic order - simply by adding some descriptions to the product name, but clearly and correctly: the name should be short, concise, and in an additional field - all possible characteristics of this product are described: for example, its color, volume, weight, manufacturer and much more.

Here, if we write down the properties of a product in the Nomenclature directory in the “Comments” field, then it will not be easy for the Analyst to make the report he needs on the popularity and turnover of a particular product with specifically given properties of the product.

We can attach to the Nomenclature directory a subordinate directory into which the user can enter the necessary properties and descriptions of the product, but in this approach we will face the problem of being unable to guess what type of information the user will want to enter additional information.

For example, under the product “Chair” - the user wants to indicate the property of the product - color, this is a string data value. This means that in the subordinate directory, we will make the props string. What if he wants to indicate an additional property of the product, for example, the manufacturer? Then we must make the details in the subordinate directory a reference type, pointing to another directory "Manufacturers". What if the user, in the additional properties of his product, wants to indicate how many legs the chair has? In the subordinate directory we must make the attribute numeric.....

From here, when we need to give the user the opportunity to create Data TYPE , into the values ​​of which he will introduce his information, then we need to create PVC(plan of types of characteristics).

We will create a complex PVC in our example, so that there is a full-fledged mechanism for describing additional properties of the product.

But first Let's look at the lesson on creating PVC from the book(p.476) " 1C_ Enterprise 8.3. Practical guide for developers. Examples and typical techniques" Radchenko/Khrustaleva

Here we already have a reference book Nomenclature. Purpose of the task: be able to know the remains of materials that have a certain characteristic value. To do this, we will create new objects in the Configurator: 1) Information register "Nomenclature Properties Values"; 2) PVC "Nomenclature Properties"; 3) subordinate to the Nomenclature reference book "Nomenclature Options" to describe batches of materials; 4) subordinate PVC reference book "Additional Nomenclature Properties" to set type values characteristics for which there are no suitable types in the configuration.

As a result, it will be enough for us to select from the information register all the elements of the subordinate directory with this characteristic value and then, based on them and their owners, obtain the remainder of the accumulation register.

In the PVC we are creating, in the “Characteristic value type” field, we will indicate a composite data type: Number, String, Date, Boolean, DirectoryLink.AdditionalNomenclatureProperties. And also in the PVC field “Additional values ​​of characteristics” - we indicate the subordinate PVC directory “Additional Properties of Nomenclature”.

2) TypeProperties, type = Plan of Types of CharacteristicsLink.PropertiesNomenclature

And create an information register resource:

Value, type = Characteristic.Nomenclature Properties.

We have created all new objects. There is no need to add them to subsystems (in the user interface), since there is a connection between the new objects, and the main thing is the “Nomenclature Options” directory subordinate to the Nomenclature, which we can see by opening any product from the Nomenclature directory:

There are several nuances when setting up the information register "NomenclaturePropertyValues", here it is advisable to set register dimension Property Set(a selection from the list OptionsNomenclature falls here) - how Presenter, this will give us the opportunity from the reference "Nomenclature Options" - call this Information register. And also for the register resource Value - set "Link by type" = Property Type and "Selection Parameter Links" = Selection.Owner(Property Type). These settings for the information register will simplify the user's input of data.

In addition, in the book in this lesson there is a detailed description of how best to set up list forms and the main forms of new objects, so that the user sees only the information he needs when filling out product properties. We won't show all this detail here.

Let's just try in our product, for example, "Electrical cables" - set the additional property "White cables", and the composition of the property: "property type" = Color and "property value" = White. This is the pattern of windows opening one after another:

....I don’t know about you, but my head is already spinning and it’s no longer entirely clear what we are doing and why))))

Imagine explaining such a chain to the user?!?.....For our user to be able to understand what we ourselves no longer understand, he must have at least three 1C certificates)))

If you are frightened and upset by the introduction of product properties according to the scheme described above, then you can look at the same diagram from the textbook itself:

It's just incredibly difficult!!! And any novice programmer will decide that it is easier to never mess with PVC than to try to figure out such a scheme.....

To get the final result of the task - the balances of goods according to their properties, the book suggests adding the "Set of Properties" dimension with a reference type to the "Nomenclature Options" directory subordinate to the Nomenclature in the Remaining register. Next, add a field with the same name and data type to the documents for the receipt/expense of materials in the tabular sections, and add to the modules of these documents the entry into the “Set of Properties” balance register. In the directory itself “Nomenclature Options” - write Characteristics in its menu, which will allow you to see them later in the SKD report. And, as a final step, create an SKD report on the Remaining Products with selection by Characteristics:

Yes, the report turns out interesting, but the process of creating additional Characteristics (properties) of a product is very confusing, in addition, the user, when entering so much additional data when filling out receipt/expenditure invoices, will not create a single error.....Starting from entering the “Set of Properties” "in the fields of the document....

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Let's try to understand the mechanism for creating additional properties for a product, perhaps we can come to a solution to the problem in a simpler way.

So what do we need:

1. Allow the user to add a description of Properties to the Nomenclature.

2. Enable the Analyst to study sales indicators in the selection by Product Properties.

Let's consider what options we have when solving the first point of the problem:

1. We can add a subordinate directory to the Nomenclature directory, in which the user will describe only specific, string-type data that we have specified in the Configurator.... this is not suitable, since when describing the Properties of a product, a Type “unpredictable” by us in the Configurator may be needed data: for example date, number, line, link to another directory.

2. Therefore, to create additional properties of the Nomenclature, we must create PVC, since PVC is a reference book + Description of Data Types.

If we are in the Nomenclature directory, we will create a tabular part in which there will be two fields - the Data Type of the entered Product Properties and, directly, the value itself. It's very simple - one field will refer to PVC, another to the Characteristics of this PVC.

But in this case, we won’t be able to make the entries unique... Just imagine an option where under a product, for example, Sausages, you can enter two types of values ​​for the “Color” Property: both red and green)))

Therefore, this method is the simplest, but does not provide uniqueness in the properties of the Nomenclature.

3.Let's create PVC, but we will type its values through the Information register. Information Register - contains only unique data.

This is the most versatile option. We will record Product Properties with different types of data, and the values ​​of these properties for a specific product will be unique.

p.s. Here you can create a subordinate PVC directory in order to record all the string Properties of the item in it. But let's not complicate things for now.

To do this, we add two dimensions in the information register:

2) Properties of Nomenclature, type = Plan of Types of Characteristics Link. Universal PVC.

In the register resources we indicate “Property Value”, type = Characteristic.UniversalPVC:

That's all for now, we have created a mechanism for the unique properties of the product. We still need to configure the convenience of selecting data for the user.

Let's select the "PropertyValue" resource of the information register and in the menu on the right on the "Views" tab - create connections so that when selecting the value of this register in user mode, we will immediately get a list from the dimension of this register "Nomenclature Property". Because We remember that the dimension “Property of Nomenclature” is PVC, and the resource “Property Value” is the Characteristic of this PVC. So, on this board indicate "Relationship by Type" = "Nomenclature Property". Now, if we have selected a Data Type in the register dimension, for example, string, then when we enter a value into a resource, we will immediately have the type string, and not all possible lists of types!

Let's go to user mode, select any product from the Nomenclature directory, open it, on the top of the directory element we have a link to the created information register, into which we will add new properties of our product:

In this example, for the Product “Philips 2N2369 Transistor” - first create the Type of the desired product property, let it be “Transistors”, and immediately indicate the data type for this property - in this example we manually select the data type = String. Save. And then we need to set the values ​​for this type of product properties, let it be “Low-current transistors”:

Let's add one more Property to this product, for example, manufacturer "Korea".

Let's take another product, create a "Transformers" property for it, type = string, value = "String transformers". And the second property that we want to enter for this product will also be “Manufacturer” - there is no need to create it, we already have it in the selection, but if we try to enter the same value of this property, equal to “Korea”, then we will have to typing it manually....It's not very convenient...It's good when a value entered once can be substituted many times.

To add this convenience, let's go to the Configurator and create a directory, on the "Owner" tab we will indicate our "Universal PVC" created earlier. Now, if our value properties are strings, then we do not have to constantly select the type = String; it will be enough to provide a link to this subordinate reference book: it is very convenient to save string values ​​in it, and in addition, this method will allow us to select ready-made string values for Product Properties.

Let's make some small adjustments to the PVC in connection with the subordinate directory that appears:

Also, in the information register, we need to add settings so that when selecting a register resource value, we immediately have a selection by the Owner of this property.

We completed the first point of the task - we created a mechanism for creating unique properties for the product.

Let's fill in various properties of the item in the 1c user mode. Please note that previously entered properties, such as, for example, Manufacturer, are already immediately available in the property selection option, and we are also given the option to immediately select a ready-made value for this property, for example, “Korea”.

Now let's move on to the second stage of solving the task: to make it possible to make a selection in the report, for example, by product balances or by product sales from the Properties of this product.

I’ll say right away that we will not come up with a complex mechanism by adding any product properties to the fields of the tabular parts of documents!!! In practice, this cannot be done, otherwise there will be such a confusion with the documents that then no one will have enough strength to fix it....

Everything is much simpler. We have a product, its name is short, laconic, all the nuances are described in its properties. If we have a product with different types of properties, this means that this product is different, and not the same!

For example, we have one product “Samsung Line Transformer”, which has two properties: 1) “Transformers” = “Line Transformers”; 2) “Manufacturer” = “Korea”, and another product “Russia Line Transformer”, which has two properties: 1) “Transformers” = “Low-line transformers”; 2) “Manufacturer” = “Russia”. So we cannot say in any way that these two products are the same, but differ only in properties!!! No, these two products are different, which we briefly indicate their difference in the Name, and describe in more detail in the properties of this product.

Hence, we do not need to create some additional field in the primary documents in order to register one of the characteristics of the product (we can have more than one of these characteristics!).

We will re-issue all our invoices and documents again. Provision of Services. (here in the documents from the first method from the book there are fields with additional characteristics, but they do not in any way affect our newly created own PVC mechanism)

In the Configurator we will create a Report on the register “Uniqueness of Universal PVC”. Let's write the following code into the ACS report request:

SELECT Material Remaining Remaining And Turnover. Material, Material Remaining Remaining And Turnover. Quantity Initial Remaining AS Initial Remaining, Material Remaining Remaining And Turnover. Quantity Receipt AS Incoming, Material Remaining Remaining And Turnover. Quantity Expense AS Consumption, Material Remaining Remaining And Turnover. Quantity Final Remaining ok AS Final Remainder, Uniqueness of UniversalPVC.Property of Nomenclature, Uniqueness ofUniversalPVC.ValueProperties FROM RegisterAccumulation.Remaining Materials.RemainingsAndTurnover AS Remaining MaterialsRemainingandTurnover LEFT CONNECTIONRegisterInformation.UniquenessofUniversalPVC AS Uniqueness of UniversalPVC ON Remaining MaterialsRemainsAndTurnover.Material = UniquenessofUniversalPVC.Nomenclature

In the ACS report settings, we will allow it to be used in the “Selection” user mode. When generating a report in 1C-Enterprise, select Nomenclature Property = Manufacturer in the selection. We will get a very interesting report:

By replacing the balance register with the Sales register, we will create a second Sales report with the ability to select by product properties.

We have fulfilled and even exceeded the second point of the task - to enable the Analyst to create reports in the context of Product Properties.

In our version, the PVC mechanism turned out to be simple, clear and quickly customizable.

p.s. When creating this article, the information I read from here helped me a lot:

////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

I hope that my article will be useful to novice programmers on the 1c 8.3 platform

p.s. I am attaching a training database in which all the current examples were created in the download. I started writing this database from scratch using the lessons from the book “1C_ Enterprise 8.3. Practical guide for a developer. Examples and typical techniques” by Radchenko/Khrustaleva http://v8.1c.ru/metod/books/book.jsp?id=441, simply complementing it with his own achievements.

Good luck in mastering PVC, in the case of solving this difficult problem - the slogan below is very suitable)):

Just in case, copyright

In the query designer, when it is called from the data source setup form, for the data composition schema. There is a “characteristics” tab, the use of which is not clearly described in the documentation. In this article I will try to explain how and why characteristics are used in ACS.

Typical configurations actively use the mechanism of properties and property values, available for almost any object. Primitively, in reference books, this mechanism was implemented in configurations 7.7. Now this mechanism is implemented using a plan of characteristics types and an information register, but the idea remains the same.

When I first encountered the need to use this mechanism in an access control scheme, I struggled for a very long time, organizing nested queries, joining them to the main selection and racking my brains over how to take into account the possibility of the emergence of new types of properties that did not exist at the time of report development. The entire mechanism of properties, being simple and logical from the user’s point of view, did not lend itself to any normal processing until I figured out the “Characteristics” tab.

The table on the tab is very capricious, either you enter the entire line correctly, or refuse to enter the line at all; the system will not allow you to leave an incompletely filled line “for later.”

So, let's get down to specifics. First column: Type– here we select the type of object to which the characteristics will be attached, for example “DirectoryLink.Nomenclature”

This means that it will now be possible to obtain property values ​​for all objects of the specified type.

Further in the next column Source of species we must set the property view source parameters. Possible options table m request, why do we need an option? request I'll tell you later, now let's select an item table.

In a collumn Types of characteristics we must select the infobase table in which the required types of characteristics are stored, in our example it will be “Plan of Types of Characteristics.Properties of Objects”.

Next, the values ​​available to us for selection in the columns Key field, Name field And Value type field, directly depend on the fields of the table we select. IN Key field we choose Link, V Name fieldPerformance(the user will see it as the name of the attribute), and in Type field respectively TypeValue.

Now let's move on to the source of values. Our source of values ​​will be the information register “ObjectPropertyValues”, so we select in the column Source of valuestable, and in the column Attribute Values– “Information Register.Values ​​of Object Properties.” In columns An object, Property,Meaning, select the appropriate register fields An object, Property, Meaning.

It would seem that that's all. We go to the schema settings, add a grouping by products, and add a subordinate grouping, for example by Brands, we have such a property.

We expand the list of details of the Nomenclature group and... we don’t see any properties there:

The fact is that we are in the configurator, from where there is no access to the data. How to make the necessary settings? The most convenient way to do this is to use the data composition console, the one on the ITS disk, or the one included in the “Developer Tools” subsystem. But you can simply open the report settings in enterprise mode.

So, let's open the same setting, but in enterprise mode:

As you can see, we have added new “Details”, and the property “ Brand” outwardly does not differ from the usual directory details. And the property “ Product type” is in square brackets because the property representation contains a space.

However, we also have the property “ Type of agreement” which is linked to the directory “ Treaty” and has nothing to do with “ Nomenclature“. If not used in the setting “ Type of agreement” then everything will work correctly, but if you select it, then as a result it will turn out to be unfilled, because not a single item in the nomenclature has this property actually filled in. But how can you filter out unnecessary properties so that they don’t get under your feet?

To do this, we need to change the view source setting in the query designer, on the “Characteristics” tab. Remember, at the beginning of the article I promised to tell you why the view source type is needed request? Now is just such a case. Change the view source type to request. In the column of types of characteristics, click the “[...]” button and a new query designer window opens.

Enter the following query there:

CHOOSE
Object Properties.Ref.
Object Properties. Name + “(property)” AS Name,
Object Properties.TypeValues
FROM
Plan of Types of Characteristics. Properties of Objects AS Properties of Objects
WHERE
Object Properties. Purpose of Properties = VALUE (Plan of Types of Characteristics. Purpose of Properties of Object Categories. Directory_Nomenclature)
AND (NOT ObjectProperties.DeletionMark)
AND (NOT ObjectProperties.Category)

In columns Key field, Name field And Value type field, select the appropriate selection fields: Link, Name And TypeValue. It will turn out like this:

Now, when we move on to setting up the report, the picture in the list of Nomenclature details will change:

Now the product only has those properties that are assigned to it, moreover, they are now noticeably different from the usual details, thanks to the postscript (property), which we added to the property name in the request.

That's all, but many may be confused by the impossibility of setting it up in the configurator. There's really nothing wrong with it. It is enough to save the setting (or the entire circuit) to a file and restore it in the configurator.

The configurator will display details that it does not understand with red crosses as unavailable:

But this is no longer scary, because a report with such settings can be saved in the configuration and it will work correctly when opened by the user.

Creating a plan of characteristics types, working with the chart of accounts

in the 1C:Enterprise 8 system.2 »

Goal of the work: mastering the basic techniques for creating a plan of characteristics types, setting up a chart of accounts in the software package "1C:Enterprise 8.2".

    Answers to security questions

    Results of the task.

Guidelines

Characteristic type plans

To maintain analytical accounting in the 1C:Enterprise system, the subconto mechanism is used. Subconto Any object of analytical accounting is called: fixed assets, intangible assets, materials, organizations, accountable persons, contracts, etc.

View of the subconto, in turn, a set of analytical accounting objects of the same type is called. For example, a list of buyers and customers (assuming that these are only organizations) in the 1C:Enterprise system will be called “subaccount type “Organizations”, and any organization from this list will be called “subaccount”.

To implement analytical accounting for subconto, a new application object “Plan of characteristics types” is used. It describes possible characteristics in the context of which analytical accounting is required, for example, Counterparties, Nomenclature.

The main property of the plan of characteristic types is the type of characteristic value, which indicates the configuration objects used as a subconto, for example, DirectoryLink. Nomenclature.

Similar to predefined accounts in terms of types of characteristics, even at the development stage, predefined types of characteristics (types of subaccounts) are usually indicated, for example Counterparties.

The Subconto View object itself does not describe any data objects. The subconto view only “references” to a specific data type. The subconto type indicates the possibility of using a specific type of data to organize analytical accounting for business accounts. Data objects for maintaining analytical accounting can be elements of directories, documents, transfers, etc. When setting up analytical accounting (sub-account) for a specific account, the type of sub-account is indicated. For example, to organize analytical accounting for account 3310, you can select the subaccount type “Counterparties”, which has the data type “DirectoryLink.Counterparties”. Thus, the subconto type makes a certain type of data available for use in analytical accounting.

Charts of accounts

Charts of accounts are lists of data objects of the “account” type - accounting registers by which funds will be grouped when working with the 1C:Enterprise system. The concept of “chart of accounts” in the 1C:Enterprise system is fully consistent with the generally accepted understanding of a similar term in accounting. Thus, accounts are intended for storing objects of synthetic accounting of enterprise funds.

Charts of accounts contain a list of accounting or tax accounts, for example, self-supporting, tax, and tax plans of accounts with a simplified taxation system.

Account properties can be flexibly configured depending on the adopted accounting system in a particular country and a particular type of enterprise.

For the chart of accounts, the length of the account code and the number of levels of subaccounts, as well as the number of characters in the subaccount of each level are specified. Additional details are configured for accounts, as well as forms for viewing the list and editing accounts.

Accounting accounts are the basis of the accounting system. When setting them up, the properties of additional accounting sections are set - currency, analytical and quantitative.

The system supports multidimensional and multilevel analytical accounting. In addition, the ability to use an accounting separator is configured. The accounting separator allows you to maintain accounting independently for several organizations in one information base.

An important feature of accounting accounts is the ability to create objects, both in the configuration and in the information base itself. Introducing specific accounts into a configuration is advisable if the behavior of the configuration itself requires the presence of the accounts themselves or specific properties of these accounts.

Example 1: Creating a plan of characteristic types

To create a new plan for types of characteristics, in the “Configuration” window, select the branch “Plans for types of characteristics” and click on the “Add” button. A designer window will open in which we specify the name “Plan of Types of Characteristics1”. The synonym will be generated automatically when you click on the field.

In the “Characteristic value type” field, click on the button. The “Edit data type” window will open, in which you need to enable the “Composite data type” option, and then check off all the directories (Fig. 1) that will be required for analytical accounting (chart of accounts settings). Let's mark three directories: Employees, Contractors, Nomenclature. Let's click "OK".

Let's close the designer window. As a result, the line “Plan of Types of CharacteristicsTypical” will appear in the branch “Plans by type of characteristics” of the configuration tree. To add. predefined types of characteristics (types of subconto), you need to right-click on the line “PlanTypes of CharacteristicsTypical” and select “Open predefined data”. A window will open in which you need to add predefined types of characteristics (types of subconto).

Let’s add the first type of subaccount “Employees”. The type of subconto “Employees” corresponds to a directory of the same name, which contains information about the employees of the enterprise and is used both for filling out constants and extracting primary documents, and for maintaining analytical accounting on account 1251.

Click on the “Add” button. The “Predefined characteristic” window will open, in which you need to specify the name (Employees), name (Employees) and select the type DirectoryLink.Employees using the button (Fig. 2). Then click "OK".

In the same way, add subconto types: “Counterparties” and “Nomenclature”.

Fig. 1 – Editing the data type

Fig. 2 – Predefined characteristic

Fig.3 – Type editing data type (employees)

Thus, the Plan of types of characteristics has the following form (Fig. 4)

Fig. 4 – Window “Plan of characteristics types”

Example 2: Setting up a chart of accounts

The main component of the configuration is the chart of accounts. The composition of accounts, sub-accounts, the ability to maintain analytical accounting, accounting in quantitative and currency terms - all this is defined in the chart of accounts.

To implement this task, it is necessary to create a chart of accounts with analytical and quantitative accounting for account 1330, as well as with analytical accounting for accounts 1210, 1251, 3310.

To do this, open the “Configuration” window (menu “Configuration - Open configuration”). Let’s find the “Charts of Accounts” branch and expand it. In the drop-down list, double-click on the “Self-accounting” line.

An editing window (constructor) for a specific chart of accounts will open, in this case the “Charter of Accounts Self-supporting” window.

Since we copied this chart of accounts, the name and synonym are already indicated in the “Basic” tab. Let’s leave them unchanged and move on to the “Data” tab (Fig. 3).

Fig. 1 – Chart of accounts window (Data tab)

We are satisfied with the settings shown here. Therefore, let's move on to the “Subconto” tab.

Here we select “PlanTypes of Characteristics1” in the Types of subconto field, then the “Maximum number of subconto” field will become available for editing. Let's set it to number two.

Let’s close the editing window and go to the “Predefined Accounts” window.

Let's enable analytical accounting on account 1330 (41), connecting to it the subconto1 type - Nomenclature. To do this, at the bottom of the window, click on the “Add” button and select the desired type of subconto. We will leave the remaining features in this line unchanged (Fig. 4).

Rice. 2 – Setting up a predefined account

Exercise.

    Create a characteristic type plan

    Set up a chart of accounts...

Control questions:

    Subconto mechanism.

    Purpose of the applied object “Plan of characteristics types”.

    Give examples of transfers.

    Stages of creating a document form.

    Editing chart of accounts properties.

Using a plan of characteristic types, you can organize the storage of object properties that are not yet known at the time of configuration development. Those. the user can independently enter new properties, for example, color, size, dimensions, power. Each group of products may have its own set of properties: for refrigerators - the volume of the freezer compartment, the number of compressors, the noise level; for computers - the amount of RAM, the amount of hard disk; for clothes - size, height, color, etc. Then, based on these characteristics, you can build reports, analyze sales volume, and obtain valuable information for decision-making.

An important feature of the characteristic type plan that distinguishes it from other objects is its "Value Type" property. This property allows you to define a list of possible data types used for characteristic types. Those. Usually a compound data type is used, and you can specify both primitive data types (number, string, date, boolean) and reference data types (DirectoryLink, DocumentLink, etc.). For each type of characteristic, the type of values ​​from the list of selected types is indicated, for example, for the characteristic Supplier, select DirectoryLink.Counterparties. The user can enter new characteristics in the "Enterprise" mode and specify a value type for them from the list of types specified in the configurator for the characteristic type plan.

Another important property of the plan of characteristic types is the “Additional characteristic values” property, which specifies a subordinate directory, for example, ObjectPropertyValues, containing possible characteristic values. Typically, this reference book is used by the user in the "Enterprise" mode when entering new types of characteristics for which there are no suitable reference books in the configuration, then in the ObjectPropertiesValues ​​reference book the user can enter a list of possible values ​​for each type of characteristic.

As an example, you can see how the properties mechanism is implemented in the standard “Trade Management” configuration. The following objects are used for this:
- Plan of types of characteristics of Properties of Objects, which uses a compound data type as a characteristic value type, which includes primitive data types (number, string, date, boolean) and links to various application objects: directories, documents, enumerations.
- Reference Values ​​of Object Properties, subordinate to the plan of types of characteristics of Object Properties. This reference contains a list of possible values ​​for a given property, for example a list of all the colors for the Color property: red, green, white, etc.
- Information Register ObjectPropertyValues, which has dimensions Object (DirectoryLink, DocumentLink) and Property (Plan of Types of CharacteristicsLink.Properties of Objects) and a resource Value, which contains the value of a specific property for a specific object.

Note. To simplify understanding, the mechanism for assigning object properties is not touched upon here. This mechanism uses the plan attribute of characteristics types and another information register.

Another important application of the plan of characteristics types is analytical accounting for subcontos in accounting. In terms of types of characteristics, predefined types of subcontos are created, for example, counterparties, items, contracts, etc. These subaccount types are then attached to the account stored in the chart of accounts. The user in the "Enterprise" mode can also enter new types of subcontos into the plan of characteristic types.

For example, consider how subaccount accounting is implemented in the “Accounting” demo configuration supplied on the ITS disk. The following objects are used:
- Plan of types of characteristics TypesSubconto. Reference data types are used as value types. It is highly not recommended to use primitive data types for subconto accounting; this will reduce system performance.
- Chart of accounts Main, in which this plan of characteristics types is indicated as a source of subconto types
- Subconto Directory, subordinate to the plan of types of characteristics.

Currency accounting involves reflecting transactions on certain accounts (usually settlement accounts) not only in the currency of regulated accounting (in rubles), but also in other currencies. When creating entries for such accounts, the ruble balance indicator (that is, the one that is reflected in the debit of one account and the credit of another to ensure balance, equality of debit and credit balances and turnover) is calculated based on the current (or specified in the document) exchange rate of the currency that selected as the currency of mutual settlements with the counterparty. If the exchange rate changes, we are faced with the need to revaluate the debt with the exchange rate difference being charged to the profit and loss account. If we talk about real accounting, these procedures look more complicated, but their essence boils down to the operation described above.

Suppose we owe counterparty A $1000; at the time the debt arose, the dollar exchange rate was 30 rubles. Speaking in accounting terms, we get the following accounting entry:

D Materials K Settlements with suppliers 30,000 rub. ($1000)

A month later, the dollar exchange rate changed to 31 rubles. If the debt to the supplier has not yet been repaid, then we, in fact, now owe him not 30,000, but 31,000 rubles. In order to reflect this difference in the accounting accounts, you can use the following entry (we repeat - here only the essence of the actual processes associated with revaluation is reflected)

D Profit and loss C Settlements with suppliers 1000 rub.

Please note that we make an accounting entry reflecting only the ruble amount, since when the currency exchange rate changes, it is this amount that changes. Obviously, with the growth of the currency exchange rate, in this case, we received an “unexpected” loss in the amount of 1,000 rubles, although the amount of debt in foreign currency did not change. The opposite situation occurs when the exchange rate depreciates. If at the time of revaluation the dollar exchange rate is 29 rubles, we will receive an “unexpected” profit:

D Payments to suppliers K Profit and loss 1000 rub.

In accounting there are accounts called off-balance sheet. Such accounts are used to store information without using double entry. For example, this could be information about leased fixed assets. The organization, on the one hand, must store information about them, on the other hand, they should not affect the balance sheet, since the organization does not own them, it does not charge depreciation on these fixed assets. Therefore, such information is stored in off-balance sheet accounts. Receipt entries for such accounts are made on the debit side, while expenditure entries are made on the credit account. Off-balance sheet accounts do not correspond with other accounts.

About analytics

Accounting can be maintained in one or more analytical sections. For example, for a materials account it is quite logical to provide a section Nomenclature, thanks to which you can find out which item items are taken into account on the account. It is logical to keep records of settlements with counterparties in the context of the counterparties themselves, and, possibly, agreements with counterparties, and currencies. Analytical sections It is customary, in 1C:Enterprise terminology, to call subconto. The phrase "Subconto Nomenclature" should be understood as "Analytical section Nomenclature".

Objects 1C:Enterprise and accounting subsystem

To implement the accounting subsystem, we will need the following 1C:Enterprise 8 objects:

  1. Plan of characteristics types. We will use it to store the types of analytics (subconto) that should be present in our accounts.
  2. Chart of accounts. This is the basis of the accounting subsystem. The chart of accounts stores descriptions of the accounts in which accounting will be kept. Configurations may contain an unlimited number of charts of accounts, however, usually the number of charts of accounts in one configuration does not exceed 1-2. The chart of accounts can be compared to a special-purpose directory, which is designed to store information about accounting accounts.
  3. Accounting register. It is associated with the chart of accounts and is used to store accounting records. Accounting register can be compared to a journal in which accounting records are kept.

When creating an accounting configuration subsystem, we first create plan of characteristics types- it will need to be referenced when creating a chart of accounts, then - a chart of accounts - without specifying the chart of accounts we will not be able to create accounting register.

Plan of characteristics types

Let's create a new one plan of characteristics types, let's call it TypesSubconto, rice. 1.1


Rice. 1.1.

Plan of characteristics types adds a new data type to the system, which is essentially a composite data type. This composite type of data usually includes directories, the elements of which are ultimately used in analytical accounting. Characteristic values ​​can be supplied not only by reference books - in addition, they can, for example, be documents and enumerations.

Let's add the created plan of characteristics types into the subsystem Accounting.

When setting plan of types of characteristics its properties are of particular importance Characteristic value type And Additional stat values. They define a set of data types united by a plan of characteristic types.

To properly configure these properties, before continuing, let's create a new directory - let's call it Subconto.

Let's add a directory to the subsystem Accounting.

Let's select, on the tab Owners directory settings windows, plan of characteristics types TypesSubconto as the owner, set the parameter Using Submission in meaning Elements, rice. 1.2.


Rice. 1.2.

We will not configure other directory values, although this can be done if necessary. We need it in order not to limit the user of the configuration to the subconto values, which he can set using existing directories specified in terms of types of characteristics. In fact, this will allow the user to independently set the necessary analytical sections without resorting to system configuration and setup plan of types of characteristics.

Let's go to plan of characteristics types, on the bookmark Basic open its property Characteristic value type, rice. 1.3.


Rice. 1.3.

Check the box Composite data type, uncheck the box Line(not recommended for use in plans of characteristic types