Back to Details

yonbip-workflow-path-table

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

YonBIP Workflow Path Table Generator

YonBIP Workflow Path Table Generator

Converts natural language business approval workflow descriptions into YonBIP-standard Excel workflow path tables.
Converts natural language business approval workflow descriptions into YonBIP-standard Excel workflow path tables.

Core Principle: Dynamic Column Extraction

Core Principle: Dynamic Column Extraction

CRITICAL: Do NOT assume any fixed columns. Every table structure must be derived from the user's description:
  1. Condition Columns: Extract all condition dimensions mentioned
    • Examples: 费用类型, 金额, 供应商类型, 部门, 地区, 采购类别, etc.
  2. Role Columns: Extract ALL roles mentioned in the approval chains
    • Examples: 部门主管, 财务经理, 总经理, 行政主管, 采购专员, 法律顾问, etc.
  3. Build table structure based ONLY on what's actually in the description
CRITICAL: Do NOT assume any fixed columns. Every table structure must be derived from the user's description:
  1. Condition Columns: Extract all condition dimensions mentioned
    • Examples: Expense Type, Amount, Supplier Type, Department, Region, Procurement Category, etc.
  2. Role Columns: Extract ALL roles mentioned in the approval chains
    • Examples: Department Supervisor, Finance Manager, General Manager, Administrative Supervisor, Procurement Specialist, Legal Counsel, etc.
  3. Build table structure based ONLY on what's actually in the description

Core Principle: Mutually Exclusive Conditions

Core Principle: Mutually Exclusive Conditions

每一行的条件组合必须是唯一的、互斥的。 任意给定输入只能匹配唯一一行。
The condition combination in each row must be unique and mutually exclusive. Any given input can only match exactly one row.

为什么互斥很重要？

Why is Mutual Exclusivity Important?

YonBIP 系统需要根据条件确定唯一的审批路径。如果两行的条件有重叠，系统无法判断应该走哪条路径。
The YonBIP system needs to determine a unique approval path based on conditions. If there is overlap between the conditions of two rows, the system cannot determine which path to take.

互斥规则

Mutual Exclusivity Rules

  1. 同一列的值必须互斥：对于每个条件列，任意两行的值不能同时匹配同一输入
    • ✅ 
      < 1000
      和 
      >= 1000
      互斥
    • ❌ 
      全部
      和 
      >= 5000
      重叠（"全部"包含">= 5000"）
    • ❌ 
      < 5000
      和 
      >= 3000
      重叠（3000-5000 同时匹配两者）
  2. 行组合必须互斥：即使单列值不互斥，组合后也必须互斥
    • ✅ 
      行政类采购 | < 5000
      和 
      生产类采购 | < 5000
      互斥（采购类别不同）
    • ❌ 
      行政类采购 | 全部
      和 
      行政类采购 | >= 5000
      重叠
  3. 使用分区而非叠加：不要用"全部"叠加更具体的条件
    • ❌ 错误：先写"全部"的规则，再叠加">= 5000"的规则
    • ✅ 正确：按金额区间分区：
      < 5000
      和 
      >= 5000
  1. Values in the same column must be mutually exclusive: For each condition column, values in any two rows cannot match the same input simultaneously
    • ✅ 
      < 1000
      and 
      >= 1000
      are mutually exclusive
    • ❌ "All" and 
      >= 5000
      overlap ("All" includes 
      >= 5000
      )
    • ❌ 
      < 5000
      and 
      >= 3000
      overlap (values between 3000-5000 match both)
  2. Row combinations must be mutually exclusive: Even if single-column values are not mutually exclusive, their combinations must be
    • ✅ "Administrative Procurement | < 5000" and "Production Procurement | < 5000" are mutually exclusive (different procurement categories)
    • ❌ "Administrative Procurement | All" and "Administrative Procurement | >= 5000" overlap
  3. Use partitioning instead of overlay: Do not overlay specific conditions on top of "All"
    • ❌ Wrong: First write the "All" rule, then overlay the 
      >= 5000
      rule
    • ✅ Correct: Partition by amount ranges: 
      < 5000
      and 
      >= 5000

金额区间的标准分区方式

Standard Partitioning Method for Amount Ranges

< 1000           →  小于1000
[1000, 5000)     →  1000到5000以下（含1000，不含5000）
>= 5000          →  5000及以上
这种分区方式确保每个金额值都能匹配唯一一行。
< 1000           →  Less than 1000
[1000, 5000)     →  1000 to below 5000 (includes 1000, excludes 5000)
>= 5000          →  5000 and above
This partitioning method ensures that each amount value matches exactly one row.

Workflow

Workflow

Dry Run Mode: If user specifies 
--dryrun
flag:
  • Skip Step 0 (clarification)
  • Skip Step 4 (Excel generation)
  • Only output the markdown table
Dry Run Mode: If user specifies 
--dryrun
flag:
  • Skip Step 0 (clarification)
  • Skip Step 4 (Excel generation)
  • Only output the markdown table

Step 0: Understand and Clarify (理解与澄清)

Step 0: Understand and Clarify

Skip in --dryrun mode: If the 
--dryrun
flag is set, skip this entire step and proceed directly to Step 1.
After receiving the user's approval rules, first analyze the content:
  1. Understand: Parse the natural language and identify:
    • The main business scenario (费用类型、采购类型等)
    • Key conditions mentioned (金额区间、供应商类型等)
    • Approval roles and their sequences
  2. Check for Ambiguities: Determine if the rules are complete and unambiguous:
    • Incomplete condition coverage (是否有遗漏的场景?)
    • Unclear role definitions (角色名称是否明确?)
    • Boundary conditions not specified (边界值如何处理?)
    • Multiple interpretations possible (是否有歧义?)
  3. Decision Point:
    • If rules are clear: Skip directly to Step 1 (no user interaction needed)
    • If ambiguities exist: Proceed to clarification
  4. Interactive Clarification (only if ambiguities exist):
    • First, present your understanding of the rules
    • Then, ask specific questions using AskUserQuestion tool:
      • Present specific questions with clear options
      • Allow "Other" for custom input
      • Wait for user response before proceeding
    • Example: "我理解您的规则是...，但有以下疑问：..."
  5. Proceed to Step 1: Once the rules are clear (either no ambiguities or user has clarified), proceed to extract and structure the data.
Typical scenarios requiring clarification:
  1. 条件覆盖不完整：
    • 规则："1000元以下走A，5000元以上走B"
    • 问题："1000-5000元之间如何处理？"
  2. 角色不明确：
    • 规则："主管审批"
    • 问题："是部门主管还是业务主管？"
  3. 边界值歧义：
    • 规则："1000元以下"和"1000-5000元"
    • 问题："正好1000元走哪条路径？"
  4. 默认值/兜底规则：
    • 规则：只说明了特定场景
    • 问题："其他未说明的场景如何处理？"
Skip in --dryrun mode: If the 
--dryrun
flag is set, skip this entire step and proceed directly to Step 1.
After receiving the user's approval rules, first analyze the content:
  1. Understand: Parse the natural language and identify:
    • The main business scenario (Expense Type, Procurement Type, etc.)
    • Key conditions mentioned (Amount Range, Supplier Type, etc.)
    • Approval roles and their sequences
  2. Check for Ambiguities: Determine if the rules are complete and unambiguous:
    • Incomplete condition coverage (Are there any missing scenarios?)
    • Unclear role definitions (Are role names clear?)
    • Boundary conditions not specified (How to handle boundary values?)
    • Multiple interpretations possible (Is there any ambiguity?)
  3. Decision Point:
    • If rules are clear: Skip directly to Step 1 (no user interaction needed)
    • If ambiguities exist: Proceed to clarification
  4. Interactive Clarification (only if ambiguities exist):
    • First, present your understanding of the rules
    • Then, ask specific questions using AskUserQuestion tool:
      • Present specific questions with clear options
      • Allow "Other" for custom input
      • Wait for user response before proceeding
    • Example: "My understanding of your rules is..., but I have the following questions:..."
  5. Proceed to Step 1: Once the rules are clear (either no ambiguities or user has clarified), proceed to extract and structure the data.
Typical scenarios requiring clarification:
  1. Incomplete condition coverage:
    • Rule: "Amount <1000 goes to A, amount >=5000 goes to B"
    • Question: "How to handle amounts between 1000 and 5000?"
  2. Unclear roles:
    • Rule: "Approved by supervisor"
    • Question: "Is it the department supervisor or business supervisor?"
  3. Boundary value ambiguity:
    • Rule: "Amount <1000" and "Amount 1000-5000"
    • Question: "Which path should exactly 1000 yuan take?"
  4. Default/fallback rules:
    • Rule: Only specific scenarios are mentioned
    • Question: "How to handle other unmentioned scenarios?"

Step 1: Extract and Structure

Step 1: Extract and Structure

Analyze the natural language and identify:
A. All Condition Dimensions (前几列)
  • What categories/dimensions determine the approval path?
  • Common patterns: 费用类型, 金额区间, 供应商性质, 部门类型, etc.
B. All Approval Roles (后几列)
  • Who are the approvers? List ALL unique roles mentioned
  • Preserve the exact role names from the description
  • Do NOT add roles that aren't mentioned
C. Approval Logic (表格内容)
  • Map out each scenario's approval sequence
  • Use numbers (1, 2, 3...) for approval order
  • Use 
    n/a
    for non-participating roles
  • Use 
    N:[condition]
    for conditional approvals
Analyze the natural language and identify:
A. All Condition Dimensions (First few columns)
  • What categories/dimensions determine the approval path?
  • Common patterns: Expense Type, Amount Range, Supplier Nature, Department Type, etc.
B. All Approval Roles (Last few columns)
  • Who are the approvers? List ALL unique roles mentioned
  • Preserve the exact role names from the description
  • Do NOT add roles that aren't mentioned
C. Approval Logic (Table content)
  • Map out each scenario's approval sequence
  • Use numbers (1, 2, 3...) for approval order
  • Use 
    n/a
    for non-participating roles
  • Use 
    N:[condition]
    for conditional approvals

Step 2: Generate Markdown Table

Step 2: Generate Markdown Table

Build the table with extracted columns:
| [条件列1] | [条件列2] | ... | [角色1] | [角色2] | [角色3] | ... |
|----------|----------|-----|---------|---------|---------|-----|
| 值A      | 条件X    | ... | 1       | n/a     | 2       | ... |
Validate mutual exclusivity before presenting:
Check that no two rows have overlapping conditions. If overlap exists:
  1. Identify the overlapping rows
  2. Refactor using proper partitioning (e.g., split "全部" into specific ranges)
  3. Ensure each input matches exactly one row
Present to user for confirmation.
Build the table with extracted columns:
| [Condition Column 1] | [Condition Column 2] | ... | [Role 1] | [Role 2] | [Role 3] | ... |
|----------|----------|-----|---------|---------|---------|-----|
| Value A  | Condition X | ... | 1       | n/a     | 2       | ... |
Validate mutual exclusivity before presenting:
Check that no two rows have overlapping conditions. If overlap exists:
  1. Identify the overlapping rows
  2. Refactor using proper partitioning (e.g., split "All" into specific ranges)
  3. Ensure each input matches exactly one row
Present to user for confirmation.

Step 3: User Confirmation

Step 3: User Confirmation

Ask: "请确认以上流程路径表是否正确？如需修改请直接告诉我。"
Wait for approval or modifications.
Ask: "Please confirm if the above workflow path table is correct? Please let me know directly if modifications are needed."
Wait for approval or modifications.

Step 4: Generate Excel

Step 4: Generate Excel

After confirmation, use the conversion script to generate Excel file.
write the markdown file to same folder of the Excel file.
Script location: 
scripts/md_to_excel.py
(within this skill directory)
Usage:
bash
python3 ${SKILL_DIR}/scripts/md_to_excel.py <input.md> <output.xlsx> --condition-cols <N>
Parameters:
  • --condition-cols N
    : 指定前 N 列为"条件"列（如：费用类型、金额区间），其余列为"环节"列（审批角色）
The script will:
  • Parse the Markdown table structure
  • Add explanation row ("条件" | "环节")
  • Apply YonBIP standard formatting (headers, borders, alignment)
  • Convert 
    n/a
    to empty cells
  • Generate 
    .xlsx
    file
After confirmation, use the conversion script to generate Excel file.
Write the markdown file to the same folder as the Excel file.
Script location: 
scripts/md_to_excel.py
(within this skill directory)
Usage:
bash
python3 ${SKILL_DIR}/scripts/md_to_excel.py <input.md> <output.xlsx> --condition-cols <N>
Parameters:
  • --condition-cols N
    : Specify the first N columns as "condition" columns (e.g., Expense Type, Amount Range), and the remaining columns as "node" columns (Approval Roles)
The script will:
  • Parse the Markdown table structure
  • Add explanation row ("Condition" | "Node")
  • Apply YonBIP standard formatting (headers, borders, alignment)
  • Convert 
    n/a
    to empty cells
  • Generate 
    .xlsx
    file

Examples

Examples

Example 1: 招待费（简单场景）

Example 1: Entertainment Expense (Simple Scenario)

Input:
招待费审批规则：1000元以下只需部门主管审批；1000-5000元需要部门主管和财务经理；5000元以上则需要部门主管、财务经理和总经理。
Extracted:
  • Condition columns: 费用类型, 金额
  • Role columns: 部门主管, 财务经理, 总经理
Output:
费用类型金额部门主管财务经理总经理
招待费< 10001n/an/a
招待费[1000, 5000)12n/a
招待费>= 5000123
Input:
Entertainment expense approval rules: Amount <1000 only requires department supervisor approval; Amount between 1000 and 5000 requires department supervisor and finance manager; Amount >=5000 requires department supervisor, finance manager, and general manager.
Extracted:
  • Condition columns: Expense Type, Amount
  • Role columns: Department Supervisor, Finance Manager, General Manager
Output:
Expense TypeAmountDepartment SupervisorFinance ManagerGeneral Manager
Entertainment< 10001n/an/a
Entertainment[1000, 5000)12n/a
Entertainment>= 5000123

Example 2: 采购审批（多条件+多角色）

Example 2: Procurement Approval (Multiple Conditions + Multiple Roles)

Input:
行政类采购：无论金额，部门负责人(1)→行政主管(2)。超过5000元增加财务总监(3)。
生产类采购：<20000：部门负责人(1)→采购专员(2)→财务总监(3)。
≥20000：部门负责人(1)→采购经理(2)→财务总监(3)→总经理(4)。
新合作方需增加法律顾问。
Extracted:
  • Condition columns: 采购类别, 金额, 供应商类型
  • Role columns: 部门负责人, 行政主管, 采购专员, 采购经理, 财务总监, 总经理, 法律顾问
Output:
采购类别金额供应商类型部门负责人行政主管采购专员采购经理财务总监总经理法律顾问
行政类采购< 5000全部12n/an/an/an/an/a
行政类采购>= 5000全部12n/an/a3n/an/a
生产类采购< 20000全部1n/a2n/a3n/an/a
生产类采购>= 20000老合作方1n/an/a234n/a
生产类采购>= 20000新合作方1n/an/a2345
Note: 条件互斥 - 每行代表唯一的条件组合，没有重叠。
Input:
Administrative Procurement: Regardless of amount, Department Head(1)→Administrative Supervisor(2). Add Finance Director(3) if amount >=5000.
Production Procurement: <20000: Department Head(1)→Procurement Specialist(2)→Finance Director(3).
≥20000: Department Head(1)→Procurement Manager(2)→Finance Director(3)→General Manager(4).
New partners require additional Legal Counsel approval.
Extracted:
  • Condition columns: Procurement Category, Amount, Supplier Type
  • Role columns: Department Head, Administrative Supervisor, Procurement Specialist, Procurement Manager, Finance Director, General Manager, Legal Counsel
Output:
Procurement CategoryAmountSupplier TypeDepartment HeadAdministrative SupervisorProcurement SpecialistProcurement ManagerFinance DirectorGeneral ManagerLegal Counsel
Administrative< 5000All12n/an/an/an/an/a
Administrative>= 5000All12n/an/a3n/an/a
Production< 20000All1n/a2n/a3n/an/a
Production>= 20000Existing Partner1n/an/a234n/a
Production>= 20000New Partner1n/an/a2345
Note: Mutually exclusive conditions - Each row represents a unique condition combination with no overlap.

Example 3: 差旅费（标准YonBIP角色）

Example 3: Travel Expense (Standard YonBIP Roles)

Input:
差旅费5000元以下走主管和财务；5000-10000增加经理；10000以上全审。
Extracted:
  • Condition columns: 费用类型, 金额
  • Role columns: 业务主管, 财务专员, 业务经理, 业务总经理, 总裁 (注意：按出现顺序提取)
Output:
费用类型金额业务主管财务专员业务经理业务总经理总裁
差旅费用< 500012n/an/an/a
差旅费用[5000, 10000)132n/an/a
差旅费用>= 1000014235
Input:
Travel expense <5000 requires Supervisor and Finance approval; 5000-10000 adds Manager; >=10000 requires all approvals.
Extracted:
  • Condition columns: Expense Type, Amount
  • Role columns: Business Supervisor, Finance Specialist, Business Manager, Business General Manager, President (Note: Extract in the order of appearance)
Output:
Expense TypeAmountBusiness SupervisorFinance SpecialistBusiness ManagerBusiness General ManagerPresident
Travel< 500012n/an/an/a
Travel[5000, 10000)132n/an/a
Travel>= 1000014235

Value Formatting

Value Formatting

Condition Values

Condition Values

  • 金额: 
    < 5000
    , 
    >= 10000
    , 
    [5000, 10000)
    , 
    全部
  • 类别: 具体类别名称 (如: 差旅费用, 行政类采购)
  • 通用: 
    全部
    表示不限制
  • Amount: 
    < 5000
    , 
    >= 10000
    , 
    [5000, 10000)
    , 
    All
  • Category: Specific category names (e.g., Travel Expense, Administrative Procurement)
  • General: 
    All
    means no restriction

Approval Nodes

Approval Nodes

  • 1, 2, 3...: Approval sequence order
  • n/a: Role does not participate
  • N:[condition]: Nth step with additional condition
    • Example: 
      2:[金额>=500]
      = 2nd approver AND amount >= 500
  • 1, 2, 3...: Approval sequence order
  • n/a: Role does not participate
  • N:[condition]: Nth step with additional condition
    • Example: 
      2:[amount>=500]
      = 2nd approver AND amount >= 500

Common Patterns

Common Patterns

Threshold phrases:
  • "X元以下" → 
    < X
  • "X元以内" → 
    <= X
  • "X-Y元" → 
    [X, Y)
  • "X元以上" → 
    >= X
Chain phrases:
  • "走A和B" → A then B (sequential)
  • "增加C" → Add C to chain
  • "全审/全部" → All roles participate
Condition phrases:
  • "如果是X且Y" → Add condition columns
  • "满足XX条件" → 
    N:[XX]
  • "需XX审批" → Add XX role
Threshold phrases:
  • "Below X yuan" → 
    < X
  • "Within X yuan" → 
    <= X
  • "X to Y yuan" → 
    [X, Y)
  • "Above X yuan" → 
    >= X
Chain phrases:
  • "Go through A and B" → A then B (sequential)
  • "Add C" → Add C to chain
  • "Full approval / All" → All roles participate
Condition phrases:
  • "If it is X and Y" → Add condition columns
  • "Meet XX condition" → 
    N:[XX]
  • "Requires XX approval" → Add XX role

Common Mistakes to Avoid

Common Mistakes to Avoid

❌ 错误：条件重叠

❌ Mistake: Overlapping Conditions

| 采购类别 | 金额 | ... |
|---------|------|-----|
| 行政类采购 | 全部   | ... |  ← 与下一行重叠
| 行政类采购 | >= 5000 | ... |  ← "全部"包含了">= 5000"
问题：一个6000元的行政类采购会同时匹配两行。
| Procurement Category | Amount | ... |
|---------|------|-----|
| Administrative | All   | ... |  ← Overlaps with the row below
| Administrative | >= 5000 | ... |  ← "All" includes `>= 5000`
Problem: An administrative procurement of 6000 yuan will match both rows simultaneously.

✅ 正确：互斥分区

✅ Correct: Mutually Exclusive Partitioning

| 采购类别 | 金额 | ... |
|---------|------|-----|
| 行政类采购 | < 5000  | ... |  ← 不包含5000
| 行政类采购 | >= 5000 | ... |  ← 从5000开始
| Procurement Category | Amount | ... |
|---------|------|-----|
| Administrative | < 5000  | ... |  ← Does not include 5000
| Administrative | >= 5000 | ... |  ← Starts from 5000

❌ 错误：区间边界重叠

❌ Mistake: Overlapping Range Boundaries

| 金额 | ... |
|------|-----|
| < 5000   | ... |
| >= 3000  | ... |  ← 3000-5000 重叠
| Amount | ... |
|------|-----|
| < 5000   | ... |
| >= 3000  | ... |  ← 3000-5000 overlap

✅ 正确：边界明确

✅ Correct: Clear Boundaries

| 金额 | ... |
|------|-----|
| < 3000      | ... |
| [3000, 5000) | ... |
| >= 5000     | ... |
| Amount | ... |
|------|-----|
| < 3000      | ... |
| [3000, 5000) | ... |
| >= 5000     | ... |

❌ 错误：使用"全部"叠加具体条件

❌ Mistake: Using "All" with Overlaid Specific Conditions

当用户说"超过5000元需要额外审批"时，不要生成：
| 金额 | 财务总监 |
|------|---------|
| 全部 | n/a |     ← 错误：与下一行重叠
| >= 5000 | 3 |   ← 被上面包含
When the user says "Amount >=5000 requires additional approval", do NOT generate:
| Amount | Finance Director |
|------|---------|
| All | n/a |     ← Wrong: Overlaps with the row below
| >= 5000 | 3 |   ← Included in the above

✅ 正确：分区覆盖所有情况

✅ Correct: Partition to Cover All Scenarios

| 金额 | 财务总监 |
|------|---------|
| < 5000 | n/a |
| >= 5000 | 3 |
| Amount | Finance Director |
|------|---------|
| < 5000 | n/a |
| >= 5000 | 3 |