LT7200B - Simulation system and method for specialized operatinal learning to work with state tax administration system functions - Google Patents

Abstract

This invention solves a technical problem arising in the implementation of a specialized operational learning method for state tax administration system functions, particularly when working with financial data registers and their verifications. A proposed simulation system, implemented as a set of functional modules, comprising User Communication, Parameter Input, and Register Management modules ensuring general communication and state management. The novelty, innovativeness, and technical advantage of the invention stem from these additional modules: a Primary Verification Module performing temporal register overlap detection; a Parameter Verification Module applying specific tax administration logic rules; an Imitation Search Module performing simulated searches against an imitation parameter storage; and a State Transition Module implementing specific state transition logic. Processing signals and parameters, the entirety of these modules and their communication allow for the technically accurate replication of specific state tax administration system actions and verification logic within an isolated simulation environment. Thus, the technical effect is achieved – a technically suitable and safe operational environment is created, which allows for the effective and reliable formation and consolidation of specialized operational skills necessary for working with a specific state tax administration system.

Description

TECHNICAL FIELD

The present invention relates to the field of simulation systems and learning methods. More specifically, the invention relates to a modular simulation system and method for specialized operational learning, allowing users to safely/controllably acquire practical skills in working with specific functions of the state tax administration system, such as managing financial data registers, including the application of related verification and state change logic in an automated environment.

STATE OF THE ART

Various simulation systems and techniques are known for training and developing practical skills in various fields, including accounting and finance. Such systems often aim to provide users with the opportunity to test the functionality/functions or processes of equipment in an environment that simulates real-world conditions, eliminating the risk of errors and accelerating the learning process.

However, when analyzing the current state of the art, it is noticeable that general simulation training systems, even those applied in the field of accounting (e.g. using ERP systems), usually do not reproduce the specific logic, rule sets and operational procedures characteristic of state tax administration systems accurately enough or not at all. Existing solutions are often limited to simulating common accounting cycles or equipment functions, without providing users with the opportunity to acquire reliable skills necessary for working with highly specific, rule-based processes, such as maintaining VAT invoice registers in accordance with national requirements, including specific checks and status management.

Specific known prior art solutions and their disadvantages compared to the present invention will be discussed below.

In the analysis of the current state of the art, a document US7991675B2 / US2010211528A1 (D5) was discovered, published on August 19, 2010, which describes a financial consulting method and system for helping clients achieve financial goals (e.g., retirement planning). The system uses an analysis of clients' goals (ideal and acceptable values) and their priorities, and capital market modeling (e.g., Monte Carlo simulations) to generate recommendations and assess the likelihood of achieving such goals.

Although the aforementioned D5 uses simulations in the field of finance, it does not solve the technical problem posed by our invention for the following reasons:

D5 is intended for strategic financial planning and consulting, not for developing operational skills in working with a specific system. The purpose of D5 is to assess the likelihood of achieving financial goals, and the purpose of our invention is to implement a specialized operational learning method so that the user learns to perform specific actions in the system.

The D5 system does not simulate or replicate specific actions, verification logic or status change rules of the state tax administration system (e.g. filling in the VAT invoice register, checking for overlap, submission). D5 simulations are focused on modeling the behavior of long-term financial markets, rather than on the operational logic of a specific system.

D5 does not provide the user with the ability to practically enter parameters into forms, receive feedback on violations of specific rules, or perform a sequence of actions typical of tax recordkeeping in an isolated and technically adapted environment. D5 is an analysis tool, not a practical learning simulator.

In summary, D5 solves a completely different technical problem (optimization of financial goals and risk assessment) and does not offer any technical solution to create a modular simulation system capable of technically replicating the specific operational actions and verification logic of the state tax administration system for learning purposes.

Also known is US5395243A (D4), published on March 7, 1995, which describes an interactive learning system for learning to use common applications such as word processors or spreadsheets.

The system offers various learning methods: interactive audiovisual lessons that simulate the operation of the real program, access to textual information materials (short, detailed, personalized via clipboard) and the opportunity to practice using the real training program itself. The user can choose different learning paths (lesson sequences, topic selection, work support). After completing a cycle of lessons on a certain topic (unit), the user can use the real program to perform exercises related to the same topic.

Although D4 describes an interactive, simulation-based learning system, it does not solve the technical problem posed by our invention due to the following fundamental technical differences:

D4 is a general-purpose system designed to teach how to use any application. It does not have built-in specific logic needed to simulate the functions of a state tax administration system (e.g. VAT invoice registers). It teaches how to use the program, not how to perform a specific administrative procedure.

D4 does not include or describe any functional modules for performing specific checks that are specific to tax administration.

The D4 system does not implement or describe specific status transitions, such as changing the status of a register from In preparation to Accepted.

Unlike our system, D4 also does not have the functionality of a simulated search module.

The technical goal of D4 is to create a flexible general-purpose learning platform with various ways of presenting information. The technical goal of our invention is to create a specific modular architecture that technically accurately replicates the operating system/logic and checks of a specific state system for learning purposes.

In summary, D4 is a generic software training tool that does not have the specific technical elements and functionality required to implement a specialized operational learning approach in the field of state tax administration functions.

Also known is the document US11854092B1 (D3), published on December 26, 2023, which describes systems and methods for tax compliance solutions. The system is designed to allow the user to simultaneously submit multiple requests for resolving arrears to national tax authorities and provide the necessary documents according to the selected option. The system uses information from the tax agency website and personal information of the taxpayer (e.g. income, expenses) to calculate the most favorable solution.

Although D3 works in the tax area and uses user financial data, it does not solve the technical problem posed by our invention due to the following technical differences:

D3 is an analysis and decision-making system designed to help a user find the optimal way to pay off an existing tax debt. Compared to our invention, the system described in D3 is not intended for training or developing operational skills.

D3 does not simulate the tax administration process (e.g. filling in, checking, submitting a VAT invoice register). It only analyzes the current situation and suggests solutions, but does not recreate the sequence of actions that the user should perform when managing registers.

D3 does not include functional modules such as: the initial verification module, the parameter verification module (with specific tax administration logic), the simulation search module or the state change module, which in our system are designed to technically replicate the system actions and verification logic for learning purposes in an isolated environment. D3 modules (e.g.: interface with tax systems, analysis engine, user interface) are designed for data collection and decision generation.

Since D3 is not a simulator, it does not provide the user with the ability to perform tax administration actions in a controlled and risk-free manner by entering parameters and observing the system's reactions according to the appropriate processing logic.

In summary, D3 is a decision support system for taxpayers in debt, but it does not have the technical elements or functionality to implement a learning approach by replicating the specific actions and verification logic of the state tax administration system.

There are also general accounting education simulation systems using enterprise resource planning (ERP) resources (D2). It is indicated that such simulations allow students to communicate with real-world business process models. However, the publication also mentions that these simulations, most often, cover only general accounting cycles - from recording transactions to preparing financial statements.

Although ERP discusses simulations for training, this system does not solve the technical problem posed by our invention due to the following differences:

D2 describes simulations focused on common business accounting processes implemented in standard ERP systems. They do not reproduce or include highly specialized functions, rules, and logic specific to a specific state tax administration system (e.g., iSAF VAT invoice registers).

The publication does not describe the implementation of specific verification mechanisms in a simulation environment, such as checking for register overlap or applying specific logical rules to financial parameters according to tax administration logic. ERP systems have general verification mechanisms, but they cannot be directly applied to our system without special adaptation.

D2 does not discuss specific state management and transitions (e.g. from the Preparing state to the Accepted state) that are performed using the state change module.

D2 describes the development of general accounting skills using existing ERP platforms as a training tool. The technical objective of our invention is to create a specific modular architecture that technically accurately replicates the operational logic and checks of a unique state system in order to implement a specialized operational learning approach.

In summary, the use of ERP simulations for accounting training described in D2 is too general and lacks the specialized technical solutions needed to create a simulation system capable of implementing a specialized operational learning approach, accurately replicating the specific actions and verification logic of the state tax administration system.

The closest prior art is CN112331000A (D1) published on February 5, 2021. This document describes a computer-based accounting simulation training system consisting of teacher, intermediate and student terminals. The student terminal contains an accounting business simulation system with various management departments, such as: general ledgers; reporting, payroll, fixed assets, receivables/payables, purchases and returns, sales and inventory management modules. The purpose of this system is to overcome the shortcomings of existing training systems - their excessive simplicity, insufficient systematicity and lack of feedback to the teacher on student actions.

Although D1 describes a modular accounting training system and is the closest analogue, it still does not solve the technical problems posed by our invention due to the following fundamental technical differences: ί i ii

The D1 system is focused on training general company accounting processes (e.g. payroll, purchases, sales, inventories). It does not include or simulate highly specific functions, logic and procedures specific to a particular state tax administration system, e.g. maintaining VAT invoice registers according to national requirements.

D1 does not describe or integrate specific verification modules or logic required for tax administration, for example: a primary verification module that would check for overlaps in time between registers, or a parameter verification module that applies specific tax administration logic rules to entered financial parameters.

D1 is limited to modeling general accounting transactions.

D1 does not describe the state transition logic, e.g. changing the state of the register from Preparing to Accepted, in the case of our invention this is done using a state transition module.

D1 does not mention or include any functionality equivalent to our Simulated Search module, which would perform simulated searches against a simulated parameter repository (e.g., Taxpayer Register (MMR) simulation).

The technical objective of D1 is to create a more systematic general accounting training platform with feedback. The technical objective of our invention is to create a specific modular architecture that technically accurately replicates the operating system/logic and checks of a unique state tax system in order to implement a specialized operational learning approach.

In summary, although D1 is the closest analogue describing a modular accounting simulation system, it lacks the following elements: a primary verification module, a specific parameter verification module, a simulation search module, and a state change module, which are necessary to technically replicate the actions and verification logic of a specific state tax administration system, and therefore cannot implement the intended specialized operational learning approach in this specific area.

A detailed analysis of the state of the art has revealed that none of the known solutions, including general accounting simulation systems, universal software training platforms or financial consulting and tax decision tools, solves the specific technical problem of creating a modular simulation system capable of technically accurately replicating the specific actions and verification logic of the state tax administration system and thus implementing a specialized operational learning method in this area. There is a lack of a technical solution that would allow for the controlled and reliable formation of specific skills in an isolated simulation environment. Our solution will be presented in more detail below.

ESSENCE OF THE INVENTION

The essence of this invention is to solve the technical problem related to the implementation of a specialized operational learning method when working with specific functions of the state tax administration system, in particular with the management of financial data registers and their verification. Existing state-of-the-art solutions do not provide a suitable system capable of accurately replicating the specific logic and actions of tax administration in an isolated (sandbox) environment.

The present invention proposes a simulation system, implemented as a set of functional modules, which enables the implementation of the aforementioned specialized operational learning method. The system includes: a user communication module, a parameter input module and a register management module, which ensure overall interaction and management of register states (Preparing, Accepted).

The novelty and technical advantage of the invention are determined by specific additional modules:

a preliminary verification module that performs the determination of temporary register overlap;

a parameter verification module that applies specific tax administration logic rules to the entered parameters;

a simulated search module, which performs simulated searches against a simulated parameter store (e.g., mmr simulation); and a state change module, which implements specific tax administration state transition logic.

By processing signals and parameters, the set of these modules and their communication with each other allows for technically accurate replication of specific actions and verification logic of the state tax administration system in an isolated simulation environment. In this way, the main technical effect is achieved - the creation of a technically appropriate and safe operating environment, allowing for the reliable formation and consolidation of specialized operational skills necessary for working with a specific state tax administration system.

DRAWINGS OF THE INVENTION AND THEIR BRIEF DESCRIPTION

Fig. 1 shows a modular diagram of the simulation system of the present invention, comprising the following modules with signal communication directions:

the user (V);

a user communication module (1);

parameter input module (2);

register management module (3);

initial screening module (4);

a parameter verification module (5);

a simulation search module (6); and a state change module (7).

MOST SUITABLE IMPLEMENTATION OPTIONS

The embodiments of the present invention will be described in detail below, providing examples of how the simulation system and its functional modules are implemented to solve the previously defined technical problem. The invention implements a specialized operational learning method that allows users to controllably and safely develop the skills necessary for working with state tax administration systems. The entire modular scheme of the simulation system is depicted in the drawing Fig. 1, which illustrates the set of main functional modules of the system and their mutual communication by processing signals and parameters in order to technically accurately reproduce specific system actions and verification logic.

As shown in Fig. 1, the proposed simulation system consists of interconnected functional modules. These modules are designed to process and transform signals and parameters, which ensure a specialized operational learning method in the field of state tax administration functions. The main components of the system are the following:

user (V);

user communication module (1);

parameter input module (2);

register management module (3);

initial screening module (4);

parameter verification module (5);

a simulation search module (6); and a state change module (7).

Below we describe in detail each of these aforementioned modules and their operation in the context of the system.

User (V).

The User (V) transmits control signals (commands) and input parameters (data) to the Module (1). The User (V) receives visual output signals (interface, messages, results) from the Module (1). All other Modules (2, 3, 4, 5, 6, 7) are internal.

User communication module (1).

The user communication module (1) is the main system module responsible for all user (V) interaction with the simulation system. It performs two main functions:

The module (1) is configured to receive external control signals: user (V) commands and input parameters entered via the interface.

The module (1) also generates output signals for the user (V), e.g. visual.

Technically, this module (1) implements the entire graphical/visual user (V) interface that the user (V) sees. This includes, but is not limited to, blocks such as: Login, List of VAT invoice registers (where created registers and their statuses are displayed), Start filling in the register (where register attributes are selected) and Entering data of received/issued VAT invoices. The user communication module (1) reflects the parameters of the simulated financial registers and the general state of the system.

This module (1) communicates with the user (V): accepts his commands and parameters and returns responses in the user (V) interface. Also, the User Communication Module (1) directs the detailed financial parameters entered by the user (V) (e.g. from the VAT invoice entry form) to the parameter input module (2) for further processing. On the other hand, the user communication module (1) has an interface with the register management module (3), to which it transmits command signals related to the life cycle of the registers (e.g.: command to initiate a new register, command to Submit register, command to Adjust register). Updated data on the list of registers and their saved status values (e.g.: Preparing, Accepted) are received from this module (3) in order to display them to the user (V). Furthermore, the user communication module (1) has an interface with the register verification module (5), where if the entered parameters do not comply with the verification rules, error signals (e.g., error messages in the form) are sent from the parameter verification module (5) to the user communication module (1).

These are:

module (1) transfers the entered detailed financial parameters to module (2);

module 1 transmits command signals to module (3), e.g.: Submit register, Adjust register;

module (1) receives updated data from module (3) for display, e.g.: list of registers, changed states; module (1) receives error signals from module (5) for display to the user (V).

Parameter input module (2).

The parameter input module (2) acts as a specialized medium responsible for receiving and preparing detailed financial parameter signals. This module (2) does not receive signals directly from the user (V), instead, it accepts raw input signals that the user communication module (1) receives when the user fills in structured interfaces (e.g. electronic forms). The main function of this module (2) is to structure and transform the received signals into clearly defined parameters suitable for further processing in the system. The module (2) is configured to process specific financial parameters necessary for VAT invoice registers, such as: VAT invoice identifiers (series, number), dates (issue, supply of goods/services), supplier/buyer codes (VAT code, code), monetary values (taxable value, VAT amount) and tax codes and rates.

The aforementioned parameter input module (2) communicates with the user communication module (1): it receives the initial input signals (parameter values) from the module (1) when the user (V) enters them via the interface. The module (2) also has a connection with the parameter verification module (5): it transmits structured parameter signals to the parameter verification module (5) in order to initiate their verification according to the specific tax administration logic. The module (2) also communicates with the register management module (3): it also transmits structured parameter signals to the register management module (3) in order to associate them with the corresponding register and their values are saved (e.g. when writing a new invoice entry to the register).

These are:

the module (1) transmits the primary input signals/detailed financial parameters entered by the user (V) via the interface to the module (2);

the module (2) transmits structured parameter signals to the module (5) for further verification;

The module (2) transmits structured parameter signals to the module (3) in order to store and associate them with the corresponding register.

Register management module (3).

The register management module (3) is a key component of the simulation system, acting as the main manager of the financial parameter registers. Its main function is to process command signals related to the life cycle of the financial parameter registers. This cycle includes:

initialization: when the module (3) receives a command signal (e.g. from the user communication module (1)) to create a new register (e.g. Start filling the register), it initiates this process;

content management: module (3) is responsible for managing the content of the register, e.g.: reviewing the list of all included accounts or assigning a new parameter (obtained from the parameter input c c c c c Γ c If e \\J e Π e c module (2)) to a specific register;

modification: module (3) processes commands such as Adjust Registry or Remove Registry;

State management: An important function of module (3) is to manage and maintain the saved state value for each register. For example, when a register is created, module (3) sets its initial state to Preparing.

Communication with other modules:

module (3) receives command signals related to register management (e.g.: Start filling register, Submit register, Adjust register), from Module (1);

module (3) transmits updated data to module (1) for display, e.g.: a list of created registers and their saved state values;

module (3) receives structured parameter signals (e.g. new invoice data) from module (2) and is responsible for storing and assigning these parameters to the appropriate register;

during registry initialization, the module (3) passes the attributes of the new registry (e.g., type and period) to the initial verification module (4) for checking for overlap;

the module (3) receives a verification response signal (creation allowed/not allowed) from the module (4), based on which it decides whether to continue the register creation operation;

When the module (3) receives a command to change state (e.g., submit a register), it communicates with the state change module (7), transmitting to it (7) a command signal to perform a specific state change operation.

Initial inspection module (4).

The initial verification module (4) performs a single, but critical, specialized function that is essential in solving the technical problem of this invention - it (4) ensures the integrity of the simulated registers in time. The main function of this module is to determine temporal overlaps. When the register management module (3) initiates the creation of a new register, it transfers to this module (4) the attributes (parameter signals) of the new register, defining its type (e.g.: "received" or "issued") and period (e.g.: calendar month or half-year). Then the initial verification module (4) performs a logical comparison mechanism with the parameters of existing registers (which are stored in the system). This mechanism checks whether the newly created register does not overlap with any other already existing register in terms of its type and time interval. This is a direct check for the implementation of overlapping registers. After performing the comparison, the module (4) generates a verification response signal (e.g., creation allowed or creation not allowed/overlap detected), which it returns to the register management module (3).

Communication with other modules:

module (4) receives parameter signals (attributes of the new register: type, period) from module (3);

module (4) returns (transmits) the verification response signal (creation allowed/not allowed) to module (3).

Also, in order to perform the comparison mechanism/procedure, this module (4) must be able to read the parameters of existing registers from the internal system storage managed by the register management module (3).

Parameter verification module (5).

The Parameter Verification Module (5) is a very important module responsible for applying specific tax administration logic and ensuring data accuracy in the simulation environment/system. It is the main module that implements the need to replicate the verification logic specified in the technical problem. The main function of this module is to accept structured parameter signals (received from the Parameter Input Module (2)) and apply a predefined set of logical rules (verification rules) to them. This module (5) implements the Verify function, which allows the user to verify the data before final saving.

The inspection includes:

format checking: whether the parameters comply with the required format (e.g. dates, VAT code structures);

checking mutual compatibility: whether different parameters do not contradict each other (e.g. whether the VAT amount corresponds to the specified rate and taxable value);

checking compliance with the simulated tax administration logic: whether the parameters comply with specific rules specific to this tax system.

If the parameters do not comply with the established rules, the module (5) generates error signals that indicate the errors found.

To perform specific checks of identification parameters (e.g. supplier/buyer VAT code or code), this module (5) communicates with the simulation search module (6).

Communication with other modules:

the module (5) receives structured parameter signals from the module (2) for verification;

module (5) transmits (returns) error signals to module (1) so that it can display them to the user (V) in the interface; module (5) transmits specific identification parameters (e.g. VAT code) to module (6) for performing a simulated search;

module (5) receives simulated response signals from module (6) (e.g. confirmation of the existence of the code) and uses them for further verification.

Simulation search module (6).

The simulated search module (6) is a specialized component whose purpose is to replicate communication with external data repositories that are necessary for the real tax administration process, but cannot be used in a learning environment due to security and data integrity. It is a direct technical implementation of the simulated search MMR and simulated parameter repository elements. The main function of this module is to perform a simulated search operation. When the parameter verification module (5) checks the supplier or buyer data, it transfers specific identification parameters (e.g. VAT number, company code) to this module (6). The module (6) accepts these parameters and performs a search not in the real state database, but in the internal simulated parameter repository (e.g. MMR simulation). This repository stores simulated data that corresponds to the real data in its structure and content. Module (6) returns simulated response signals (e.g., a company name found or a signal that such a code does not exist) back to the parameter verification module (5), which uses this response for further verification. This module is essential in order to create a technically secure operating environment that allows the user to practice with realistic-looking scenarios without risking affecting real systems.

Communication with other modules:

module (6) receives specific identification parameters (e.g. VAT code) from module (5);

The module (6) returns (transmits) the simulated response signals (search results) to the module (5).

State change module (7).

The state change module (7) is a logical component responsible for managing the state of simulated financial registers according to the defined tax administration state transition logic. This module (7) is necessary for solving the technical problem, since it technically replicates the real system action when a register changes its status in the system. The main function of this module is to receive a specific command signal (e.g.: Submit register) associated with a specific register, which is transmitted to it by the register management module (3). Upon receiving this signal, the module (7) activates the state transition logic and modifies the state value stored in that register (which is physically stored in the system's internal storage). For example, it changes the register state from the initial Preparing to the final Accepted. This module ensures that the state change occurs only according to strictly defined rules (e.g.:

only when the register successfully passes all checks of the parameter verification module (5), thus accurately simulating the behavior of the real system.

Communication with other modules:

the module (7) receives a specific command signal (e.g.: Submit Register) and the identifier of the associated register from the Module (3);

The module (7) returns a confirmation signal to the module (3) about the successful (or unsuccessful) state change so that the module (3) can update its information and transmit it to the module (1) for display.

Together with the register storage, the module (7) modifies (writes) the new saved state value (e.g.: Accepted) to the corresponding register in the system's internal storage.

The following describes the overall operating process of the system, illustrating how the previously described functional modules (1-7) interact with each other to implement a specialized operational learning approach.

The process begins when the user (V) initiates interaction with the system through the user communication module (1), for example: by selecting the command to create a new financial data register.

1. Registry creation script:

The user (V) selects the Start filling in the register command through module (1) and specifies the initial register attributes (e.g. type and tax period).

The module (1) transmits these attributes as a command signal to the register control module (3).

The module (3), upon receiving the signal, contacts the initial verification module (4), passing it the attributes of the new register.

Module (4) performs a logical comparison mechanism (checks for overlap with existing registers) and returns a check response signal (allowed/not allowed) back to module (3).

If the signal is positive (allowed), module (3) creates a new register entry in the system storage, sets it to the initial saved status value Preparing and passes the updated register list to module (1) for display.

2. Parameter entry and verification script:

The user (V) selects the active (Preparing) register through module (1) and opens the parameter entry form (e.g.: entering VAT invoice data).

The user (V) enters detailed financial parameters into the interface provided by module (1).

Module (1) receives these primary input signals and routes them to the parameter input module (2).

Module (2) structures and transforms these signals into parameters understandable by the system, and simultaneously transmits them:

to the register management module (3) - so that the parameters are temporarily linked to the register being filled;

to the Parameter Verification Module (5) - to perform the verification.

Module (5) applies a set of logical rules (format, compatibility, tax administration logic) to the parameters.

During verification, the module (5) sends specific identification parameters (e.g. VAT code) to the simulation search module (6).

Module (6) performs a simulated search in the simulated parameter repository (MMR simulation) and returns a simulated response signal (e.g. code found or error) back to module (5).

If module (5) detects discrepancies, it generates error signals and sends them to Module (1), which displays them to the user (V).

3. Register submission scenario:

When the user (V) finishes filling in the register, he activates the command signal Submit Register via Module (1).

The module (1) transmits this command signal to the register control module (3).

The module (3), having identified which register the command applies to, communicates with the state change module (7).

Module (7) executes the defined state transition logic - modifies the state value stored in the register from Preparing to Accepted.

Module (7) returns a confirmation signal to module (3), which updates the register list and transmits it to module (1), which displays the changed register status to the user (V).

This cyclical process, which includes specific checks and state management, allows for technically accurate replication of the operation of a real system and achieves the main technical effect of reliable formation of specialized operational skills.

In addition to the basic functionality described above, the simulation system may include additional functional options for registry administration and analysis.

1. Registry adjustment functionality:

In one embodiment, the register management module (3) is further configured to receive and process a specific command signal Adjust register received from the user communication module (1). Upon processing this signal, the module (3) communicates with a state change module (7) that modifies the state value stored in the register, for example from Accepted back to Preparing (or to a special state Adjusting). This allows the user (V) to reuse the parameter input module (2) and the parameter verification module (5) to edit the same register, thus simulating a real tax administration system adjustment process.

2. Registry removal functionality:

In another embodiment, the register management module (3) is further configured to receive a command signal Delete Register. Upon receiving this signal from the module (1), the module (3) initiates the removal of all parameters associated with that register and its stored state value from the system's internal storage.

3. Summary analysis functionality:

In yet another embodiment, the register management module (3) is further configured to implement the function of Total Data. Upon receiving a corresponding command signal from the user communication module (1), the module (3) performs the summation of the related financial parameters (e.g., taxable value, VAT amount) stored in the register and returns the processed result (total signals) back to the module (1) for display.

4. Managing individual parameters in the registry:

The system can also be configured to manage not only the entire register, but also individual entries in it. The register management module (3) can be configured to receive command signals for the removal of a specific account from the register or for the Invoice change function. This allows the user to perform more detailed operations, which are again checked through the parameter verification module (5).

The following describes a simulation method for specialized operational learning to work with the functions of the state tax administration system, implemented through the previously described set of functional modules. The method includes several main steps implemented by the relevant modules in processing and transforming signals and parameters.

1. Registry creation step:

The method includes a register creation step initiated by a user (V) initiating a command signal via a user communication module (1). This signal, which defines the attributes of the register (type and period), is transmitted to the register management module (3). A preliminary verification step is performed, during which the preliminary verification module (4) performs a logical comparison with existing registers to determine a temporal overlap. Upon receiving a positive verification response signal, the register management module (3) creates a register entry and sets it to an initial stored state value of Preparing.

2. Step of entering and checking parameters:

The method includes the input and verification of detailed financial parameters. When the user (V) enters the parameters through the module (1), these primary signals are directed to the parameter input module (2), where they are structured. The prepared parameter signals are transmitted to the register management module (3) and to the parameter verification module (5).

A parameter checking step is performed, during which the module (5) applies a set of logical rules (format, compatibility, tax administration logic). During this step, a simulated search is also performed, when the module (5) contacts the Simulated Search module (6), which performs a simulated search operation against a simulated parameter store (e.g. MMR simulation) and returns a simulated response signal. If discrepancies are detected, the module (5) generates error signals, which are transmitted to the module (1) for display.

3. Register submission step:

The method includes a register submission step initiated by a user (V) command signal Submit Register via module (1). The signal is transmitted to a register control module (3), which routes it to a state change module (7). A state change step is performed, during which module (7) modifies the state value stored in the register from Preparing to Accepted, thus completing the simulated register submission cycle.

The basic simulation method, which includes the steps of register creation, parameter entry/verification and submission, can be supplemented with the following operational steps:

1. Registry adjustment step.

In one embodiment of the method, after the state change module (7) sets the register to the Accepted state, the method includes an additional register adjustment step. This step is initiated by a user (V) command signal Adjust Register transmitted via module (1) to module (3). The module (3), in communication with module (7), modifies the state value stored in the register back to the Preparing (or special Adjusting) state. This allows the user to repeatedly perform the parameter entry and verification step for the same register, thereby simulating a real data adjustment process.

2. Registry removal step.

In another embodiment of the method, the method includes a step of deleting a register. This step is initiated by a command signal Delete Register from the user (V), which is transmitted via the module (1) to the register management module (3). The module (3), upon receiving the signal, performs the operation of deleting all parameters associated with that register and its saved state value from the system's internal storage.

3. Aggregate data generation step.

In yet another embodiment of the method, the method includes a step of generating aggregate data. This step is initiated by a user (V) command signal Aggregate data via module (1). The signal is transmitted to the register management module (3), which performs an aggregation (summation) operation of the financial parameters (e.g. taxable value, VAT amount) stored in the register. The resulting result (aggregate signals) is transmitted back to module (1) for display.

4. Step for managing individual parameter records.

In a more detailed embodiment of the method, the step of entering and checking parameters may include not only adding new parameters, but also managing existing ones. The method may include a step of deleting an individual record (account), where the user (V) sends a command to the register management module (3) via the module (1) to remove a specific set of parameters (account) from the register. A step of changing an individual record (account) may also be implemented, allowing the steps of entering parameters (2) and checking (5) to be repeated for an already saved record.

In summary, the above-detailed modular architecture of the simulation system and its implemented operational method, which includes specific modules for initial verification (4), parameter verification (5), simulation search (6) and state change (7), provide a unified and effective technical solution that allows achieving the set technical goal of creating a reliable and controlled environment for the formation of specialized operational skills.

Claims (10)

DEFINITION OF THE INVENTION 1. A simulation system intended for specialized operational training in working with the functions of the state tax administration system, including financial data registers, consisting of interconnected functional modules configured to process and transform signals and parameters, including: a user communication module (1) configured to receive external control signals and input parameters and generate visual output signals; a parameter input module (2) configured to provide a structured interface for receiving detailed financial parameters; a register management module (3) configured to process command signals to manage the life cycle of financial parameter registers and maintain a saved state value for each register, characterized in that it additionally comprises: a pre-verification module (4) configured to communicate with the register management module (3) and perform a logical comparison mechanism to determine the temporal overlap of the initialized register with existing registers, generating a verification response signal; a parameter verification module (5) configured to receive parameters from the parameter input module (2), apply a predefined set of logical rules (verification rules) to check the format, mutual compatibility and compliance of the parameters with the specific simulated tax administration logic, and communicate with the simulation search module (6); a simulated search module (6) configured to receive specific identification parameters from the parameter verification module (5), perform a simulated search operation against the simulated parameter store, and return simulated response signals to the parameter verification module (5); a state change module (7) configured to communicate with the register management module (3) and modify the state value stored in the register according to a defined specific tax administration state transition logic, wherein said modules (1-7) are configured to operate together to technically replicate specific actions and verification logic of the state tax administration system in an isolated simulation environment. 2. The simulation system according to claim 1, characterized in that the register control module (3) is further configured to receive a command signal to adjust the register and, in communication with the state change module (7), modify the state value stored in the register from Accepted back to Preparing or Adjusting, allowing the reuse of the parameter input module (2) and the parameter verification module (5) for editing the same register. 3. The simulation system according to claim 1, characterized in that the register management module (3) is additionally configured to receive a command signal to Delete a register and initiate the removal of all parameters associated with that register and its saved state value from the system's internal storage. 4. The simulation system according to claim 1, characterized in that the register control module (3) is additionally configured to receive a command signal Summarized data, perform an aggregation operation of the financial parameters stored in the register and return the processed result, the sum signals, to the user communication module (1) for display. 5. The simulation system according to claim 1, characterized in that the register management module (3) is additionally configured to receive command signals for managing individual parameter entries in the register, such as Removing a specific account from the register or Changing an invoice function. 6. A simulation method intended for specialized operational learning to work with the functions of the state tax administration system, including financial data registers, where the method is implemented through mutually communicating functional modules (1-7), processing and transforming signals and parameters, comprising the following steps: receiving external control signals and input parameters from the user (V) and generating visual output signals for the user (V), performed by the user communication module (1); receiving detailed financial parameters via a structured interface, performed by the parameter input module (2); life cycle management of financial parameter registers by processing command signals and maintaining a saved state value for each register, performed by a register management module (3), characterized in that it additionally includes the following steps: a preliminary check, during which, in communication with the register management module (3), a logical comparison mechanism is performed in order to determine the temporal overlap of the initial register with existing registers, and a verification response signal is generated, which is executed by the preliminary check module (4); parameter verification, during which a predefined set of logical rules is applied to the parameters received from the parameter input module (2), checking the compliance of the parameters with the specific simulated tax administration logic, and communicating with the simulation search module (6), executed by the parameter verification module (5); a simulated search, during which, upon receiving specific identification parameters from the parameter verification module (5), a simulated search operation is performed against the simulated parameter storage and simulated response signals are returned to the parameter verification module (5), performed by the simulated search module (6); a state change, during which, by communicating with the register management module (3), the value of the register's saved state is modified according to the defined specific tax administration state transition logic, executed by the state change module (7), where the aforementioned steps are executed together in order to technically replicate the specific actions and verification logic of the state tax administration system in an isolated simulation environment. 7. The simulation method according to claim 6, characterized in that it additionally includes a register adjustment step, during which, when the register control module (3) communicates with the state change module (7), the state value stored in the register is modified, allowing the parameter entry and verification step to be repeated for the same register. 8. The simulation method according to claim 6, characterized in that it additionally includes a register removal step, during which the register control module (3), upon receiving a command signal, performs an operation of removing all parameters associated with that register and its saved state value from the system's internal storage. 9. The simulation method according to claim 6, characterized in that it additionally includes a step of generating aggregate data, during which the register management module (3) performs an aggregation/summation operation of the financial parameters stored in the register and transmits the obtained result/summary signals to the user communication module (1) for display. 10. The simulation method according to claim 6, characterized in that the step of entering and checking parameters additionally includes a step of deleting an individual record or a step of changing an individual record when the register management module (3) receives corresponding commands from the user communication module (1).