Schedules - Configure schedule events

After switching on, the automat checks the last communication times of active devices, WHICH data is downloaded by the PVD Aggregator application. While sending communication statuses with individual devices, e.g. meters on the communication bus, inverters, devices with MODBUS protocol, the PVD application also sends the time of the last correct communication with this device.

Only one configuration parameter for this machine. With failureThreshold in seconds we can specify an alert point. If communication with any active device in any aggregator occurred earlier than X seconds from now, a SCHEDULED alert will be generated for the event management system (Events). In it, it is possible to define the reaction to this message (sending a notification, e-mail, text message).

After switching on, the automatic unit checks the last communication times of active PVD Aggregator devices. Each of these devices sends the so-called heartbeat, i.e. confirmation that it works and communication is correct. Based on this information, the system can check and generate a warning for selected users if the time of the last communication with active aggregators is greater than the configuration parameter.

Only one configuration parameter for this machine. With failureThreshold in seconds we can specify an alert point. If communication with any of the active aggregators occurred earlier than X seconds from now, a SCHEDULED alert will be generated for the event management system (Events). In it, it is possible to define the reaction to this message (sending a notification, e-mail, text message).

An automaton that checks the times of the last communication through the API. Sometimes we may want to know if an external system is transmitting data continuously to the AMAGE system. For each transmission, the last date/time of such communication for a given API key is stored in the database.

With this automaton, we can generate an email event alerting that a given API key has not been used in the last X seconds. With the deviceFailureThreshold parameter we define the time since the last communication, apiAccessKeyUuid we specify the key we want to monitor, with the language, emails, email_topic, email_content tags we can specify the email recipients, title and content of the message.

Availability: AMAGE Web

Integration with the GS Software weighing system. It allows you to download information about weighings in the GS Software system and enter it into the appropriate production parameters of the system. Configuration of access data is carried out by variables db_url, db_login, db_password. Enabling the download of data on individual weighings is set using the fetch_car_weight option. Grapple weighing performed using a separate interface is enabled through the fetch_grapple_weight option and the production parameter code must be specified, to which the value will be entered via fetch_grapple_item_code. Ignored codes from the GS Software system can be entered into the ignored_codes variable. These data will not be copied to the system. By default, the machine analyzes the current month (downloads data from the beginning of the current month to the date of the operation). This period can be extended by specifying the number of months back that the system should analyze through the month_before_count variable.

Integration with the Xpertis system. The database data allows ODBC access to the Xpertis system. Separately, you must configure an ODBC connection to the system with this connection alias. In addition, we specify the UUID of the service event state (finished_state_uuid), which is treated as the state in which the event should disappear from the Xpertis system (cost controlling). In order to link the costs of warehouse and invoices in the Xpertis system, we provide the UUID of services, which are treated as warehouse costs and external costs of invoices (service_item_warehouse_type_uuid and service_item_invoice_type_uuid). For storage costs, the service must first be created in AMAGE and have the document number entered as in the Xpertis system. The scheduler will automatically update the costs of a given document. In the case of invoices, the scheduler will CREATE new entries in a given service event with the costs of invoices that have been assigned to a given service event.

The task sends an email with a generated PDF report of the complaint to the supplier associated with the given complaint through an order. The task is activated for a given complaint if its state is specified by the complaint_begin_state_name parameter. The email address is taken from the contractor’s data as the company’s main email address. Additional email addresses are provided in the config.emails variable. After sending the email, it changes the complaint status to that specified in the complaint_end_state_name parameter. The report is generated in the locale specified in the language parameter. The title and content of the email are specified in the email_topic and email_content parameters. You can also use the email_portal_url parameter, to which the supplier will be directed, to comment on the complaint. The %token% field can be used to specify a token identifying the complaint.

The task sends an email with the generated PDF delivery/return report to the supplier associated with the given delivery. A task is activated for a given delivery if its status is defined by the delivery_begin_state_name parameter and the delivery is of delivery_type. The e-mail is sent only if the contractor has the "send orders automatically by e-mail" flag marked in the contractor definition for the contract. The e-mail address is taken from the contractor’s data as the company’s main e-mail address. After sending the email, the delivery status is changed to the one specified in the delivery_end_state_name parameter. The delivery document is generated only if the send_document flag is set (off by default). The report is generated in the locale specified in the language parameter. The title and content of the email are specified in the parameters email_topic, email_content. Additional email addresses are provided in config.emails.

You can also use the email_portal_url parameter to which the supplier will be directed to confirm the order. In it, you can use the %token% field to specify the token identifying the order.

If the delivery has an assigned work order and this order has a specific location with a point on the map, you can use the options in the formatter: %location_url% and %placeofwork_url%, which will contain a link to the page with the location on the map. To enable this, the config.email_location_url configuration parameter appears, in which a link to the geolocation page is provided. There, we use the %lat% and %lon% templates to indicate latitude and longitude in digital form, e.g. 23.4234.

The task sends an email with the generated PDF order report to the supplier associated with the given order. A task is activated for a given order if its state is specified by the order_begin_state_name parameter. The e-mail is sent only if a given contractor has the "send orders automatically by e-mail" flag marked in the contractor’s definition for the contract. The e-mail address is taken from the contractor’s data as the company’s main e-mail address. After sending the email, it changes the order status to the one specified in the order_end_state_name parameter. The report is generated in the locale specified in the language parameter. The title and content of the email are specified in the parameters email_topic, email_content. Additional email addresses are provided in config.emails.

You can also use the email_portal_url parameter to which the supplier will be directed to confirm the order. In it, you can use the %token% field to specify the token identifying the order.

If the order has an assigned work order and this order has a specific location with a point on the map, you can use the options in the formatter: %location_url% and %placeofwork_url%, which will contain a link to the page with the location on the map. To enable this, the config.email_location_url configuration parameter appears, in which a link to the geolocation page is provided. There, we use the %lat% and %lon% templates to indicate latitude and longitude in digital form, e.g. 23.4234.

Automatic generating settlement of the employee’s attendance. It uses attendance registrations (entry/exit) to calculate attendance time. Attendance registrations can be made using the built-in mobile application for attendance registration using proximity cards on an Android phone. These data can also come from an external T&A/AC system as entry/exit registration readings.

Configuration of the automaton allows you to define the time period for which calculations are performed, whether it is also this month or the previous calendar month. Using the language parameter, we define the content of messages recorded in the system after performing correct/incorrect data calculations.

Detailed information about the generated data can be found in the event log for the automation (scheduler) module.

Generating a schedule for employees for a specified number of months. It allows you to automatically complete the generation of a new (for the next) month of the schedule when the schedule is launched. The generateMonthCount option specifies the number of months to be generated. If it is 1, only the schedule for the next month is generated. If it is 2, a schedule is generated for the next month and the month after it. If it is 3, a schedule is generated for the next month, for the month after it and for the month after it, etc. We always generate a schedule, starting from the next month from the current one.

The task analyzes the expiration date of employees' competencies in the given range of days (from_today_start to from_today_end), e.g. 7-14 is the next week. If an employee’s competence expires in a given period, it is added to the content of the email. The configuration of the email content is carried out by the title, content header and lines of one competency importance (for many it will be a list consisting of these lines). You can use the variables given in the examples.

Automatic generating notifications about upcoming CRO inspection dates. If the notification_enable option is enabled, notifications go to the notification bar in the Web application. If the email_enable flag is enabled, an email will be sent. The content of messages is defined in other options.

An automatic device that generates information reminding about the required and expected emission monitoring measurements. As part of the definition of emission monitoring, we specify what type of event (taking a sample, receiving a report, sending a notification) we want to receive an e-mail notification and how many days before this activity is to be performed.

In the scheduler, we define only the information to be included in the header, title and description of each notification element. With the language option, we specify the language used in the email. With the topic option, we define the title of the email, and with the email_header option, we define the content of the main header of the email (in the body). We specify each of the notification elements with email_item_template.

The system generates information about:

Automatically generating notifications about upcoming contract dates. If the notification_enable option is enabled, notifications go to the notification bar in the Web application. If the email_enable flag is enabled, an email will be sent. The content of messages is defined in other options.

Automatic generating notifications about upcoming decision dates. If the notification_enable option is enabled, notifications go to the notification bar in the Web application. If the email_enable flag is enabled, an email will be sent. The content of messages is defined in other options.

Automatic generating notifications about upcoming reporting deadlines. If the notification_enable option is enabled, notifications go to the notification bar in the Web application. If the email_enable flag is enabled, an email will be sent. The content of messages is defined in other options.

Automatic generator that generates a planned schedule for the division of energy production in energy cogeneration plants. The system retrieves information on energy prices based on the data source selected using the energy_prices_type parameter. Based on this data, it generates a plan for the production of electricity and heat. The minimum, average and maximum values of energy generation are determined using the parameters min_heat_generation, mean_heat_generation, mean_electric_generation, max_electric_generation. The system tries to maximize the profits from energy production. The algorithm is then presented in analyzes and reports.

The task checks the two previous values of the delivered energy in quarter-hour quanta (15 minutes). In case the last delivered energy value falls below the threshold value (in thousands of kW) an email will be sent with the "below" values. If for the last two values the generation returns above the limit value, another email with "over" values will be generated.

Generation of information about energy production. Generates a file to be used by visualization systems. Contains data on electrical and thermal production. We generate every three hours. The target file described by the variable. We generate a file with the following columns: date [yyyy-MM-dd]; time [0-23]; delivered energy [MWh]; generated energy [MWh]; delivered thermal energy [GJ]

The algorithm collects data from energy registration. We provide the IDs of the parameters we want to retrieve. If there is no data in the system, the algorithm generates information about the lack of data. If data is available, the algorithm generates information about the downloaded data. The parameters correspond to the identifiers of production parameters in the system and denote energy_prices_type the type of energy price data source selection. The remaining parameters are the identifiers of the production parameters that we want to retrieve.

The generator collects information about the price values for 1GJ of thermal energy supplied to the network. In the initial implementation, it has a static configuration with a single price.

The generator retrieves information from the PSE source for the balancing market and enters the data into the system. The configuration contains information about the address from which we download data.

The generator retrieves information from the TGE source for the day-ahead market and enters the data into the system. The configuration contains information about the address from which we download data.

Sample configuration file (execution at 0:00 on the third day of each month, start delay 30 seconds, task active). We check the previous month and if no data for that month has been entered for the active production data, emails are created for each person responsible for the data and an email is sent to them with a list of production data.

Energy production data analyzer. If a list of parameters with the sum of values exceeded in a given year is detected, it generates an email with a list divided into critical exceedances and warnings as defined in the parameters. In the text elements, you can use templates according to the example. Only parameter limits with the "do not notify" flag disabled are included in the list. If the notification_enable flag is set to 'true', a notification will be generated for each responsible person in the system with a message in the notification_template.

A generator that creates new entries in the production data for a given month. It should run once a month at the beginning of the month. It will then create a new entry for inputting production data. Running multiple times within a given month will not result in any action. It has no additional configuration parameters.

The machine generates new limits for production parameters. If the appropriate options are selected, it generates a new limit as a copy of the previous limit for a given period.

Inspection planner. Inspection executions are generated based on defined inspection plans. In the inspection plan template, you can enable automatic generation of inspection executions X days before the need to perform such an inspection. The machine is responsible for generating such data. A notification is generated for the user in the system that he has been assigned to a given inspection as a contractor. If we define the UUID of the work order, the machine will automatically assign the inspection execution to a given work order.

Automated email generation to the list of users with information regarding the plan of necessary inspections in the selected period of time. The number of days from the script execution date to be taken into account for the analysis is given. The target list of email addresses as well as the title, message header and a single element of the message text (single device) are modifiable.

Automatic generating PDF reports of performed and checked inspections. After enabling, I can specify whether the generated report file should have the Public flag, i.e. be available, for example, via the Customer Portal. Whether to save the generated report in the work order to which the inspection is attached. Whether to save to the resource to be inspected and what category to assign to the attached file.

During the execution of the machine, the protocols that are made are checked, but they do not have a generated report. After performing the action and saving the reports, the Report generated flag is set for the audit.

An automation that will automatically enter a record of the supervision status into the resource connected to the inspection after it has been performed. This allows you to link inspections and supervision of a given resource. For example, after performing an inspection, the machine can automatically enter the "Inspection performed" status for "Installation supervision" of a given resource. It automates and connects two modules - Inspection and Supervision.

The configuration allows you to indicate the ID of the inspection template to which the inspection_template_uuid machine applies. Indications which flags will trigger the inspection_executed and inspection_checked actions. We then provide the supervision template ID supervision_template_uuid and the specific supervision state supervision_template_state_uuid. We can get all this data in the user interface.

Notification of pending inspections. Inspections that were performed in the period from from_today_start to from_today_end as the number of days from today have the completed flag and not the checked flag. The email will be generated collectively for people who are indicated for inspection verification. Email content and title defined in options.

We check the UUID inspection round given in the letter. If the time since the last execution > 48 h, we send a message to the e-mail addresses provided.

The task sends an email with a reminder at the end of the execution of a given lease in the days before the end of the execution time specified in the reminder_days_before_end parameter. It is necessary to specify the UUID (list) of contracts that this scheduler applies to. The email_topic and email_content fields contain the title and content of the email. You can use the given tags, which will be converted to the current date and name of the work order. Sample configuration file (execution at 6:15, 14:15, 22:15, start delay 30 seconds, task active).

The automaton allows you to automatically change the state of the ISO register regarding corrective actions. After switching on, the machine monitors the tasks assigned to a given corrective action and after detecting the completion of all tasks, it automatically changes the status of a given corrective action to the selected one and then sends messages to people creating/responsible for a given register. In addition, if there are any new, unfinished tasks or tasks change their status to uncompleted, the system will automatically restore the initial state of the given register.

The configuration allows you to indicate the UUID of the initial state config.begin_state_uuid and the UUID of the final state config.final_state_uuid. The automaton checks both states and performs appropriate actions depending on the state of the tasks. Users are sent messages that can be customized with the config.text_finish_state and config.text_begin_state options.

The machine allows you to automatically change the status of the ISO register regarding rationalization applications. After switching on, the machine monitors the tasks attached to a given register and after detecting the completion of all tasks, it automatically changes the status of a given application to selected and then sends messages to persons creating/responsible for a given register. In addition, if there are any new, unfinished tasks or tasks change their status to uncompleted, the system will automatically restore the initial state of the given register.

Configuration allows you to indicate the CODE of the initial state config.begin_state_name and the CODE of the final state config.final_state_name. The machine checks both states and performs the appropriate actions depending on the task state. Messages are sent to users, which can be customized with config.text_finish_state and config.text_begin_state.

The machine allows you to automatically change the state of the ISO register regarding the register of risks/opportunities. When activated, the machine monitors tasks attached to a given register and after detecting the completion of all tasks, it automatically changes the status of a given application to selected and then sends messages to persons creating/responsible for a given register. In addition, if there are any new, unfinished tasks or tasks change their status to uncompleted, the system will automatically restore the initial state of the given register.

Configuration allows you to indicate the CODE of the initial state config.begin_state_name and the CODE of the final state config.final_state_name. The machine checks both states and performs the appropriate actions depending on the task state. Messages are sent to users, which can be customized with config.text_finish_state and config.text_begin_state.

Automatic checker of external sources of legislative documents. If new documents are detected that are not in the system. The system supports the API of the Sejm of the Republic of Poland and the ability to download data from the Journal of Laws and/or Monitor Polski. Tags tag1, tag2, tag3 are used to filter documents. If new documents are detected, the machine generates an email with a list of new documents. The variables %date%, %labels%, %number%, %title%, %address%, %displayAddress%, %link% can be used in the email content. The %address% value is used to generate links to documents.

The machine generates an e-mail notification about upcoming legislative deadlines. The system will automatically send notifications assigned to a given day at the time specified in the scheduler.

The AMAGE system has the ability to generate notifications for users. Notifications appear in the system in messages for the user available in the system menu with the "bell" icon. The system can specify the expiry date of the notification, i.e. they will disappear from the notification, e.g. after 48 hours, if the user does not explicitly approve it. The scheduler allows you to disable these notifications after this time has elapsed. Enabling the scheduler without additional options allows you to disable notifications that have an active validity time.

In addition, some notifications can be displayed without an expiry date. Sometimes it happens that users do not acknowledge these messages and they queue up all the time for users.

The scheduler allows you to close such notifications after a certain time from their publication. After enabling the scheduler, you can configure additional options that will close notifications without an expiry date. Set the config.close_notification_without_expiration option to true and set the time (days) after which these notifications will disappear from the user’s notification field. The value is set in the config.close_notification_age_days variable

Report generator in PDF format. We generate a report based on the UUID list of report tabs and then send the result to e-mail addresses. One email will be sent with as many reports as selected tabs. The filenames are the names of the bookmarks. In the parameters, we specify the list of emails to which the report is to be sent, the email subject and the email content. You can use the %date% variable to introduce contextual information into the email body and title. You can specify the language of the generated report via the language variable. If the variable is not provided, the default language of the server on which the synchronization server is run is set.

The task verifies the last time the service event was updated in the specified state. For all service events in the <state.uuid> or <config.states_uuid> state, the task checks the task’s last modified time. If no statuses are provided, the system searches for all service requests whose current status does not have the public status set to 'Resolved'.

Then the modification time is checked. If the time is greater (older) than the number of minutes specified in the <state.stalled_minutes> configuration, an email is sent with the title <config.email_topic> and the content <config.email_content> to the recipients <config.email_recipents> (addresses separated by spaces). In the content and title, you can replace the fields of the current date, event status and the list of ticket numbers that are overdue. Restricting the types of service events is done by providing a list of UUID types that are to be selected for this machine. In addition, you can select the option to send notifications separately to the person assigned to the <config.email_assigned> event as creating it or to the person currently assigned <config.email_creator>.

The task changes the state of the service event from the initial state to the final state. During the state change, it adds a record (comment to the request) indicating the mechanism of the change and indicates the final state to which it changed. The start and end UUID of the service request status must be specified in the configuration. Restricting the types of service events is done by providing a list of UUID types that are to be selected for this machine.

Generation of PDF reports from service reports.

Generates a PDF file from the service protocol, which has the flags: DONE and CHECKED, but does not have the REPORT_GENERATED flag. For such reports, a protocol is generated in the format defined in the report tab with the given UUID in the 'report_bookmark_uuid' parameter. If the UUID of the bookmark is not provided, the default appearance of the report is generated. After generating the file, it is saved to the superior service request if the 'store_in_serviceevent' flag is set. The file is given a category (optional) with a UUID in the 'attachment_category_uuid' parameter and a public flag if the 'public_files' flag is set. Enabling the send_email_to_representative option allows you to send an email to the person indicated as the representative of the applicant.

The task analyzes the expiry date of the equipment check in the given range of days (from_today_start to from_today_end) e.g. 7-14 is the next week. If the device calibration expires in a given period, it is added to the content of the email. The configuration of the email content is carried out by the title, content header and lines of one competency importance (for many it will be a list consisting of these lines). You can use the variables given in the examples.

It checks the inventory objects and if it can associate all parameters with the product, it automatically creates the product in the structure based on the inventory. An additional parameter is the indication of the product group to which the new product will be added. If the product_subgroup_time option is enabled, a subgroup of products with the current date will be automatically created. This allows you to place new products in the structure with the dates of their entry into this structure. If the product_subgroup_delivery_number option is enabled for inventory objects from deliveries, the group name will have the number of delivery documents.

The supervision initiator that has the supervision data specified in the internal configuration. The difference in relation to the universal initiator is the possibility of specifying a group of products (and subgroups) for which supervision will be initialized.

The machine performs the following tasks:

The automatic configuration allows you to enable notifications for selected users notification_user_logins. Notifications are generated to them informing about the creation of supervision types and the creation of new supervisions for new resources.

An automaton that automatically generates a specific inspection after a given resource reaches a certain state in supervision. This allows you to automatically create inspections for some supervision in case some supervision state is reached.

For example - if the assembly status of a device reaches the "connected and ready" state, the system can automatically generate an inspection for this resource with the template "Final check of the device" and assign it to the foreman along with the work order.

We configure the data in the machine options. We define the inspection template that will be used to generate the inspection_template_uuid inspection. We specify the supervision template supervision_template_uuid and the specific supervision state supervision_template_state_uuid that will trigger the generation of this inspection. When generating an inspection, we assign it to the user responsible_user_uuid and assign it to the work order work_order_uuid.

Inspections will be created only for resources in the root_group_uuid product group (and subordinates) and only for resources with type_categories

After the inspection is generated, a notification with the specified text will be generated for the user.

Universal supervision initiator based on supervision settings in the user interface. After switching it on, according to the schedule, the machine reviews the data and performs the following actions:

The automatic configuration allows you to enable notifications for selected users notification_user_logins. Notifications are generated to them informing about the creation of supervision types and the creation of new supervisions for new resources.

The machine verifies the quantities declared in the warehouse and compares them with the quantities resulting from warehouse documents. If inaccuracies are detected, it generates an e-mail notification.

The machine allows you to send warehouse documents to email addresses. In the configuration you can specify the types of documents to be sent, recipients, language, email content and attachments. The algorithm is identical to sending order documents.

The machine generates a summary report of minimum stock levels in the warehouse. During execution, all e-magazines are analyzed and a collective email is generated to the list of addressees specified in the machine parameter. The content of the header, title and individual elements can be modified with additional parameters.

The machine allows you to automatically stop work orders at the end of the working day. In the configuration you can specify the language, work end time, work template and notification template. If a work order is stopped, the machine adds a comment to the order with information about the automatic stop of the order.

The automaton allows you to send emails to people with reminders about tasks that are about to start or are close to the end date. Using the appropriate options, we can define the time when the information will be sent, to which recipients and what its content is. The automaton is based on the dates of expected start and expected completion of tasks.

In the configuration, we can specify with the config.expected_start_notify option the number of days from the expected start date when the email will be sent. It can be, for example, -5, i.e. 5 days before or 5, i.e. five days after the given date. The same applies to the task end option in the config.expected_deadline_notify parameter. Using the config.email_assigned option, we specify whether to send an email to the person assigned to the task, and using config.emails, we specify additional email addresses to which the notification should be sent.

The content of the email is defined by the elements config.email_topic, config.email_header. Each of the ranges can be preceded by the texts config.email_topic_item_start and config.email_topic_item_deadline respectively. Each of the tasks will be displayed in a list (in bulk), where each row is defined using config.email_item_template.

An automaton that allows you to notify selected users when there is no change in parameter values over time or no new parameter values over time. Such an automaton makes it possible to detect a lack of communication with selected devices or external systems that should provide information on an ongoing basis. It also allows a quick response to missing data, which can be crucial when monitoring important parameters.

The language parameter allows you to specify the language of notifications for texts built into the application. The parameter_setting_uuid parameter defines the UUID of the parameter that we are monitoring. config_no_entry enables notifications when there are no history records for the parameter. notify_no_entry_minutes defines the time after which the notification will be sent. notify_no_entry_template allows you to specify the content of the notification. Similarly for notify_no_value_change, notify_no_value_change_minutes and notify_no_value_change_template, which specify notifications when the parameter value does not change. The application_notify and email_notify options allow you to specify whether the notification should be sent to application users as part of notifications or to email addresses. In the case of emails, you can specify additional parameters such as emails, email_topic, email_header. For notifications in the application, additional parameters must be specified, such as application_notify_logins, which defines the list of user logins that are to receive notifications. If the language is not specified in the configuration, the machine uses the language of the server on which the synchronization server is running.

An automaton that allows the transformation of the value of one parameter to another parameter or to production data. The automaton allows, for example, to rewrite data from a parameter continuously collected from some device (energy meter value) or data from external IT systems stored in parameter settings to production data at the end of the month using additional actions and aggregation.

Using the language parameter we set the language of messages permanently saved in the system. parameter_setting_uuid specifies the UUID of the parameter that will be processed. Then we select either the UUID of the production data or the UUID of another parameter setting that will be the target of the transformation. Using target_value_equation we can additionally process the value from the parameter using an additional equation mechanism (dividing, multiplying, etc.). Additionally, using operation_type we can specify the value of the parameter that we are processing. CURRENT specifies the current value of the parameter. LAST - the previous value of the parameter. SUM - will perform the sum of the parameter setting records in the specified time, DIFFERENCE/MEAN - the difference and the arithmetic mean value of the measurement values in the given range, respectively. We specify the date range using operation_interval_type and operation_interval_value.

Additionally, we can specify whether the notification should be sent to application users using application_notify, application_notify_logins, application_notify_template and whether it should be sent to email addresses using email_notify, emails, email_topic, email_header, email_item_template.

Automation allowing synchronization of Merit system warehouse documents with AMAGE. Automation downloads specific warehouse documents from Merit system and then creates appropriate warehouse documents in AMAGE system along with records of warehouse/storage location statuses and creation of element types if they are not available in the system. Using db_alias, db_login and db_password options we provide configuration of access to the database via ODBC interface. documents_type option indicates types of documents that should be downloaded to AMAGE system. area_numbers option provides area (section) numbers from Merit system, whose documents will be synchronized. Using measurement_unit_map we define unit names in Merit system and appropriate unit codes in AMAGE system, to synchronize this type of data accordingly. Using default_supplier_uuid we provide UUID identifier of default supplier in case of necessity of creating new types of material (Merit system does not provide this data). Using default_warehouse_uuid and default_warehouse_place_uuid we provide the identifiers of the warehouse and storage location to which the documents will be synchronized. Using receive_documents_months we specify the number of months in which the documents are to be retrieved from the Merit system. Of which value = 1 means the current month, value 2 the current and previous, etc.

The system synchronizes data and detects existing documents by their numbering. If it detects them, they are not processed again.