Lesson 1. Introduction, Creating an Infobase
Estimated duration of the lesson is 40 minutes.
CONTENT:
- Programming or Development?
General Overview.
Configuration and Application.
System Operation Modes.
Creating an Infobase.
In Designer Mode.
- Introduction to the Designer.
Configuration Object Tree.
Definition of a Configuration Object.
Adding Configuration Objects.
Properties Palette.
Initializing Debugging in the 1C: Enterprise Mode.
The first lesson focuses on familiarization with the 1C: Enterprise 8 and with the main development tool, the Designer.
You will learn the meaning behind the terms platform, configuration and application. You will also get to know various 1C: Enterprise 8 startup modes.
You will also learn what configuration objects are, how new objects are created and their properties defined.
Finally, you will create a new empty infobase for development of our training configuration.
Programming or Development?
What exactly am I doing?! This question comes up from time to time for everyone who has worked in 1C: Enterprise development or merely looked into it.
"I'm programming," is the most frequent response. "In what?" - "1C." "What are you working on?" - "1C." "What is it coded in?" - "1C." "Wanted, accountant with 1C knowledge," "part-time 1C programmer needed...," etc.
You can hear phrases like these ones everywhere, and you've probably heard them as well. For a casual listener they draw no particular attention. However, for those who know something about 1C: Enterprise development, questions like these are baffling, since the term 1C is used to refer to entirely different things, and the term program is just mind-boggling.
If your goal is to learn programming in 1C, this is not a totally correct goal. 1C: Enterprise 8 includes a script but this script is not the most important part of the development process. And this book does not teach you programming as people normally understand it. This book teaches development of applications on the 1C: Enterprise 8 platform. This process definitely includes programming but only as one of the development tools.
It is important that you understand it from the very beginning, as soon as you just begin to operate 1C: Enterprise 8.
To help you understand exactly what we will be creating together throughout this book, we will start with an overview of what 1C: Enterprise is.
General Overview
1C: Enterprise is a universal software for automating a company's financial and operational activities. Since these activities can be quite diverse, 1C: Enterprise has the capability to adapt to the specific needs of the field where it is used. This capability is summarized in the term configurability, which describes the ability to customize the system based on the needs of a specific company and a specific set of tasks.
What makes this possible is the fact that 1C: Enterprise is more than just a program, comprised of a set of fixed files. Rather, it is a diverse set of software tools employed by developers and users. Logically, the system can be divided into two major components that are closely interrelated: configuration and platform that controls functioning of the configuration.
To make it easier to understand the relationship between these system components, we compare it to a CD player. As everyone knows, a player is required in order to listen to music. However, given the variety of "different strokes for different folks", there are lots of CDs out there with music to suit any taste.
To listen to a track, you need to put a CD into the player, and the player will reproduce the music that is recorded on it. In addition, the latest CD players will even let you record your own selection of music, i. e. create a new CD.
On its own, the player is useless without a CD, and likewise, a CD is useless independently (except perhaps as a coaster for your coffee cup) if you don't have a player.
Getting back to 1C: Enterprise, you could say that the platform is a sort of a "player," and a configuration is a "CD." The platform allows the configuration to function and makes it possible to modify a configuration or create a new one.
There is only one platform (1C: Enterprise 8) and many configurations. For an application to operate, you always need to have the platform and some configuration (a single one, fig. 1.1).
On its own, the platform does not perform any automation tasks, since its purpose is to provide an environment where a configuration can operate. The same is true for a configuration as well: for it to execute the tasks it is intended for, it needs to have a platform that manages its operation.
Fig. 1.1. Many configurations and a single platform
Configuration and Application
Now we can finally answer the question that was posed in the previous section. In the process of reading this book and implementing the demo example, we will develop a configuration.
A word should be said about a minor ambiguity in the terminology that will be used below. The ambiguity comes from the use of various terms to refer to a single object: configuration and application.
Both terms refer to the part of the 1C: Enterprise that is managed by the platform and is visible to all the users. Of course there are users who work with the platform apparatus but those are power users. Use of one term or the other depends on the context where they are used.
When talking about a developers work, the term "configuration" is used, since this is a more precise term within 1C: Enterprise. On the contrary, the term "application" is more widely used and understood by 1C: Enterprise users.
Therefore, since the automation tasks can be quite varied, as we mentioned above, 1C Company and its partners develop applications, each of which is designed to automate one specific area of human activities. Examples of existing applications are as follows:
- 1C:Small Business Management 8,
- 1C:Accounting 8,
- 1C:Enterprise 8. Trade Management,
- 1C:Payroll and Human Resources 8,
- 1C:Enterprise 8. Manufacturing Enterprise Management,
- 1C:Consolidation 8.
There are numerous other standard applications. Standard applications are universal in their nature to satisfy the requirements of the widest range of companies working in the same field. That is a good thing.
On the other hand, this kind of universality inevitably ends up creating a situation where some companies will not use a large number of the application's features, while some of the features will be missing (you can't please everyone).
This is where configurability comes into play, since, in addition to managing a configuration's features, the platform has resources that make it possible to customize the configuration in use. Additionally, the platform will allow you to create your own configuration from scratch, if for some reason you should decide against using one of the standard configurations.
Note that, in one paragraph, we made the leap from application to configuration. There's no way around it. One way makes more sense for users and the other way for developers.
So now if we return to the CD player analogy, we are able to alter whatever melody was previously recorded on the CD to suit our tastes, and can even create disks with our own music. And we will not need any musical instruments. Everything we need to create a melody is already contained within our CD player.
System Operation Modes
In order to provide these features, 1C: Enterprise has two different modes of operation: 1C:Enterprise and Designer.
1C: Enterprise mode is the basic one: it allows users to work with the software. In this mode, users enter data, process it, and obtain the results.
Designer mode is used by developers and infobase administrators. This is the mode that provides the tools needed to modify an existing configuration or create a new one.
Since the purpose of our book is to teach you to create your own configurations and modify existing ones, the discussion that follows will deal mainly with using the system in the Designer mode. We will only run the system in the 1C: Enterprise mode from time to time to check our work.
If you study this book, we assume that you already have 1C: Enterprise 8 installed on your computer. If that is not the case, now is the time to go ahead and install it, since the text that follows is going to walk you through the logic of working with the software.
Creating an Infobase
You should have no problem installing 1C: Enterprise. For details on the installation process, see "1C:Enterprise 8.2. Administrator Guide."
You should also have no trouble with launching the software and creating an infobase with an empty configuration.
Please note! In order to create the example contained in the book, you will need an infobase intended to develop a new configuration, rather than an infobase created from a template. To do so.
Run 1C: Enterprise. In the dialog that opens you will see the list of infobases you work with. If the list is empty, you will be prompted to create a new infobase. If any infobase is available in the list (i.e. you have the demo configuration installed already), click Add to create a new infobase (fig. 1.2).
Fig. 1.2. Creating an infobase. Step 1
In the dialog that opens select Create a new infobase (fig. 1.3).
Click Next. Next select Create an infobase without configuration... (fig. 1.4).
Fig. 1.4. Creating an infobase. Step 3
Click Next. On the next step define a name for your infobase and select On this computer… for its location type (fig. 1.5).
Click Next. Next specify a directory for your infobase. The default language is English (fig. 1.6).
Fig. 1.6. Creating an infobase. Step 5
Click Next. Now click Finish (fig. 1.7).
In the 1C: Enterprise startup dialog the list of infobases will contain the newly created empty infobase (fig. 1.8).
Fig. 1.8. 1C: Enterprise startup in Designer mode
In Designer Mode
Introduction to the Designer
Now, let us run 1C: Enterprise in the Designer mode. To do so, click Designer in the startup dialog (see fig. 1.8).
The Designer window is displayed (fig. 1.9).
This is the tool we will use to create our configuration. The Designer main menu is located right below the window title. This menu includes the following items: File, Edit, Configuration, Administration, etc. Every menu items includes numerous subitems that are used to carry out various actions in the Designer.
The Designer toolbar is located under the main menu. This toolbar includes the icons to access the most frequent actions that can be otherwise accessed via the menu.
Hence, one action can be carried out in any of the two manners: by selecting a specific menu item or by clicking a corresponding toolbar button.
A large number of unfamiliar icons often confuses a novice developer. But there is nothing to worry about. In time, you will be able to easily distinguish them. Simply point your mouse cursor to any of the buttons and hover it there for a few seconds for a tooltip to appear and describe the function of the button (see fig. 1.9).
Chances are that you will initially use the menu items but eventually you will begin to use the toolbar more because it is more convenient. If required, you will be able to customize the toolbar by adding or removing specific buttons (fig 1.10).
Configuration Object Tree
Let us use the first command that is always used to begin operations on any configuration – open it. To do so, use the Configuration 4 Open Configuration menu item or click corresponding toolbar button (see fig. 1.9).
The configuration object tree is displayed (fig. 1.11).
We could say that the configuration object tree is the developer's primary tool. The configuration object tree contains virtually all the information about how the configuration is structured.
You may already be asking yourself: why does the tree contain anything before we create anything?
The answer is that, for the developer's convenience, all the configuration items are joined into groups, and at this point the tree demonstrates these groups. If you run along the tree and click the + symbols, you will find that all the groups are empty. The only exception is the group Common 4 Languages where you will find "something" titled "English." The platform created the "English" item on its own because, in this case, the designer is using the English language interface.
You are obviously ready to begin actually doing something, but first we need to go over some terminology. You may already have noticed that when talking about the contents of the configuration we have consciously avoided using specific terms. Now is a good time to define some terms and talk about configuration objects.
Definition of a Configuration Object
A configuration is essentially a definition. It defines the data that users will have access to in the 1C: Enterprise mode.
In addition, a configuration will define all of the routines that are available to process the data. Besides, a configuration contains information on how the data is to appear on screen and in printouts, and so forth. The 1C: Enterprise platform then uses this definition to create a database that will have the appropriate structure and will allow a user to work with the data.
In order to quickly and easily customize 1C: Enterprise for specific applications, all of the definitions contained within a configuration are represented as logical items named configuration objects. Perhaps you have had a chance to flip through the documentation manual "1C: Enterprise 8.2. Developer Guide", that briefly describes a configuration object.
We will not rehash that definition in this book, since our task is not to present the strategies behind the 1C: Enterprise system design as metadata structures focused on business essentials, but to teach you how to use the features of 1C: Enterprise correctly and effectively.
Therefore, we will explain the nature of configuration objects on a "work-a-day" level. This explanation will nonetheless allow you to correctly understand the objects' role in the tasks we will be dealing with.
On the one hand, configuration objects are the pieces of a set of building blocks the configuration is assembled of. A set of building blocks normally comes with a certain assortment of pieces. The pieces can be different: long, short, rectangular, square, etc. Now imagine that you can make as many of each kind of pieces as you need (say, 5 long pieces and 3 short ones). We can connect the pieces together in various ways.
The same is true for configuration objects. We can only create certain types of configuration objects. However, we can create as many as we need of each object type. Objects of one type differ from objects of another type in that they have different properties (or more precisely different sets of properties). Objects can interact with one another and we can define that interaction.
How else are configuration objects like pieces in a set of building blocks? In a set of building blocks there are usually pieces that can be attached to each other, as well other pieces, such as wheels, that cannot be attached to one another, but can be connected to an axle so that the wheel will rotate. In other words, different pieces of one set behave in a different manner.
Likewise, configuration objects have different behaviors, and that behavior depends on the type of objects. Some objects may perform certain actions, while others cannot do so, but have their own specific set of actions.
Another characteristic of configuration objects can be demonstrated using a car as an example. Cars consist of a large number of parts. An engine is one of those parts. In turn, however, an engine also consists of a set of parts, while a single part may be used in different engines.
In the same way, "complex" configuration objects consist of "simpler" objects and the same "simple" objects may be used to make up complex objects. This structure makes it easier to work with configuration objects, since, if we know how a certain "simple" object works, we will deal with it in the same manner when it is part of a "complex" object.
And finally, the most important property of a configuration object is its practical application. Configuration objects are not merely abstract constructs the developers use to attempt to describe a task at hand. Rather, they correspond to the tangible objects that are used by a company in the operations.
For example, every company uses various documents that help it to establish the facts of performance in its transactions. In the same manner, a configuration contains objects of the Document type.
Additionally, every company must maintain a list of employees and catalogs of items or goods. Within a configuration there are also dedicated objects of the Catalog type, which allow a developer to create computerized versions of these lists.
As mentioned above, based on the configuration objects, the platform will create database tables that will contain the data. In the documentation, as a rule, a configuration object and its corresponding set of database tables are referred to in the same manner.
For example, if a configuration contains the catalog object Employees, the set of tables created by the platform based on this configuration object will also be referred to as the Employees catalog.
We will steer clear of that sort of "fuzzy" writing style, and in those places where we are talking about the configuration, we will use the unambiguous term: the Employees catalog configuration object. In those places where we are talking about the database, we will simply refer to the Employees catalog.
Adding Configuration Objects
Before we begin adding initial configuration objects, note that in order to develop your own configuration to automate a company's economical activity, a developer may only use a limited set of configuration objects that is strictly specified in the platform. A developer cannot create their own configuration objects. It is only possible to add standard objects available in the system to a configuration.
Before we begin, we should explain some techniques used to operate the Designer.
In order to open or close a configuration, use Configuration4Open Configuration or Configuration4Close Configuration menu items. Respective toolbar buttons are available as well.
Once the configuration is open, its contents will be visible in the configuration tree window (see fig. 1.11). This window can be closed like any other Windows window, but if you do so, the configuration itself remains open (i.e. it can still be edited). To display the configuration tree window again, use the Configuration4Configuration window menu command.
There are several methods used to add a new configuration object. You can use the method that is most clear and convenient for you.
First method. Move the cursor to the required branch of configuration objects and select Actions4Add button in the configuration window command bar (fig. 1.12).
Second method. You can use the context menu that opens upon rightclicking. Locate the cursor over the required branch of configuration objects and right-click it. In the menu that pops up, select Add (fig. 1.13).
Fig. 1.12. Adding a configuration object
Fig. 1.13. Adding a configuration object
Third method. Move the cursor to the required branch of configuration objects and click Add (with the icon +) in the configuration window command bar (fig. 1.14).
We consider the last method to be the most convenient one so we will mainly use it in the future.
Properties Palette
So, let us begin!
Let us define a name for our configuration and use this example to introduce the properties palette a developer can use to define various properties of the configuration objects created.
A properties palette is a dedicated service window that is intended to edit all the properties of a configuration object and other related information. Since different configuration objects have very different properties, the contents of this window will vary depending on the current object (the configuration object where the cursor is located).
Now highlight the Configuration root item in the configuration object tree and double-click it to open its properties palette.
Choose StartersGuide as the configuration name.
The corresponding synonym is defined automatically but you can change it if required. In the future this is what we will see in the 1C: Enterprise working window (fig. 1.15).
When a developer executes certain actions, the properties palette is opened automatically. But developers can always open the properties palette of an object manually by selecting the Properties command of the context menu (accessed by right-clicking).
In that case, the properties palette also opens in a similar manner and docks within the Designer's work area. It means that when any configuration object is highlighted, the window of its properties will always be opened. However, there is a handy option to "detach" the properties palette using the push-pin icon in the title of the properties palette window (fig. 1.16).
In this state, when the mouse pointer is moved to any other window, the properties palette is minimized to a separate right-hand panel (fig. 1.17).
Fig. 1.16. Detaching properties palette
Fig. 1.17. Button on additional panel
It opens up again when the cursor is moved to the icon of the minimized palette.
In addition to the properties palette, other Designer windows (such as the configuration tree window) behave in a similar way (can be docked, hidden and so on).
Initializing Debugging in the 1C:Enterprise Mode
Now let us verify out initial modifications in the 1C: Enterprise mode.
To do so, select Debug 4 Start
Debugging or click the corresponding button on the Designer toolbar
. The software analyzes availability of changes in the
configuration and prompts you to update database configuration (fig. 1.18).
We will not discuss in details why it happens as this will be described in "Main Configuration and Database Configuration" (page 92).
Select Yes in the Designer prompt. The 1C: Enterprise window is displayed (fig. 1.19).
In 1C: Enterprise Mode
Appearance of the Application Interface
Fig. 1.19. 1C: Enterprise
The window title displays the name of the configuration. The empty space is the work area of the application. This area is not filled with any items for now.
Nothing is displayed in the configuration title in the 1C: Enterprise window. And this is exactly what we should have expected.
We have created neither any configuration objects, nor subsystems to display such objects yet.
The subsystems as the basis of the 1C: Enterprise interface development are discussed in the next lesson. For now, after taking a look at the summary of the first lesson, test your knowledge to see how comfortable you are with the material that has been discussed.
Quiz
- What is configurability of the 1C:Enterprise system?
- What are the major components of the system?
- What is the difference between the platform and the configuration?
- What are the uses of the two modes of running 1C: Enterprise?
- What is the configuration object tree?
- What are configuration objects?
- What does the system create based on configuration objects?
- How can one add a new configuration object?
- What is the properties palette used for?
- How does one launch 1C: Enterprise in the debugging mode?