1C:Enterprise 8.3. Developer Guide. Contents
CONCEPT OF THE SYSTEM
1C:Enterprise is an all-purpose enterprise automation system. The all-purpose nature of the 1C:Enterprise system means it can be used to automate the most diverse areas of economic operations: accounting for merchandise and materials, mutual settlements with contractors, etc.
1.1. CONFIGURABILITY
A major feature of the 1C:Enterprise system is its configurability. The 1C:Enterprise system itself is a set of mechanisms designed to manipulate various types of objects in a subject area. A set of objects, data array structures and information processing algorithms for the assigned task are defined by a specific configuration. Joined with the configuration, the 1C:Enterprise system functions as a ready-to-use software product customized for particular enterprise types and task classes.
The configuration is created and supported by standard system tools. A configuration is usually supplied as standard for a particular area of application, but it may be modified or extended by the user or developed from scratch. The 1C:Enterprise system supports standard configurations using standard tools.
1.2. FUNCTIONING OF THE SYSTEM
Functioning of the system involves two processes: development (description of a subject-area model by system tools) and execution (processing of subject-area data).
The development stage includes:
Structuring the processed information
Creating forms for source data entry and data list display
Storing the entered and derived information
Generating reports and data processors
Creating command interfaces for various user groups
Creating a user list
Assigning rights to users
Development results in software (configuration) representing a model.
The designing mode permits the user to create new configurations, edit the existing ones and compare or merge several configurations.
At the development stage, the system uses universal concepts or objects such as Document, Document Journal, Catalog, Attribute, Form, Register and others. A set of these concepts defines the concept of the system. In its turn, the configuration process is broken down into several components (this is an arbitrary division) that define the order in which volumes of description are written and assigned. These are "visual" configuration (creation of the configuration structure, forms for dialog boxes and output documents, user-data interaction mechanism or interface and access rights of various user groups to various types of information) and generation of programs in the 1C:Enterprise script for processing input and output data.
The actual concepts of objects and standard operations for processing them are defined at the system level. Configuration tools can be used to describe the structure of information included in the objects and algorithms that describe the specifics of their processing to account for their various accounting features.
The information structure is designed at the level of the processable subject-area objects specified in the system (constants, catalogs, documents, registers, enumerations, etc.).
As it runs, the system works with specific concepts described at the configuration stage (product and organization catalogs, bills, invoices, etc.).
When the user works in the 1C:Enterprise mode, information is processed both with standard system tools and using algorithms created at the configuration stage.
1.3. BASIC CONCEPTS OF THE SYSTEM
This section discusses the basic concepts used by the 1C:Enterprise system. It is useful to those who are not yet familiar with the 1C:Enterprise system.
The description of various mechanisms is illustrated with examples. You can encounter unfamiliar terms and concepts in the description. Keep reading – the meaning of the terms used will become clear as you do so; if you want more detailed information, you can always refer to the corresponding chapters of this guide.
1.3.1. Configuration Concept
The basic concept is that of configuration.
In the 1C:Enterprise system, a configuration means a set of interrelated components:
subsystems
accounting data structures and data input, selection and print forms
a set of mechanisms for totals accounting and register records of accounting data
a set of various reports and data processors
command interface
a set of roles or access rights
a set of common procedures and functions (application module, managed application module, external connection module, session module, and common modules), spreadsheet templates, etc.
auxiliary objects:
○ functional options and their parameters
○ settings storages
○ Web tools (Web-services, WS references)
○ various auxiliary information (pictures, templates, styles, etc.)
In fact, a configuration structure is a subject area model. A configuration is created using the Designer. The resulting configuration is used by the 1C:Enterprise system to create a software environment suitable for the accomplishment of the necessary accounting tasks.
Roles in the 1C:Enterprise system define whether users can work with information processed in the system. A set of privileges granted to the user is generally defined by the scope of the user's duties.
Assignment of roles to the user accomplishes two things:
On the one hand, it limits the number of users having access to sensitive information that is always a part of any accounting system.
On the other hand, prohibition of certain operations (primarily data deletion and editing) helps prevent a possible loss of information.
All components of a configuration are closely interrelated and generally require consistency in making changes (this applies especially to user rights).
Thus, roles can be assigned only for existing configuration objects (specific documents, journals, catalogs or reports). Insertion of an object into the configuration structure must be accompanied by appropriate role changes.
When creating a command interface, the system accounts for the assigned object rights. For example, if a user is not allowed to view a catalog, the Open command for the catalog list form is automatically removed from the command interface. When displaying forms, granted rights are also important.
1.3.2. Configuration Object
In the 1C:Enterprise system, a configuration object means a formal description of a group of concepts (the subject area and the means of interaction between the user and the system) with similar characteristics and the same purpose.
Consider the following example. The Catalog configuration object in 1C:Enter- prise is intended for maintaining lists of similar data items: catalogs, card files, regulatory handbooks and the like. Use of this type of configuration objects enables the user to organize any catalogs needed to automate enterprise operations.
As a rule, Catalog type configuration objects are electronic equivalents of catalog types that actually exist at the enterprise (e.g., a catalog of employees or a product list), although they can also be used to organize lists that have no obvious physical equivalents.
Please keep in mind that configuration objects describe value types rather than specific values. For example, the Persons catalog does not describe particular persons; it contains a list of attributes (a set of characteristic types for an individual person) as well as forms for entering their values, forms for viewing lists and templates for printing information. In other words, the configuration contains a descriptive model that is used to account for all similar objects in a subject area (in the above example with the Persons catalog, a single description is used for both Peters and Jones or any other person).
Therefore, a configuration object is an electronic equivalent of a particular concept in a subject area implemented in the 1C:Enterprise system using a configuration object.
1.3.2.1. Properties of Configuration Objects
Each configuration object possesses a unique set of properties. This set is described at the system level and cannot be changed during task configuration setup. The property set of a configuration object is determined mainly by its purpose in the 1C:Enterprise system.
The main property of any configuration object is its name – a short description of the configuration object. When a new configuration object is created, it is automatically assigned a conventional name consisting of a word determined by the object type and a number (for example, when an attribute is created, it is named Attribute1; when a document is created, it is named Document1, etc.). This name can be changed when editing configuration object properties; the system makes sure names are unique. The name of a configuration object cannot be null.
Of all the properties inherent in a configuration object, some are available for editing and can be modified during system configuration. Types of possible changes and their limits are set at the system level. The specialist configuring the system can intentionally modify properties of a configuration object to make it behave as desired when the system runs. However, these changes do not alter the essence of the object and will not enable it to perform actions that are not inherent in objects of this type.
Consider the following example.
The Constant configuration object in the 1C:Enterprise system is designed to store information that does not change over time or changes very rarely. Previous values of a constant are irrelevant. A simple example of a constant would be the name of the enterprise: it generally does not change as the enterprise operates (if you expect to select values of time-variable accounting data depending on the timing, you should use an information register without dimensions rather than a constant).
A constant has a large number of editable properties. The following are the most relevant:
constant name
synonym (alias)
comment
data type
data lock control mode
link opening the constant manager module
In the most general case, the value of a constant is entered once (for example, the enterprise name). From the standpoint of constant use, it is not important what exactly is stored in the constant; what matters is that the constant should preserve the entered value.
The ability to preserve the entered value is an integral feature of constants in the 1C:Enterprise system. Editing constant properties does not affect this ability.
1.3.2.2. Basic Types of Configuration Objects
All the configuration objects that exist in the 1C:Enterprise system fall into several basic types. Each type makes up one of the "building blocks" that are used to create a configuration.
Formally, configuration objects are combined into types in the configuration tree. Type names are displayed at the top level of the configuration tree when you open the Configuration window in the Designer (see fig. 1).
Even though there is no formal definition, names of configuration object types are widely used when working with the 1C:Enterprise system.
Fig. 1. Metadata Tree
For example, a specialist who configures the 1C:Enterprise system aims to develop a required set of catalogs, documents, reports and journals that implement the desired accounting system. The end user of the 1C:Enterprise system – an executive, accountant, manager, storage clerk, etc. – also works with particular catalogs, documents and so forth to accomplish his/her tasks. These two categories of users also communicate in terms of configuration object types.
A data object of some type is a specific document, report, journal, constant, etc. Each object is generally used to work with specific information of a subject area.
Below we outline basic types of configuration objects in the 1C:Enterprise system. Detailed information on the configuration objects that make up each of these types is provided later in this guide. Constants
The system uses Constant type objects for constant and nearly constant data. Information stored in constants rarely changes, but is often used, as a rule. For example, constants can store the name of the enterprise, its tax ID, names of the director and chief accountant and similar information. The system supports an unlimited number of constants.
Catalogs
The system uses Catalog type objects for constant and nearly constant data consisting of value sets.
Catalogs are usually lists of materials, products, entities, currencies, employees, etc.
The catalog engine allows the user to design and support various catalogs. Properties of each catalog can be described at the configuration stage. Customizable properties include, for example, code length and type, number of hierarchical levels, code uniqueness support and catalog attribute set.
Aside from the code and description, the catalog engine allows the user to create attribute sets for storing any additional data about catalog items (e.g., for a product line it could be the purchase and sale prices and the manufacturer; for an employee it could be his/her job title, education, residence, etc.) as well as tabular sections. Tabular sections store variable arrays of similar-type data, such as description of product components, list of employee family members, organization telephone numbers, etc.
Each catalog has several form type options: item, folder, list, selection and folder selection. You can create an unlimited number of forms of each type.
You can use subordinate catalogs to describe subordinate entities. In this case, each item of the subordinate catalog "belongs" to a particular item of the parent catalog.
In a specific configuration, the required number of catalogs is created to store data on objects used to automate the given subject area. For example, you might have catalogs called Organizations, Goods, Employees, etc. Enumerations
The 1C:Enterprise system uses enumerations to describe constant sets of values that do not change as the configuration runs.
At the configuration stage, you can describe a virtually unlimited number of enumerations. Unlike values in a catalog, enumeration values are specified at the configuration stage and cannot be changed at run time.
Typical examples of enumerations are forms of payment (cash, check or barter), client status (regular or one-time), etc.
One of the main features of an enumeration that makes it different from a catalog is that a set of values within enumeration does not change as the end user works with the system. For example, the configuration algorithm could be designed so that each client has one of two statuses: either "regular" or "one-time". In this case, the user can specify the client's status by selecting one of the values from the enumeration. The user cannot add a new status.
Enumerations are different from catalogs in that you normally enter specific values for catalogs as you work with the program, for example: product names, contractors, etc.
Documents
Documents are objects used to represent business process events pertaining to the automated subject area. For example, a configuration designed to account for trading transactions may contain documents such as bills, receipts, invoices, etc.
Documents are used to show payments from the account, cash register transactions, warehouse register records and other similar events.
Configuration involves customizing an arbitrary number of document types. Typical examples of document types are Purchase Order, Bill, Goods Receipt, Sales Invoice, Warehouse Transfer, Cash Receipt, etc. Each document type represents a certain event type. It determines the structure and properties of the document as defined in the configuration.
Each document type can have an unlimited number of attributes and tabular sections. Several tabular sections are required when one document must record essentially different but related events, for example: to show receipt of goods at the warehouse and record additional expenses incurred – payment for transportation, truckers, etc.
Document data are entered via input forms which are on-screen equivalents of hard-copy documents. If the document data are used in other forms, forms selection are created to include this information. List forms are created for editing the list of documents of a given type. The number of forms is unlimited.
Each document can also have an unlimited number of print forms.
All documents are characterized by a number, date and time. At the document setup step, other options such as document number length, number uniqueness rules and others can be set.
Documents are central to the basic mechanisms implemented by the system. All documents form a single chronological sequence. The latter represents the sequence of actual events. Within a certain date, document sequence is defined by the document creation time. The document creation time is a way of arranging documents in a proper and unambiguous order within the same date rather than a record of the actual (astronomic) time of document input. Data entered in a document (in its attributes and tabular sections) usually contain information about an event – for example, an invoice contains information about the originating warehouse, the type and quantity of goods shipped and any additional expenses incurred.
A crucial action for a document is its posting. If a document is not "postable", it means that the event it reflects does not affect the state of the accounting maintained in that particular configuration. If a document is posted, it changes some of the accounting data. Posting permits the event recorded in the document to be reflected in the mechanisms implemented by various registers.
For example, a company can use Quote documents. These documents indicate customer’s intents to buy goods or services and they usually do not alter the status of the goods or cash. Therefore, they do not require posting transactions to accounting registers.
In some cases a Quote can be used for reserving goods for a specific customer. This locks a certain quantity of goods and removes them from the warehouse balance. Therefore, this document will require posting the transaction to accounting registers.
Document Journals
Document journals are designed for viewing various types of documents. Each document type can be shown in several journals. A document journal does not add new data to the system; it is a means of displaying documents of several types in a single list.
For example, you can create a Warehouse Documents journal which will show all receipts and invoices as well as internal waybills.
You can define columns for a journal to show attributes of the various document types assigned to the journal. For example, a trading document journal can include a Counterparty column that contains the Vendor attribute of a Purchase Order document, the Customer attribute of a Sales Invoice document, etc. Each journal can have an unlimited number of display and print forms.
Reports and Data Processors
To describe reports and information processing procedures, an unlimited number of reports and data processors can be created at the configuration stage. Reports and data processors can have several forms designed, for example, for entering report generation or data processing parameters. For example, to generate a warehouse report, select a specific warehouse.
The algorithm used to obtain a report can be described using the 1C:Enterprise script or automatically created by the system if the data composition schema is used (see page 1-531). To generate reports, you can use either text format or a specialized tabular report format (templates).
The system also supports development of external data processors stored in separate files rather than the configuration.
Charts of Characteristic Types
In the 1C:Enterprise system, Charts of characteristic types objects are designed for describing sets of similar analytical accounting objects.
Charts of Calculation Types
Objects of this type are designed for creating calculation types used in periodic payment mechanisms.
Charts of Accounts
A chart of accounts is one of the basic accounting concepts. A chart of accounts is a set of synthetic accounts that group information about enterprise transactions. Data stored in synthetic accounts enable the user to get a complete picture of the state of enterprise funds in monetary terms.
Exchange Plans
This object type is used to arrange data exchange between different infobases or between infobases and external software systems.
Business Processes and Tasks
These are designed to create formal descriptions of standard job sequences within the organization that are later used to make lists of tasks assigned to an employee at a specific point in time. For example, a process of product sales can be represented as a sequence of events: billing, bill approval, cash payment and product shipment from a warehouse. Each step can be assigned to a different employee. Therefore, you can see the state of the product sales process at every step and identify an employee responsible for specific actions at this step.
Registers
Registers are designed for storing and processing various information that reflects the enterprise commercial and organizational operations and has no objective nature.
Registers usually store information on changes in the status of objects or other information that does not directly reflect subject-area objects. For example, registers can hold information on currency exchange rates or information on the receipt and dispensing of merchandise.
The 1C:Enterprise system has four types of registers:
information registers
accumulation registers
calculation registers
accounting registers
Specialized Configuration Objects (Common Branch)
In addition to objects that describe the domain of accounting, the configuration contains several auxiliary objects that do not relate directly to the enterprise operations, but are closely tied to the functioning of the system itself. These are mechanisms that help users interact with the 1C:Enterprise system (command interfaces, filter criteria, access rights of various user groups to different types of information); auxiliary formatting objects that enable configuring based on existing styles, picture libraries that take the national language into account; the application module and common modules containing procedures and functions accessible from other configuration modules; common print form templates and much more.
1.3.2.3. Subordinate Object Groups
Depending on the type of a configuration object, it can have various subordinate object groups. For example, attributes, dimensions, forms, tabular sections, etc. The type of the object determines the structure of its subordinate objects.
Attributes are additional object information that is accessible from within the object only.
Tabular sections are sets of additional information about the object represented as a table.
IMPORTANT!
A tabular section cannot contain more than 100,000 lines.
Attributes of tabular sections are the contents of the object tabular sections that are accessible from within the object tabular sections only.
Forms are used to enter, view and edit information stored in a configuration object; each form contains a form module, i.e. a program in the 1C:Enterprise script. Having a visual representation configuration objects can interact with users. Nature of this interaction is defined by the specialist who configures the 1C:Enterprise system and is determined mainly by the type of the configuration object. To develop forms, the Designer has a comprehensive form editor which enables you to edit all components of a form interactively. Each object can have several forms.
Commands are used to run operations with an object. They can be independent or defined by parameters.
Templates are spreadsheet, HTML or text documents (you can also use binary and Active documents) designed to generate print forms for an object.
Graphs are columns of document journals.
Dimensions (for registers) are configuration objects with data accounted for in the register.
Resources are data accounted in the register.
Groups of subordinate objects cannot be deleted and do not have editable properties.
1.3.2.4. Typed and Type-Specifying Objects
One of the main properties of certain configuration objects is Type, which represents the object data type. This property defines the kind of information that the configuration object can contain. Configuration object data type is set when object properties are created or edited during configuration setup.
In the 1C:Enterprise system, configuration objects whose information type can be specified are called typed configuration objects.
Configuration objects such as Catalog, Document and Data Processor are not typed because they contain "complex" information and typed configuration objects.
Possible configuration object data types can be divided into two groups.
The first group comprises primitive data types: Number, String, Date and Boolean. Accordingly, information stored in a configuration object can be a number, an arbitrary character string, a date or a logical value. Additionally primitive types include NULL, Undefined and Type (for details see section "Primitive Data Types" in the 1C:Enterprise script help).
Some configuration objects in the 1C:Enterprise system can also specify data types. For example, a constant can be assigned the DocumentRef data type. In this case, the constant value represents a reference to a document existing in the 1C:Enterprise system.
Configuration objects that can specify types of configuration values in the 1C:Enterprise system are called type-specifying configuration objects. These are:
catalogs
documents
charts of characteristic types
charts of accounts
charts of calculation types
exchange plans
business processes
tasks
enumerations
Please note that type-specifying configuration objects specify the data type as soon as the Designer creates any of these types of objects. Three new types appear immediately: Ref, Object and List. For example, when the Designer creates a new catalog, new data types appear in its list of data types: CatalogRef.<CatalogName>, CatalogObject.<CatalogName> and CatalogList.<CatalogName>. These data types can be assigned to any typed configuration object.
Some data can be assigned composite data types. To do this, select the Composite data type check box in the data type editing window and specify the types that data can have. You can also select a special type, AnyRef.
In addition to selecting attribute data types defined in a particular application, you can select sets of types. AnyRef, CatalogRef and Characteristic.<name> are examples of type sets.
Type sets, like the composite data type, contain a certain list of types defined in the application, but, unlike the composite type, the system generates this list automatically based on metadata analysis.
For example, an application contains Nomenclature and Contractors catalogs. If composite data type attributes are defined and contain CatalogRef.Nomenclature and CatalogRef.Contractors types, you can define another attribute containing the CatalogRef type set. In both cases, the attribute can store references to the Nomenclature and Contractors catalogs.
After you add a new Prices catalog, the composite type attribute can still only store references to the Nomenclature and Contractors catalogs, while the attribute described as a type set allows you to store references to any catalog available in this configuration, including the Prices catalog.
Upon application startup, the system usually converts the type set to the composite type which contains all types included in this set. Therefore, the new Prices catalog is included in the type set in the second case.
However, the system does not always convert the type set to the composite data type. If a single value type is included in the type set, it is converted to this value type. This is possible when a chart of characteristic types (e.g., Properties) has a single value type in the CharacteristicValueType property. Then the system converts the Characteristic.Properties type set to the only value type specified for the chart of characteristic types rather than to the composite data type.
This feature may be important when, for example, an attribute whose type is described as Characteristic.Properties is checked for completeness. If Characteristic.Properties is converted by the system to the composite data type, you should run a check for the Undefined value; if Characteristic. Properties is converted to a specific value type, a check for the default value of this type is required.
1.3.3. Command Interface
Command interface is a basic tool allowing the user to navigate the configuration functionality. It is based on subsystems. The configuration developer includes application objects into the corresponding subsystems.
This information (i.e. the structure of subsystems and object assignments to subsystems) is used in the system to create a command interface for the user automatically. The user can see application structure (subsystem hierarchy) and use standard commands to access application object functionality (e.g., call catalog or document lists, open reports or data processors, etc.). At the same time, the developer can edit the system layout of the command interface (change the command order and display options). A command interface editor serves this purpose. It can be called both for a particular subsystem and for all subsystems.
Commands included in the command interface (opening lists, entering new objects, opening reports, etc.) are automatically provided by the system. The developer can also create custom commands to be displayed in the command interface.
The interface gives users quick access to the information they need to perform their duties.
1.3.4. Form
Form is a combination of a dialog box, module, attributes and commands.
Most configuration objects in the 1C:Enterprise system can have a visual form. In the most general case, a form as a configuration object comprises the following components:
on-screen dialog box used to enter and edit information;
form module, i.e. program in the 1C:Enterprise script. The form module generally processes information entered in the dialog box for input control, calculations, etc.;
list of attributes;
commands used in the form.
Any of the form components can be blank, in other words, contain no information.
Forms can be used to implement user interaction with an application object. The corresponding behavior is defined by the specialist who configures the 1C:Enterprise system. For details on form structure see page 1-361.
To develop forms, the Designer has a form editor which enables you to edit all form components interactively.
1.3.5. Module
Module is a program in the 1C:Enterprise script. Modules are located at specified points in the configuration structure and executed at predefined times in the course of 1C:Enterprise operation. The specialist who configures the system can use modules to describe complex algorithms of interaction between configuration objects that do not have adequate visual tools available in the Designer.
A configuration has several types of modules. These are: managed application module, ordinary application module, external connection module, session module, common modules, form modules and configuration object modules (value managers for constants, catalogs, documents, charts of characteristic types, charts of accounts, charts charts of calculation types, exchange plans, business processes, tasks, reports, data processors and sets of register records), configuration object manager modules (for catalogs, documents, charts charts of characteristic types, charts charts of accounts, charts charts of calculation types, exchange plans, business processes, tasks, reports, data processors, information registers, accumulation registers, accounting registers, calculation registers, enumerations, document journals and settings storages), record set modules (information registers, accumulation registers, accounting registers, calculation registers), command modules.
To access a module, select Open Object Module… in the configuration object context menu. Select managed application module, session module, external connection module and ordinary application module for the root configuration object. Some objects (for example, constants or document journals) have no modules.
For a detailed description of modules see section "What is a Program Module?" in the 1C:Enterprise script help.
Within object modules you can declare variables, procedures and functions that extend the object context and are available for working with the object externally using the 1C:Enterprise script. These modules contain procedures for processing various events, for example, Generate. They also have various procedures to perform actions with an object that are initiated from outside the object (for example, printing).
Manager module allows you to extend the system-provided manager functionality by creating procedures and functions using the 1C:Enterprise script. In fact, this enables you to define methods for a configuration object (e.g., a catalog) that refer to the configuration object in general rather than to a specific database object instance. The manager module cannot have variables or a module body.
If the manager module procedures and functions are declared as exported, they are accessible through the object module.
// Manager module of the Contractor catalog. Function GetReceivablesList() … EndFunction // Call from application code. Receivables = Catalogs.Contractor.GetReceivablesList();
1.3.6. Template
In the 1C:Enterprise system a template is a configuration object designed to generate print forms.
Common print form templates are located in the Common templates branch of the configuration tree Common branch, while print forms of configuration objects (catalogs, documents, document journals, charts of accounts, charts of characteristic types, charts of calculation types, registers, reports, data processors and other objects) are located in Templates subordinate objects and in external files (in the latter case, you have to set the Template property for the spreadsheet).
Templates can be of the following types:
Spreadsheet document: Standard methods to create and use templates are expected. The template is prepared using the spreadsheet editor.
Text document: Use of a text document as a template is expected. The text template is prepared using the text template editor.
Binary data: Binary data are used.
Active document: Use of OLE Active document method is expected.
HTML document: Use of HTML editor is expected.
Geographical schema: Use of a geographical schema prepared in the geographical schema editor as a template is expected.
Graphical schema: Use of a graphical schema prepared in the graphical schema editor is expected.
Data composition schema: Use of a data composition schema prepared in the wizard is expected.
Data composition appearance template: Use of a data composition appearance template is expected.
1.4. OPERATION MODES
1C:Enterprise supports two operation modes:
file mode
client/server mode
In both versions all applications function in an identical way. The file mode is mostly intended for personal use, while the client/server mode is used in work groups or throughout the organization.
1.4.1. File Mode
The file mode of infobase operation can be used by a single user or by a small group of users in the local network. In this case all infobase data (configuration, database and administration data) are stored in a single file.
This version facilitates installation and operation of the automated system. There is no need in additional software to operate the infobase, apart from the operating system and 1C:Enterprise.
The file mode of 1C:Enterprise ensures infobase integrity and easy creation of backup copies. System failure due to a user error resulting in storing infobase files incorrectly (e.g., while copying the infobase) is totally ruled out.
You can also create backups at the file level by simply copying the infobase file.
Despite its ease of use, the file mode has certain restrictions (see page 2-1249).
1.4.2. Client/Server Mode
The client/server mode can be used by work groups or the entire organization. It is implemented as a three-tier client/server architecture.
The client-side application interacts with the 1C:Enterprise server cluster, while the cluster communicates with the database server, as necessary (Microsoft SQL Server, PostgreSQL, IBM DB2 or Oracle Database). Physically, the 1C:Enterprise server cluster and the database server can be located on either a single machine or different machines. This is useful if the administrator needs to distribute the workload between the servers.
Using the 1C:Enterprise server cluster is a good way of centralizing the most resource-intensive operations of data processing. For example, user application can only retrieve the required data selection, while the server performs all the processing, even with the most complex queries. Expanding a server cluster is generally a lot easier than upgrading all client machines.
Another important aspect of the three-tier architecture is ease of administration and streamlined access of users to the infobase. In this mode the user is not supposed to know the physical location of the configuration or the database. Access is always granted through the 1C:Enterprise server cluster. When sending a request to a database, the user is only required to specify the cluster and infobase names, while the system prompts the user to enter username and password. For details on system administration see "1C:Enterprise 8.3. Administrator Guide".
Although the 1C:Enterprise system tries to hide database server behavior from the user, it is not always possible. For information about system interaction with a specific database server see page 2-1250.
An important feature of the client/server mode is the ability to run the 1C:Enterprise server and database servers under various operating systems (the Windows family and various Linux distribution kits).
1.5. DEVELOPMENT TOOLS
The 1C:Enterprise system uses several methods to describe specific algorithms for processing information and creating an interface for convenient representation of data described in the configuration.
1C:Enterprise Script. The need in the 1C:Enterprise script is defined by the system customizability concept. Syntax of the 1C:Enterprise script meets all the standards of high-level languages.
The script is object-oriented. It supports specialized subject area data types defined by the system configuration. The 1C:Enterprise script processes these data types using object techniques. The script is designed for users with various levels of qualification. In particular, it is characterized by weak data typing (it supports quick writing of program modules) and tight syntax check reducing probability of errors.
Since the system combines visual and linguistic configuration tools, using the 1C:Enterprise script in the system has an event-dependent orientation, i.e. script modules are used at specific places to handle certain algorithms that are customized in the configuration process. Thus, you can describe an algorithm for automatically filling in document attributes when a new document is entered. The system will call this procedure when needed.
Query Mechanism. The system provides an object-oriented query mechanism that can produce any report with a complex structure. This tool relies on the existing conventional variable structure of the system infobase permitting fairly complex queries to be described in a relatively simple way.
The built-in text editor is used to create program modules in the 1C:Enterprise script and to edit text documents.
One of the editor features is contextual color-coding of the 1C:Enterprise script syntactic constructs and grouping various syntactic constructs.
When typing texts in the 1C:Enterprise script, it is convenient to use tooltips and templates.
The 1C:Enterprise script has powerful text manipulation tools, so you can use text format successfully to share all types of information with other systems.
Built-in Form Editor. Working with customizable data structures and working in the Microsoft Windows interface requires the ability to setup information input and editing forms arbitrarily. To do this, the 1C:Enterprise system has a built-in form editor.
The editor enables you to format most windows used in the system to enter and view object information (document and catalog forms and report settings).
Built-in Spreadsheet Editor. All output documents (primary documents and reports) have a uniform system-defined format: spreadsheet document format.
The spreadsheet editor is a powerful tool that combines spreadsheet structure and vector graphics formatting capabilities. It can be used either to create small documents with very complex line structures (such as payment orders) as well as long payrolls, journals and other similar documents.
The spreadsheet editor offers users a rich variety of formatting capabilities (fonts, colors, lines and patterns). It has the ability to output information in graphical form (as charts).
One of the main features of the spreadsheet editor is its orientation toward generation of reports using the 1C:Enterprise script. Flexible features of report creation are ensured by a mechanism for manipulating named areas of a document. The spreadsheet editor permits manipulation of both horizontal and vertical areas which makes it possible to create reports scalable both horizontally and vertically. Using the editor together with the data composition system enables you to create all-purpose reports where you can process and represent information in various ways and drilldown levels without additional developer intervention.
On the other hand, a spreadsheet can serve as a form control element and thereby be used for data input.
Built-in Picture Editor. This editor enables you to create pictures of any size and use them as toolbar icons, button images and for other formatting purposes.
Built-in HTML Editor. This editor enables you to create user descriptions and has strong formatting capabilities (hyperlinking, use of styles, picture placement, etc.).
Wizards are auxiliary tools that simplify development of standard items in the 1C:Enterprise system. For example, the system has wizards for constant forms, catalogs, documents, document journals, reports and other objects; print form wizards; register record wizards and more.
You can use wizards to generate visual components of these objects and, in certain cases (generating objects based on other objects, printing, output form, etc.), to generate program modules.
User Interface Customization System. For the interface of a particular system configuration to fully include customized data structures and algorithms, the 1C:Enterprise system, in addition to the dialog box form and spreadsheet editor, provides a functionality of system command interface setup.
The command interface is set up automatically based on the access rights of a user logging into the system. Consequently, the user will only see accessible system objects.
Subsystems. The Designer enables you to select various subsystems within a single configuration (for example, trade accounting and research system) at the design stage. You can specify configuration objects to be included in each subsystem. A single object can be assigned to multiple subsystems. In essence, subsystems define main configuration sections available to the user. Since the subsystem structure defines the configuration interface, you should pay special attention to subsystem design (and hierarchy).
Access Rights (Roles) Customization System. This system permits description of sets of rights corresponding to user job titles or types of activities. The structure of rights is determined by the specific system configuration. For example, you can create sets of rights such as Chief Accountant, Storekeeper, Manager and Head of Department.
In addition, for objects stored in the database (catalogs, documents, registers, etc.), you can define access rights to specific fields and records.
The actual user list is created for your specific organization. Each user is assigned one or more roles, default interface and language to be used when he or she works with the program.
Debugger. The system provides a debugger for convenient configuration development. The debugger permits the user to follow execution of configuration program modules, measure the relative execution time and inspect the contents of variables.
Configuration Repository. In distributed configuration development, developers use a configuration repository mechanism. It enables you to assign access rights to modify a configuration object and make the necessary changes concurrently rather than sequentially.
Configuration Support. To make configuration updates easier, the system provides a mechanism for developers to generate standard configurations of distribution files and distribution kits (including installation program) as well as a mechanism for updating standard configurations under support contracts.