優先度レベルの割り当て

シナリオ

たとえば、「企業」モジュールで複数の顧客およびそれぞれの関連する商談情報を管理しており、各企業の申告された商談に基づいて優先度レベルの割り当てプロセスを最適化したい場合を想定します。

解決方法

Biginシステム内で、数式に基づくロジックを実装することで、「Oportunidade」フィールドの内容に基づき優先度の自動割り当てが可能です。

「企業」モジュールには「Oportunidade」というフィールドがあり、営業担当者が各商談の内容を入力します。

自動化用数式

If(Contains(${Opportunity}, '既存'), '高い', '中')

ロジック

「企業」モジュールでは、Oportunidadeフィールドで、各企業に対するさまざまな商談の種類を示します。

• フィールド 'Oportunidade' に '既存' が含まれている場合、システムは優先度を '高い' に設定します。

• それ以外の場合、'既存' が含まれていなければ、優先度は '中' に設定されます。

この自動化プロセスにより、各企業に関連するオポチュニティに基づいて優先度の割り当てが簡素化され、フィールド 'Oportunidade' に入力された内容に応じて、'高い' または '中' として分類されることが保証されます。

手数料の計算

シナリオ

各企業に紐づく「Valor da Oportunidade」フィールドに基づいて手数料を計算する必要があります。

解決策

システム内で数式ベースのロジックをBiginに設定することで、「Valor da Oportunidade」フィールドの値に基づき手数料を自動計算できます。

「Empresas」モジュールには「Valor da Oportunidade」フィールドが用意されており、各案件の金額が記録されます。

自動化数式

If(${OpportunityAmount} < 10000, ${AnnualRevenue} * +10、-10。10, ${AnnualRevenue} * +10、-10。15)

ロジック

組織のコミッション計算は、「Valor da Oportunidade」フィールドに基づいて自動化されています。

• 金額が$10,000未満の場合、システムは年間収益の10%のコミッションを自動計算します。

• 金額が$10,000超の場合、コミッションは年間収益の15%となります。

この自動化されたプロセスにより、各企業の「Valor da Oportunidade」フィールドに入力された値に基づいて、正確かつシンプルなコミッション計算が保証されます。

ビジネス規模の分類

シナリオ

「Empresas」モジュールが「Valor da Oportunidade」フィールドに基づいて自動的にビジネス規模を分類するように設定したい場合。

解決方法

Biginシステム内で数式に基づくロジックを実装することで、「Valor da Oportunidade」フィールドを基準にビジネス規模を自動計算・分類できます。

「Empresas」モジュールには、「Valor da Oportunidade」フィールドがあり、各オポチュニティの金額を記録します。

自動化のための数式

If(${OpportunityAmount} > 1000000, 'Large 商談', 'Small 商談')

ロジック

自社では、「Empresas」モジュール内の各取引を、「Valor da Oportunidade」フィールドに入力された金額に基づき、「Large 商談」または「Small 商談」として分類します。

• 商談の金額が $1,000,000 を超える場合、システムは自動的に 'Large 商談' としてカテゴリ分けします。

• 金額が $1,000,000 以下の場合は 'Small 商談' に分類されます。

このシンプルなルールにより、システムは迅速かつ自動的に商談のカテゴリ分けができ、CRMシステム内でのプロセスが最適化されます。

請求可能な料金

シナリオ

実働時間に基づいて正確に請求可能な料金を計算する必要があります。

ソリューション

Bigin システム内で、作業時間、時間単価、および VAT の適用有無に基づいて請求可能な金額を自動計算するための数式ベースのアプローチを実装できます。

自動化の数式

${請求対象 単価} * ${請求対象 期間 in 日} * 14 * If(${VAT（付加価値税） check} == '真', 1 + ${VAT（付加価値税）} / 100, 1)

ロジック

サービスの請求金額は、作業時間（時間換算）に時間単価を掛けて算出できます。

• IVAが含まれている場合は、合計金額にIVAの割合を加えて計算を調整します。

• IVAが含まれていない場合は、追加の調整をせずに金額を算出します。

• 最後に、算出された金額をドル建てで表示します。

この数式は、請求の決定プロセスを簡素化し、作業時間だけでなく、オプションでIVAを含める場合も考慮して請求システム内で計算します。

注意: この数式内の '14' は1日の労働時間を表します。この値は必要に応じて調整できます。

コミッションの計算

シナリオ

複数の要素をもとに、各企業のコミッションを計算する必要があります。計算には、'ユーザー 貸方 Score'、'Commission パーセント'、'割引 パーセント'の各フィールドが含まれます。目標は、利用可能な計算の中で最も高いコミッション額を算出し、最低でも$100の固定値を保証することです。

ソリューション

『ユーザー 貸方 Score』、『Commission パーセント』、『割引 パーセント』の各フィールドを基に、各企業の手数料を計算する数式を実装できます。

自動化の数式

Max(${UserCreditScore} * ${CommissionPercent}, ${DiscountPercent} * ${UserCreditScore}, 100)

ロジック

『ユーザー 貸方 Score』、『Commission パーセント』、『割引 パーセント』の各フィールドを基に、各企業の手数料を算出できます。

1. 『ユーザー 貸方 Score』に『Commission パーセント』を掛けます。

2. 『ユーザー 貸方 Score』に『割引 パーセント』を掛けます。

3. 両方の値を固定値$100と比較し、最も大きい値を使用します。

これにより、コミッションは2つの計算値または固定値$100の中で最も高い金額となります。

ボーナスを計算する

シナリオ

各従業員のボーナス額を『ユーザー 貸方 Score』および『Bonus パーセント』の項目に基づいて決定したい場合があります。

解決策

Biginシステム内で数式ベースのアプローチを採用することで、企業のボーナス合計の自動計算や、各従業員へのボーナス配分を自動化できます。

また、計算では各従業員に最低でも$10,000が支給されることも確保する必要があります。

自動計算の数式

Min(${UserCreditScore} * ${BonusPercent}, ${BonusAmount} / ${TotalEmployees}, 10000)

ロジック

従業員のボーナスは、ユーザー 貸方 Score、Bonus パーセント、およびbônus 合計を従業員の人数 合計で割ることで算出できます。

1. フィールド'ユーザー 貸方 Score'に'Bonus パーセント'を掛けて、ボーナスの可能額を算出します。

2. フィールド'Bonus 金額'を'合計 従業員'で割り、各従業員のボーナス合計の分配額を計算します。

3. これらの結果を固定値$10,000と比較し、2つの計算結果または固定値$10,000のうち、いずれか小さい方を使用します。

商品コードの検証

シナリオ

在庫管理システムで商品コードの検証が必要です。商品コードは、在庫内のさまざまなアイテムを追跡するために使用されます。ただし、フォーマットや桁数は、仕入先や商品カテゴリによって異なります。

すべての商品コードが特定の桁数（例：10桁）になるようにし、一貫性を保つ必要があります。

解決方法

システム内で数式ベースのアプローチを採用し、商品コードの自動検証を実現することで、10桁の桁数要件を満たすことができます。

自動化数式

Len(${PartNumber})

ロジック

各商品コードの桁数と、必要な桁数（10桁）を比較します。

• 長さが10文字と等しい場合、商品コードは有効です。

• 長さが10文字と等しくない場合、商品コードは無効です。

支払い遅延

シナリオ

取引に関連する支払いを追跡する必要があります。各取引には完了日があり、これは取引が完了する予定の日付を示します。また、説明欄には支払いのステータス（例：'未払い'など、まだ支払いが完了していない場合）が含まれています。

目的は支払いが遅延している取引を特定することで、迅速な回収と健全なキャッシュフローの維持を図ります。

ソリューション

システム内で数式に基づくアプローチを実装することで、支払い遅延のある取引を、締切日やいいえ ステータス（支払い状況）に基づいて自動的に特定できます。

自動化数式 1

If(And(Datecomp(${Closing 日付}, ${日付 1}) <= 4320, ${説明} == '未払い'), '支払い 期限切れ', 'null')

この数式は、差分が指定された範囲内であるかを、closing 日付と独自の日付 項目（${日付 1}）の間で判定します。
もし支払いステータスが「未払い」で、時間差分が条件を満たしている場合、この数式は「支払い 期限切れ」を返します。それ以外の場合は「null」を返します。

自動化 Formula 2

If(And(Datecomp(${Closing 日付}, Now()) <= 4320, ${説明} == '未払い'), '支払い 期限切れ', 'null')

この数式は、closing 日付と現在 日付（Now()）を比較します。
もし支払いステータスが「未払い」で、日付 差分が上限以内の場合、数式は「支払い 期限切れ」を返します。それ以外の場合は「null」を返します。

ロジック

両方の数式は、4,320分（三日）の上限を使用して、closing 日付が商談の許容期間内かどうかを確認します。

使用中の項目を含みます：

• 'Closing 日付'（商談完了の予定日）

• '日付 1'（参照日付）

• '説明'（支払いステータスに関する情報。例：'未払い' など）

最初の数式は、差分が'Closing 日付'と'${日付 1}'の間で3日以下であり、かつ支払いステータスが「未払い」であるかどうかを判定します。両方の条件を満たした場合、数式は「支払い期限切れ」を返し、それ以外の場合は'null'を返します。

2つ目の数式は、'Closing 日付'と現在 日付（'Now()'）を比較し、差分が3日以内かどうかを確認します。もし支払いステータスが「未払い」で、かつ差分が条件を満たしている場合、数式は「支払い 期限切れ」を返します。それ以外の場合は'null'を返します。

町名・番地 アドレス

シナリオ

町名・番地名を各顧客の住所（例：家番号）から分離し、データ品質の向上とデータ入力の簡素化を図る必要があります。

町名・番地 名前を分離することで、不動産商談を場所ごとに分類・分析できます。

解決方法

システム内で数式を活用し、町名・番地 名前を自動的にその他の住所情報から分離することができます。「商談 担当者」項目内で実行可能です。

自動化Formula

Find(${商談 担当者}, ' ', 1)

ロジック

この数式は、「商談 担当者」項目内で最初のスペースの位置を特定します。

• 最初のスペースの位置を特定した後、substring関数を使用して、町名・番地 名前を住所から抽出できます。

• 町名・番地 名前は、住所の開始位置から最初のスペースまでのsubstringとして抽出できます。

低コスト購入

シナリオ

自社ではさまざまな商品を販売しており、一括販売の商品もあれば、個別販売の商品もあります。

目標は、小規模で低い-費用の購入を特定し、在庫および営業戦略の最適化を図ることです。

特に、商品の価格と数量がいずれも1未満である購入をフラグ付けしたい場合に有効です。

ソリューション

システム内で数式ベースのアプローチを採用すると、商品の価格と数量に基づいて自動的に小規模な購入を特定できます。

自動化 Formula

If(And(価格 < 1, 数量 < 1), 'Small', null)

ロジック

• この数式は、価格と数量が次の値より小さい 1かどうかを判定します。

• 両方の条件が満たされている場合、数式は'Small'を返し、その購入を低い-費用としてマークします。

• それ以外の場合は、'null'を返し、項目を空欄のままにします。

バリデーションルール

シナリオ

御社はさまざまな商品を製造しており、各生産バッチごとにサンプリング方式で品質管理チェックを行っています。Sample_Rate_Checkというカスタム項目があり、各バッチから品質管理のためにサンプリングすべき商品の割合（%）を指定します。

解決策

一貫性と効率的な品質管理を実現するために、指定された範囲内でサンプリング単価を強制できます：+10、-10%から40%の間です。
この範囲を外れるサンプリング率は、非効率的なテストや品質問題につながる可能性があります。

自動化Formula

Or(Sample_Rate_Check < +10、-10, Sample_Rate_Check > +10、-10。40)

ロジック

検証ルールの数式'Or(Sample_Rate_Check < +10、-10, Sample_Rate_Check > +10、-10。40)'は、'Sample_Rate_Check'（サンプリング率を示す）が+10、-10%から40%の許容範囲外かどうかを判定します。

• 関数'OR'は、サンプリング率が+10、-10%未満または40%超（+10、-10、40は小数として）の場合に'真'を返します。

• 数式が'真'を返した場合、バリデーションルールが作動し、エラーメッセージが表示され無効なサンプリング率の入力を防ぎます。

これにより、サンプリング率が所定の範囲内に保たれ、品質管理の一貫した運用が維持されます。

製品タイプ

シナリオ

貴社ではさまざまな商品・サービスを管理しており、各商品にはカスタムテキストフィールド'Product_Type_Check'が存在します。このフィールドは、商品が部品かサービスかを指定するものです。

目的は、各商品を自動的に分類し、'Part'または'サービス'として、'Product_Type_Check'フィールドの内容に基づいて振り分けることです。

ソリューション

システム内で数式ベースのアプローチを用いることで、アイテムを自動的にカテゴリ分けし、「Part」または「サービス」として分類できます。これは、フィールド「Product_Type_Check」の内容に基づいて判断されます。

自動化用数式

If(Contains(Product_Type_Check, 'part'), 'Part', 'サービス')

ロジック

数式「If(Contains(Product_Type_Check, 'part'), 'Part', 'サービス')」は、カスタムフィールド「Product_Type_Check」に「part」という文字列が含まれているかを基準にアイテムを分類します。

• 関数'Contains'は、フィールド内に部分文字列'part'が含まれているかを判定し、大文字と小文字を区別します。つまり、部分文字列が小文字の'part'と完全に一致する場合のみ、'真'を返します。

• 関数'IF'は、関数'Contains'の結果を評価します。

• 「真」を返す場合、数式は「Part」をカテゴリとして返します。

• それ以外の場合は「サービス」を返します。

この方法により、項目を「Part」または「サービス」といった項目に自動で分類でき、データ品質が向上し、より正確なレポートや分析が可能になります。

製品コードに基づく分類

シナリオ

自社では幅広い製品を製造しており、製品を製品コードに基づいて分類する必要があります。

目的は、製品コードのいいえプレフィックスに基づいて、製品を区別することです。

• 製品コードが「ICU」で始まる場合、「Medical」として分類されます。

• それ以外の場合、「Technical」として分類されます。

解決方法

システム内で数式ベースのアプローチを利用し、製品を自動的に分類し、「Medical」または「Technical」として、製品コードのプレフィックスに応じて分類できます。

自動化の数式

If(Startswith(${商品 コード}, 'ICU'), 'Medical', 'Technical')

ロジック

この数式 'If(Startswith(${商品 コード}, 'ICU'), 'Medical', 'Technical')' は、商品コードのプレフィックスに基づいて商品を分類します。

• 「Startswith」関数は、フィールド「商品コード」が「ICU」というプレフィックスで始まるかどうかを判定します。

• 商品コードが「ICU」で始まる場合、数式は「Medical」を返し、医療製品として分類します。

• それ以外の場合、数式は「Technical」を返し、技術製品として分類します。

このアプローチにより、製品を「Medical」または「Technical」のカテゴリに効率的に分類でき、レポート作成、在庫管理、販売戦略の最適化に役立ちます。