Stored configuration and database configuration

If you quit the Designer at this point and reenter the infobase using 1C:Enterprise mode, you will see the following message:

The thing is that you cannot directly edit the configuration stored in the infobase (also known as “database configuration”). Instead the Designer makes your local editable copy of the configuration and saves it to a temporary file on your computer. The changes you make won’t get to the infobase until you explicitly perform the database configuration update. There is a special mark showing that your saved configuration has not been saved into the infobase yet:

To update the database configuration you need to press this button (or select “Update database configuration” menu item):

Running the infobase in user mode

After updating the database configuration, you can run the infobase in user mode. You can do it by pressing “1C:Enterprise” button in 1C:Enterprise startup window, or directly from Designer mode:

After this, you will see the “empty” 1C:Enterprise application doing next to nothing.

Let’s quit it and come back to Designer to start implementing our functional.

Metadata types

When you develop 1C:Enterprise application you use “building blocks” - objects, having their data structure, complex functionality and appearance. The process is pretty similar to building a house. You have bricks, floor panels, doors, windows, roof covering and so on. You might use a few varieties of bricks (of different color, for instance) but they all intended to the same purpose - to form the solid walls. Therefore they all have a lot in common. The same thing applies to doors - there are front doors and interior doors, but they all have to support “open” and “close” operations.

Here is the metadata types in the configuration tree:

Metadata types are various types of building blocks you can use developing your application. Each metadata type has its purpose and, therefore, its predefined data structure and behavior. You have to use appropriate metadata type for every specific task - exactly the same way as you use bricks to build walls and don’t use them to cover the roof or floor.

1C:Enterprise doesn’t allow you (or anyone else, for that matter) to modify the metadata types list. Coming back to the building construction analogy, you are supposed to use some specific types of building blocks and cannot add, say, bounty bars or banana leaves to the list. It makes 1C:Enterprise a specialized (rather than general purpose) development tool.

Documents

We recommend you starting app development with defining the main business transactions you need to register in your system. In our case these are:

• Purchasing materials and spare parts for repair
• Selling repair services

Let’s start with the purchase materials and see how we can implement this functionality using 1C:Enterprise.

1C:Enterprise has a metadata type specially dedicated for the purpose of registering business transactions - Document. You should use this metadata type for the list of objects with the following characteristics:

• Reflects a business transaction of another kind of event
• Has a date-time stamp (the moment of the event)
• Has a unique number

To implement our functionality we need to create a new metadata object of this type.

Metadata objects

All bricks are to form walls. But there might be a few different types of walls in your building (carrying wall, external wall, internal wall), so you are going to need different types of bricks. The same is applicable to business transactions. All types of transactions have something in common (date and time of the transaction, a unique number for bookkeeping purposes, same patterns of behaviour and so on). At the same time, every document is somewhat unique because aimed at registering its specific transaction (invoice, goods receipt and so on).

In construction you have to order what you need from suppliers, when you develop 1C:Enterprise application you can create your metadata objects that inherit basic features of their parent metadata type but allows you customize and fine-tune these features to meet your requirements.

So, unlike metadata types that hardcoded into the Platform and cannot be changed in any way, metadata objects can (and has to) be created by the developer in order to build the app he needs.

Metadata object inherits data structure, default behaviour and interface appearance from its parent metadata type.

Let’s create our first metadata object (document) and see what does it look like in “all-by-default” mode - without any customization.

Creating “GoodsReceipt” document

Every time we unload the shopping truck to our warehouse we want to register this fact creating a new document. Let’s name this type of documents “GoodsReceipt”.

As you can see 1C:Enterprise has automatically generated default user interface allowing you to work with the metadata object you’ve defined including the creating and deleting of the documents themselves in 1C:Enterprise (i.e. user) mode.

Now we need to define the data we want the document to contain. Here is a list of attributes we need:

• Date and time of the event
• Unique number for accounting purposes
• Warehouse (where we unloaded the delivery truck to)
• List of materials (what did the truck deliver):
  • Material (what kind of good it is)
  • Quantity (how many of it we get)

System attributes of documents

All documents are intended for the same purpose - to register business events meaningful for bookkeeping purposes. Therefore, all documents have the same predefined attributes:

• Date and time of the event
• Unique number

There is no need to add them, and there is no way to delete them (but you can adjust the way documents are being numbering). Let’s add other attributes we need.

Adding Warehouse attribute

We can add a new attribute “Warehouse” right in the configuration tree:

After this, we need to choose the proper type for the attribute using the properties palette:

Default type 1C:Enterprise offers is string, which seems to be not the best idea for this attribute:

• User can put it in more than one way (“warehouse 1”, “Warehouse on Main St”) or simply misspell it (“warehouse 1”) while typing and the application cannot control it. As a result, you will not be able to filter docs by warehouse;
• If you need to rename the warehouse you have to do it in all the docs related to it - one by one;
• User will spend an extra time typing the warehouse name (it would be easier to select what he needs from a list);
• There will be excessive disk space spent.

As a solution to the problem, we need to separate the list of warehouses into a different metadata object. Let’s see how it works.

Course description | Lesson 1-3