As we saw in episode three, the platform uses the rep standard attribute as an internal object identifier. This is how the platform tells one object from another. But sometimes, we, humans need to identify objects too. For example, any countable document must have a unique number so that people are always sure they talk about the same document. Another example is person's initials, or short nickname that can be easier to refer to instead of something like Constantine Rubasov, or Zachary Galifianakis. This is what we use code, and number standard attributes for. The code attribute lives in the catalogs, and number attribute lives in the documents. As you will see, these two attributes are named differently but work essentially the same. You can specify the catalogs code and the documents number manually, but we use it for identification so it has to be unique to some extent, right? This is why it's usually assigned automatically. It's also tab here on the numbering tab, and there are our auto numbering checkboxes. You can also ask the platform to make sure that all codes or numbers are unique using these checkboxes. Even when the auto number in his own, you still can set the code or number manually. But the platform will ask you to think twice before doing that. Both code and number can be a string or a number. This is how it's setup for the catalogs, and this is for the documents. The difference will be that the string code number will be padded by leading zeros like this. Another difference with the string type attribute is that we can add a prefix to it. This is done right here in the metadata object module. Here is the onset new number event, and channeler has the prefix parameter. I can set it to any string, and these are the document numbers I'll start getting. It works the same for the catalogs, but the event is called onset new code. This prefix thing opens up some interesting prospects, number and lice. For example, I can maintain several independent number sequences within one metadata object. I might not want my purchase documents to be numbered continuously. If these two documents belong to the infinity food supplier and this one belongs to the gross grocery, then I really should expect questions like, "Sorry, is this our first document and where it's numbers two then?" Or, "Excuse me, did we lose our second document somewhere? Because we have number three following number one. " I want my purchase documents to be numbered separately dependent on the supplier. This is how we do that using prefixes. First of all, I need to buy-in the purchase documents with my company's catalog like this. Then I will create a new attribute named "prefix" here in the company's catalog. Now I'm going to the purchase documents metadata objects module, creating the onset new number event handler, and writing this simple code. Said the prefix chew this object, which is the current purchase document, dot our new company attribute, dot, and our new prefix attribute, or the company's catalog. Okay, let's try it. First I go to the company's Catalog and assign the prefix for the infinitive foods company. Then I create a new company and give it another prefix. Now I'm creating a purchase document of either infinity foods. Here we go. The document to be IFD prefix is here. The second one with the same company, and the document number is increased by one. Okay, let's try that gross grocery supplier. Here's document and we have another number one document but with a different prefix. The second one, and the number is now two. I have an independent number in, for each prefix, great. Wait, and what happens if I use the same prefix for another company? Well, let's try. I'm going to create a test company and give it the same prefix as my infinity foods has. Now if I create a purchase document of this test company, I'll have the document Number 3. What the platform does, it just remembers older prefixes and tracks the number sequences inside each one of them. If it sees the same prefix, it just uses this prefix sequence, that's it. We can use the prefixes and just a tiny bit of code in to split the number and sequence of a single metadata object. Platform also supports some other fully automatic ways of splitting the numbering. For the catalogs, this feature is called code series, and it works along with the hierarchies we were talking about in the last episode. Remember these two standard attributes. If I select this option, the numbering will be split between parents. There will be one independent sequence of codes within each group, or within each item if it's the item-item hierarchy. If I select this option, the same will happen to the ownership hierarchy. Each owner will have its own independent sequence of codes. There is some number and sequence splitting for the documents to, it's called periodicity and it's built around a document's date. The idea here is that we might want to reset the document number once in a while. You're now starting your life from mundane celebrated by starting overall document counters. On a serious note, there might be official requirements about the same numbers of unaccountable documents. These are our options. We can reset the counter and start the number in order at the beginning of a year, a quarter, a month, or a day. These were splitting the number and sequences within one metadata object. Sometimes reasonably rare, we need the opposite to keep the single sequence of numbering across several documents. It might be necessary, for example, for somewhat similar documents that belonged to the different metadata objects. In this case, we use document numerators that live right here. We can set up these already familiar properties for a numerator and then use it in as many documents as we need. Just like this. These are our numbering options. Stay tuned for the next episode about predefined data.
