We asked Kirill Pavkin, a participant from Russia and the WorldSkills Championship winner, to tell us more about the challenges he faced and his approaches to solving them.
Below is the description of the task and how Kirill handled it. We also asked Vitaliy Rybalka, 1C employee and one of the experts of IT Solutions for Business Sandbox, to comment on Kirill’s solutions.
According to the task, it was required to automate the following activities:
• Activities of users responsible for corporate asset accounting
• Activities of users responsible for unscheduled repairs and scheduled maintenance of the corporate assets
• Activities of component/consumable procurement managers
• Activities of oil exploration and production departments
• Analytical reporting to top managers
Here you can get a full analysis and the example of development
Session 1
The participant had to implement the following asset (e.g. vehicle fleet) management functions:
1) asset accounting (adding new and editing current assets)
2) quick search, search filters
3) transferring assets between the company's divisions and asset groups
4) keeping a log of such transfers and providing transfer analytics
Asset accounting was mainly handled for mobile user groups.
Kirill: A noteworthy subtask was introducing buttons in the asset list. I used a dynamic list: we write a random request and, having received data on the server, we assign links to images from the image library to appropriate fields.
According to the problem statement, images can be attached to an asset in two ways: through shooting a photo (multimedia) or choosing from the gallery (file selection dialog).
Some forms had to be redrawn for portrait orientation:
When changing screen settings, we change the visibility of button groups.
Entertaining but simple tasks were filters in a dynamic list, search by number and name, and asset serial number generation.
Expert: the task was quite clear as seen from the solution presented with the 1C:Enterprise. In addition to creating a mobile application, the participant had to ensure data transmission from the DBMS of the "server" (desktop MS SQL) to the mobile application and vice versa. For this, we used the mechanisms of external data sources and http-services in the desktop "proxy application." For the mobile platform itself, the most complicated task was to organize the output of images to a dynamic list.
Session 2
It was required to arrange corporate asset maintenance management. The task implied that the participant logged maintenance requests (by division and group), consider repair priorities, schedule maintenance works following the priorities, ordering new components, and accounting existing components. It should be kept in mind that some components had a limited life. If a component had been ordered for an asset and it had not expired yet, then it was unnecessary to purchase the same component again. The repair interface was developed for the desktop component of the company's software.
What participants also had to create was an advanced authorization form for a responsible officer and maintenance manager. After the authorization, the user was automatically assigned a role.
Below is the responsible officer's form:
Kirill: We can only highlight pending maintenance requests here. The issue was addressed by introducing conditional appearance in the dynamic list.
To proceed to the next form, a user should click the button at the screen bottom:
This form is quite common to the 1C:Enterprise.
The maintenance manager's form is as follows:
This form features sorting by priority and request date. By clicking the button below, the user can go to the form of a specific request:
Along with ensuring fool tolerance, the form needed to display a list of parts to be repaired. That subtask was interesting as some parts have a limited life. This means that, if an asset already got into an emergency and a non-expired component had been ordered, such a component could be reused. This should be shown to the user.
Expert: Kirill set the priorities correctly. There was nothing extra special in terms of implementing the thing in the 1C:Enterprise. The task required a careful analysis of accounting and spare part usage conditions and competent fulfillment.
In addition, it was necessary to skillfully arrange accounting for service requests. The main difficulty was time pressure (2.5 hours). Moreover, as in mobile development, participants should correctly retrieve data from an external DBMS (MS SQL).
Session 3
Participants were required to design a long-term maintenance schedule. The schedule needed to be formed
-
by validity terms (e.g. every second month on the 3rd day) and
-
by a quantitative indicator (e.g. odometer readings, including oil change every 5,000 km, tire change every 20,000 km).
A maintenance manager needed a convenient mobile application that would dynamically display a list of overdue, current, and completed maintenance for a specific period. Besides, every maintenance type had to be highlighted as prescribed.
A mobile app was supposed to ensure adding new maintenance schedules and marking completed procedures at workshops, with immediate updating on the server.
Kirill: There are two repair types: time-based and run-based. Each of them allows variability. For example, planned repairs should be performed every Friday on the 13th day of a month or every 20,000 kilometers. The task is considered complete if it has a checkmark to its right.
A task sorting condition was also provided. Also, every line had to be highlighted based on conditions. The user could create a new maintenance plan by clicking the button below:
Required fields are displayed depending on the schedule type. If one chooses a weekly schedule, they will see two fields: week number and week day. For instance, on Tuesdays every three weeks.
Expert: Similar to the previous mobile development on 1C:Enterprise, this task was divided into two big parts: communication with the "server" over the web API and correct dynamic list displaying with conditional formatting and filtering (selection). Another worthwhile requirement was accounting maintenance operations by time and quantitative indicator.
Session 4
Speaking of components and consumables, it was required to organize the stock, plan expenses and future purchases. Also, there was such a feature as batch accounting (though not for all goods). All this had to be carried out in the framework of a great number of warehouses, including reception, expenditure, and transfer. According to the task, it was required to ensure the stock control and avoid conflicts when working with actual inventory. Purchase managers use the desktop program.
Below is the main form:
Kirill: Beside conditioned sorting, it was required to provide custom sorting. In fact, 1C never allows it. The field with the number of parts should be highlighted in green for incoming invoices.
At this stage of the challenge, developers were asked to control the stock balance. So, the system displays a message when a user tries to delete a receipt. Here we recall the platform engineer admission exam. Below is the invoice form:
Every component has an attribute determining whether this component belongs to a specific batch. For such components, it is required to specify the batch number in all documents. This is an additional measurement for monitoring component balance. They can also be moved between warehouses:
The only thing that differs this form from the previous one is that the user specifies the supplying warehouse instead of the customer. A selection list for a batch is automatically compiled after selecting a component. The user can generate a report on the current stock:
Here we can see the balance of the selected warehouse. The checkbox to the right of the warehouse allows a user to configure filtering and sorting. In fact, this list doesn't feature explicit separation by batch for those components that require it. The user can view the balance by the batch number for any component using the navigation link on the right.
Expert: batch accounting first appeared in this very session. Contestants had to account consumables and goods respecting batches to which they belong. At large, the task was perfectly suitable for the 1C:Enterprise. However, programmers had to prepare everything from scratch and on time (they were given humble 2.5 hours).
Session 5
In the fifth session, the task was to develop the well management functionality. It was required to create a mobile application for survey crews that would account oil/gas wells. The problem was to retrieve the list of wells from the server and illustrate a selected well by layer (ground, sand, stone, oil), with due respect for depths of each layer.
Besides, the application was supposed to allow updating well data and adding new wells. For this application, the customer stipulated special requirements concerning offline and online operation (server connection control)—e.g. checking server connection every 5 seconds and transforming application functionality depending on the server availability.
Kirill: After the user chooses a well, they see a bar chart with highlighted layers above oil/gas deposits. Also, it stores the name, color, and bedding range for each layer. In such design conditions, built-in diagrams cannot work it all out. Meanwhile, a spreadsheet easily pulls it off. The user can add and edit wells:
The form had no noteworthy features besides multiple fool tolerance. The next task was to control the server connection. To this end, we try to connect every 5 seconds. If we fail, then we restrict the application functionality and display a message.
Expert: what made that task interesting was its graphical component. Those contestants who used the 1C:Enterprise solved the task in two different ways. Some employed diagrams, while others used the spreadsheet. Both approaches had their pros and cons. As we remember, every task given during the WorldSkills Championship was limited in time, including that one. Another noteworthy problem was pinging the server every 5 seconds and switching the application behavior depending on the server availability.
Session 6
It was required to create a Dashboard, a workspace for the company executives. Participants needed to display general company performance indicators for a specific period, in the graphical and table forms. The main form was the cost report:
Besides Dashboard, programmers had to implement the distribution of spare parts for asset repairs, with the help of FIFO/LIFO/The cheapest leaves first write-off methods.
The distribution needed to respect the batch accounting, employ stock balance control, and feature fool tolerance.
Kirill: When solving the task, I used the value table with programmed column generation (any number of columns is allowed).
-
The first table handles the total spending on departments by month. To this end, the most loss-making department is highlighted in red, while the most profitable one is marked green.
-
The second table displays the most expensive and most-used spare parts for each month. If there are several parts that meet the same criteria, then they should be displayed in one cell, comma-separated.
-
The most costly assets are displayed in the first row of the third table. The second row displays the department to which the above asset belongs. If there are two most expensive assets of the same cost, then they should be displayed in one cell, comma-separated.
I displayed charts using the built-in mechanisms and filled them out with the help of queries.
It was also required to implement the support of several languages. The software loads XML files with the interface element localization, and the form needs to be redrawn if the user changes the language from the drop-down list.
The user opens the stock balance form by clicking a button in the bottom-left corner:
In this form, we finally start to spend spare parts on repairs. First, we find components we need to repair an asset. For the fields selected and distribution method chosen (FIFO, LIFO, the cheapest leaves first), matches or a "No matches" message are displayed. After that, the user can mark components as intended to be used for repairing the asset. Stock balance control is relevant for the current session. If one has already assigned components, they won't be found in matches.
Expert: the session was more than exciting. It makes the maximum use of what the 1C:Enterprise can do:
-
competent handling of accumulation register tables
-
programming form elements (tables and headers)
-
diagrams
-
LIFO/FIFO methods when analyzing stocks, profit/loss analysis, etc.
Session 7
At the final stage of the challenge (session 7), the customer provided software (exe-file) on project activities and a short tutorial video. It was necessary to carry out reverse engineering and, based on this, create two diagrams: a diagram of use options and the "essence-relationship" diagram. Moreover, some requirements for developing the software in the future were stipulated; it was required to create an interface model based on those requirements.
As per the championship terms, developers could only use MS Visio when creating diagrams.
Expert: in that session, contestants didn't use the 1C:Enterprise's capabilities. As per the competition terms, diagrams were designed in MS Visio. At the same time, programmers were allowed to create the interface prototype in an empty 1C database.
General Notes
At the beginning of every session, the users were offered to import data via an SQL script. And that was 1C's key disadvantage compared to C# since we had to spend at least half an hour to transfer data to external sources, create tables, and transfer strings from external sources to our tables. Other participants just needed to click Execute in Microsoft SQL Studio.
For obvious reasons, one shouldn't store data on a mobile device. To this end, we created server databases during mobile sessions. We used those databases to store data and granted access to them over HTTP services.
Expert: while it took considerably long for programmers who used the 1C:Enterprise to connect to an external DMBS (Kirill mentioned it), C#/Java (Android Studio in mobile development) could make use of the time given to craft interfaces, write more code, etc. Therefore, the results of each session were unpredictable and extremely interesting for all experts. The tension never loosened throughout the event. Just look at the final winner table showing the distribution of points.
Kirill finished his story :)
