Our specialists helped the customer draw up Technical specifications for the modernization of the ventilation system.

More details under the cut..

Technical task

for the modernization of the technological equipment of the ventilation systems of the laboratory building No. 451,452, building 17 at the address: Moscow

1. General Provisions

1.1. This technical assignment provides for the implementation of work on the modernization of technological equipment, control systems and automation of ventilation units of the building, laboratories No. 451,452 of building 17.

1.2. To carry out the work, develop working documentation for sections of the AOB, EM, XS, AHS, AK brands, which must be agreed upon in accordance with the established procedure.

1.3. Carry out work in compliance with the requirements of regulatory and technical documentation.

1.4. Upon completion of the work, present the as-built documentation made in accordance with the requirements of GOST and SNiP.

1.5. Hand over the completed work to the Customer.

1.6. Certain provisions of this Technical Specification may be clarified during the work process by agreement with the Customer.

2. Technical requirements

2.1. Modernization of heat and cooling control units for ventilation units.

2.1.1. Heat supply control units.

The following are subject to modernization:

· heat supply control units for the first heating of ventilation units K1, K2, K2a, K4 of the MIK-V building, P2, P6 of laboratory No. 452, P1 of laboratory.

· heat supply control units for the second heating of ventilation units K1, K2, K2a of the MIK-V building.

Existing heat supply control units are subject to dismantling, while some of the equipment of control units (circulation pumps, shut-off valves) corresponding to the condition and technical specifications, to be used in mounted control units.

The composition of the equipment of the installed control units, as well as the equipment used, is indicated in Appendix No. 1.

Conduct hydraulic tests of heating circuits and heaters of ventilation units with the execution of a hydraulic test report.

Carry out painting of pipelines and thermal insulation work.

2.1.2. Units for regulating the cold supply of ventilation units.

The refrigeration units of ventilation units K1, K2, K2a, K4 of building MIK-V, P2, P6 of laboratory “452”, P1 of laboratory No. 451 are subject to modernization.

Scope of work:

· replacement of thermostatic valves of refrigeration control units;

· dismantling/installation of the fan of the compressor-condensing unit K1;

· dismantling/installation of filter-driers of compressor-condensing units K1, K2;

· dismantling/installation of the evaporator of the K4 ventilation unit;

· pressure testing in an inert gas environment, vacuuming, refilling refrigeration circuits with freon;

· restoration of thermal insulation of pipelines.

2.1.3. Feeding units for humidification circuits.

Install cold water purification filters at the replenishment units for the irrigation chambers of air conditioners K1, K2, K2a.

2.2. Control and automation cabinets for ventilation units.

Control cabinets for ventilation units K1, K2, K2a, K4, RU3, V1, V2, V3, V6, V7, V8, buildings MIK-V, P2, P6, V1, V2, V3 laboratories No. 451, P1, V1 laboratories No. 451 are subject to dismantling 452.

Layout of newly installed control panels:

SHUA K1 – control and automation cabinet for the ventilation unit and compressor-condensing unit (KKB) of the air conditioner K1 (MIK-V);

SHUA K2 – control and automation cabinet for the ventilation unit and control unit for the K2 air conditioner (MIK-V);

SHUA K2 – control and automation cabinet for the ventilation unit and control unit for the air conditioner K2a (MIK-V);

SHUA K4 – control and automation cabinet for the ventilation unit and control unit for the air conditioner K4 (MIK-V);

SHUV – control cabinet for exhaust units RU3, V1, V2, V3, V6, V7, V8 (MIK-V);

SHUA P2, P6 – control and automation cabinet for ventilation units and compressor-condensing units P2, P6 (laboratory No. 452);

SHUV – control cabinet for exhaust units V1, V2, V3 (laboratory No. 452);

SHUA P1,V1 – control and automation cabinet for ventilation units P1, V1 (laboratory No. 451).

Modernized control cabinets must provide:

· selection, from the front panel of the cabinet, of the control mode for ventilation units (manual/automatic);

· light signaling of normal and emergency operating modes of process equipment of ventilation units (operation/emergency);

· shutting down ventilation units in the event of a fire;

· automatic activation of protections and blocking of equipment operation in the event of emergency situations.

Frequency converters for controlling electric motors of fans and pumps are subject to further use.

2.3. Automation and dispatch system

The automation and dispatch system is designed to manage and monitor the operation of ventilation units, as well as to collect, process, present and store incoming information.

2.3.1. Automation system.

The automation system should ensure, basically, autonomous operation of ventilation units, which does not require the intervention of maintenance personnel and a transition, if necessary, to manual control mode. For any control options and regardless of the state of the local controller, the condition for automatic shutdown of the general ventilation system in the event of a fire must be maintained. Disconnection should be carried out individually for each system while maintaining power supply to the frost protection circuits.

Local automation of ventilation systems should include:

· regulation of the supply air temperature at the outlet of the ventilation unit or, if necessary, the temperature of the exhaust air from the serviced room;

· regulation of supply air humidity;

· stopping fans and closing air valves when a fire alarm is triggered;

· turning off air conditioner humidification when its fan stops;

· opening and closing of the air valve, respectively, when starting and stopping the fan;

· automatic heating of heaters before starting systems in winter mode;

· protection against freezing of air and water heaters (turning off the fan, closing the air damper, opening the heating valve 100%);

· fan shutdown in the absence of pressure drop;

· control of contamination of installation filters.

Remote influence on local automation with automated workstation is determined in the following volume:

· changing the settings of temperature and humidity controllers;

· enable/disable settings.

Existing peripheral equipment of the automation system is subject to verification, cleaning and further use in the following order:

· temperature and humidity sensors of ventilation units are subject to verification;

· differential pressure switch sensors must be checked and cleaned;

· Thermostats for protecting heaters of ventilation units from freezing must be replaced.

· drives of control valves of control units must be replaced in accordance with clause 2.1.1.

· air valve drives are subject to inspection and further use;

To control the recirculation of the K1 air conditioner, replace the on-off air valve drives with valves with a control signal of 0..10V.

2.3.2. Dispatch system.

The dispatch system should include the following components:

· a complex of measuring devices, actuators and automation equipment based on Honeywell software and hardware;

· multifunctional cable system;

· complex of software and hardware for the dispatch center.

To dispatch ventilation systems, provide for display, archiving and logging of the following information:

· graphical representation of installations with temperature and humidity sensors, anti-freeze thermostats, differential pressure switches, control valves, humidifiers, air valves;

· installation numbers;

· readings of temperature and humidity sensors;

· differential pressure relay sensor readings;

· position readings of control valves 0..100%;

· fan operation/stop mode;

· operating/stop mode of pumps;

· position of air valves “open/closed”;

· stopping systems when a fire alarm is triggered;

· stopping systems when there is a threat of freezing of the heater;

· stopping the installation if there is no pressure drop across the fan;

· turning off the air humidifier when the air conditioner fan stops;

· operation of systems according to a given time schedule or without it;

· signaling of accidents and emergency situations in the event of equipment malfunction, as well as when the values ​​of technological parameters go beyond the specified ranges;

· registration of accidents and emergency situations in the message log;

· parameter registration log for the current time, indicating the name of the controlled parameters, units of measurement, controller number and input/output channel.

2.3.3. The power supply of the automation and dispatch system must be carried out from an alternating current network with a voltage of 380/220 V, a frequency of 50 Hz using sources uninterruptible power supply on rechargeable batteries and provided as power supply for electrical receivers of the first category

In life, it often happens that a person cannot explain what he wants, even in everyday things. When it comes to explaining your “wants” to a programmer, a person simply falls into a stupor.

Ideally, the technical specifications should be drawn up by the customer - only he knows what he needs. But in practice, due to the customer’s low competence in the 1C field, this often has to be done by the contractor. The customer verbally voices his needs, and the programmer (consultant) puts it in writing.

Why do you need technical specifications?

Any, ideally, should be accompanied by technical specifications. This is, firstly, a clear definition of the task, deadlines and method of implementation. Secondly, this is a document with the help of which all controversial issues in the future are resolved. Whether to write technical specifications or not is, of course, your business; for me personally, technical specifications make my work and communication with the client easier.

Get 267 video lessons on 1C for free:

What should the terms of reference contain?

Those. the assignment must contain:

• target— the problem that we will solve by implementing this specification;
• description — summary upcoming improvements;
• implementation method — detailed description methods for solving the goal. At this point, it is necessary to describe all the nuances of the task in the programmer’s language: what kind of tasks we are creating/editing, what the interface should look like, etc. If you do not speak “programmer language”, but “have heard something”, it is better not to try to write in a technical language - it turns out to be quite fun. The description should be unambiguous and not raise questions. It may also contain an example of implementing a similar solution in another area;
• performance evaluation- a very important point, a description of labor costs.

There are also state standards for writing technical specifications - GOSTs. In practice, they are rarely used, but sometimes the customer insists on it.

From experience, when handing in work, situations very often arise like “we told you then...”, which is not very pleasant, and often you have to redo the entire work. Therefore, a well-written technical specification makes life much easier for both parties.

Examples and samples of technical specifications for 1C

A small selection that I found freely available on the Internet. Starting from the simplest and most accessible to quite complex documents.

Due to the fact that people often ask for examples of technical specifications, I share some of my work with the community. These documents have no commercial value (due to age and configuration), but I hope they can be useful as samples.

Technical task:

Automated

SALES system.

Technical task

On sheets

"_" ______________ 2010

1. General information

Name of the automated system

"AS Sbyt"

Customer

Executor

Basis for the work

Planned dates for the start and end of work on creating the system

Start of work: 01.09.2010

Completion of work: 12/31/2010

Purpose and goals of creating the system

Purpose of the system

The automated system being developed is designed to automate the sales processes of an enterprise.

Goals of creating the system

Goals of creating an automated system

The objectives of the development of "AS Sbyt" are:

1. 3. Characteristics of the automation object

3.1 Enterprise business processes

3.1. 1 Business process “Concluding an agreement”

3.1.2. Business process “Calculation of payments”

1. 4. System requirements.

4.1. Requirements for the system as a whole.

4.1.1. Methods developed at AS and software modules should contain opportunities for further development of the system.

5.1.1. The system being developed should consist of automated systems, subsystems and accounting modules, allocated according to their functional purpose in accordance with the established methodology for constructing automated systems of financial and economic class.

5.1.2. The AS being developed should ensure ease of setting up an automated workstation (AWS) for each specific performer in accordance with the existing accounting system.

5.1.3. The AS being developed must ensure differentiation of user access rights and provide the ability to access information to the extent necessary and sufficient to carry out the official duties of each performer.

5.1.4. Protection of information from unauthorized access must be implemented using the following mechanisms:

1. Restrictions on access rights at the 1C:Enterprise platform level 8.1.

2. Additional restrictions on access rights at the runtime environment level.

5.1.4.1.Priority should be given to restrictions on access rights at the platform level. Removing additional restrictions at the runtime level does not give access rights to objects or functions of the system if a system restriction is imposed on them.

5.1.4.2. Information protection at the platform level

· Information protection at the platform level is provided by system means. This regulates the rights to read and edit system objects, use interfaces, system functions and performing routine operations with data information system.

· All access rights must be systematized into appropriate sets - Information system roles.

· The list of information system users must be determined by the system administrator.

· The access rights of each user must be determined by the set of information system Roles available to him.

· The sets of information system roles available to each user must be determined by the system administrator.

· When starting to work in the system, the user must go through the authorization procedure by indicating his name in the system and password.

5.1.4.3. Protection of information at the runtime level

For a number of directories in the system, additional restrictions on editing rights must be provided.

Directories for which it is necessary to prohibit editing in the system:

• Address abbreviations
• Currencies
• Types of mutual settlements
• Types of activities of counterparties
• Group of users
• Identity documents
• Organization positions
• Divisions
• Users
• Cash flow items
• Expenditures
• Rates

5.1.5. To ensure the safety of information in case of accidents, daily automatic data archiving must be provided.

5.1.6. Requirements for ergonomics and technical aesthetics

5.1.6.1. To ensure unification of the design of user interfaces, toolbars and context menus automatically generated by the 1C platform should be used by default.

5.1.6.2. The terminology used to designate objects and user actions in the system must correspond to the standard terminology of the subject area.

5.2. Requirements for the structure and functioning of AS "SABYT".

5.2.1. AS "Sbyt" should consist of the following automated subsystems:

Subsystem for entering primary information about the subscriber (concluding an agreement);

Subsystem for generating payment documents;

Communication subsystem with the ASKUE system;

Communication subsystem with payment terminals.

5.2.2. The composition of the Subsystem for entering primary information about the subscriber (concluding an agreement) should be as follows:

Document “Agreement with the subscriber”;

5.2.3. The composition of the Subsystem for generating payment documents should be as follows:

Document "Receipt"

Document “Accrual of penalties”

Document "Consumed Energy"

Module for checking the status of mutual settlements

5.2.4. The composition of the Communication Subsystem with the ASKUE system should be as follows:

Module Communication with the ASKUE system.

5.2.5. The composition of the Communication Subsystem with payment terminals should be as follows:

Module Communication with payment terminals.

5.3. Requirements for the functions of the Subsystem module for entering primary information about a subscriber (concluding an agreement)

5.3.1. The subsystem for entering primary information about the subscriber (concluding an agreement) must perform the following functions:

Entering and storing information about the installed capacity of the counterparty (hereinafter referred to as the subscriber);

Entering and storing information about the subscriber’s installed meters;

Entering and storing information about subscriber tariffs;

Entering and storing information about the conditions for calculating penalties for the subscriber;

Entering and storing information about the duration of the contract;

5.4. Requirements for the functions of the Subsystem for generating payment documents

5.4.1. The subsystem for generating payment documents must perform the following functions:

Determining the status of mutual settlements with the subscriber and determining the conditions for the occurrence of penalties.

Generating payment documents (receipts or invoices).

5.5. Requirements for the functions of the communication subsystem with the ASKUE system

5.5.1. The communication subsystem with the ASKUE system must perform the following functions:

Transfer of data on newly concluded contracts with subscribers. The communication key must be the uniqueness of the pair “Subscriber ID” - “Subscriber Agreement Code”.

Obtaining data on the subscriber's electricity consumption. The communication key must be the uniqueness of the “Counter ID” - “Counter Code” pair.

5.6. Requirements for the functions of the Communication Subsystem with payment terminals

5.6.1. The communication subsystem with the ASKUE system must perform the following functions:

Receiving data on payments made by subscribers for electricity through payment terminals.

1. 6. The procedure for control and acceptance of AIS "SALES".

6.1. The following procedure is established for presentation and delivery of work results to the Customer:

6.1.1. The contractor demonstrates the functionality of the software using a test example.

6.1.2. The data for the test case is prepared by the Customer's representatives.

6.1.3. The Contractor transmits software to the Customer's information department and trains the Customer's administrator.

6.1.4. Based on the results of the test case solution, a Certificate of Transfer of Software for Trial Operation should be prepared.

6.1.5. In case of non-compliance functionality According to the requirements of the technical specifications, the Contractor eliminates the comments within the total cost of developing the AS.

6.1.6. If additional Customer requirements to the technical specifications arise, an additional technical specification for revision is drawn up.

6.1.7. The presence of additional requirements of the Customer should not be a basis for refusal to sign the Certificate of Transfer of Software for Trial Operation.

6.1.8. After transferring the software into trial operation, according to the Implementation Schedule agreed with the Customer, the Contractor briefly trains the Customer’s personnel in working with the software and transfers Instructions for working with the software to each subsystem.

6.1.9. When implementing the software (trial operation), the Customer carries out:

Entering the required reference data;

Entering actual data;

Generating reports and checking work results.

6.1.10. During the implementation process, the Contractor must provide assistance to the Customer within the framework of the Implementation Schedule.

6.1.11. In case of poor preparation of the Customer’s personnel for implementation and the need for additional assistance by the Contractor for successful implementation of the software, an additional protocol must be drawn up for agreeing on contractual prices for the provision of information and consulting work.

6.2.The procedure for further support of tasks of AS "SALES".

6.2.1. After the software is put into operation, additional modifications and wishes of the Customer can be implemented according to the technical specifications agreed with the Customer.

The TOR must indicate the complexity and cost of work to implement additional requirements.

6.2.2. The Contractor undertakes to maintain telephone " hotline"for software support.

6.2.3. At the Customer's request, the Contractor may provide software support directly from the Customer, which must be carried out on the basis of an additional agreement for software support.

6.2.4. Errors identified by the Customer within six months from the date of transfer of the software into operation must be corrected by the Contractor promptly and free of charge.

If the Contractor discovers that the error arose as a result of incorrect actions by the Customer, the time spent by the Contractor to find and eliminate it must be paid additionally.

6.2.5. The customer, within a year after purchasing 1C: Enterprise, has the right to receive free all updates from the 1C company related to the development of 1C programs and changes in legislation. Installation of changes must be carried out by the Customer's automated control system.

6.2.6. The Contractor guarantees the confidentiality of the content of the Customer's databases and any other information received from the Customer during the development, implementation or maintenance of the AS.

Technical project:

I APPROVED I SUBMIT FOR APPROVAL

" "______________ 2010 " "_______________ 2010

Appendix to the technical specifications dated “____” ________ 2010

Automated

SALES system.

Technical project

On sheets

Valid from "__" ____________ 2010

Directories. 3

Counters. 3

Tariffs.. 3

Substations. 3

Penalty options. 3

Transfers. 4

Types of charges. 4

Information registers. 4

Meaning of Tariffs. 4

Subscriber tariffs. 4

Meters data. 5

Accumulation registers. 5

Power consumption. 5

Documents.. 6

Agreement with the subscriber.. 6

Energy consumed. 6

Receipt. 7

Calculation of penalties. 9

Processing. 10

Receiving data from the ASKUE system. 10

Retrieving data from payment system.. 11

Directories

Counters

Requisites:

Rates

Details: no

Penalty options

Details: no

Transfers

Types of charges

Values:

Information registers

Duration of contracts

Frequency: Non-periodic

Purpose: Designed to store the validity periods of contracts with subscribers

Measurements

Meaning of Tariffs

Frequency: Day

Purpose: Designed to store tariffs and the dates from which the tariffs begin to apply

Measurements

Props		Purpose
		Daily rate cost
		Night rate cost (may not be specified)

Subscriber tariffs

Frequency: Day

Purpose: Designed to store tariffs assigned to the subscriber according to contracts

Measurements

Props		Purpose
	Directory Tariffs	Subscriber tariff

Meters data

Frequency: Day

Purpose: Designed to store meter readings for subsequent charging

Measurements

Props		Purpose
IndicationsDay		Meter reading
IndicationsNight		Meter reading

Accumulation registers

Power consumption

Purpose: Designed to store information about energy consumption for subsequent billing

Register type: negotiable

Measurements

Documentation

Agreement with the subscriber

Purpose: Designed to reflect the fact of concluding an agreement with the subscriber

Props		Purpose
Counterparty	Directory Contractors
Counterparty Agreement
	Directory Tariffs
InstalledPower		Storing the subscriber's installed power in KW
Start DateAction		Date from which the contract is valid
End DateAction		Contract expiration date
Organization	Organization Directory
Option of Accrual of Fines
Nomenclature	Directory Nomenclature
Manual Adjustment		Sign of manual adjustment of document entries

Table part: Counters and Tariffs

Posting a document

The document is carried out:

According to the information register “Meter readings”, where the subscriber’s meters and initial meter readings are registered;

According to the information register “Subscriber Tariffs”, where the tariff established for the subscriber from the start date of the contract is recorded

According to the information register “Validity periods of contracts”, where the contract is written, the start date and the expiration date of the contract

Energy Consumed

Purpose: Designed to reflect meter readings on a specific date

Filling out the document

The document can be filled out in two ways: manually and by calling the “Receiving data from the ASKUE” processing.

Posting a document

The document is carried out:

According to the information register “Meter readings”, where the meter readings are recorded as of the date of the document;

According to the accumulation register “Energy consumed according to the following algorithm:

1. Meter readings are taken from the information register “Counter Readings” as of the document date and the previous meter readings.

2. Differences in reading values ​​are entered into the corresponding resources of the accumulation register.

Printable forms

Register of meter readings

Receipt

Purpose: Designed to reflect charges to subscribers

Filling out the document

The document can be filled out in two ways: manual entry and by calling the “payment accrual” processing

Tabular part: Meter readings

Props		Purpose
Counterparty	Directory Contractors
Counterparty Agreement	Directory Contracts of counterparties
Nomenclature	Directory Nomenclature
	Directory Tariffs	Subscriber tariff according to the contract
	Directory Counters
TypeAccruals	Transfer Types of Accruals
Energy Consumed		Energy consumed
Tariff value		Tariff value as of document date
Accrued		Amount charged to the subscriber

Posting a document

The document is carried out:

According to the tax chart of accounts:

Printable forms

Register of charges

Filling algorithm

The document is filled out on the basis of the reference book “Counterparty Agreements”.

1. From the directory, contracts are selected for which, according to the information register “Validity periods of contracts”, the Start Date is less than the document date and the End Date is greater than the document date;
2. Meters corresponding to these contracts are selected;
3. For meters, energy consumption is determined as the turnover in the accumulation register “Energy Consumption” for the period between the date of the document and the date of the previous document; if the date of the previous document is unknown, then the entire turnover in the register is taken. The resulting value is recorded in the “ConsumedEnergy” field
4. The tariff is established in accordance with the contract and the value of the tariff as of the date of the document;
5. The accrual type is set to “According to meter readings”;
6. The Accrued Field is calculated as the product of Energy Consumed and Tariff Value.

Algorithm

Kt. 90.01 with analytics SubcontoKt1 - Nomenclature.NomenclatureGroup, SubcontoKt2 - Nomenclature.VAT Rate.

If there is a Credit balance on account 62.02, then the advance is offset with the posting

Dt. 62.02 with analytics SubcontoDt1 - Counterparty, SubcontoDt2 - Counterparty Agreement

The transaction amount is the minimum value of the credit balance of account 62.02 and the value of the “accrued” variable)

Dt. 90.03 with analytics SubcontoDt1 - Nomenclature.NomenclatureGroup, SubcontoDt2 - Nomenclature.VAT Rate

Kt. 62.01 with analytics SubcontoKt1 - Counterparty, SubcontoKt2 - Counterparty Agreement

Transaction amount = “Accrued”*VAT Rate/(100+VAT Rate), where VAT Rate is “Nomenclature.VAT Rate”

Calculation of penalties

Purpose: Designed to reflect the accrual of fines to subscribers

Filling out the document

The document can be filled out in two ways: by manual entry and by calling the “calculation of fines” processing

Tabular part: Meter readings

Props		Purpose
Counterparty	Directory Contractors
Counterparty Agreement	Directory Contracts of counterparties
Option of Accrual of Fines	Directory Options for Accrual of Penalties
Accrued		Amount charged to the subscriber

Posting a document

The document is carried out:

According to the self-supporting chart of accounts:

According to the tax chart of accounts:

Printable forms

Register of charges

Payment receipt with barcode

The barcode is generated using the “Infograftbarcode” font

Formation algorithm Line “0000”+Subscriber agreement code+Accrued

The receipt layout is attached in the file KV_1.mxl

Algorithm

For each line of the tabular section “Meter readings” the following entries must be made:

Dt. 62.01 with analytics SubcontoDt1 - Counterparty, SubcontoDt2 - Counterparty Agreement

Kt. 91.01 with analytics SubcontoKt1 - Other income.

Transaction amount - the value of the “Accrued” attribute;

Treatments

Receiving data from the ASKUE system

			Accuracy	Purpose
				The meter code in the Sales system coincides with the meter_ID in the ASKUE system
				Daily meter readings
				Meter readings at night tariff

Processing details

Processing algorithm:

1. Get the counter code from a data transfer file line
2. Find the corresponding element in the “counters” directory by code; if the element is not found, then display the message “The counter with the code was not found...”
3. If the element is found, then add a line to the table of values, where: “counter” - the found element, “ReadingsDay” - “Day”, “ReadingsNight” - “Night”
4. If processing is called from the document “Consumed Energy” and the number of lines

in the table of values ​​is greater than 0, then write the contents of the table of values ​​into the tabular part of the document and post the document.

1. If there are rows in the value table and processing is not called from the “Consumed Energy” document, then create a “Consumed Energy” document with a date equal to the current date and then post the document.

Receiving data from the payment system

Data transfer file format is DBF;

Data transfer file structure:

Processing details

Processing algorithm:

1. Create a table of values ​​with the structure:

1. Select data transfer file lines
2. Start looping through the lines of the data transfer file
3. Read data transfer file line
4. Get the contract code from the data transfer file line
5. Find the corresponding element by code in the “Counterparty Agreements” directory; if the element is not found, then display the message “An agreement with the code was not found...”
6. If the element is found, then add a line to the table of values, where: “Agreement” - the found element, “Date” - “Data_plat”, “Payment Number” - “Nomer_plat”, “Amount” - “Summa_plat”
7. After receiving the last line of the data transfer file, end the cycle
8. For each row of the value table, create a “Payment order for receipt of funds” document. When creating a document, check whether there is a document in the system with the same date and the same number of the incoming document. If the document is present in the system, then the document is not created.
9. Rules for filling out document details:

Props	Fill value
Type of operation
	TableLineValuable.Date
Incoming document number	Table LineVal.NumberPayment
Date of incoming document	TableLineValuable.Date
Counterparty agreement	TableLineValuable.Contract

Many people are faced with the fact that it is quite difficult to explain briefly and clearly what we want in everyday life. And when you need to give a specialist the task of writing a program for an organization or individual entrepreneur, taking into account the features and your own wishes for functionality, you can get completely stuck.

Who should write the technical specifications?

Of course, the technical specifications must be provided by the customer, since he certainly knows his needs and capabilities. But, as practice shows, the vast majority of clients are not competent in 1C. That is why the contractor himself is often forced to delve into the customer’s needs, understand what final product he needs, and accordingly put all this in writing for the programmer.

Why is the technical specification needed?

In an ideal situation, with one or another modification in a 1C software product, a technical specification is required. First of all, the tasks, deadlines and method of execution must be spelled out.

This is an important document, because if any controversial issues arise, the competent development of technical specifications will become the starting point in negotiations.

Whether to draw up a technical specification or not is something everyone decides for themselves, but it certainly won’t be superfluous: it will simplify communication with the client and give the work a business-like and concrete character.



Let us outline a list of the most important points that should be in the technical specifications:

1. Goal/Objective. Formulate what should be implemented in the end.

2. Description. Briefly outline the content of the planned improvements.

3. Method of implementation. Describe in detail the methods by which the goal should be achieved. All features of the task should be written down in the programmer’s language: registers, directories (create them or edit them); interface design, etc. For those who are not familiar and have only heard something about a specific programming language, we advise you not to make unnecessary attempts to “speak” in a technical language. Because a description ideally is a dry statement that eliminates ambiguity and the possibility of unnecessary questions arising. In addition, this paragraph may include an example of how similar programming has already been performed somewhere.

4. Performance evaluation. This point is very important - it needs to describe labor costs.

Two more important points: there are approved standards for writing technical specifications - GOSTs. Nowadays they are rarely used, but some clients may ask to use them in the old-fashioned way.

And secondly, when the work is handed in, something like this may arise - “but we kind of asked you to do such and such and then...”. There is a possibility that you will have to start doing everything from the very beginning.

Therefore, we repeat that a well-written technical specification will be useful for both the customer and the contractor.

Example of technical specifications for a programmer

Technical specifications 1C for finalizing external processing


Target
It is necessary to configure the uploading of data from 1C to the bank's automated workplace.


Description

In connection with the organization’s transition to the 1C “Salaries and Personnel of a Government Institution” configuration, it is necessary to develop other processing solutions that would provide similar functionality on the new configuration.

Uploading data should be based on the documents “Application for Opening Personal Accounts of Employees” and “Statement for Payment of Salaries to the Bank”.


Initial data

Existing processing for the 1C configuration “Salary of a budgetary institution”, which uploads data from the document “Application for Opening Personal Accounts of Employees” and other directories and registers into the DBF file for data exchange with the bank’s automated workplace of the established standard.

Processing uploads data into the fields TAB_N, NAME, SERNUM, PASSCODE, PDAT, PWHR, BIRTHDAY, POSTINDEX, COUNTRY, CITY, STREET, REGION, BUILDING, CORP, FLAT, BPLACE, CITIZEN the corresponding information from the 1C configuration, previously entered into the specified document and other accounting tables. The personnel number, full name of the employee, his passport and address details, birthday and citizenship are uploaded.


Implementation method

These will be external reports and processing using the extension mechanism, if the current base compatibility parameters and platform capabilities allow this. When changing the database configuration, you should create: directories, documents, registers.


Performance evaluation

P 5 working days of programmer work are required.

How accurately the technical specifications for the modification of 1C are drawn up directly determines whether the tasks assigned to the developers will be solved. However, there are some difficulties when working with such a document. In a broad sense, the TOR specifies the standards for creating and modernizing an automated system (AS), as well as the procedure for work. This also includes a set of standards for launching a project. This understanding of the role of the technical specifications is dictated by the requirements of GOST 19.201-78 and 34.602-89, according to which the development of technical specifications for 1C is being carried out. There is another interpretation of the meaning of this document, closer to practice.

According to another definition, the terms of reference for the revision of 1C are a document regulating the purpose and parameters of the future system, as well as the process of developing documentation and its list. This interpretation allows taking into account the interests of programmers and the customer.

What should the technical specification be?

Any technical assignment for the development of a 1C program is created by the contractor. But this is not done by a programmer, but by an analyst. This is an important point, since the document must be drawn up in a language understandable to the client, without highly specialized technical terms. When all the nuances of the project are taken into account and the information is formulated correctly, the technical specifications are agreed upon with all customers. If it is accepted, programmers are involved in the work. In this case, the document must clearly outline the desired result. This helps developers set the right goal and check it at different stages. Also, when drawing up technical specifications for the modification of 1C, much attention should be paid to the wording. Care should be taken to ensure that they are sufficiently specific and do not imply other interpretations. This is the first thing to remember when working with technical specifications. You also need to approach the design responsibly. This also applies to the title page of the document.

The main errors in the technical specifications for the development of 1C

The structure of the technical specifications is regulated by GOST 34.602-89. This document contains clear requirements for the number and sequence of information blocks in the technical specifications. At the same time, there are no strict standards for presentation methods. This situation contains great potential for solving complex problems and at the same time can lead to many errors when drawing up a document. The most common inaccuracies are:

1. Repetition of some sections in different interpretations.
2. Information is given randomly. Ideally, it should relate to a specific structure, such as business processes or system modules.
3. Information in different sections is presented with varying degrees of detail.

All this prevents the customer from understanding the information contained in the technical specifications. This complicates the collaboration process, making it more labor-intensive.

After the customer views the sample technical specification for modification of 1C, it may change and not always for the better. This, in turn, usually prevents programmers from correctly perceiving information. This is especially true for specialists with little experience. At this stage, the following errors often occur:

1. The requirements of different sections contradict each other.
2. The wording turns out to be inaccurate.
3. In some places the information is too detailed.

It’s easy to get rid of all the listed errors. You need to focus, first of all, on the result, and not on carefully prescribing wording. It is worth remembering that the technical specification describes the functionality of the project, its main parameters and purpose.

How to avoid mistakes when developing technical specifications?

The basic rule that applies to all subsequent recommendations is that the wording must be specific. To do this, you need to use references to GOSTs and other regulatory documents. This allows the contractor and the customer to perceive information in the same way.

An example of a technical specification for the modification of 1C assumes the use of the language of the business sector for which the project is being carried out. This is necessary, first of all, for the customer. However, you should not use any comparisons in the text, since they can be interpreted in different ways.

Basic rules when drawing up technical specifications for the development of a report and other 1C elements:

1. The technical specification is created jointly by the contractor and the customer.
2. Only objective requirements should be imposed on the work of programmers. For successful project development, the customer’s subjective vision must be minimized.
3. It is necessary to describe in detail the result that the customer needs. In this case, in the example of a technical specification for the development of a 1C configuration, it is necessary to specify all the parameters by which the element should operate. Otherwise, the result may differ greatly from the desired one.
4. The risks of the contractor and the customer should be approximately equal and minimized.
5. You cannot use terms that are used in business communication and are not used in a specific industry.

To create a technical specification for the development of a report in 1C or another element, the analyst must know all the features of the customer’s field of activity. The requirements should only provide useful information that will be useful to the contractor. Considering that Special attention here the focus is on the final tasks that the software must solve; there is no single example of a technical specification.

The danger of incorrectly drawing up technical specifications

The errors listed above can lead to an increase in the time spent on creating the system. This entails unnecessary costs and dissatisfaction. The terms of reference for the development of a database or other 1C configuration should be drawn up by experienced specialists. The benefit of all participants depends on how easy this document is to understand. The customer receives an effective automated system for solving business problems. At the same time, the contractor has another satisfied client. Business owners need to be as careful as possible when choosing 1C partner companies, because the effectiveness of the organization largely depends on how well the technical specifications for revision are drawn up.