Any applied solution in 1C:Enterprise 8 is based on a set of configuration
objects.
In fact, a developer's task is to build a required applied solution structure
from these objects, and then describe specific interaction and functioning
algorithms for these objects, where it differs from the standard
(framework-predefined) behaviour.
The set of objects, supported by the framework, was created basing on
analysis of the domains (areas of use) of 1C:Enterprise 8, selection and
classification of the business entities used in those domains. As a result,
developers during the process of application designing can operate such object
terms as
catalogs, documents, information registers,
charts of accounts, etc.
To standardize and simplify the development process, it provides efficient
GUI to describe required object set to be used in a particular applied
solution.
Basing on this description, the framework will create proper information
structures in the database, and will handle data according to the description.
Developers should not care of such things like in what table some data should be
stored, how they will be modified or displayed to users. All these things (and
many others) are done by the framework, proceeding from the standard behaviour
of the objects used.
Thereby, developers work with metadata – 'data about data' – or configuration
objects.
Developers cannot create their own (new) types of objects; they can work only
with the provided set of them. Such approach to development allows, on the one
hand, to standardize the development process, and on the other hand – to provide
simple and quick modification of applied solutions by other developers (or
users).
Here is the full composition of configuration objects used in
1C:Enterprise 8:
The set of configuration objects
provided by the framework
Further in this and other sections we'll consider the major configuration
object types used in 1C:Enterprise 8 in more details.
Catalogs
Catalog type objects allow storing data of identical structure and of catalog
type. It could be such business objects as Items (goods), partners, currencies,
warehouses, customers, etc. They all have such common properties as internal
object identification in the system, hierarchy (including multi-level) and
grouping support, nested tables support; these objects are included into
business transactions.
A particular set of information is the same for all items of a particular
catalog, and the catalog's attributes are used to store that information.
Various catalogs may be subordinated to others, i.e. a catalog's items are
subordinated to items or groups of other catalog.
Catalog object example ('Customers')
Documents
Documents, Document journals, numerators and Sequences are used to specify
such business objects as invoices, orders, receipt slips, etc. These documents
reflect various business events in an enterprise’s life.
Document object examples
Each document is specified with a number, date and time. The system support
auto-numbering and the uniqueness check providing there will be no two documents
in a system with the same number.
Apart from the number and date/time, every document, as a rule, contains some
additional information that describes a document in details. It could be
information on a supplier, warehouse that goods are acquired to, etc. This kind
of information is stored in document's attributes.
An important feature of documents is the posting functionality. Upon posting,
a document changes the state of some data being accounted. For example,
'Receipt' document upon posting may change the state of order transactions and
the general ledger transactions.
Additional information and posting
support in documents
For documents 1C:Enterprise framework supports business event identification,
nested tables, placement in a timeline, reflection of the event in
record-keeping mechanisms.
Document numerators are used for consistency check and for through numbering
of documents of different types.
Sequences are used for the recording of business events in real time.
Document journals are intended for browsing documents of different types, at
that every document form may be shown in one or more journals.
Document journal object example
Documents support several forms; there are three types of document forms:
list form for browsing across documents of one type; document form for a
particular document from the list; and the choice form for selection of one or
other document on the base of the minimum information provided in the form.
Registers
The document itself only describes a business event. In real business these
facts must be accounted and the movements of resources (products, finances,
etc.) must be reflected in various record-keeping systems. For this the document
must be posted (registered) and this is what registers are for.
They store various information on objects, their characteristics, events,
resource movements, business accounting and more.
There are four types of registers:
Information registers – to store multi-dimensional information on various
values, such as currency exchange rates or competitors’ production prices,
etc.
Accumulation registers – responsible for resource movements accounting
(financial, goods, materials, etc); They are widely used in automation of
warehouse accounting, mutual settlements, planning. Their functionality
allows getting balances at a certain point of time, totals calculation, etc.
Accounting registers – used for implementation of double entry system in
business accounting, support multi-layer hierarchical Charts of Accounts
with fixed or variable code capacity, multi-layer and multi-dimensional
analytical accounting (defined with Charts of characteristic types),
accounting across several charts of accounts and several organizations,
optional quantitative, summary and currency accounting for separate
analytical sets, etc.).
Calculation registers – for implementation of payroll calculation models.
They allow describing various payroll types (salary, additional payment,
alimony, fines, etc.), to specify rules of payrolls' dependencies, store
intermediate data and final results. They can be used to calculate income
taxes for private persons, etc.
All registers are customizable by a business application developer for any
economic conditions.
Chart of Accounts
and Accounting Mechanisms
The mechanisms of business accounting allow implementing the double-entry
accounting system. However, the mechanisms do not impose any accounting
principles on developers and allow creation of accounting models applicable in
different countries.
The accounting mechanisms implement the following major features:
Multi-level charts of accounts with arbitrary hierarchy, with fixed or
variable accounts' digit capacity.
Analytical accounting by several dimensions and levels.
Accounting on several charts of accounts at a time.
Consolidated accounting on several legal entities.
The possibility to specify arbitrary number of accounting types, such as
quantitative accounting, currency accounting, etc., for individual
analytical dimensions.
Business accounting in 1C:Enterprise 8 is implemented with three applied
objects:
Chart of accounts
The structure of chart of accounts supports multi-level 'account –
sub-account' hierarchy. Number of nested accounts is not limited in
1C:Enterprise 8.
Chart of accounts object
Creation and modification of a chart of accounts can be done by developers
(predefined accounts) as well as by users, as they work with their application.
(However, users cannot delete predefined accounts.) For users to be able to view
and modify chart of accounts data, the system supports several types of forms).
Chart of accounts display
Analytical accounting is possible for any account or sub-account.
Chart of Characteristic Types
To describe analytical accounting objects a chart of characteristic types is
created. It specifies the sub-accounts required and the types of values that
a particular sub-account can be of.
Accounting Register
It is used in 1C:Enterprise 8 to record information on business operations
and getting resulting data on the accounting state. The register is
referenced to one of charts of accounts and stores accounting totals,
according to its structure.
The system provides the uniqueness of records in the Accounting Register.
Business Processes
(Workflows)
Business processes allow to consolidate individual operations (such as
writing out invoices, payment acceptance and goods delivery) within a single
workflow (for example, sale). The logic of business processes is created
visually in the Designer. There can
be some routs with conditional jumps, paralleling and synchronization, nested
business processes, etc. It can generate a list of tasks for a particular
executive person automatically. Moving across routs can be done manually or
automatically either.
It is possible to add the mechanism of business processes to an existing
applied solution without much efforts.
The business process mechanism is represented in 1C:Enterprise with two objects: Task and Business Process.
Task object is intended for description of tasks (jobs) and describes
their assignment across executive persons according to an enterprise's
organizational structure. When a task has been done, the business process moves
over to next task along the route map. Tasks in themselves consist of a list of
assignments to an individual responsible person.
Business process object describes a business logic in the route map
and controls a workflow lifecycle from the beginning to the end. It includes a
route map itself, action points and routing rules (there may be group, personal,
positional and conditional routing).
A business process logic is described visually as a 'roadmap' with
interconnected waypoints, conditional jumps' algorithms, reaction of the
business process to various events, etc.
Reports and Data
Processors
These applied objects are for processing of user information and generation
of resulting data in a shape convenient for browsing and analysis.
They describe data processing algorithms, contain various forms and
algorithms for data representation to users.
This object stores information on various objects' characteristics. It allows
to provide the possibility to describe goods with arbitrary number of
characteristics (color, size, type, etc.), which are not yet known by the time
of development, creating a characteristic type and data type for corresponding
objects.
For example, to describe particular clothes, one should first create the
following characteristics:
Size, type is Integer;
Length, type is Integer.
Color, type is Reference.CatalogColors.
The structure of the chart is similar to the catalog structure.
Chart of characteristic types
To store values of characteristics which users define for particular objects
information registers are used.
A list of possible data types for the chart is specified by developers, when
developing an application.
Exchange Plan
Object
The Exchange Plan object is intended for description of a distributed
information system and definition of a list of data to exchange with within that
distributed system. This allows creation of distributed system based on both
1C:Enterprise 8 and other information systems.
This type of objects store constant or conditionally-constant information,
such as a company name, taxpayer ID, names of the managing staff, etc. There can
be any number of constants in an applied solution.
Constant objects
The system automatically generates a form for users to be able to browse and
modify constants.
Enumerations
Enumerations allow storing sets of values which do not change during the
applied solution operation. For example, it can be enumeration of tax rates
applicable (NoVAT, VAT13, etc), states of orders (Scheduled, InProcessing,
Completed), etc.
Enumeration objects
Filter
Filter objects are used for selection of a information of a certain type, for
example sales documents.
Filter object
Developers define a filter type and then can select the configuration objects
which should be considered in the filter.
Role Objects
These objects allow describing user access rights according to their position
(the role they play) in a company. For example, a company director should have
full access to any information stored in the application, while a warehouse
manager should operate warehousing documents only.
Specification of access rights for
roles
A role sets up what actions will be available to do upon which objects for a
user that the role has been assigned to.
Event Subscription
The event subscription mechanism allows assigning handlers to non-interactive
events of one or more applied objects.
An exported procedure in common module script can be defined as a handler.
Scheduled Jobs
The Scheduled Job objects are defined at the designing stage.
For each scheduled job a schedule can be predefined, it also can be created
or modified during execution of the application (by a user). The system provides
one-time and repeated execution. One can specify start and end time, a schedule
by days, weeks and months.
When being executed, a job spawns a background job that actually performs the
processing.
A scheduled job can be started on behalf of a specified user; it can be
re-started (for example, in case of a failure).
In client-server
operation mode scheduled tasks are managed by the cluster manager. This
provides starting of such tasks even if there is no connections to the
information base.
For file operation mode starting
of scheduled tasks requires a separate client connection which is used as a task
scheduler.
Interface Objects
These objects allow creation of individual user interfaces, for standard
(un-managed) operation mode.
Interface object definition
Using individual interfaces simplifies user operation, giving him access only
to required functionality.
Language Objects
These objects allow creation of multi-lingual applied solution.
Language objects
Since all configuration texts and database are in
UNICODE format, developers can specify several versions of display for a
string.
Creation of multilingual document
Unmanaged Forms
Forms in 1C:Enterprise 8 are used for users to browse and modify data. Forms
may belong to some particular configuration objects. For example, catalog and
document object may have the following types of forms:
List form
Choice form – to select an item from the list
Group choice form – to select a group only, among other groups.
Element form – to view and modify an element's data.
Groups form – to view and modify information on a particular group of a
catalog.
Document form – to view and modify data of individual documents.
Configuration object forms
(example for a document object)
And with it, there can be common forms, not associated with any particular
objects, and used by an entire configuration:
Common forms shown in the configuration tree
An important feature of 1C:Enterprise 8 system is that it can generate
default forms. It relieves a developer from the necessity to create all possible
forms for every configuration object. It is enough for a developer to create a
new object and the system will generate in runtime proper forms to display the
object information for users.
Thereby, developers need to create only form whose design would be different
from the default one.
There is a form designer for developers
to create and modify forms.
Next
Previous