オブジェクト別ドキュメント既定値

IFS のビジネスオブジェクトからドキュメントを作成するときは、ドキュメントに関する属性値を入力します。ドキュメント クラスはドキュメントがどのカテゴリに分類されるかを示し、フォーマットはドキュメントにチェックインされたファイルの形式を示し、言語コードはドキュメントが記述されている言語です。

これらの属性には既定値があり、任意のオブジェクトから作成されたドキュメントに対して一元的に設定されます。ユーザーがオブジェクトに新しいドキュメントを作成すると、これらの既定値は自動的に取得されます。

異なるタイプのビジネスオブジェクトに異なる既定値を設定するには、オブジェクト別ドキュメント既定値ページを使用する必要があります。ビジネスオブジェクトのキーやその他のフィールド値に基づいた既定値の制御もできます。

注釈:この機能のルールを設定するには、DEFINE SQL システム権限が付与されている必要があります。これは、ルールを作成するときに、ユーザーが実行する SQL を間接的に作成するためです。無効の SQL を作成するとルールが機能しなくなるため、作成しないようにする必要があります。

条件フィールドと属性フィールド

このページの機能を説明するために、フィールドは大まかに条件フィールドと属性フィールドの 2 つのカテゴリに分類できます。

条件フィールド

条件フィールドは、オブジェクトからドキュメントを作成するときに、ユーザーが入力する実際の属性と照合するために使用される式を定義するフィールドです。条件フィールドについては次のとおりです。

条件フィールドには、条件が式の形式で含まれています。式は、ルールがドキュメントおよびオブジェクトの属性に対してテストされるときに評価されます。

LU名およびキー参照フィールドの式には、英数字、空白、区切り文字を含む固定値、標準の SQL ワイルドカード (% および _)、またはその両方を組み合わせたものを指定できます。セミコロン (;) で区切られた複数の式も含められます。

オブジェクト条件フィールドの式には、有効な SQL 式を含めることができるため、とても柔軟で強力です。通常、オブジェクト上の特定のフィールドを固定値と照合するために使用されます。例えば、LU名が EquipmentFunctional に設定されている場合、オブジェクト条件フィールドにはmch_type = 'SYSTEM' のような式が含まれます。このような式は、Mch Type フィールドの値が SYSTEM である施設/設備オブジェクトのみに一致します。より高度な条件がサポートされており、AND や OR などの論理演算子や、ワイルドカード一致のための LIKE などの演算子も含まれています。SQL 関数もサポートされているため、次のような式を使用できます。SUBSTR(mch_type, 1, 1) = 'S' この式は、Mch Type フィールドが文字 S で始まるすべてのオブジェクトに一致します。

注釈:条件フィールドの LU名とキー参照には、値を入力する必要があります。設定しない場合は、システムがフィールドにワイルドカード % を設定します。オブジェクト条件の列フィールドの使用は任意で、空白のままにしておくこともできます。

どの条件フィールドを使用すべきですか?これは、オブジェクトと照合する際にどの程度詳細にするかによって異なります。ほとんどの場合、LU名を照合したいオブジェクトタイプに設定するだけで十分です。その他のケースでは、キー参照内のキーの 1 つと一致させたい場合や、オブジェクト上の任意のフィールド (カスタムフィールドを含む) と一致させたい場合、SQL 式を使用する場合などがあります。

属性フィールド

属性フィールドには、ドキュメントに設定する実際の既定値が保持されます。これらのフィールドには必ず値を入力する必要があります。属性フィールドについては次のとおりです。

上記の 2 つのカテゴリのフィールドとは別に、 コンフィギュレータ番号フィールドと 優先度フィールドがあります。前者は、特定のルールを参照するために使用できる単なる識別子/番号です。後者については以下で説明します。

グローバル変数プレースホルダーと列プレースホルダー

多くのルールの必要性を減らすために、ルール内のいくつかの式に動的な値を挿入することが可能です。これは、グローバル変数と列/フィールド値の 2 種類のプレースホルダーを使用して行われます。次のセクションでは、このオプション機能の使用方法について説明します。

グローバル変数プレースホルダー

オプションで、キー参照、オブジェクト条件、ドキュメント クラス フィールドで、グローバル変数プレースホルダーを使用できます。グローバル変数のプレースホルダーは、#NAME# という形式で、NAME はグローバル変数の名前です。現在、SITE と COMPANY という名前がサポートされており、これらはユーザーの既定サイトと既定会社を表します。

例:ドキュメント クラスフィールドの任意の場所に #SITE# を入力すると、ドキュメントクラスの最終的な既定値が設定される前に、ユーザーの既定サイトの値に置き換えられます。通常のテキストと組み合わせることができるため、ユーザーの既定サイトが 70 の場合、 SPEC#SITE# のような式は SPEC70 と評価されます。会社も同様に機能します。必要に応じて、複数のグローバル変数プレースホルダーを組み合わせることができます。

キー参照フィールドとオブジェクト条件フィールドでは同様に機能しますが、目的は異なります。ドキュメント クラスフィールドで使用する場合、グローバル変数はクラス値自体を生成するために使用されますが、キー参照フィールドとオブジェクト接続フィールドでは、一致するルールを見つけるための条件として使用されます。例えば、オブジェクト接続フィールドに次の式があるとします: #SITE# = 70このルールがテストされる前に、#SITE# はユーザーの既定サイトに置き換えられるため、テストに使用される結果の式は 70 = 70 (常に true) となり、オブジェクト条件に一致します。キー参照フィールドで使用すると、同じように動作します。

列プレースホルダー

列プレースホルダーは、接続されたオブジェクトからフィールド (列) の値にアクセスし、それをドキュメントクラスやその他のフィールドに適用する方法です。列プレースホルダーの構文は [COLUMN_NAME] です。列/フィールドは、LU名のソリューションマネージャ/オブジェクト接続で構成されているデータベース ビューに存在する必要があります。例: LU名 = EquipmentObject のルールの場合、ドキュメント クラスフィールドの任意の場所で [CONTRACT] (サイト) という式を使用できます。施設/設備のサイトが 10 であると仮定すると、式 [CONTRACT] は 10 に置き換えられます。グローバル変数プレースホルダーと同様に、列プレースホルダーは組み合わせて複数回使用できます。同じオブジェクトの異なる項目でも同時に使用でき、またグローバル変数のプレースホルダーと組み合わせることも可能です。

コンフィギュレータ間の優先度

定義されたルールが特定のオブジェクトに一致するかどうかを試す場合、計算されたスコアに従ってルールが試行されます。スコアが低いルールの方が優先度が高くなります。最も優先度の高い (スコアが最も低い) ルールは、優先度の低い (スコアが高い) ルールよりも先にテスト/適用されます。

ルールの優先度は、より具体的であるほど (スコアが低い) 高く、より一般的であるほど (スコアが高い) 低くなります。

ワイルドカードを含むルールの各条件フィールドは、より一般的 (より幅広いレコードに一致するため) になり、スコアが低くなり、優先順位が高くなります。フィールド値 (たとえば、PUMP) は非常に具体的で、低いスコアと高い優先度が与えられます。文字または数字をワイルドカードと組み合わせたフィールドは、文字と数字のみのフィールドよりも具体的ではありませんが、ワイルドカードのみのフィールドよりも具体的です。複数の式を含むフィールドは、式が 1 つだけのフィールドよりも優先順位が低くなります。

オブジェクト条件フィールドには非常に複雑な式を含めることができるため、これを使用するルールに対して正しいスコア/優先度の計算すはできません (式はとても具体的または一般的である場合があります)。オブジェクト条件が設定されている場合、スコアはとても低くなるように修正されます。

システムが認識するルール間の優先順位が同じ場合、または期待通りの優先順位でない場合、オプションの優先度フィールド (既定では非表示) を使用してスコアに影響を与え、優先順位を変更できます。システムが予想とは異なるルールを使用する場合は、優先順位を高くしたいルールの優先度フィールドに数値を入力します。値はルールのスコアに影響するため、値が低いほどルールの優先度が高くなります。

ルールのスコアまたは優先度をよりよく理解できるように、ページにデータが入力されると、ページ内のレコードは優先度が最も高いルールから順に並べ替えられます。このようにして、優先順位が期待どおりになるまで、優先度フィールドの値を調整できます。優先順位を変更する場合は、ページを再度入力して新しい順序を確認します。

例

ビジネスオブジェクトタイプに基づく

機能オブジェクトから作成されたドキュメントのドキュメント クラス属性に既定値 100 を設定する場合は、以下のようにルールを定義する必要があります。形式と言語を選択します。

上記で、ルール 1 はすでに説明しました。ルール 2 では、使用するドキュメントクラスの式で列プレースホルダーを使用します。設計オブジェクトの KEYA01 列/フィールドの値と固定テキスト SPEC を組み合わせて、既定値のドキュメントクラスを決定します。ルール 3 では、グローバル変数プレースホルダーを使用して、使用する既定値のドキュメントクラスを定義します。ユーザーの既定会社が 20 の場合、使用されるドキュメントクラス名は INVOICES_20 になります。

ビジネスオブジェクトのキーに基づく

また、ビジネスオブジェクトのキー値の 1 つに応じて異なる既定値を設定することも可能です。次の例では、特定のサイトの機能オブジェクトに対して特別なルールを定義しています。

上記のルールでは、サイト 20 の機能オブジェクトで作成されたドキュメントに対して、ドキュメント クラスを 100、フォーマットを A3 、言語コート゛を en に設定しています。

オブジェクト条件に基づく

ビジネスオブジェクトの任意のフィールドの値に応じて異なる既定値を設定する場合は、オブジェクト条件フィールドを使用できます。これは、キー参照内のキーと一致させることに似ていますが、任意のフィールド (カスタムフィールドも含む) と一致させられるため、より一般的です。また、あらゆる形式の SQL 式がサポートされています (WHERE 句で記述できるものほぼすべて)。以下にいくつか例を挙げます。

上記のルール 2 は、オブジェクト名が エリア という単語で始まる施設/設備オブジェクトに一致します。ルール 3 は、 仕様という名前のドキュメントフォルダに一致しますが、 プロジェクト X という名前の親フォルダを持つドキュメントフォルダには一致しません。ルール 4 は、秘密のプロジェクト X に接続されたドキュメントのルールです。ルール 5 には、ユーザーの既定サイトが 70 であるかどうかを確認するグローバル変数プレースホルダーが含まれています。

異なるルールに対する異なる優先順位の例

以下は、特定のドキュメント オブジェクト接続 (設備機能からドキュメントを作成するときに使用するドキュメントクラスおよびその他の情報) にすべて一致するルールのリストです。ただし、一部のルールは他のルールよりも具体的であり、システムがルールを選択するときにそのルールの優先順位が高くなります。

上記のルールを考慮すると、ルール 3 は最も一般的なルールであるため、優先順位は最も低くなります。ルール 4 は、LU名に固定値が設定されていてより具体的であるため、ルール3よりも優先順位が高くなります。ルール 5 は条件フィールドでとても具体的であるため優先度が最も高く、他のルールよりも先に試行されます。ルール 6 にはオブジェクト条件が設定されており、優先度も高くなっています (ただし、ルール 5 よりは低いです)。