Later in this Module, we will be talking about two Metadata Classes that are very different from others. These are Catalogs and Documents, and the difference is that they are so-called Object Entities (as opposed, for example, to registers that aren't). Object Entities store data objects rather than just records, and this makes a huge difference in terms of how the Platform treats them.
So, let's see what the object entities are, how the Platform works with them and when we should and shouldn't use them.
Let's say, we pay our cashiers for hours worked, so we need to track the time spent behind the counter. Let's think for a minute how we need this to work.
Meet our very best cashier named Angus.
He works hard and sometimes logs as many as 60 hours a week.
The thing about Angus (and all other cashiers for that matter) is that he stays himself regardless of any changes.
He can grow a hipster beard, change the passport and the social security number, or even change the gender identification and the name.
But this is still the same person, and this exact person needs to get paid for all the hours logged under both Angus and Agnes names.
Now. What if one day another person looking exactly like Agnes comes to the store and claims her name is Agnes too? Is this the same person? No, this isn't. This is somebody else making false claims; and I should, probably, call 911 instead of just staring at her.
This is what the data objects are all about. They stay the same regardless of any changes, and they have an inherent and universal uniqueness about them. So another data object having precisely the same characteristics is still another data object, not the same one.
Now, let's take a closer look at these shifts worked by Agnes.
If she logs a shift incorrectly, she can fix it, but the record will still represent the same factual shift worked. In other words, this will be the same shift if differently timed.
If Agnes tries to log the same shift twice, she should get an error message, and the transaction should be canceled because one factual shift has to be represented by the only record in the tracker log.
So these tracker records are also data objects as they retain both the sameness and the universal uniqueness.
The significant difference is that they have to be bound to a specific point in time. Why? Because at the end of the month Agnes will want a paycheck, right? And this paycheck has to include all working hours logged in this month. So, the timestamp is an integral part of this data object. It just doesn't work without it.
So, both cashiers and time tracker log records should be represented by data objects. Cashiers are not bound to the timeline. In 1C:Enterprise we use Catalogs for this kind of data objects. The time tracker records are attached to the timeline. In 1C:Enterprise we use Documents to store this kind of data objects.
Now let's take a look at some non-object entity to really grasp the difference.
The classic example of a non-object entity is an Accumulation Register. So, I'm going to add the Inventory register to the Other subsystem interface and show you what's inside of it and why these are the records rather than the data objects.
So, what do we have here? These are all the document records posted to the register. Those with pluses are added to the Inventory balance, those with minuses are subtracted from it.
What happens if I replace this Pringles with the Duracell Batteries? Will this record stay the same object in any sense? No, it will become a very different animal. So, no sameness here.
What happens if I create the second record precisely like this one? Will it be an error? Should somebody call 911 or something? No, not really. It was just two separate battery packs the cashier scanned one after another.
So, no uniqueness here too.
What does it tell us? It tells that these records are not the data objects and we shouldn't use Catalogs or Documents to store them. And we don't, obviously. We store them in the Accumulation Register. And now you know why.
So, these are non-object entities. They do not retain any data-independent sameness and have no inherent uniqueness about them.