How to write TK on the system or revision of the 1C system
In order for you, as a customer, consultant or methodologist, to understand what a 1C developer needs in order to refine your system or develop a new one, you need to understand what categories of information it operates during its work. This will greatly simplify the understanding of what is wanted from the programmer.
In this article I will try to briefly and, at the same time, sufficiently fully explain what you need to write in the technical task in addition to the general sections with a glossary, a title page and a description of business requirements.
These rules are easy to follow, even when writing short user stories, if you create them as part of the SCRUM / Agile project.
')
So let's get started.
To begin with, you should understand what the programmer 1C actually programs in 90% of cases:
Let's take a look at each category separately.
Information entry forms
These can be either forms for entering information into the system (documents, reference elements, tables with data), and forms for downloading this data from somewhere in a pattern (for example, Excel or XML and other formats for integration with other systems).
Do not forget to specify a list of buttons, commands that the user must command your system.
If the technical assignment does not contain a thoughtful pre-image of such forms or templates, then the programmer will invent them at his discretion, and you will complain that this is inconvenient for you to work.
Control procedures
In business processes, these procedures are preliminary controls so that you can understand. Those. these are the controls that the system itself does when the user tries to work with the system with a particular role, and issues a warning or deliberately interrupts the user's work, not allowing him to carry out his plans.
This category falls into:
If the technical task does not contain control procedures, then the created system will allow doing anything to any user, almost like in Excel, only with a different design. What is your benefit from this?
Data model
Of course, the programmer will make the data model in the way that his current experience tells him. If an experienced programmer, he will make an effective data structure. And if not so - not so.
If you are also “not very” a programmer, then the only useful thing you can write for a programmer in this part will be the basic characteristics of the data model:
This information will help the programmer to create the necessary category of objects of the system, which then will not need to be redone, if he himself did not realize the above characteristics.
Algorithms for automatic data filling
If your input form contains many fields or tables, your users are unlikely to want to fill in all the fields from scratch every time.
Here you need to think about which fields or tables can be filled in by other fields or tables of this or other business objects.
Also, here you think up dependent automatic filling of input forms depending on the fields just changed by the user. For example, after selecting a nomenclature, the user does not need to select its main unit of measurement, the system will substitute it by default by itself.
Forms of information output
Reports and forms of “viewable” or “choice” objects fall into this category. Understandably, the programmer does not have to invent a report form that you imagine in a very specific way.
Draw a prototype of such a report in Excel, preferably with formulas and comments, where to get the information, and invest in the TK. It's enough.
Also here are forms of uploading data to Excel or XML and other formats for integration with other systems.
***
Input and output forms can often be combined with data filling algorithms and control procedures into functional interactive user workstations, supplemented with buttons that trigger certain actions and events in the system. Nevertheless, the same principles of writing technical specifications are applicable to them, taking into account these features.
Providing the programmer with this uncomplicated set of information in the technical assignment, you are 90% insure yourself that he will do something wrong.
PS Well, except that a real 1C programmer works for you. Maybe he writes better in python?
In this article I will try to briefly and, at the same time, sufficiently fully explain what you need to write in the technical task in addition to the general sections with a glossary, a title page and a description of business requirements.
These rules are easy to follow, even when writing short user stories, if you create them as part of the SCRUM / Agile project.
')
So let's get started.
To begin with, you should understand what the programmer 1C actually programs in 90% of cases:
- Information entry forms
- Control procedures
- Data model
- Algorithms for automatic data filling
- Forms of information output
Let's take a look at each category separately.
Information entry forms
These can be either forms for entering information into the system (documents, reference elements, tables with data), and forms for downloading this data from somewhere in a pattern (for example, Excel or XML and other formats for integration with other systems).
Do not forget to specify a list of buttons, commands that the user must command your system.
If the technical assignment does not contain a thoughtful pre-image of such forms or templates, then the programmer will invent them at his discretion, and you will complain that this is inconvenient for you to work.
Control procedures
In business processes, these procedures are preliminary controls so that you can understand. Those. these are the controls that the system itself does when the user tries to work with the system with a particular role, and issues a warning or deliberately interrupts the user's work, not allowing him to carry out his plans.
This category falls into:
- Role-Access Matrices
- Rules for granting access to form and data fields
- Verification of the correctness of filling data in the input forms
- Data Verification Procedures
If the technical task does not contain control procedures, then the created system will allow doing anything to any user, almost like in Excel, only with a different design. What is your benefit from this?
Data model
Of course, the programmer will make the data model in the way that his current experience tells him. If an experienced programmer, he will make an effective data structure. And if not so - not so.
If you are also “not very” a programmer, then the only useful thing you can write for a programmer in this part will be the basic characteristics of the data model:
- The list of business objects with which the user deals and the relations between them, references to which objects should be stored in which objects
- The composition of the data fields (plate in Excel) for each business object that has an input form
- Hierarchy support - needed or not
- How much data is planned to be stored
- The frequency of entering and changing this data
- Is it necessary to store several data tables in one object, and if so, with which analysts, will any other object refer to the records of these tables
- Storage support with history by date - needed or not
- Support for calculating totals on any date, or turnovers for a period - needed or not
- Dual account support - needed or not
- Support for preemptive graphs of values ​​in time - needed or not
- Support for user interaction processes on an object - needed or not
This information will help the programmer to create the necessary category of objects of the system, which then will not need to be redone, if he himself did not realize the above characteristics.
Algorithms for automatic data filling
If your input form contains many fields or tables, your users are unlikely to want to fill in all the fields from scratch every time.
Here you need to think about which fields or tables can be filled in by other fields or tables of this or other business objects.
Also, here you think up dependent automatic filling of input forms depending on the fields just changed by the user. For example, after selecting a nomenclature, the user does not need to select its main unit of measurement, the system will substitute it by default by itself.
Forms of information output
Reports and forms of “viewable” or “choice” objects fall into this category. Understandably, the programmer does not have to invent a report form that you imagine in a very specific way.
Draw a prototype of such a report in Excel, preferably with formulas and comments, where to get the information, and invest in the TK. It's enough.
Also here are forms of uploading data to Excel or XML and other formats for integration with other systems.
***
Input and output forms can often be combined with data filling algorithms and control procedures into functional interactive user workstations, supplemented with buttons that trigger certain actions and events in the system. Nevertheless, the same principles of writing technical specifications are applicable to them, taking into account these features.
Providing the programmer with this uncomplicated set of information in the technical assignment, you are 90% insure yourself that he will do something wrong.
PS Well, except that a real 1C programmer works for you. Maybe he writes better in python?
Source: https://habr.com/ru/post/326068/
All Articles