Explanatory note to the terms of reference. Explanatory note

1. general provisions;
2. description of the activity;
3. main technical solutions;
4. activities for.

[from clause 2.2.1 of RD 50-34.698-90]

General provisions

In chapter " General provisions» result:

1. projected and the names of documents, their numbers and date, on the basis of which the NPP is being designed;
2. list of participants in the system, deadlines;
3. goals, purpose and AS;
4. confirmation of compliance of design solutions with current standards and, fire and explosion safety, etc.;
5. information about those used in the design;
6. information about, advanced, used in the development of the project;
7. the order of creation of the system and the volume of each.

[from clause 2.2.2 of RD 50-34.698-90]

Description of the activity process

In the section "Description of the process of activities" they reflect the composition of the procedures (), taking into account the interconnection and compatibility of processes and activities, form the organization of work in the AU [from clause 2.2.3 of RD 50-34.698-90]

Main technical solutions

In the section "Main technical solutions" they give:

1. decisions on the structure of the system, means and methods of communication for information exchange between, subsystems;
2. decisions on the interconnection of the AU with adjacent systems, ensuring it;
3. solutions for, system operation;
4. decisions on the number, qualifications and functions, modes of its work, the order of interaction;
5. information about the provision of the system (subsystems) specified in the consumer characteristics that determine it;
6. composition, task complexes () implemented by the system (subsystem);
7. decisions on the complex, its placement on;
8. decisions on the composition of information, volume, methods of it, types of computer, and documents, sequence and other components;
9. decisions on the composition, languages ​​of activities, procedures and operations and methods for their implementation.

The section provides illustrations of other documents that can be included in accordance with GOST 34.201 [from clause 2.2.4 of RD 50-34.698-90]

Measures to prepare the automation object for putting the system into operation

In the section "Measures to prepare for the commissioning of the system" give:

1. measures to bring information to a form suitable for;
2. measures for training and testing the qualifications of personnel;
3. measures to create the necessary units and jobs;
4. measures to change the automation object;
5. other activities based on the specific features of the created AS.

27.10.2016 09:57:23

This article discusses the technical design stage related to one of the stages of the system life cycle information security(NIB) - the "design" stage, which, in accordance with domestic standard GOST 34.601-90 immediately follows the development of the Terms of Reference for an information security system.

1. Development of technical project documentation for NIB

The life cycle of an information security system (hereinafter - SIS) in general view consists of the following steps:

• analysis of requirements for ISS;
• design;
• implementation;
• implementation;
• exploitation.

This article discusses the stage of the technical project related to the "design" stage and, in accordance with the domestic standard GOST 34.601-90, immediately follows the development of the Terms of Reference for the information security system.

1.1. Why develop documentation for NIB at all?

The answer to this question should be considered in two planes: in the plane of the owner of information resources (for the protection of which the ISS is created) and in the plane of the direct developer of the ISS.

For the owner of information resources, it is important to get the result in the form of a functioning information security system that reduces the risks of compromising restricted access information in the organization. Technical project in this case serves to develop the fundamental foundations of the future system, namely, it includes a description of how the ISS will be built and function, what measures and means will ensure the protection of information, what are the possibilities for developing and improving the system. Upon completion of the development of a technical project for an information security system, the Customer receives a comprehensive set of documentation for the NIS, which describes all the technical nuances of the future system.

For the direct executor at the stage of the technical project, it is necessary to lay down the most appropriate architecture of the NIS, as well as to make right choice measures and means of protecting information in the organization. It is also important to ensure that the characteristics and properties of the system are consistent. terms of reference, or substantiate, with the participation and consent of the Customer, the adjustment of the requirements specified in the TOR in order to increase the efficiency of the system being created.

Thus, as a result of the development of technical project documentation, the Customer will have answers to the following questions:

• what is the general architecture of the NIB;
• what measures and means will be used to implement the requirements for information protection;
• how the NIS will function;
• what changes in the organization, necessary to increase the level of information security, will follow as a result of the introduction of the ISS;
• whether the requirements of the Customer (business requirements) and the requirements of regulatory legal acts in the field of information security will be taken into account when developing and implementing the ISS and, if so, how.

The contractor in the process of developing the technical project documentation will receive the following results:

• the basis for the transition to the next stages of building the NIS, namely the stages of working documentation and implementation;
• understanding of the architecture, technologies and tools used, the order of building the system;
• how the requirements of the Customer (business requirements) and regulatory documents in the field of information security for the system are implemented.

1.2. Overview of approaches to the development of technical project documentation

The development of a technical project for an information security system is most often carried out on the basis of relevant standards and guidance documents. And for public institutions their use is mandatory, and for commercial purposes it is recommended. On practice commercial organizations also use state standards when developing technical project documentation for the following reasons:

• repeatedly proven approach to the creation of information systems;
• thoughtful structure and content of documents;
• a set of documents sufficient for the development and description of almost any system.

For the development of documentation for the stage of the technical project (TP) on the NIB, state standards and guidance documents of the 34 series are used:

• GOST 34.201-89 "Types, completeness and designation of documents when creating automated systems." This standard specifies:
  • types and names of documents of the TP stage;
  • completeness of documentation;
  • accepted designations of documents;
  • rules for the designation of NIBs and their parts.
• GOST 34.003-90 "Terms and definitions";
• GOST 34.601-90 “Automated systems. Stages of creation. The standard specifies:
  • list of stages of work carried out at the TP stage;
  • detailed description works carried out at the TP stage;
  • list of organizations participating in the creation of the NIS;
• RD 50-34.698-90 “Automated systems. Requirements for the content of documents. This guidance document specifies the requirements for the content of the TA stage documents.

It is important to understand that according to the 34 series standards, a technical project is a stage in the creation of a system, and not just a set of documents. This stage in practice is often combined with the preliminary design stage, which serves to develop several preliminary solutions and substantiate the most suitable one. Such a combination is allowed by the standard, but it must be borne in mind that this does not negate the need to achieve the objectives of the preliminary design stage.

Most often, the draft design stage is developed when the requirements of the technical specifications for the system can be implemented in several fundamentally different ways, and also if there are no unambiguously preferred methods among these methods.

However, it should be noted that the above standards are too general and mainly implement a design and general structural function. To develop the substantive part of the documents of the technical design stage, designers use information from the following sources:

Current regulatory documents (NLA) that regulate the requirements for the protection of this or that information of limited access. These RLAs present the requirements for measures to protect information in information systems, describe the nuances of the implementation of these measures and additional strengthening measures. Among the current NPAs, the following can be distinguished:

• order of the FSTEC of Russia dated February 18, 2013 No. 21 “On approval of the composition and content of organizational and technical measures on ensuring the security of personal data during their processing in personal data information systems”;
• order of the FSTEC of Russia dated February 11, 2013 No. 17 "On approval of requirements for the protection of information that is not a state secret contained in state information systems"
• order of the FSTEC of Russia dated March 14, 2014 No. 31 "On approval of requirements for ensuring the protection of information in automated control systems for production and technological processes at critical facilities, potentially hazardous facilities, as well as facilities representing increased danger for the life and health of people and for the natural environment;
• methodological document "Information protection measures in state information systems", approved by the FSTEC of Russia on February 11, 2014

The requirements for the protection of information of restricted access and the lists of protective measures vary for IS of different levels/classes of security. If the information in the organization does not belong to the protected in accordance with federal laws RF (for example, an official secret), then the owner of this information can use the approaches proposed in these legal acts to build a corporate ISS.

Russian and foreign standards describing various approaches to the implementation of the stages of the life cycle of building an ISS, including the stages of a technical project:

• a series of state standards GOST R ISO / IEC 2700X, identical international standards ISO/IEC 2700X. These standards describe process approach PDCA (Plan, Do, Check, Act) to the implementation of the life cycle of the information security management system, which is an integral part of the ISS;
• NIST SP 800-64 is a US National Institute of Standards and Technology standard that describes life cycle development of information systems;
• NIST SP 800-37 is a US National Institute of Standards and Technology standard that provides guidance on integrating risk management into the information systems development life cycle.

Manufacturer's operational documentation for information security and aids. These documents contain comprehensive technical information about the tools used in the construction of the ISS, including those that are not directly related to the implementation of IS measures, for example, servers, data storage systems, virtualization tools, and others. General set of such documents for different manufacturers is different and depends, among other things, on the execution of a particular tool (hardware/software). Below is standard set operational documentation for information security tools used to develop documents of the technical design stage:

• general description (datasheet);
• administrator's guide (may include local and centralized management guide);
• user guide;
• quick installation and deployment guide (for hardware GIS);
• operator's manual;
• virtual infrastructure deployment guide (for software GIS);

General information about the available NIS architectures, best practices in terms of building the NIS, guidance on security and integration of information security systems with each other, information about problems in the interaction of certain information security systems. Examples of such information may include the following documents:

• information security system architecture guides, for example: Defense-in-Depth, Cisco SAFE, Check Point SDP and others;
• information security best practices, such as those available at these links (https://www.sans.org/reading-room/whitepapers/bestprac/ , http://csrc.nist.gov/publications/nistpubs/800-14 /800-14.pdf). These documents are most often presented on English language, however, any Russian manufacturer SZI and upon request they can be provided;
• safety guides for IPS and operating environments. An example is the "Security" section on the official portal Microsoft(https://technet.microsoft.com/en-us/library/dd637672.aspx).

1.3. Development of a technical design for the NIB in accordance with GOST 34

The development of documents for the technical project stage at the NIS is most often carried out by integrators of these services and is implemented mainly in accordance with the following plan:

Determination of the list of documents to be developed - this information is indicated in the terms of reference for the NIS. In some cases, the developer of documents, in agreement with the Customer, can expand or reduce this list, if the possibility of this is provided for in the TOR;

Development of document templates for the TP stage - the structure is used in accordance with RD 50-34.698-90 and GOST 2.106 (for some documents), execution in accordance with GOST 2.105-95;

Development of the substantive part of the documents. Requirements for the system are set in the terms of reference for the NIB. In accordance with these requirements, a list of protective technical and organizational measures necessary for implementation in the system is determined. Protection measures can be defined in the relevant legal acts (depending on the type of information being protected), corporate standards and information security policies, as well as based on the presence of current security threats identified at the stage of developing the organization's threat model. Based on the list of protection measures, the ISS developer selects the appropriate information protection tools and develops the functional structure of the information security system (subsystems, components). Further, in the documents of the technical project, the practical implementation of protection measures based on the selected GIS or organizational measures in the infrastructure of the organization is described.

Coordination of the developed documentation and the solutions presented in it with the Customer of the system.

When developing technical project documentation, most often it is not required to develop a complete list of documents specified in GOST 34.201-89, since this standard is obsolete and some of the documents do not take into account the development trends and technologies of modern information systems. The minimum set of documents required to describe an information security system is as follows:

• statement of the technical project;
• explanatory note to the technical project;
• functional structure diagram;
• structural diagram of a complex of technical means;
• scheme organizational structure;
• list of purchased items.

At the request of the Customer or if the NIS is a complex multicomponent system, the following documents can be additionally developed:

• automation scheme;
• description of automated functions;
• description of the information support of the system;
• description of the complex of technical means;
• description of the software;
• description of the organizational structure.

It should be noted that GOST 34.201-89 allows for the expansion of the range of documents at the TP stage, however, in practice, these documents are more than enough.

Technical design sheet

Designation: TP.

This document is intended to describe the list of documents developed at the stage of the technical project. The number of pages of each of the developed documents is also indicated.

Explanatory note to the technical project

Designation: P2.

This document is the main one for the TP stage and includes a description of the ISS architecture, technical and organizational measures, ISS functions, software and hardware complexes, and others. According to the standard, it consists of four main sections:

• general provisions;
• description of the activity process;
• main technical solutions;
• measures to prepare the automation object for putting the system into operation.

Functional structure diagram

Designation: C2.

This document describes the logical structure of the NIS, namely:

• logical subsystems and components included in the NIS;
• functions implemented by means of subsystems and components;
• information links between logical elements of the NIS and types of messages in the exchange.

Structural diagram of a complex of technical means

Designation: C1.

This document includes a description of the following elements of the NIS:

• technical means as part of the logical subsystems and components of the NIS;
• communication channels and exchange between technical means with indication of transport protocols.

Organization chart

Designation: C0.

This document describes the organizational structure of the organization in terms of ISS management, namely:

• subdivisions and responsible persons of the organization involved in the functioning of the ISS;
• functions performed and communications between departments and responsible persons.

List of purchased products

Designation: VP.

This document includes a list of all software and hardware, as well as licenses used in the creation of the NIS. Developed in accordance with GOST 2.106.

Note. It is also worth noting here that the governing document RD 50-34.698-90 allows the addition of any document of the TP stage (inclusion of sections and information other than those proposed), the merging of sections, as well as the exclusion of some individual sections. Decisions about this are made by the developer of documents of the TP stage and are based on the features of the created NIS.

1.4. Documentation development rules

• structural conformity state standards;
• strict compliance with the requirements of the technical specifications for the system;
• application of document templates (application of uniform styles, markup, fields, etc.);
• individual approach and simultaneous use of existing developments when filling out sections of documents.

Explanatory note to the technical project:

• the development of the document is carried out in the Microsoft Word environment, after the completion of the development it is recommended to convert the document to PDF format for convenience;
• terms and abbreviations should be the same within all sections of the document;
• it is recommended to avoid explicit repetitions and unnecessary increase in the volume of the document;
• technical solutions should be described in as much detail as possible, indicating:
  • architecture and technologies used;
  • locations of software and hardware in the infrastructure of the organization;
  • used information security tools with a description of their characteristics, implemented functions, certification information;
  • basic settings of information security tools in terms of protection mechanisms, addressing, routing, interaction with related systems and tools, and other things;
  • controls, methods of access to them and their installation locations;
  • schemes (structural, functional, organizational):
    • develop circuits in the environment Microsoft Visio;
    • after development, insert diagrams into a document using the Paste Special dialog in EMF format (Windows metafile);
    • develop separate schemes for the system, subsystems and components of subsystems;
    • make the design of schemes the same type, using the same elements, abbreviations, icons, text styles, and so on.

1.5. Resources to help you develop documentation

A huge amount of information is posted on the Internet, which, to one degree or another, can help in the development of technical project documentation. The main resources are presented in the table below.

Table. NIS Engineering Design Resources

1.6. Examples of documents of the stage of the technical project

To understand the requirements for the content of the documentation of the TP stage, examples of filling out the main documents (document sections) are presented below.

1.6.1. Explanatory note to the technical project

The explanatory note is a rather voluminous document, therefore, here is an example of the content of the section "Basic technical solutions" in terms of one of the ISS subsystems - the security analysis subsystem.

NIS security analysis subsystem

Structure and composition of the subsystem

The security analysis subsystem (SAS) is designed to systematically monitor the security status of automated workstations (AWPs) of personnel and organization servers. The basis of the PAZ is the software tool "Test" produced by the company LLC "Information Security". SZI Test has a certificate of FSTEC of Russia for compliance specifications(TU) on information security and on the 4th level of control of the absence of undeclared capabilities.

The composition of the PAZ includes the following components:

• Test Server management server;
• test console management console.

The description of the subsystem components is presented in the table below.

Table. PAZ components

Feature provision

PAZ provides the following functions:

• implementation of proactive protection of workstations and servers of the organization by monitoring the state of information security;
• automation of compliance control processes domestic politicians and certain safety standards;
• reducing the cost of auditing and security control, preparation of status reports;
• automation of resource inventory, vulnerability management, security policy compliance and change control processes.

Solution for a complex of hardware and software tools

The list of used software and hardware ESD is given in the table below.

Table. PAZ software and hardware

PAZ control server

Technical means

The physical server used as the SIS management server must meet the technical requirements for the software and OS installed on it, given in the table below.

Table. Requirements for the OS and software of the PAZ management server

Software

Management Server OS

Windows 2008 R2 OS is installed on the management server in the standard way from a bootable distribution.

The management server OS is managed both locally from the console and via the RDP protocol.

Management Server DBMS

The installation of the Microsoft SQL Server 2008 R2 database is carried out under an account with local administrator rights using the standard installation wizard from the distribution package supplied by the product developer.

Test Server software

The Test Server software is installed on the management server using the standard installation wizard.

The initial configuration and subsequent management of the Test Server software in normal mode is carried out using the Test Console management console installed on the IS administrator's workstation.

IS administrator workstation

Technical means

As a platform, an existing workstation of an employee of the organizational unit responsible for providing information security is used, running an OS of the Microsoft Windows family.

The technical means of the IS administrator's workstation must have the following characteristics of the hardware configuration (recommended at least):

• CPU 2 GHz;
• RAM 4 GB;
• HDD 80 GB.

Software

Test Console Software

The IS administrator's workstation, on which the Test Console software is being installed, must operate under one of the following operating systems:

• Microsoft Windows 7, 32- and 64-bit;
• Microsoft Windows 8/8.1, 32- and 64-bit.

In addition, for the correct operation of the Test Console management console software, the IS administrator's workstation must have Microsoft .NET Framework version 3.5 SP1 or higher installed, and the security settings of the OS used must allow access to the Test Server.

Installation of the Test Console software on the PAZ administrator's workstation is carried out using the standard Test Server software installation wizard with the option to install the Test Console management console and other default settings.

Interaction with related systems

For PAZ, adjacent are:

• means of the firewall subsystem;
• directory services Active Directory;
• Workstation and servers of the organization.

To ensure network interaction with adjacent systems and directly between the ESD components themselves, the passage of the necessary network traffic must be organized.

To provide the ability to receive updates of the knowledge base and modules of the Test software for the Test Server scanner, it is necessary to provide access to the update.com web server of Information Security LLC update.com on port 443/tcp.

When scanning in the PenTest mode, the interaction between the Test Server scanner and the workstation and the organization's servers is carried out via the IP protocol. Audit and Compliance scans use protocols remote control WMI, RPC, etc. To scan nodes on devices with firewall functions, you must allow connections from the Test Server to the scanned nodes via the IP protocol. Accordingly, for the Test Server, it is necessary to provide access to the network ports of the scanned nodes using the appropriate remote control protocols.

Since PAZ, when scanning in Audit and Compliance modes, uses remote control protocols for analysis, the scanning tools of the Test software must be authenticated and authorized on the scanned node. In PAZ, to scan nodes in Audit and Compliance modes, each type of node (workstation, server, application systems, DBMS, etc.) uses accounts with administrative privileges.

All registered information security events are stored in the Microsoft SQL DBMS. These events can be sent via special connectors to the IS event monitoring subsystem.

Operation and maintenance of PAZ

Subsystem Users

The operation and maintenance of PAZ tools is carried out by employees of the organization with the functional role of "IS administrator".

An IS administrator is a specialist whose tasks include:

• defining parameters for scanning organization nodes;
• setting up and launching scanning tasks;
• analysis of scan results for vulnerabilities, configuration errors or non-compliances in information systems technical standards;
• control of elimination of vulnerabilities;
• formation of standards and requirements that apply to ensuring the security of workstations and servers of the organization.

System operating modes

Regular mode of operation

In normal operation, the PAZ operates 24 hours a day, 7 days a week.

In normal operation, the IS administrator performs:

• scheduled and unscheduled scanning of nodes;
• report generation;
• updating knowledge bases and modules of Test software.

Emergency operation

In the event of a malfunction of the PAZ means, the functioning of the subsystem is disrupted. Violation of the operability of PAZ means does not affect the functioning of the workstation and servers of the organization.

1.6.2. Functional structure diagram

Functional diagrams can be developed for the entire NIS or for a part of it, such as a subsystem or component.

An example of a general functional diagram of the NIB is shown in the figure below.

1.6.3. Structural diagram of a complex of technical means

A block diagram of a complex of technical means can be developed both for the entire NIS and for its parts - subsystems and components. The expediency of developing schemes for parts of the NIS is determined by the scale of the system and the required detail.

An example of a block diagram of the complex of technical means of the NIS is shown in the figure below.

Ministry economic development and trade Russian Federation

Below is an example (sample) of a project document " Explanatory note to the technical project for the creation of an automated system"based on methodological guidelines RD 50-34.698-90. This document is formed by an IT specialist at the stage technical design of the information system.

As an example of the development of an information system, the project for the implementation of an information and analytical system was used. "Corporate Data Warehouse".

On the page below is content of the explanatory note of the technical project in accordance with GOST, within each of the sections briefly the requirements for the content and the text of the filling example are given(highlighted by a vertical line).

Sections of the explanatory note:

General provisions

Main technical solutions

Decisions on the structure of the system, subsystems, means and methods of communication for information exchange between system components

Solutions for the interconnection of the AU with adjacent systems, ensuring its compatibility

Solutions for operating modes, diagnosing system operation

Decisions on personnel and modes of its work

Information on ensuring the consumer characteristics of the system specified in the terms of reference, which determine its quality

The composition of functions, complexes of tasks implemented by the system

Composition and placement of complexes of technical means

Explanatory note to the technical project.

The main purpose of creating an IS is to speed up the "sales process", as well as increase the efficiency of employees. To ensure the system's performance on computers where it is used, it must be installed software:

• - OS of the Windows family;
• - 1C: Enterprise 8;

New data is entered into the system before starting work, this is necessary for entering initial balances. To limit unauthorized changes, authorization is used when entering the program. If the password is entered incorrectly, the system will display a message and will not allow you to connect to the database.

The system has three main tasks:

• - maintenance of directories;
• - maintaining warehouses;
• - registration of sales;
• - output of reports.

The DB application for IP is developed using the 1C: Enterprise 8 software environment. To host the system, personal computers are used that are available to the individual entrepreneur for whom the system is being developed.

Scheme functional structures

The general requirements for the functionality of the system being designed are shown using the VI diagram in Figure 1

Table -2 The main section of the VI execution script "Add directory data"

	Edit directory data
	Storekeeper, IP
	Maintaining up-to-date information about the objects of the subject area
Short description	The user adds a new directory element and writes it down. The system saves the changed data in the database
Precondition	1. The user is authorized in the system. 2. The user has the rights to add data to the directory
postcondition	1. The directory element is written to the database. 2. The directory element is displayed in the form of a directory list

Table -3 Typical course of events of the VI execution scenario "Add directory data"

Table -4 Exclusions of the VI execution scenario "Add directory data"

Table -5 The main section of the VI execution script "Set item prices"

Table - 6 Typical course of events of the VI execution scenario "Set item prices"

Table -7 Exclusions of the VI execution scenario "Set item prices"

Table -8 The main section of the VI execution scenario "Register the receipt of goods"

Table -9 Typical course of events of the VI execution scenario "Register receipt of goods"

Actor actions	System response
1. The storekeeper executes the command to create a new document "Receipt of goods"	2. The system displays the document form
3. The storekeeper fills in the details of the header Exception #1: Storekeeper manually fills in the Number field
4. The storekeeper adds a new row in the tabular section on the Products page	5. The system displays a new line
6. The storekeeper fills in the Nomenclature column	7. The system substitutes the value of the columns
8. The storekeeper fills in the Quantity column	9. The system calculates the value of columns Amount,
10. The system displays in the footer of the tabular part the total values ​​of the columns Total
11. The storekeeper enters new product(return to step 4) or execute the Write command Exception #2: The value of the Number field is not unique	12. The system writes a new document "Receipt of goods" in the database
13. The storekeeper executes the command Print -	14. The system displays the completed printed form receipt order
15. The storekeeper executes the Print command	16. The system prints out the receipt order
17. The storekeeper executes the command Close the printing form	18. The system closes the printing plate
19. The storekeeper executes the command Close the document "Receipt of goods"	20. The system closes the form of the document "Receipt of goods"

Table -10 Exceptions for the execution scenario of the VI "Register the receipt of goods"

The values ​​of the sum and total columns are calculated by the formula:

Amount = Quantity * Price

Table -11 section of the scenario for the execution of the VI "Make sales"

Table -12 Typical course of events of the scenario for the execution of the VI "Make sales"

Actor actions	System response
Payment for one "sales" document
1. The manager executes the command to create a new sales document	2. The system displays the form of "sales" documents
4. Manager posting the document
5. The system holds the document
9. The system prints

Table - 13 Exceptions of the VI execution scenario "Register document"

Table -14 section of the script for the execution of VI "Reservation"

Table -15 Typical course of events of the scenario for the execution of the VI "Making Sales"

Actor actions	System response
Product reservation
1. The manager executes the command to create a new reservation document	2. The system displays the form of "reservation" documents
3. The manager enters data about the client, the purchased product and purchased services
4. Manager posting the document Exception #1 not all fields are filled	5. The system holds the document
6. The manager executes the Print command	7. The system displays the completed printable
8. The manager executes the Print command	9. The system prints
10. The manager executes the command Close the printing form	11. The system closes the printing plate
11. The manager executes the command Close the document "provision of services"	12. The system closes the document form

Table - 16 Exceptions of the VI execution scenario "Register document"

Table -17 VI "Create a report"

Development of the directory structure

Directory "Contractors" designed to store information about customers, suppliers.

Table -15 Details of the reference book Clients

Legal status is of type enum. This means that when this field is selected, a list of three statuses will appear: IP, Physical. Person, Organization.

Creation directory "Employees". Designed to store information about the employees of the organization. Allows you to link a sale to a specific employee.

Table -16 Details of the directory Employees

Creation directory "Warehouses". Designed to determine the storage location of goods. The IP will have two warehouses - Trading Point 1 and Trading Point 2.

Creation directories "Option Items» and "Additional Properties". These references are intended to define additional characteristics for a particular product range, that is, monitors may be identical, but colors will differ. These directories will be called in the form of the nomenclature directory. The value of these fields is displayed in the "Sales" document.

Creation directory "Nomenclature". To account for goods purchased from a supplier, we will create a reference book "Nomenclature".

Items in the Nomenclature lookup will be combined into groups according to their functional purpose, so the lookup will look like a “hierarchy of groups and elements” hierarchy.

Table -17 Requisites of the reference book Nomenclature

Development of the structure of the information register "Nomenclature prices"

To store the cost of nomenclature units, we will create a register of information with the name "Prices". The frequency of the register is within a second (ie prices can be tracked for any moment in time), the recording mode is independent.

Table -18 Structure of the information register Prices

The Leading property indicates that the information register entry is of interest as long as the object whose reference is selected as the value of this dimension in this entry exists. When an object is deleted, all information register entries for this object will be automatically deleted.

Development of the structure of the document "Receipt of goods"

The document "Receipt of goods" is intended to reflect the fact of receipt of purchased goods by the organization.

Table-19 details of the document "Receipt of Goods (Receipt Invoice)"

Table -19 Details of the tabular part of the document "Receipt of Goods"

A code was written to automatically calculate the values ​​of the columns Amount, when changing the values ​​of the columns Quantity, Price.

The form of the document will look like shown in Figure 2




Figure 2- Document form Receipt of goods

Development of the structure of the document "Sales"

The document for the provision of services is intended to record the activities of an individual entrepreneur. It controls the write-off of goods, services that have been completed, and also allows you to view a report on the work of employees.

Table -20 Details of the document "Sales"

Table -21 Details of the tabular section of the Sales document

Development of the structure of the document "Reservation"

The "Reservation" document is designed to reserve the existing goods in the warehouse, and in case of shortage, take the missing part of the goods for the client. It is also necessary to reserve the goods until the customer pays the cost of the order. This document is designed to control stock balances in order to avoid misunderstandings with the client.

Table -20 Details of the document "Reservation"

Table -21 Details of the tabular part of the document Reservation

Development structures document "Input primary remnants"

This document is required to enter the initial balances into the database.

Its details are similar to the document "Receipt invoice".

Creation report "Products"

The Goods report is designed to quickly view the write-off and receipt of goods. That is, it allows the user to view how much this moment is nomenclature, how many sold.

In the 1C Enterprise 8 environment, there is a report builder that allows you to quickly develop a report by generating queries and design based on tables.

Creation report "Register of Documents of Sale"

This report is designed to generate a register of "sales" documents. Also, various reports will be implemented in the system, which will be similar in terms of the structure of creation.

Creation roles and appointment them users

Administration of the list of 1C:Enterprise users and assignment of roles to them in accordance with their official duties- very important points for organizing the interface of the applied solution as a whole and delimiting the rights and actions of its individual users.

Users should be restricted from performing actions on database objects. For example, the storekeeper can create Goods Receipt documents and record documents, since he is responsible for registering the receipt of goods. The manager, in turn, should have access to adding customer directories, drawing up a "sales" document, "reservation", but at the same time he should not have access to the receipt of goods.

Role configuration objects are used to describe such permissions. Each user of the system is assigned one or more roles.

Roles are created based on what permissions are required for different user groups to access information. The following roles will be implemented in our system:

• - administrator - in the 1C:Enterprise system there must be a role that includes full rights to work with IS data;
• - storekeeper;
• - manager;
• - IP.

Assignment of roles to users is carried out through the main menu item Administration -> Users.



Figure 3 - Creating an "Administrator" user with the "Administrator" role



Figure 4 - List of system users

The interactive delete right is disabled for all database objects for all roles.

Editing command interface sections and working table

Improving the application's command interface, setting the visibility of commands by roles and the desktop makes the application more user-friendly and gives it a complete look.

Let's sort the commands depending on the priority and frequency of use into the following groups:

• - navigation bar.Important;
• - navigation bar. Normal;
• - navigation bar. also;
• - action bar.Create and
• - action bar. Reports



Figure 5 - Command interface of the "Materials Accounting" section of a user with the "Storekeeper" role



Figure 6 - Command interface of the "Provision of Services" section of a user with the "Manager" role




Figure 7 - Command interface of the "Enterprise" section of a user with the "Director" role



Figure 8 - Command interface of the "Retail.Electronics" section of a user with the "Administrator" role

The desktop is designed to accommodate the most frequently used documents, reports, directories, etc. by the user. When 1C:Enterprise is launched, the Desktop section becomes active by default and the required forms immediately open in the application workspace.




Figure 9 - Desktop for a user with the role of "Storekeeper"




Figure 10 - Desktop for a user with the "Manager" role

automation wholesale software documentation