An important difference between developing business applications in 1C:Enterprise and developing them in generic development systems is that in the first case the applications are developed in terms of classes of task-oriented business entities. This is one of the main distinguishing features of 1C:Enterprise.
If you are developing an automation system for an enterprise or business, you will need to describe a number of various entities: goods, materials, other resources, customers, vendors, accounts, invoices, and other documents, as well as the way in which their changes and interaction will be recorded. When the 1C:Enterprise platform was designed, all these were sorted and combined into classes of entities (prototypes) which the developer of the applied solution manipulated. At the same time, the number of entity classes should not be multiplied too many times (Occam’s Principle), and their number should not exceed a couple of dozen.
The following criteria were used to differentiate these classes.
- Similar purpose of entities.
- Similar purpose of entities in a data model.
- Similar purpose of entities in use cases.
- Division by classes should provide a clear picture of the applied solution’s structure.
- Division by classes should ensure unification of the applied solution development process.
1C:Enterprise applications are therefore based on the metadata structure. Actually, the composition of classes (metadata objects) defines the overall application design structure, while the composition of specific objects defines a specific application. It can also be said that 1C:Enterprise-based applications are designed rather than programmed (coded). By relating a certain subject area entity to a certain type of metadata (by actually creating a metadata object), the developer receives both a ready-to-use standard set of functions that are characteristic of all entities of this kind, as well as a way to specify certain features that a specific entity can possess.
1C:Enterprise provides powerful functionality for maintaining these types of entities on the applied solution level without any programming or having to add any new functionality (as compared with the one provided by the platform).
Let us review several examples of business entity classes and look at how to design applications with these classes.
Catalogs
Descriptions of such entities as goods, contractors, currencies, and warehouses are united by certain common properties such as the internal identification of an object in the system, the need to support hierarchies and groups of elements, and the need to maintain embedded tables. Information on these objects needs to be stored, as they are used in the enterprise’s business operations. In 1C:Enterprise, all these entities are combined into a common class — catalog, for which the properties and capabilities described above are supported at the platform level.
To create a catalog in 1C:Enterprise, all you have to do is describe the required set of parameters. This is done visually — you do not have to write a single string of code. For instance, to create the Goods catalog, you need to complete the following actions in 1C:Enterprise Designer mode:
- specify its name: Goods;
- specify that the catalog is hierarchical (goods can be divided into groups and subgroups);
- define other properties that need to be supported by the system for this catalog, such as the element numbering method, auto numbering, etc.;
- specify catalog item fields: this can be a purchasing price, a sales price, weight, etc., for goods.
You have therefore completed the minimum required to create (describe) an entity that belongs to class “catalog”: now you can save this entity with one click and start working with it in 1C:Enterprise mode. The system automatically generates the screen form for working with the catalog we have just created, i.e., the developer does not need to make any additional efforts to enable the user to input the names of individual goods or groups of goods, specify prices and other parameters, etc. The developer can of course construct such a screen for this on his or her own by using a screen form designer. In this scenario, the developer can define the appearance and properties of the form according to the task to be solved, the usability considerations, etc.
Documents
Documents (bills, invoices, orders, etc.) are used to record various events in the economic life of the organization. Time-boundedness is one of the document’s main characteristics. 1C:Enterprise allows you to specify an economic event itself, its embedded tables, and its position on the time scale for such objects. It also provides the reflection of the event in accounting mechanisms and sequence control, as well as reflects the event changes in real time. This set of functionality is integrated into the system and ensures quick development of such entities.
For instance, to describe a “purchase invoice” document that records all the goods delivered to the enterprise, we only need to specify the document’s attributes in Designer:
- Company (contractor) from which we receive the goods: a reference to a companies catalog. This creates another important feature: objects and entities described in the system become data types themselves.
- A warehouse where the goods are delivered: a reference to the warehouses catalog.
- Document structure. Several types of goods may be delivered with a single invoice, so the document includes an embedded table with the “goods catalog” fields, the quantity (number) and the total cost (number) values.
In the simplest scenarios, this is enough to describe the document’s data structure and start working with it: you can switch to 1C:Enterprise mode and input invoices that register the goods receipt. The system will let you select field values from the corresponding catalogs (for example, “companies” or “goods”), input new values to these catalogs, etc. in the input form.
However, the document itself can only be used to describe a certain fact in the enterprise’s economic life. In addition to that. you need to account for these facts in business applications, i.e., to reflect resource movements (goods, finances, etc.) in different accounting systems. To do this, you need to post the document. From the user’s point of view, this means giving a certain command, i.e., clicking the Post button in the document’s screen form. From the point of view of the developer, posting means calling a corresponding processing, thus executing a 1C:Enterprise script algorithm that describes the way the event is reflected in different accounting systems. Registers (entity classes) are provided in 1C:Enterprise to describe accounting systems.
Accumulation registers
The multi-dimensional accumulation registers feature is responsible for accounting resource records (finances, goods, materials, etc.) and can be used to automate warehouse accounting, mutual settlements, and planning. Accumulation registers store information on the receipt and consumption of resources, while the functionality of those registers implemented in 1C:Enterprise can be used to obtain balances as of a certain point in time, to calculate and cache totals, etc.
For example, we can create a register with the “Inventory” and “Warehouse” dimensions and describe the relationship between the “Document” and “Register” entities, to establish the simplest quantitative accounting of the inventory by warehouse. To do this, we need to specify in the wizard that posting the documents “sales invoice” and “purchase invoice” creates records in the register.
In this case, we not only describe the data structure and show how it is represented, but define the business logic of the application. To describe such business logic, we need to program with 1C:Enterprise script because there are many accounting methods that can be used depending on the situation, the type of activity and the business specifics of an enterprise, so it should be described algorithmically. The wizard creates an algorithm (script) prototype, which can be used “as is” in simple scenarios, e.g., if we only need to record changes in the quantity of goods stored at the warehouse based on goods receipt and consumption taken from the appropriate invoices. In practice, such algorithms are more complex: they can be used to automatically calculate discounts, support certain methods of material values write-off (by average cost, LIFO, FIFO), control availability of the goods at the warehouse, or ship the goods to the buyer depending on the size of its debt, etc.
Information registers
Information registers store multi-dimensional information on the values of various parameters that have no object semantics on their own. These can, for instance, be exchange rates or competitors’ prices as of a certain date. This information can be static or can change in time — in the latter case the change history can be stored.
Information register functionality in 1C:Enterprise can be used to set arbitrary storage periodicity, to slice and dice information as of a certain period.
Chart of accounts and accounting registers
Double-entry accounting is a different type of accounting model. Due to its specifics, the charts of accounts and accounting registers are implemented as separate classes of entries in 1C:Enterprise.
1C:Enterprise is widely used to automate accounting in Russia and other countries. There has not been a single instance of 1C:Enterprise’s accounting mechanisms not being able to handle the required accounting tasks. At the same time, these mechanisms do not impose any accounting principles on the developer. Note that creating a similar tool from scratch is a rather complex task, even if the functionality implemented in 1C:Enterprise is used, e.g., a multi-level chart of accounts with a fixed or variable code depth, multi-level and multi-dimensional analytical accounting, multicurrency accounting, accounting with several charts of accounts, accounting for several companies (legal entities), optional quantitative, totals, and currency accounting by analytical slices, etc. The system provides the developer with a tool for manipulating the totals that makes building complex queries with all the variables mentioned above a matter of just a few strings.
Chart of calculation types and calculation registers
1C:Enterprise provides a versatile feature for automating periodic calculations (by day, month, or year) of any complexity (where calculation types impact one another, time displacement or recalculations are used). Salary calculation is the most common example of how this feature is used.
Complex calculations usually consist of several calculations (intermediate results) which have independent meanings and must be saved. Many intermediate calculation results, which are used for reporting to state agencies, must be saved when calculating employee wages. Types of calculations that are grouped into charts of calculation types are used to implement such intermediate results in 1C:Enterprise 8. Each chart of calculation types describes the relationship between the entries in a calculation register and can be used to set the rules by which the entries are to be calculated and their relative timing as well as the appropriate recalculation rules.
You can set predefined calculation types in the chart of calculation types during the applied solution development stage. Predefined calculation types actually help set up the calculation scheme for a specific subject area during the configuration development stage.
Calculation registers are used to store calculation records (intermediate and final results). Each calculation register is based on a certain chart of calculation types. When you edit a chart of calculation types, you can specify its other characteristics, such as the calculation periodicity, the mechanism of retrieving base calculation type, action period support (for a displacement feature), charts where action periods are specified, etc.
The system automatically monitors any records which require recalculation. This can be the case, for example, when the results of such records are in any way related to other calculation types, and those calculation types have been changed. For instance, you will need to recalculate the taxes if the employee’s accruals have been changed.
Support for multiple accounting systems
Each 1C:Enterprise-based applied solution can support multiple accounting systems. For example, a sales invoice can decrease the number of goods at your warehouse when registered in the goods accounting system, increase the buyer’s debt when registered in the settlement system, and change the account balances in the accounting system.
Many-to-many connections are maintained between the documents and accounting systems (registers), i.e., one document can send entries to different registers supported by the applied solution, and records for one register can be created when documents of different types are posted.
Of course, entity classes and options for describing application business logic supported by 1C:Enterprise are not limited by the examples above. These are just a few approaches for joining entities to classes available through 1C:Enterprise that demonstrate the basic applied solution development principles in terms of such classes in 1C:Enterprise.