是一項為22歲以下青少年組織職業比賽的國際運動。
國際決賽每兩年舉行一次。 今年的決賽場地是 （上屆決賽於 2017 年在阿布扎比舉行，下屆決賽將於 2021 年在上海舉行）。
世界技能錦標賽是世界上最大的職業技能錦標賽。 他們從藍領職業開始，近年來越來越多地關注“未來的職業”，包括IT學科，喀山錦標賽上為這些職業分配了一個單獨的巨大集群。
在 IT 領域，有一項能力（一項特定的“運動”），稱為“商業 IT 軟件解決方案”。
在每場比賽中，允許使用的工具清單都是有限的。 例如，如果對於“景觀設計”，可能的工具列表是有限的（當然，沒有指明明確的製造商或顏色），那麼在“商業軟件解決方案”能力中，參與者可以使用的可接受技術列表受到嚴格限制，表示特定的技術和特定的平台（.NET 和Java 以及一組特定的框架）。
1C對此問題的立場是：信息技術是一個非常活躍的領域，世界上不斷出現新技術和開發工具。 從我們的角度來看，允許專家使用他們想要且習慣於工作的工具是正確的。
2018 年秋天，世界技能大賽管理層聽到了我們的聲音。 現在我們必須測試將新技術融入比賽的方法。 這並不簡單。
1C：企業平台被列入喀山錦標賽基礎設施清單，並組織了商業沙箱IT軟件解決方案實驗平台。
請注意，錦標賽的官方語言是英語。 所有包含解決任務結果的材料（源代碼、隨附文檔、軟件界面）也將以這種語言傳輸。 儘管有些人有疑問（仍然如此！），你可以在 1C 中用英語寫作。
來自9個國家（菲律賓、台灣、韓國、芬蘭、摩洛哥、俄羅斯、哈薩克斯坦、馬來西亞）的8名小伙子在本站參加了比賽。
評審團是一個專家團隊，由來自菲律賓的專家喬伊·馬南薩拉 (Joey Manansala) 領導。
來自芬蘭、阿聯酋、哥斯達黎加、韓國、俄羅斯和台灣的專家出席了會議。
另外，我們注意到來自俄羅斯（Pavkin Kirill、Sultanova Aigul）和哈薩克斯坦（Vitovsky Ludwig）的參賽者決定使用 1C:Enterprise 平台作為競賽的一部分。 其餘參與者使用 .NET 進行桌面開發，使用 Android Studio 進行移動開發。 有趣的是，選擇1C的參與者都很年輕（基里爾是斯塔夫羅波爾一所學校的學生，今年進入11年級，艾古爾是韃靼斯坦喀山的大學生），而他們的對手則經驗豐富得多（例如，一位來自韓國的參賽者——2013年萊比錫世界技能大賽冠軍；所有人都有參加世界技能大賽的經驗和多年的行業專業經驗）。
考慮到參賽者在比賽期間使用了各種現代技術，我們有機會在真實的戰鬥條件下測試 1C:Enterprise 平台，以比較在其幫助下獲得的解決方案的質量以及使用其實現的開發速度。
另外，我們注意到，在特殊的商業 IT 軟件解決方案沙盒平台框架內，參與者完成了與主要的商業 IT 軟件解決方案平台參與者相同的任務。
該任務本身是一項自動化特定業務的複雜任務；今年的業務示例是虛構的 KazanNeft 公司。
傳說
喀山石油公司是韃靼斯坦共和國最大的石油企業之一，是該領域的全國市場參與者和國際知名品牌。 該公司總部位於喀山（俄羅斯），專門從事石油、石油產品和天然氣的現場勘探、生產、生產、精煉、運輸以及銷售和分銷。
由於公司正在俄羅斯各地實施快速擴張和設立新辦事處的戰略，公司管理層決定引入新的業務自動化軟件，旨在維護和管理某些運營。
冠軍條件
任務以模塊（會話）的形式分配給參與者，並要求在有限的時間內完成。 總共有7個模塊。 三個在桌面上解決問題的課程 – 每個 2.5 小時。 三個會話 - 客戶端-服務器開發，其中客戶端是移動應用程序，客戶端和服務器之間的通信通過 WEB-API 進行。 這花了 3.5 小時。 最後一節課——現有軟件的逆向工程任務，2.5 小時。 作為逆向工程的一部分，參與者必鬚根據提供給他們的信息，設計應用程序數據庫的結構（通過構建 ER 圖），分析使用系統的場景（通過構建用例圖），以及根據所提供的功能需求，開發設計軟件解決方案的界面。
使用的主要開發平台是.NET（C#）和Java（包括用於移動開發的Android Studio）。 實驗性 SandBox 使用 .NET、Java 和 1C:Enterprise 版本 8.3.13。
在每次會議結束時，專家們都會評估結果——一個現成的可行項目，可以實施會議開始時設定的任務。
任務的特殊性在於它們的“活力”——要求多且時間有限。 大多數問題不是特殊的奧林匹克問題，而是非常接近實際的工業問題 - 專家們每天都會遇到它們。 但任務很多，時間也有限。 參與者必須解決最多數量的問題，從而為企業帶來最大的利益。 從算法的角度來看，複雜的任務比基本的任務更重要，這根本不是事實。 例如，對於企業來說，創建一個由三個表組成的功能齊全的會計系統比一個具有復雜算法的漂亮報表更重要，如果沒有這些表，這是完全沒有必要的。
我們請比賽的獲勝者、來自俄羅斯的參賽者基里爾·帕夫金 (Kirill Pavkin) 告訴我們更多有關任務是什麼以及他如何解決問題的信息。
以下是該任務的描述，基里爾自己關於他如何解決該任務的故事。 我們還請 1C 員工、商業沙箱 IT 解決方案專家之一 Vitaly Rybalka 對 Kirill 的解決方案發表評論。
作為任務的一部分，有必要自動化幾種類型用戶的活動：
- 負責公司資產的會計核算
- 負責公司資產的計劃外維修和計劃維護
- 零部件和消耗品採購經理
- 石油勘探和石油生產部門
- 高層管理人員需要分析報告
第一節
從資產（例如車隊）的角度來看，有必要實現其會計（建立新資產、編輯現有資產）、快速搜索和各種過濾器以顯示信息、在公司部門之間移動資產以及資產組本身。 保留此類運動的歷史記錄並在將來提供分析。 資產核算主要針對移動用戶群體進行。
西里爾：一個有趣的子任務是資產列表中按鈕的實現。 為了解決這個問題，我們使用了動態列表：我們編寫任意請求，當在服務器上接收數據時，我們將圖像庫中圖像的導航鏈接分配到所需字段。
按照慣例，照片可以通過兩種方式附加到資產：拍攝照片（多媒體）和從圖庫中選擇（文件選擇對話框）。
當屏幕旋轉時，一些形狀需要重新繪製：
當更改屏幕參數時，我們會更改按鈕組的可見性。
有趣但簡單的任務包括動態列表中的過濾器、在兩個字段（編號和名稱）中搜索以及生成資產序列號。
專家評論：從1C:Enterprise平台上的解決方案來看，任務是相當明確的。 除了實際創建移動應用程序之外，還必須負責將數據從 DBMS“服務器”（桌面上的 MS SQL）傳輸到移動應用程序並返回。 為此，在桌面“代理應用程序”中使用了外部數據源和http服務的機制。 對於移動平臺本身來說，在動態列表中顯示圖片增加了複雜性。
第一節
有必要對公司資產建立修復管理。 作為這項任務的一部分，有必要維護一份維修請求清單（按部門和小組），考慮維修緊急程度的優先級，根據優先級規劃維修時間表，訂購必要的組件並採取措施考慮到現有的。 一個有趣的子任務是某些組件有過期日期； 如果已經為給定資產訂購了零件並且其截止日期尚未到期，則對於該資產無需再次購買相同的零件。 修復界面是為該公司軟件的桌面組件開發的。
還需要為兩個角色創建一個重要的授權表單：負責人和服務經理。 特殊之處在於，授權後您必須自動選擇其中一個角色。
負責人可用的清單表格如下：
西里爾：此處只能突出顯示待處理的服務請求。 通過動態列表中的條件格式來解決。
通過單擊屏幕底部的按鈕，用戶可以轉到以下表單：
從 1C 的角度來看，這種形式並不復雜。
服務經理可用的表格如下：
該表格按優先級和請求日期排序。 通過單擊下面的按鈕，用戶可以轉到所選請求的表單：
除了萬無一失之外，該表格還建議實施一份維修備件清單。 該子任務很有趣，因為零件有到期日期。 這意味著，如果該資產已經發生緊急情況並且為其訂購了零件，且其有效期尚未過期，則可以重複使用。 這應該顯示給用戶。
專家評論：基里爾本人在這裡正確地放置了重音。 從1C:Enterprise平台上的實現來看，並沒有什麼極其複雜的地方。 需要仔細分析備件的核算和使用條件以及整個任務的有效實施。 此外，有必要正確記錄服務請求。 主要困難只是2.5小時的時間壓力。
此外，與移動開發一樣，參與者必須能夠從外部 DBMS (MS SQL) 獲取數據。
第一節
對於維護（維護），建議實施長期規劃服務。 這裡的一個有趣的功能是要求根據時間創建資產維護計劃 - 例如，每兩個月的第三天。 同樣，根據一些定量指標 - 例如，根據汽車的里程表（每 3 公里更換一次機油，每 5000 公里更換一次輪胎）。 維護經理應該收到一個方便的移動應用程序，該應用程序可以動態顯示指定時間段內過期、當前和已完成的維護列表。 此外，每種類型的維護都必鬚根據特別商定的規則塗上顏色。 移動應用程序應該確保創建新的維護計劃並標記已直接在車間完成的維護計劃，並在服務器上及時更新此信息。
西里爾：有兩種類型的修復：基於時間的修復和基於運行的修復。 每個內部都允許有變化。 例如，按照計劃，每週五、13日或每20,000萬公里進行一次維修。 如果任務右側有復選標記，則任務被視為已完成。
提供了對列表中的任務進行排序的條件。 此外，每行應根據情況以顏色突出顯示。
通過單擊下面的按鈕，您可以創建新的服務計劃：
根據所選圖表類型顯示所需字段。 如果我們選擇了每週時間表，那麼我們將顯示兩個字段：週數和星期幾。 例如，每三週的星期二。
專家評論：與之前 1C:Enterprise 平台上的移動開發一樣，這裡的任務全局分為 2 個部分 - 通過 web-api 與“服務器”通信，以及通過條件設計和過濾（選擇）動態列表的有效顯示數據。 此外，執行按期間和定量指標核算維修的要求也很有趣。
第一節
對於零部件和消耗品，有必要考慮庫存、計劃費用和未來採購。 另外，這裡出現了批量核算，但並不是針對所有貨物。 所有這些都必須在多個倉庫內進行管理，包括收貨、支出和移動。 根據任務條款，在處理當前庫存時，必須確保控制餘額並避免衝突。 採購經理使用該軟件的桌面版本工作。
主要形式如下圖所示：
西里爾：除了根據條件排序之外，還建議給予用戶隨機排序的能力。 在 1C 上你甚至不需要考慮它。 對於發票，零件數量字段應以綠色突出顯示。
在這次會議中，他們被要求控制倉庫中的剩餘貨物。 因此，當您嘗試刪除發票時，應該會顯示相應的消息。 這裡我們記住平台專家考試。 發票格式如下：
每個零件都有一個特徵，決定是否應將其分配到特定批次。 對於此類備件，必須在所有文件中註明批號。 這是監測零件殘留物時的附加測量。 它們還可以在倉庫之間移動：
該表格與前一個表格的不同之處僅在於，您需要指示將進行交貨的倉庫，而不是客戶。 選擇零件後，會自動編譯批次的選擇列表。 用戶可以生成備件餘額報告：
在這裡我們可以查看所選倉庫中的剩餘貨物。 倉庫右側的複選框允許您配置過濾和排序。 該列表沒有對需要的部件進行明確的批次劃分。 可以使用右側的導航鏈接查看所選備件每個批次號的餘額。
專家評論：在這個會話（模塊）中，批量記賬首次出現。 參與者不僅要對消耗品和貨物進行清點，還要按批次進行清點。 總的來說，該任務非常適合 1C:Enterprise 平台 - 但一切都必須從頭開始開發並在 2.5 小時內完成。
第一節
在第五節課中，我們被分配了井管理的職能。 對於勘探團體來說，有必要創建一個移動應用程序來說明石油或天然氣生產井的情況。 在這裡，需要從服務器接收當前井的列表，並按層（土壤、沙子、石頭、石油）以圖形方式顯示所選井，同時考慮到每層的深度。 此外，應用程序必須允許更新有關井的信息並添加新井。 對於此應用程序，客戶在離線和在線模式下設置特殊的操作條件（控制與服務器的通信） - 每 5 秒檢查一次與服務器的通信，並根據服務器的可用性更改應用程序的功能。
西里爾：選擇一口井時，會顯示一個條形圖，突出顯示直至石油或天然氣礦床的各層。 對於每個圖層，其名稱、顏色和出現範圍都被存儲。 由於設計特點，平台內置的圖表沒有幫助，但電子表格文檔可以完美地應對任務。 可以創建和修改井：
除了多重萬無一失的防護之外，這個形態並沒有什麼有趣的地方。
接下來，建議控制與服務器的連接。 我們嘗試每 5 秒連接一次。 如果它不起作用，那麼我們會限制應用程序的功能並顯示一條消息。
專家評論：本次會議的任務很有趣，主要是因為它的圖形功能。 使用 1C:Enterprise 平台的參與者以兩種不同的方式解決了這個問題 - 一些使用圖表機制，另一些使用電子表格文檔。 每種方法都有其優點和缺點。 作為世界技能錦標賽決策的一部分，時間是關鍵（再次記住時間限制）。 另一個有趣的任務是每 5 秒對服務器執行 ping 操作，並根據服務器的可用性或不可用性更改移動應用程序的行為。
第一節
建議為高層管理人員創建一個工作區——Dashboard。 在一個屏幕上需要以圖形和表格的形式顯示公司在指定時期內的總體績效指標。 主要形式是成本報告：
除了儀表板之外，還需要使用先進先出/後進先出/“最便宜的先”核銷方法來實施資產維修備件的分配。
在分發過程中，考慮了批量記賬、餘額控制和針對未經授權的用戶操作的保護（“傻瓜保護”）。
西里爾：為了解決這個問題，使用了帶有軟件生成列的值表，因為它們可以有任意數量：
- 第一個表負責按月劃分部門的總成本。 最不盈利和最盈利的部門分別以紅色和綠色突出顯示。
- 第二個表顯示了每個月最昂貴和最常用的部件。 如果有多個部分符合條件，則應將它們顯示在一個單元格中，並用逗號分隔。
- 最昂貴的資產（就備件成本而言）顯示在第三個表的第一行中。 第二行顯示上述資產所屬的部門。 如果有兩個最昂貴的資產具有相同的成本，那麼它們應該顯示在同一個單元格中，並用逗號分隔。
這些圖表是使用平台的內置機制顯示的，並使用查詢以編程方式填充。
還建議實施對多種語言的支持。 該程序加載帶有界面元素本地化的 XML 文件，並且在下拉列表中選擇語言時應重新繪製表單。
當您單擊屏幕左下角的按鈕時，將打開庫存管理表單：
在這種形式下，我們終於開始花費零件進行維修。 在這裡，我們首先找到修復資產所需的零件。 根據所選字段和分配方法（先進先出、後進先出或最低價格），將顯示找到的匹配項或顯示一條消息（如果沒有匹配項）。 然後，您可以將零件標記為用於修復該資產。 餘額控制與當前會話相關。 如果我們已經分配了詳細信息，那麼就無法再找到它們。
專家評論: 非常有趣的會議。 它充分利用了 1C:Enterprise 平台的功能 - 這裡可以處理累積寄存器的虛擬表，以及處理表單元素（首先是表格，其次是標題）和圖表的編程工作。 甚至在分析庫存、損益分析等時採用後進先出/先進先出法。
第一節
在任務（第 7 節）結束時，客戶提供了用於項目活動的軟件（exe 文件）以及使用該軟件的簡短視頻。 有必要進行逆向工程，並在此基礎上創建兩個圖：用例圖和實體關係圖。 此外，還對未來創建軟件提出了一些要求——需要根據這些要求創建界面佈局。
根據比賽條件，只需要MS Visio即可創建圖表。
專家評論：在本次會議中，1C:Enterprise 平台的功能實際上沒有被使用。 比賽條件圖表是在 MS Visio 中創建的。 但是可以在空的 1C 信息庫中創建界面原型。
一般說明
在每個會話開始時，建議使用 SQL 腳本導入數據。 與 C# 相比，這是使用 1C 的主要缺點，因為我們至少花了半個小時將數據提取到外部數據源、創建我們自己的表以及將行從外部源移動到我們的表中。 剩下的只需單擊 Microsoft SQL Studio 中的“執行”按鈕即可。
出於顯而易見的原因，在移動設備上存儲數據並不是一個好主意。 因此，在移動會話期間，我們創建了一個服務器庫。 他們在那裡存儲數據並通過 http 服務提供對其的訪問。
專家評論：1C/非1C 平衡在這裡很有趣- 而1C：企業程序員花費大量時間連接到外部DBMS（Kirill 在上面單獨提到了這一點），C#/Java（用於移動開發的Android Studio）開發人員將時間花在其他領域 -接口，編寫更多代碼。 因此，每次會議的結果都是不可預測的，並且對所有專家來說都非常有趣。 而這種陰謀一直持續到最後——看看最終的勝者表和積分分配就知道了。
基里爾講完了這個故事:)
總之，應該記住，執行者不需要“僅僅根據技術規範對任務進行編程”——他必須分析任務，選擇用於實現子任務的塊，設計它們並決定他到底要做什麼能夠在極短的分配時間內實施。 在這四天裡，我都必須在嚴重的時間壓力下行動，經常從頭開始每個後續的訓練。 即使是具有多年行業經驗的成年專家也很難在規定時間內 4% 完成會議指定的任務。
所採用的評估體系值得特別提及。
對於每個會話，任務作者都會開發一個複雜的標準系統，包括檢查功能、正確操作、應用程序界面的要求，甚至遵循他們正在為其開發解決方案的公司專門提供給參與者的風格指南。
評估標準非常細化——會話任務的總成本為幾十分，滿足某些標準可以為參與者增加十分之一分。 這實現了對每位參賽者成績的極高且客觀的評估。
Результаты
最終的結果令人印象深刻。
經過一番苦戰，使用1C:Enterprise平台的來自俄羅斯的基里爾·帕夫金(Kirill Pavkin)獲勝。 基里爾今年17歲，來自斯塔夫羅波爾。
從字面上看，獲勝者與追趕者之間僅相差十分之一分。 第二名是來自台灣的選手。 前六名結果的總表如下所示：
當然，基里爾獲勝要歸功於他的才華、知識和技能。
但我們注意到，使用1C:Enterprise平台作為工具的三位參與者全部進入了前五名——這無條件證實了1C:Enterprise技術的世界水平。
比賽結果公佈後，獲獎者在喀山博覽會媒體中心接受了頒獎；他們獲得了純金牌（根據他們的名次）和現金獎勵。 這些人還獲得了在 1C 實習的證書。
來源： www.habr.com