普遍的な勤務スケジュールを作成するロジック

従業員のスケジュールは、CRMシステムの不可欠な部分です。 ただし、クライアントのビジネスの詳細に応じて、非常に異なる場合があります。 クリニックでは、これらは患者の受付スケジュール、通信ではクライアント接続スケジュール、学校ではクラススケジュールです。 それらはすべて構造と本質が異なります。 異なるキャップ、異なるフィールドセット、異なるグリッドがあります。

当社のERPプラットフォームは、あらゆるニッチ構成の迅速な開発に焦点を当てており、すべてを便利に行う方法を考えました。 まずは自分のために。 そのため、特定のニッチのスケジュールを作成するための作業は、工数だけで済みます。

それ以前は、グラフィックはphpで開発されたものでした。 しかし、神！ カール！ ニッチソリューションの新しいスケジュールが必要になるたびに、このコードをコピーして処理する必要があります。 チャートの個性は、中央の変更を許可しませんでした。 そして一般的に、クライアントが独立して設定できるという点で、クラウドプラットフォームの概念を損ないました。

その結果、作業スケジュールについて次の要件を作成しました。

1. 構成可能性
   Webインターフェースから完全に構成可能でなければなりません。
2. 可変ピッチ
   可変グリッドピッチが必要です。
   あるクリニックでは、予約スケジュールは患者ごとに30分、別のクリニックでは3時間目になります。
3. カスタム帽子
   グラフのヘッダーは一意、つまり 医師、施設、教師、チームなどのセットにすることができます。 一般に、クライアントがシステムに持っているものからのもの。 私たちが想像できないものからでさえ。
4. チャートレコード-任意のフィールドセット
   システムにある任意の情報から、フィールドのセットを任意に設定できます。 また、エントリはヘッダーに従って配置されます。
5. CRUD
   任意のフィールドセットにもかかわらず、チャートエントリはCRUD（作成、読み取り、更新、削除）でなければなりません。 それだけでなく、手順を使用して複雑な相互作用を整理します 。
   
   

   例：タスクのスケジュールがあります。
   グラフの記録では、誰が仕事をどこで行うかなどを示します。 +タスクに関するいくつかのデータ（たとえば、番号と名前）。
   スケジュールを記録するための追加データは1つのテーブルに保存され、タスクデータは別のテーブルに保存されます。
   作成時に、タスク番号が表示され、誰がどこで、どこで実行するかが示されます。 また、データは2つのテーブルから表示されます。
   編集できるのは録画スケジュールのデータのみですが、タスクのデータは編集できません。
   スケジュールエントリは削除する必要がありますが、タスクは削除しないでください。
   このエントリで何かを行ったログを保持する必要があります。 なぜなら 削除でき、必ずしもスケジュールに表示されるとは限らないので、何らかの方法でログにアクセスする必要があります。 彼らはタスク自体をリードするのがより論理的です、すなわち create-modification-deletionを別のテーブルに書き込み、タスクに表示する必要があります。
   このようなことは、ストアドプロシージャによってのみ解決できるため、単純な状況と複雑な状況を解決できます。

6. フィールドはリストにすることができます。
   もちろん、フィールドは単なるテキストである必要はありません。 システム内の一部のデータのポップアップリストにすることもできます。
7. フィールドはリンクにすることができます
   たとえば、タスクの作業スケジュールからタスク自体にアクセスできる場合に便利です。
8. 非表示フィールド
   レコードに多くのフィールドがある場合は、知覚しやすいようにフィールドの一部を最小化することは理にかなっています。
9. トリガー
   録音で何が起こっているかに対するシステムの反応を調整する必要があります。 これは、トリガーを使用して行うのが最も便利です。
   
   

   たとえば、ユーザーがレコードに対して実行されたアクションに何らかのログを書き込む必要がある場合、従業員に通知を送信する場合、またはsmsクライアントを送信する場合、または想定できないことを実行する場合もあります。

10. クロスレコード
    クロスレコードは、さまざまなグラフを1つのグラフに結合したレコードです。 または、エントリが現在のグラフに表示されたときの他のグラフのエントリの外観。
    
    

    たとえば、アプリケーションやタスクなど、同じチームが作業を実行する状況があります。 つまり さまざまなスケジュールのタスクが表示される特定の一般的なスケジュールに慣れるでしょう。
    
    または、従業員が参加するすべてのスケジュールのエントリを含む従業員の個人的なスケジュールが必要です。
    このようなタスクは、標準のタスクよりも少し複雑ですが、トリガーとデータ取得手順を使用して完全に解決できます。 つまり 条項9および条項5によって。
    
    a）ユーザーがいる場合、ユーザーの個人的なスケジュールにエントリを作成する必要なスケジュールの記録にトリガーが作成されます（したがって、変更の場合、変更の場合、削除の場合）
    b）必要なデータを含む追加のフィールドがユーザーのグラフに作成され、これらの識別子を使用して他のグラフのテーブルからデータをプルする記録出力手順が開発されます。
    
    そのようなタスクは逆の方法で解決できます。個人従業員のスケジュールを作成する場合、よりcな手順が実行され、個人テーブルからだけでなく、特定の日に従業員がいる他のスケジュールのテーブルからデータが出力されます この設計に基づいたこのようなソリューションも可能です。

11. 時間オーバーレイ
    システムは、レコードの交差を時間内に正しく表示する必要があります。これは、レコードが相互にぶつかり、下位層を読み取る機会すら存在しないほとんどのシステムとは異なります。
    
    
    このように、それは悲しいです...

    
    
12. 報告書
    そのため、スケジュールに従ってレポートを作成することができました。 データストレージシステムは、レポートコンフィギュレーターで取得できるように編成する必要があります。
    

    たとえば、どの従業員がタスクにどのくらいの時間を費やしたかというレポートを作成する必要がありました。 レポートコンフィギュレーターに移動し、目的のスケジュールのレコードデータが保存されているテーブルを選択し、グラフのデータに従って標準コンフィギュレーターを使用してレポートを作成します。
    

13. 埋め込み性
    グラフは、任意のページのどこにでも簡単に埋め込むことができる必要があります。 テキストフィールドまたはボタンと同じ標準入力要素である必要があります。
    幸いなことに、複雑な標準要素の開発の経験がありました。 特に、標準のコメント要素、ファイル申請フォーム、連絡フォーム、表があります。 それらはすべて、通常の要素としてワンクリックで追加され、簡単に構成できます。
14. アクセスとセキュリティ
    スケジュール全体へのアクセス権は、一般的な権利システムによって規制される必要があり、スケジュール内では、レコードへのアクセス権は、スケジュール設定によって規制される必要があります。
    

    たとえば、著者のみが自分の投稿、グループ、またはユニットを編集できることを示します。

15. 設定が簡単
    そしてもちろん、新しいスケジュールの作成と構成は迅速に行う必要があり、問題は発生しません。 特に、私たちにとっては、典型的なケース（もちろん、それが起こることは明らかですが、非常に複雑です）の場合、この作業は工数で済むはずです。

これらの要件をエレガントに実装できたと信じており、この記事ではその方法を説明します。

現時点では、同様の汎用性のあるグラフを備えたシステムは知りません（ご存知の場合はコメントに書いてください。見た目は面白いです）

一般的なグラフ構成図は次のようになります（厳密に判断しないで、自分で描きました）。 ここでは各要素が必要です。余分な要素はありません。


すべての作業は、レコードに含めるデータセットを理解し、このスケジュール用にデータベースにテーブルを作成することから始まります。


たとえば、通信会社のタスクの作業スケジュールについては、いつ作業を実行するか、どのタスク、どのオブジェクト、どのグループのエンジニアがこの作業を実行するかを知ることが重要です。

したがって、レコードレコードIDを持つこのすべての情報+サービスフィールドがあるテーブルを作成します。 （PS：ブラウザーからクラウドで直接編集できるテーブル）。



これは単純なケースですが、より多くのフィールドまたは複数のテーブルがある場合、はるかに複雑になる可能性があります。

それだけです、ストレージ構造が形成され、今、スケジュールはそれをどのように扱うかを知る必要があります。 各エントリは、追加、表示、変更、および削除できます。


なぜなら データセットとストレージ構造は任意である可能性があり、この構造はストアドプロシージャを介して処理する必要があります。


まず、プロシージャを作成する必要があります。 この例では、ケースは単純であり、「標準手順の作成」機能を使用して、1つのボタンでコンフィギュレーターに作成できます。 この表に従って、システムはそれ自体で、作成、変更、削除、およびさまざまな結論のための手順を作成します。

たとえば、自動作成されたアップロード手順のフラグメントは次のようになります



すべての手順は、Webインターフェースから直接編集されます。 コンパイルロジックはPL-SQLに似ています。

何かが複雑な場合、これらの手順はストレージ構造に応じて編集でき、さまざまな条件、ループ、選択、更新、挿入などを設定できます。 一般に、処理構造を描画します。

各アクションのスケジュールは、このアクションを担当するプロシージャを示しています。


「組み込み」スケジュール設定

ただし、構成できるのみで構成を変更できない「有線」設定がまだあります。 これは単に必要ではありません。

-日時座標は、あらゆるレコードの不可欠なプロパティです
-システム内のグラフの場所。 これは、インターフェースの組み込みエディターを使用して編集され、グラフ自体からこれを行う必要はありません。
-ユーザーがいた場所のメモリ-このプロパティを直接設定する必要はありません。



設定では、ステップ（たとえば、20分または30のグリッド）および勤務時間の範囲（たとえば、8から20）も指定できます。

たとえば、すべての従業員が標準的な作業日に8時間働いている場合、夜間を表示することは意味がありません。

ステップ-チャートグリッドを定義します。 たとえば、あるクリニックでは20分間、別の15では3番目の30で医師の予約ネットワークがある場合があります。これはすべて設定可能です。

ただし、これは、グリッドの外部で記録を行うことができないという意味ではありません。 任意のエントリを作成できますが、グリッド内に表示されます。

5、10、15、30、60分のステップ範囲を設定できます。

レコード出力

プロシージャを作成して指定するだけでは不十分です。 スケジュールがその部分でどのように動作するかを理解することが必要です。


帽子

最も重要なことは、チャートの見出しを示すことです。 プロシージャのどの出力フィールドをヘッダーにするか。

教育機関でクラススケジュールを作成するロジックを検討してください。 レコードにTeacher-Groupセットがあるとします。

ここで、教師の見出しを作成できます。スケジュールは次のように形成されます。



ただし、グループごとに次のようにできます。


ただし、一般に2つの異なるグラフを作成して表示することができます。必要に応じて、ユーザーが選択します。 この場合、同じデータ、同じ手順が使用されます。 あるチャートの変更は別のチャートでも変更されます。

しかし、一般的に、選択は便宜の問題に依存します。 帽子は基本的に変化の少ない情報でなければなりません。 一定数のオブジェクトを提供する場合-これらはオブジェクトでなければなりません。 固定数のグループがある場合は、そうです。

帽子で面白いことをすることができます。 たとえば、タスクステータスをヘッダーとして指定した場合、タスクのステータスが変更されると、グラフのタスクレコードは対応するステータス自体にジャンプします。 つまり 実際、ほとんどかんばんボードをここで行うことができます。 もの。 プロシージャを介して記録データをシステム内のライブ情報にバインドすると、グラフ内でもデータが表示されます。 非常に柔軟なメカニズム。

また、手順でフィルタリング条件を指定する場合、グラフでは、任意のフィルターを考慮してこれらの上限を生成できます。

出力しないもの

レコードに表示するものとしないものを指定することもできます。 たとえば、手順では、バンドルの一部のサービス識別子を結果として表示できます。 ユーザーにとって重要ではないこの情報は、結論で無視できます。

隠すもの

また、表示することもできますが、猫に最小化します。 それほど重要ではないが、時には必要な情報。 たとえば、このレコードの作成者と作成者は、何らかのショーダウンの場合にのみ必要であり、運用作業には必要ありません。

参照資料

一部のフィールドをリンクにできる場合にも非常に便利です。

たとえば、タスクのスケジュールを作成する場合、その番号をクリックしてタスク自体にアクセスしてください。

コンフィギュレーターには、標準のリンクメカニズムがあります。 そこで作成して、グラフのフィールドに関連付けることができます。 すべてが機能します。

役職

もちろん、フィールドは何とか呼ぶ必要があります。 デフォルトでは、システムは手順フィールドから名前を取得しますが、認識に関して常に正しいとは限りません。 したがって、代替名を入力する必要がある場合があります。

たとえば、上記のすべてはこのように見えます。 この手順のフィールドの反対側がチェックされます。



レコードの出力は次のようになります。



新しいエントリを追加する

新しいレコードを追加するためのフィールドは、追加手順によって決定する必要があります。 プロシージャの各入力パラメータに情報を提供する必要があります。

しかし、コツがあります。 フィールドはテキストだけでなく、リストにもできます。

タスク、グループ、オブジェクトがあるテレコムの例を見てみましょう。 ユーザーにオブジェクトの識別子の検索と駆動を強制しません。 必要な情報を含むポップアップリストが必要です。 そして、どこで入手できますか？

これを行うには、プロシージャの入力フィールドで別のプロシージャをプルする必要があります。これにより、たとえば実際のタスクのリストや必要なオブジェクトのリストなどが提供されます。 同時に、テーブルのフィールドを指定することはできません。なぜなら、 複雑なフィルターが存在する場合があります。 同じタスクのうち10,000個がすでにシステムにスタンプされている場合がありますが、現在は100個のトピックタスクのリストが表示されているはずです。



一般に、別の手順のフィールド全体にひきつる手順。

実際、それは怖いだけです。 これらは十分に自動化されており、1つのボタンで標準ディレクトリに従った手順が取得されます。 グループ、タスク、アプリケーションなどのさまざまなリストの手順 さまざまなCRMモジュールの操作のために長い間実装されていました。 それらを選択するだけです。 同様の機能を持つプロシージャが既にある場合は、コピーして編集します。

追加されたフィールドのどれがヘッダーになるかを示すことも必要です。 編集システムでこれが必要になります。

私たちにとってはこのように見えます：



レコードを編集

ここではさらに面白いです。 付録のようにリスト内のすべてのフィールドを表示するだけでは不十分です。 これらのリストでは、現在の位置（選択済み）を選択する必要があります。 編集中です。

これを行うには、作成フィールドを出力フィールドに関連付ける必要があります。 また、リストボックスの場合は、出力から飛び降りるだけでなく、この情報の識別子を知ることもできます。

つまり ここで必要です：

a）編集手順を示す
b）フィールドを追加フィールドに関連付けます
c）現在のデータをリストに入れるために、フィールドをレコードデータの出力のフィールドに関連付ける

ここに示す他の機能はありません。 既に出力と追加を構成しています。

編集ウィンドウが表示されると、システムは各フィールドに必要なプロシージャを呼び出し、データを受信し、それをレコードの出力からのデータと比較し、リストに選択して、単純なフィールドに現在の値を挿入します。

こんな感じです



レコードを削除

取り外しが最も簡単です。 1つの入力パラメーターを使用した削除手順は、チャートのレコードIDで示されます。

レコードの追加/変更/削除時のイベント処理。 トリガー クロスレコード。

チャートにエントリを追加/変更するだけでは十分ではありません。 イベントを管理する必要があります。 これにより、構成の範囲が無制限になります。

イベントの管理は実際には非常に簡単です。 結局のところ、グラフレコードのデータが格納されるテーブルが既にあります。 これらのテーブルには、任意の複雑なトリガーを設定できます。 クラウドコンフィギュレーターを使用すると、これを簡単に行うことができます。

たとえば、記録で何をしたか、ログが必要でした。 すべてがシンプルです。 ログ用のテーブルが作成され、ログを含むテーブルに変更データを書き込むトリガーがチャートテーブルに配置されます。

また、これにより、クロスレコーディングが可能になります。 たとえば、この例でグループにタスクが設定されている場合、このグループのすべての参加者を識別し、個人レコードにこのレコードの2倍を入れることができます。 この場合、個人スケジュールを入力するとは、個人スケジュールのデータテーブルにエントリを作成することを意味します。 これは、このシステムのグラフでもあり、異なる構成でのみ別の場所に表示されます。 このエントリが表示されます。

または、グループユーザーに通知を送信する必要があります。 または、クライアントにSMSを送信し、そのようなタスクやそのようなタスクを時々実行するために彼に来ることを伝えます。 これを行うには、通知テーブルまたはSMSにエントリを作成するトリガーを作成します。

報告書

グラフレポートも必要であり、そのような構造で、それらを行うことができます。

たとえば、前月に従業員が外出していた期間についてレポートを作成する必要がありました。 レポートコンフィギュレーターに移動し、グラフエントリが保存されている目的のテーブルを選択し、必要なフィルターと集計関数を設定します-そして、レポートの準備ができました。

グラフデータの他の用途

グラフデータは、高度なシステムコンフィギュレーターでどこでも使用できます。 たとえば、タスクでは、[チャート]タブを簡単に作成でき、1つの簡単な手順で、このタスクの実行期間と実行者に関する情報を表示できました。



時間オーバーレイ

彼らは起こります。 そして、録音が互いにぶつかり、目的のエントリを読み取れないようにすることほど悪くはありません。 この問題も解決されました。 重複エントリのシステムは、自動的に近くに配置します。 この場合、単純なhtmlのみが使用され、テーブル構造だけがこれに必要な方法で構築されます。 システムはあらゆる深さに注意を払いますが、3つ以上のエントリはまれです。

もちろん、時間が重複する場合は、おそらく何かが計画されていません。 人が同時に2つの場所にいることはできませんが、そのような状況でも正しく表示する必要があります。



アクセスとセキュリティ

アクセスは2つのレベルに分かれています。 システムおよびパーソナルグラフィックス。 システムは、ロールエディタおよびインターフェイスコンフィギュレータで指定されたデフォルトの権限によって全体として定義されます。 たとえば、このページセル（または上記で継承したタブ、ページ、メニュー）の読み取りアクセスが拒否された場合、ユーザーロールのこの領域に読み取り権限を割り当てるまで、ユーザーはインターフェイスの表示レベルでこのグラフを見ることができません。

次に、スケジュールの内部権限があります。 彼らはすることができます

1）編集

-著者のみ
-著者のグループのみ（レコードの著者がメンバーであるグループに含まれるすべての従業員）
-著者の部門のみ（ストックによると、すべての従業員は著者の部門に含まれます）

PS：ワーキンググループと人員配置は私たちと異なる場合があります。 たとえば、1つのユニットに複数のワーキンググループがある場合や、異なるユニットの従業員が同じグループにいる場合があります。 同じ従業員が同時に異なるグループに所属することもできます。 このシステムはすべて考慮されます。

2）取り外しも同様です。

-著者のみ
-グループのみ
-ユニットのみ

なぜ内部権限が必要なのですか？

これが個人的なスケジュールである場合、またはいくつかの機能がある場合は、作成者のみを置くのが理にかなっています。

しかし、シフトスタッフと、レコードを編集する必要があり、従業員が働いていない状況があります。 どうする 他のシフト従業員がこれらのレコードを使用できるように、グループまたはユニットによる編集のためにこのようなスケジュールを設定することは理にかなっています。

また、管理する権利を持つ役割をスケジュールに示すことができます。 この役割を持つ従業員は、グループおよびユニットに関係なく、編集および削除する権利を持ちます。

---

もちろん、使用方法を知っていれば、このようなクールなものがあり、人生を大幅に簡素化できます。 すぐに経験の浅い人は把握するのが難しい場合があります。 しかし、私たちはそのようなスケジュールを単純な形で立てる必要があります。それは約工数です。

さらに、最も深い構成機能と、システムの他の要素との対話の可能性も取得します。