1C:Professional training course. Lesson 2-2

Lesson 2-2

Virtual secondary data

Now let’s delete these Total attributes and calculate all we need on-the-fly.


We also need to calculate the overall total for the entire document. This implementation is pretty similar to what we did for the persistent Total document attribute, except that this time you need to add this attribute to the form by yourself.

One more thing you should know about. You might have noticed that when we had the Total attribute stored in the Materials tabular section, form list of attributes looked like that:

It means that the Platform knows how to calculate the sum for every persistent attribute in the tabular section. So we could just put the TotalTotal attribute anywhere in the form and get the overall document price calculated automatically.

Secondary data: Virtual vs. Persistent

So, what we choose - persistent or virtual secondary data? The question is not that simple, unfortunately.

The important thing about secondary data is that they are always calculated, and, obviously, this calculation takes resources. Calculating the secondary data, we are slowing down the system and increasing its response time. The difference between persistent and virtual secondary data is all about when we want the resources to be spent or (which is the same thing) what operation we want (or can afford) to slow down.

Persistent secondary data calculation takes place when primary data are changed, i.e. during write operations (saving and posting documents and so on). Virtual secondary data calculation takes place during read operations (refreshing forms, filling out reports and so on).

Note, that persistent secondary data usually calculated less frequently than virtual secondary data (because data are read more often than they are written), but the calculation itself is more complex.

One more thing to consider is developer's resources. Persistent secondary data calculation takes much more time to implement and maintain. You need to follow specific practices to reduce the likelihood of errors and allow developers to make changes in the code easier. In that sense, virtual secondary data look more natural and less messy.

All in all, it's really hard to say in advance, which type of secondary data is a better choice in each real-world case. Therefore, the most practical advice will be the following: use virtual secondary data until you see that some specific read operation needs to be speeded up. Then introduce the persistent secondary data (only for this specific operation). Remember, that speeding up the reading you are slowing down the writing, but if you do everything right, this slowing down won't be noticeable.

The Services document

Now let’s start registering our sales. We sell home appliances repair services. One service transaction can contain one or more services we provided and some materials we used to perform a repair. So, the most obvious Sales document structure would be the following:

We need to register the customers and the technicians who perform the services. This is what the attributes “Customer” and “Technician” are for. Both attributes are supposed to be of the CatalogRef type, so we need to create two Catalogs for these purposes: Customers and Employees.

We also need to know where did we get the materials from, so we need the Warehouse attribute that has “CatalogRef.Warehouses” type. Please, note, that we assume here that all materials for one repair are taken from the same warehouse. If this might be not the case, we will have to move this attribute into the Materials tabular section.

Then, we have two separate tabular sections - Materials and Services - intended for registering the lists of materials we used and services we provided, correspondently. The Services tabular section contains the Service attribute having the CatalogRef type, so we need one more Catalog for the Services we can provide.

As you might have noticed these two tabular sections have a lot in common:

  • Both of them have the Quantity and the Price attributes;
  • For both of them we need to calculate the Total prices (for each tabular section line as well as for the entire document).

The only thing that really differs here is the first tabular section attribute referencing to the Materials or Services catalog. But what if we combine these two catalogs into one?

Combining Materials and Services into one catalog

In other words, we can try to store everything we sell in one catalog regardless of what it is - a material or a service. Basically, all we need to do is renaming the Materials catalog we already have:

The catalog supports hierarchy, so we can split materials and services into different folders to keep things tidy and easy to find.

Now we can get rid of the second tabular section and simplify the Sales document structure like this:

Developing 1C real-world applications, you are going to decide, what approach works better in every case - separating entities into different metadata objects or combining them into one object, even though they have some differences. There is no right or wrong answer that fits anyway. Separating entities usually results in more accurate and readable code, but might have its drawbacks, including performance issues. Combining different entities into one metadata object usually looks messy and takes more time to add new functionality, but sometimes can work more efficiently.

That said, there is no way you will know for sure which approach is the best option in every case. You will have to make a decision based on your experience and intuition and then, down the road, if you happened to choose the wrong path, you will need to perform a code and metadata refactoring in order to make the code more understandable, or optimisation in order to make it work faster.

Warehouse inventory balance

Let’s consider this common scenario of the Sales document usage:

  • Client calls to your office to order a dishwasher installation;
  • Receptionist answers the call and prepares the Sales document filling it out with the following services and materials:

    • Services:

      • Service call;
      • Unpacking;
      • Installation;
    • Materials:

      • 1 dishwasher branch tailpiece with nuts and washers (1-1/2-in x 8-in)
      • Disposal connector with clamps
      • 1 angle ball valve
      • 1 x 3-way brass adapter (3/8-in O.D.)
      • 1 x 16-in and 1 x 60-in braided stainless steel flex connector
      • Teflon tape
  • Receptionist tells the overall price of the service to the client;
  • Receptionist checks the availability of technicians and arranges a scheduled time;
  • Receptionist posts the document and tells a technician to fulfill the order;
  • Technician drops by to a warehouse, picks up all necessary materials and goes to the client’s place…

Wait… What if there is no “3-way brass adapter” (whatever it is) left in the warehouse?

In this case the technician misses the scheduled time (because he needs to go and get some more adapters first), client gets frustrated, posts an adverse feedback on your website, calls to another company, and you lose some money that could be yours.

So, we definitely need some way to check if there are enough materials in a warehouse to complete the order. This procedure is called balance control and involves a check of the current warehouse balance against the materials we need for the order we are filling out.

But where do we get this balance from? On the one hand, we have all the information we need: GoodsReceipt documents reflecting every material purchase transaction we’ve made and Sales documents reflecting every material we’ve already spent. But let’s consider how we can calculate the current number of adapters left? To do so we need to sum up all adapters we ever bought (by cycling through GoodsReceipt documents and through their Materials tabular section), then sum up all adapters we ever used for service (by cycling through Services documents and their Materials tabular section) and then subtract the second sum from the first one. Sounds like a lot of work, and the worst part is that the calculation is to take more and more time down the road - as we add new documents to the system.

It means that we need some other place to store the current inventory balance for every material. This balance needs to be calculated on the fly so we can check every Service document against it.

1C:Enterprise supports metadata objects specifically implemented for this purpose - accumulation registers.

Accumulation register basics

We use accumulation registers when we need a quick answer to the question “How many things are left” at any point in time including now.

Accumulation registers store secondary data, meaning that there is no new information in there - all of this is already known, the register just store it in another form - more suitable for a fast balance calculation than the primary data is.

Accumulation registers are not for direct users’ input. Usually, they are filled out automatically when a user is posting a document. This is how it works:

As you can see on the picture above, this accumulation register sums up resources (quantity in our case) across dimensions (warehouses and materials). For those of you who are familiar with SQL, this operation can be represented as following:

SELECT SUM(Quantity) FROM

Accumulation register dimensions

Accumulation register dimensions basically define how the balance is sliced up, in other words - how much balance records the register is to have. Dimensions can be of any type although CatalogRef type is used most of all.

Accumulation register resources define what is to sum up into a Balance table. Resources can be of the Number type only, although the number can represent anything that’s numeric: amount, weight, length, volume and so on.

You can specify no dimensions. In this case, you will get the Balance table containing only one record. This line will sum up all resources (materials’ quantities in our case) across all warehouses and all materials, so you will get the overall quantity of all materials you store in all warehouses:

We can add the Warehouse as the only dimension in which case the sum above (47) will be splitted up in these two records:

Or, we can use the Material as the only dimension and get these three balance records:

Obviously, not all of these Balance tables are of the practical value for us. There is no much sense in the overall number of everything (connectors, valves and adapters combined) stored somewhere (no dimensions or the Warehouse as the only dimension). On the other hand we could use the overall number of various materials throughout all warehouses (the Material as the only dimension) and it’s perfectly meaningful to keep track of the balance of every material in every warehouse (two dimensions).

So how do we choose the dimensions structure?



Lesson 2-1| Course description| Lesson 2-3

1C:Enterprise Developer's Community