DEVELOPMENT OF THE INFORMATION TECHNOLOGY FOR CHECKING TEXTUAL PROCEDURES FOR LOGICAL COHERENCE AND COMPLETENESS

The process procedure or schedule is the document determining the order of interaction between departments and employees of an organization within a certain process [1]. A working instruction, i. e. a document that defines the order of individual or interrelated actions (functions) performed by a particular unit or employee of an organization within certain processes is an integral part of the procedure (schedule). Thus, work of state bodies, institutions and organizations or implementation of any business process (BP) depend on how the schedule is built: “... the schedule becomes a key element of the public administration system effectiveness of which influences effectiveness of the entire public administration system. Therefore, one of the main tasks of ensuring sustainable work is support of functional safety of the system based on analysis of the system’s schedule realizability. To this end, it is necessary to realize a procedure that makes it possible to automate the process of development and ensure control of the schedule execution” [2]. From the point of view of technical problems, procedure is an algorithm, so certain skills of algorithmizing are necessary for developing procedures. However, the vast majority of the schedules developed in the spheres of human life are in a textual form. This is the consequence of “one-sidedness” of specialists trained by higher education institutions. On the one hand, the vast majority of technical specialists possessing knowledge of information technology (IT) focus their attention on the use of algorithms for creation of exceptionally software products. And on the other hand, most professionals involved in solving practical problems do not possess such skills [3]. At the same time, peculiarities of human perception and information processing do not enable a complete estimation of the procedures presented in this form for their logical coherence and completeness which results in appearance of errors [4]. Consequently, development of information technologies for analysis of textual schedules (procedures) is a topical task.


Introduction
The process procedure or schedule is the document determining the order of interaction between departments and employees of an organization within a certain process [1].A working instruction, i. e. a document that defines the order of individual or interrelated actions (functions) performed by a particular unit or employee of an organization within certain processes is an integral part of the procedure (schedule).
Thus, work of state bodies, institutions and organizations or implementation of any business process (BP) depend on how the schedule is built: "... the schedule becomes a key element of the public administration system effectiveness of which influences effectiveness of the entire public administration system.Therefore, one of the main tasks of ensuring sustainable work is support of functional safety of the system based on analysis of the system's schedule realizability.To this end, it is necessary to realize a procedure that makes it possible to automate the process of development and ensure control of the schedule execution" [2].
From the point of view of technical problems, procedure is an algorithm, so certain skills of algorithmizing are necessary for developing procedures.However, the vast majority of the schedules developed in the spheres of human life are in a textual form.This is the consequence of "one-sidedness" of specialists trained by higher education institutions.On the one hand, the vast majority of technical specialists possessing knowledge of information technology (IT) focus their attention on the use of algorithms for creation of exceptionally software products.And on the other hand, most professionals involved in solving practical problems do not possess such skills [3].At the same time, peculiarities of human perception and information processing do not enable a complete estimation of the procedures presented in this form for their logical coherence and completeness which results in appearance of errors [4].
Consequently, development of information technologies for analysis of textual schedules (procedures) is a topical task.

Literature review and problem statement
The ever-growing number of owners introducing a process-related approach in management of their enterprises [5] induces a sufficient number of publications on schedules both in the post-Soviet space and abroad.However, it should be noted that the vast majority of publications [6][7][8][9][10][11][12][13] on schedules contain rather generalized recom-
For example, paper [6] asserts that the textual schedules (namely such schedules constitute the majority) are suitable for completely unprepared and less qualified employees since they are conventional and, historically, the first descriptions of the business processes.With a practically only advantage consisting in simplicity of description (I write what I see), they have a lot of shortcomings (laboriousness of making corrections, unstructured process, inconvenience of perceiving a solid text and describing parallel or branching processes).To eliminate above shortcomings, it is proposed "... to use graphics because clear visualization makes it possible to avoid errors and "extra" steps (the process structure and its interrelations are seen at a glance)."Visualization "... also contributes to a rapid understanding of logic and sequence of the work processes by both experts who elaborate schedules and personnel".
Work [7] confirmed that the language of block diagrams reflecting actions and branching (conditional transitions) is the most simple and accessible language for understanding schedules.It was recommended that hierarchical decomposition of processes must be used to achieve clarity of the schemes when not only the boundaries but also nesting of processes are determined.At the same time, a conclusion was drawn that schemes cannot completely replace the schedule text: "Practice shows that the scheme with insufficient detail needs explanations.As a rule, too detailed scheme is unreadable.In addition, not all employees of even a very "advanced" organization are able to correctly read schemes.One of the main difficulties is description (in any language) of schemes of various branches, rules with exceptions and similar phenomena prevalent in domestic business.Well-structured texts willy-nilly cope with solution of these tasks but a good scheme will not be superfluous." There is no mention of the use of graphics in development of schedules in work [8], and the only specific recommendation relates to the form of verbs that must be used: "Use all information to write clear procedures.Use verbs in imperative mood when writing procedures proper.Try to avoid excessive verbosity.Make sure that you do not use a language that is not easy to understand including any jargon that a worker has not yet assimilated.For example, instead of saying "Then the calculation forms must be submitted together with the accounting statements", you can say something like "Submit calculation forms with accounting statements." As the only recommendation leading to reduction in errors when developing the block diagram of the process, the author [9] suggests to assure "that you do not complicate your drawing with too many unfamiliar symbols or too large text.If necessary, divide it into a series of small block diagrams".
In article [10], in order to increase quality of the procedures being developed, it is suggested "... to focus on the things to be said to the people performing this process and leave meaningless directions and unnecessary explanations".And to verify, "… the procedure is subject to the conditions of "the real world "and the results that you will see may not be exactly what you wanted or expected." An attempt to concretize to some degree requirements for better development of schedules was made in [11].For example, it was proposed to develop schedules "... short and accessible" "... by doing it step by step with the use of short sentences but not text blocks and paragraphs which will ap-pear difficult to follow for your employees.Visualize the procedures that you are trying to convey.Also, "... try to avoid a cumbersome physical document that may be inconvenient for correction and updates ... make it as an on-line document on a computer or in a business network".Constantly use feedback with executors of the schedule: "... they possess a lot of information and knowledge given that they are embedded deep inside and throughout your business.They are often the most suitable people to ask how to improve the situation." As regards the schedule, the term "completeness" is used in the context of logic but it was disclosed in a rather generalized form in [12].For example, "... to avoid errors in development of schedules", it was suggested "to adhere to seven C's: context, consistency, completeness, control, compliance, correctness and clarity ... In terms of completeness, the schedule should logically explain the processes without information gaps... " There are no recommendations for visualizing the procedures.
The most extensive recommendations concerning development of textual schedules (without process schemes) are presented in [13].But, nevertheless, these recommendations are of a general nature.For example, description of requirements to "Clarity, laconism and consistency" of the document being developed: "Make every word bearing its meaning.Delete unnecessary words.Remove excessive, unnecessary phrases, bloated phrases and clichés.In order your schedule to be clear and ... accurate, every paragraph that you write must contain accurate and complete information expressed briefly.Consistency is a good logic, coherence of sentences and presence of a thread of thought.The agreed text will help the user to fully perceive your schedule... Users are looking for a consistent idea and logic in the schedule ..

. Your schedule will be conformal if the relationship between sentences in each paragraph is clear and logical and the links or the relationship between paragraphs and sections is obvious."
The use of the graphical schemes as a tool for the process analysis was considered in [14].The conditions necessary for creating a qualitative scheme of the process are given.The method of verification of schemes using check-lists the structure of which contains such sections as "Absence of logical and contextual errors" and "Absence of omitted important operations" is discussed in [15].Possible lines of contextual analysis of the process schemes were suggested.It was concluded that "graphical schemes are a powerful tool for analyzing processes.But in order to use this tool, the following has to be done: -learn to create quality process schemes; -develop procedures for analyzing processes using graphical schemes; -

train managers and specialists, form their skills in developing graphical schemes and their use within the framework of the projects of analyzing and optimizing the company's business processes."
It should be noted that [14,15] used analysis mainly as a monitoring tool in the course of creation of the process scheme per se, and it was proposed to study the actually created and checked scheme by applying simulation.
Thus, in terms of description of processes, existing schedules (procedures) may have errors related to the logic of the process because: 1) specialists who do not have or have insufficient skills in algorithmizing (in comparison with those who work in the field of computer technologies) cannot effectively apply visualization in development of procedures; 2) there are no clear recommendations (i.e. a technology) for developing procedures containing description of branching processes without the use of graphical schemes.
Visualization of the process description can become a tool for detecting errors in such procedures.

The aim and objectives of the study
This study objective was to develop an information technology for checking the textual procedures containing description of branching processes based on visualization with the use of BPMN notation which will enable finding errors of logical coherence and completeness.
To achieve this goal, the following tasks were accomplished: -an information model of the "text → scheme" procedure was developed; -the subject area and characteristics were determined to search for text description of branching processes and the means of their visualization were chosen; -an information model of the procedure for creating rules of conversion of the process description text into a scheme and identifying errors was developed and implemented.

1. Developing the information model of the "text → scheme" procedure
In the course of development of IT for creating on-line schedules [16], a need for a procedure for converting a branching process into text has appeared.Following the analysis of the results obtained in development of this procedure, the following questions were formulated: 1.If there is a "scheme → text" procedure, then should there be a reverse "text → scheme" procedure?
2. Are the existing texts describing branching processes that were developed without the use of visualization correct?
The answer to the first question was development of a joint information model for the "scheme → text" and "text → scheme" procedures (Fig. 1).
The model was developed in a BPMN notation and describes the type of input, internal and output information, as well as the basic stages of information conversion.The model of the reverse "text → scheme" procedure shown in Fig. 1 became the basis for development of the proposed IT.
To answer the second question, the described studies were carried out.

2. Determining the subject area and signs for finding textual description of the branching processes and choosing the means for their visualization
Legislation was chosen as the subject area for the studies.First, it is the most accessible, known and affecting the people's life schedules.Secondly, with a high degree of probability, laws (especially codes) have "logical" errors: "Laws are written by people and to err is human.So, it is very easy to draw a conclusion that the texts of laws and other regulations may be incorrect ... Most often regulations contain simple logical inconsistencies, case sequence errors, missed words and so on.... Most of all it falls to the codes' lot because their purpose is to collect the rules of law for an individual branch and state them in a systematized form.What is added to "usual" errors arising in writing the text are systematization errors, for example, incorrect cross-references ..." [17].In the same way, correctness of the process descriptions in laws is affected by the fact that lawyers are not taught algorithmizing, but: "The law should be logical ... In general, this rule can be formulated as follows: the normative act must be stated from the general to the particular.Therefore, the law structure should provide a consistent logical presentation of the normative material, be readable and thereby contribute to its correct understanding.That is why it is very important to consistently and logically state normative provisions in the law when drafting it" [18].The requirement concerning elaboration of laws "from general to particular" set forth in the quotation fully corresponds to the methodology used in elaboration of the process schemes, in particular decomposition.
To search for texts containing description of branching processes, the following three signs were defined: 1) the title should have a description of the actions (for example, verbal nouns "checking", "drawing up" or such terms as "procedure", "order", etc.); 2) in the text found, there should be description of actions (for example, verbs "draw up", "register", "send", etc.); 3) in the text found, there should be signs of the process branching (for example, conjunction "if", preposition "in the case", etc.).
By analogy with the "scheme → text" procedure, Version 2.0 of BPMN notation [19] was chosen as a means for visualizing process descriptions which is an intuitive common language for developing the process models.Experience with experts shows that they immediately begin to "read" process schemes represented in BPMN notation despite their age and the degree of technical education.

3. Development and implementation of the information model of the procedure for creating rules of conversion of a process description text into a scheme and identification of errors
To develop the procedure (Fig. 2), structural methods of system analysis and design were used, such as partitioning the system into "black boxes", hierarchy, and functional decomposition [3].The procedure was developed in a BPMN notation.

Fig. 2. Information model of the procedure for creating rules of converting the process description text into a scheme and identifying errors
Five steps were chosen in the procedure model and corresponding tasks were fulfilled at each of them.
Step 1.Initial definition of recommendations Task 1. 1. Define initial set of rules for converting the text of the process description into a scheme (corresponds to the part of the rules from the procedure for converting the branching process scheme into text [16] by the principle "from the reverse").
Task 1. 2. Determine initial set of rules for detecting errors: missing or incorrect reference; absence of task (from the publications on errors in laws).
Step 2. Selection of material for studies Task 2. 1. Search in Ukrainian legislation (mainly in the codes) for laws or papers with texts where there is a description of actions (for example, verbal nouns "checking", " drawing up" or terms "procedure", "order", etc.) in their titles.
Task 2. 2. Search for description of actions in the selected text (for example, verbs "draw up", "register", "send", etc.) Task 2. 3. Search for the signs of process branching in the selected text (for example, conjunction "if", preposition "in the case", etc.) Step 3. Conversion of the textual process description into a scheme and search for errors Task 3. 1. Convert textual description of the process into a scheme in accordance with the current set of rules.
As experience has shown, it was usually required 3 to 5 iterations for conversion during which the scheme gradually got corresponding to the process description.
Task 3. 2. Analyze the obtained scheme for errors in accordance with the current set of rules.
Step 4. Analysis of the results obtained during conversion and error search.
Task 4. 1. Analyze the results obtained during conversion of the process description text into a scheme for their correspondence to the study objective.
Task 4.2.Introduce appropriate changes to the current set of rules for converting the process description text into a scheme.
Task 4. 3. Analyze the results obtained in the course of identifying errors in accordance with the study objective.
Task 4. 4. Make appropriate changes to the current set of rules for identifying errors.
Step 5. Decide on the development completion.Task 5. 1. Analyze the results of Steps 3 and 4 for their conformity with the state of the IT being developed and the study objective.If no conformity was reached, go back to Step 2 "Choosing material for studies".

1. Description of the IT for checking the textual procedures for their logical coherence and completeness
Three stages can be defined in the IT: 1) conversion of the process description text into a logical scheme; 2) checking the obtained scheme for logical coherence and completeness; 3) development of proposals on introduction of changes in the process description.
Conversion the process description text into a scheme.
The main recommendations that can be used when converting text: -the text is analyzed for the presence of subprocesses, that is logically isolated parts and/or commonly used parts, i. e. which are referenced from various parts of the schedule.Such parts must be converted separately.Usually such parts are the structural elements of the document: sections, subsections, paragraphs, subparagraphs; -the first action from which the process begins its development has to be found in each part.It must be remembered that every action should be atomic (indivisible); -as usual, the tasks in the scheme that follow one after another correspond in the text to the actions that are also recorded one after another or arranged as a list; -in the case of finding words like "if", "in the case" or other words which imply variants of development of events, it is necessary to reflect an exclusive gateway in the scheme and formulate the corresponding question.After that, other answers to this question should be found in the text: these will be the starts of new scenarios of the process development; -the parts of the document in which there is no description of actions are not represented in the scheme; -if the text contains references to an external procedure, this is represented in the scheme as a reference to a subprocess; -if the text refers to drawing up or filling-in a document, then its graphical image with a comment has to be attached to the corresponding task.Similarly, templates of phrases are attached to the tasks, if any.

Checking the developed scheme for logical coherence and completeness
There are three main lines of checking: -broken or missing links Broken or missing links are easy to detect in the scheme: it is either a gateway that has only one output or a task that has no output at all; -absence of tasks The check for absence of tasks follows from the logic of the process, e. g., if ahead of an exclusive gateway (the one with outputs being answers to the questions), a task is found and its work result is unambiguous (that is, no question can be there as a result of its fulfillment).This means that the process is missing a task which so to speak "puts" this question or the tasks were described one after the other but with no logical coherence between them, and so on. -

absence of analogy
The check for absence of analogy is based on the fact that the schedule is usually a set of more or less repetitive actions.Therefore, if these actions or connections exist in one case but are absent in other case, then this may be an error: there are no tasks or connections are broken or absent.

Working out proposals for introducing changes in the process description
This step is performed if errors are found in the scheme in the course of checking for logical coherence and completeness.
During this stage, analysts together with the schedule drafters correct errors or reject comments if they are not like that.

2. Example of application of the information technology
As an example, consider conversion of Article 86 "Registration of inspection results" from the Ukrainian Tax Code which contains description of a procedure [20].To ensure necessary visualization, the scheme of the Article was presented in a form of a two-level hierarchy.
This interaction is determined by the references between the paragraphs.
Paragraph 86.1 is common to paragraphs 86.3, 86.4 and 86.5, therefore the actions described therein are included in the corresponding logical schemes.Hereinafter in the description of the paragraph content: -procedural actions in the paragraph are highlighted in bold; -event development variants are underlined; -documents are written in bold and underlined).
"86.1.The results of inspections (except for office ones) are drawn up in the form of an act or certificate that are signed by officials of the state tax service body and taxpayers ... In the event of establishment of ... violations, an act is drawn up.If ... there are no violations, a certificate is drawn up.The act (certificate) ... is presented to the taxpayer ... who is obliged to sign it ... In the case of disagreement of the taxpayer with the conclusions of the act, such taxpayer is obliged to sign such inspection act with his comments ... within the time limits stipulated by this Code" [20]."86.2.Based on the results of the office inspection, in a case of finding violations, an act is drawn up in duplicate which is signed by the officials ... and after registration by the state tax service body, it is handed in or sent to the taxpayer for signing within three working days in the order stipulated by Article 42 of this Code."[20].
"86.3.The act (certificate) of a documental on-site inspection ... is drawn up in two copies, signed by officials of the state tax service body ... and registered by the state tax service body within five working days from the date of ... the end of the period established for inspection (within ten working days for the taxpayers who have affiliated branches and/or are on a consolidated payment).In the event of a taxpayer's refusal from signing the act (certificate)..., a relevant act is drawn up...One copy of the act or certificate... is handed in or sent to the taxpayer ... on the day of signing or refusal from signing.In the event of the taxpayer's refusal ... from receipt of such act or certificate ... or impossibility of its handing in and signing, ... such an act or certificate is sent to the taxpayer in the manner stipulated by Article 58 of this Code ... In the cases specified in this paragraph, the body of the state tax service draws up an appropriate act."[20].
"86.4.The act (certificate) of the documental nonfield inspection is drawn up in duplicate, signed by the officials of the state tax service body, ... and registered by the state tax service body within five working days from the day of ... the end of the period established for inspection (within 10 working days for the taxpayers having branch offices and/or who are on a consolidated payment).... Ater its registration, the act (certificate) is handed in personally to the taxpayer ... In the event of the taxpayer's refusal ...from signing the act (certificate) of inspection, a corresponding act is drawn up to certify the fact of such refusal.... The objections concerning inspection are considered in the order and terms stipulated by paragraph 86.7 of this Article.The tax notice-decision shall be aссepted in the order and the time limits stipulated by paragraph 86.8 of this Article" [20].
"86. 5. Act (certificate) on the results of actual inspection ... is drawn up in duplicate, signed by officials of the state tax service body, ... registered not later than the next working day after the end of the inspection.Act (certificate) on the results of this inspection is signed ... by the taxpayer ... Signing of the act (certificate) of such inspection ... is done at the place of inspection or at the premises of the state tax service body.In the event of a taxpayer's refusal ... from signing the act (certificate), officials of the state tax service body draw up an act certifying the fact of such refusal.One copy of the act or certificate on the inspection results shall be registered in the register of acts of the tax service body and handed in or sent to the taxpayer ... not later than the next day after its registration.In the event of the taxpayer's refusal ... from receipt of a copy of the act (certificate) of the inspection results or impossibility of its handing in to the taxpayer, ... such act or certificate is sent to the taxpayer in the manner stipulated by Article 58 of this Code ... In the cases mentioned in this paragraph, a relevant act is drawn up by the state tax service body or a note is made in the act or a certificate of the inspection results" [20].In the case when the taxpayer wishes to participate in consideration of his objections to the act of inspection, the state tax service body has to notify the taxpayer about the place and time of such consideration.Such notification shall be sent to the taxpayer not later than the next working day from the date of receipt of objections from him but not later than two working days before their consideration ..." [20].
"86.8.The tax notice-decision shall be made by the head of the tax service body ... within ten working days from the day following the day when the act of inspection was handed in to the taxpayer in the order stipulated by Article 58 of this Code ... and when there are objections ... of the taxpayer to the act of inspection, this notice-decision shall be made taking into account the conclusion on the results of considerations of objections to the act of inspection within three working days following the day of consideration of the objections and handing in (sending) the written response to the taxpayer."[20].Ignoring the legal aspects, analyze the schemes of the article and paragraphs from the point of view of compliance with the process logic.The detected errors are highlighted in red and brown in Fig. 3-9.
1) Check for broken or missing links, for example: -paragraph 86.2 (Fig. 4): the scenario "in a case of establishment of violations, the act is drawn up" is described that means presence of a gateway " Violations found?" but there is no description of at least one more scenario.
2) Check for lack of analogy, for example: -the general scheme of the Article (Fig. 3): according to the law, the notice-decision on the amount of fine is made in the event of drawing up an act after any inspection but the reference to paragraph 86.8 is only made from paragraph 86.4.The same is with consideration of objections; -paragraph.86.5 (Fig. 7): after the gateway "Does the taxpayer agree to sign?", in two scenarios of the process development, there are tasks "Registration of the document at the tax service body" with the deadline "Not later than the next working day following the end of inspection" and no tasks in the other two although registration is mandatory.
3) Check for lack of tasks, for example: -paragraph 86.3 (Fig. 5), paragraph 86.4 (Fig. 6): after registration of the act/certificate at the tax service body which can last up to 10 working days, there is description of scenarios after the gateway (question) "Does the taxpayer agree to meet and sign?" but there is no task after which this question arises, for example, "Date and place of signature of the documents to be agreed with the taxpayer"; -paragraph 86.4 (Fig. 6): after the task "Draw up an act on the refusal of signature", there is no further task on how the act/certificate of the inspection results should reach the taxpayer.

Discussion of results obtained during application of the information technology
As a result of the conducted studies, an IT for checking text procedures for logical coherence and completeness was developed.The IT is based on the information model of the "text → scheme" procedure which represents conversion of the textual process description into a scheme (visualization).The BPMN notation was used as a visualization tool.
This procedure is a conceptual continuation of the previously developed "scheme → text" procedure for conversion of the process scheme into its textual description used in the IT for creation of on-line schedules [16].
During this IT approbation conducted by students (total of thirty participants), about forty texts of Ukrainian laws with description of branching processes were chosen.Errors were found in 75 % of the resulting process schemes which indicates sufficient effectiveness of the developed IT.This high percentage of logical errors in descriptions of the branching processes can be explained by two reasons: -the skill of applying visualization in the course of description of such processes is absent in arsenal of the corresponding specialists; -there are no technologies for description of branching processes without the use of visualization.
The advantages of this IT include versatility of its application and sufficient ease of learning.
One of disadvantages of this IT is that it is rather informal and the solutions proposed in it are empirical, based on experience.This is because the task that it solves is akin to translating from one language to another (in this case, from the procedure text into the scheme in BPMN notation).Such processes are still difficult to automate and therefore experience of an interpreter, in this case business analyst, is very much decisive.
Further studies are planned to aim at elimination of this shortcoming.For example, if the text of the schedule is preliminarily formalized, say, in a form of a table (each column has its own, strictly defined content), then automation of checking for broken or missing links can be realized.
The proposed IT can be used in two ways: actually, to search for errors in already existing (or being developed) schedules (procedures) in any of the fields of activity that describes processes in a textual form and as an element of training the business analysts to expand their professional skills.

Conclusions
1. Visualization using methods of system analysis (in particular, BPMN notation) is the most effective tool for developing branching processes.
2. The lack of clear rules (technology) for development of schedules (procedures) in a textual form leads to a fairly large number of errors in the descriptions of the branching processes that are developed by specialists having no sufficient skills of using algorithmization.
3. This IT for checking textual procedures for logical coherence and completeness based on visualization using the BPMN notation has shown its high efficiency in analyzing descriptions of branching processes (e. g., from the forty process descriptions in the Ukrainian laws chosen for analysis according to certain criteria, errors were found in 75 % of the texts).
4. The developed IT can be applied in any field of activity that contains process descriptions in a textual form.Howev- er, despite its sufficient easiness, it requires a certain level of skill in algoritmization to reach proficiency in its use.To a certain degree, such requirement is called forth by unformalized content of the IT rules.Formalized rules will ensure development of a software product realizing the developed IT and, consequently, availability of the proposed IT to a wider circle of specialists.
5. The developed IT and the IT presented in [16] are a complex solution of the problems associated with both creation and checking textual schedules (procedures).

Fig. 4 -
Fig. 4-9 show level 2 of the article decomposition: the logic schemes of the corresponding paragraphs.Ahead of Fig. 4-9, text of the corresponding paragraph is given."86.2.Based on the results of the office inspection, in a case of finding violations, an act is drawn up in duplicate which is signed by the officials ... and after registration by the state tax service body, it is handed in or sent to the taxpayer for signing within three working days in the order stipulated by Article 42 of this Code."[20].

Fig. 3 .Fig. 4 .
Fig. 3. Logical scheme of Article 86 after conversion and verification, level 1 of decomposition (made in BPMN notation) Paragraph 86.6 is not considered since it does not describe the procedure."86.7.In case of disagreement of the taxpayer ... with the inspection conclusions or the facts and data stated in the act (certificate) on the inspection, he has the right to file his objections within five working days from the date of receipt of the act (certificate).Such objections are considered by the state tax service body within five working days following the day of their receipt (the day of completion of the inspection conducted in connection with the need to clarify circumstances that were not investigated during inspection and indicated in the comments) and a response is sent to the taxpayer in the order stipulated by Article 58 of this Code ... The taxpayer ... has the right to participate in consideration of his objections what is indicated in his objections.

Fig. 9 .
Fig. 9.The logical scheme of paragraph 86.8 after conversion and verification, level 2 of decomposition (performed in BPMN notation)