RuoYi-Vue-Pro Architecture Overview | RuoYiPlus

Feature List

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

This is the “capability map” of the entire platform. Before deciding to use RuoYi, you can quickly determine through this list: Are the capabilities you need already built-in? If so, how quickly can you go live?

Total code volume approximately 260,000 lines, covering 19 system features, 17 infrastructure items, and 14 business subsystems.

Feature Panorama

mindmap root((RuoYi-Vue-Pro
Feature Panorama)) System Features User Management Role Management Menu Management Department Management Position Management Tenant Management Dictionary Management Notifications & Announcements Operation Logs Login Logs Sensitive Word Management Infrastructure Code Generator File Service Message Queue Configuration Management WebSocket Service Assurance System Monitoring Business Subsystems BPM Workflow CRM Customer Management ERP Purchase-Sales-Inventory Mall E-Commerce MES Manufacturing Execution WMS Warehouse Management Pay Payment Center AI Large Model IoT Internet of Things IM Instant Messaging

System Features (19 Items)

These are the “standard” capabilities of admin panels — universal features needed by any enterprise system:

Feature	Problem Solved	Typical Scenario
User Management	Manage system login accounts, support CRUD, password reset, status control	Create employee accounts, disable departed employees
Online Users	View currently online users in real-time, support forced logout	Security investigation, account anomaly handling
Role Management	RBAC permission model, roles assigned menu and button permissions	Set “Sales Manager” to only see CRM module
Menu Management	Dynamically configure sidebar menu, support directory/menu/button three levels	Configure menus after adding new business modules
Department Management	Organizational structure tree, support data scope permissions	Beijing branch can only see Beijing data
Position Management	Position dictionary, associated with users	Link positions to salary/approval permissions
Tenant Management	SaaS tenant registration, package assignment, expiration handling	SaaS provider managing multiple enterprise clients
Tenant Packages	Bind different menu permissions for different tenant packages	Basic/Professional/Enterprise edition feature differences
Dictionary Management	Global enumeration value maintenance, shared by frontend and backend	Gender, status, type dropdown options
SMS Management	SMS templates, sending records, channel configuration	Verification codes, notification SMS
Email Management	Email templates, sending records, SMTP configuration	Registration verification, system alerts
Internal Messages	In-system message notifications, read/unread status	Approval notifications, system announcements
Operation Logs	Record every user operation with request parameters and results	Audit tracing, issue investigation
Login Logs	Record login IP, time, result	Security audit, abnormal login detection
Error Code Management	Unified error code definitions, user-friendly prompts	API returns `1002005001` for “User not found”
Notifications & Announcements	System-level announcements, support scheduled publishing	System maintenance notices, company announcements
Sensitive Words	Sensitive word library management and auto-filtering	Content moderation, comment filtering
Application Management	Multi-application configuration, e.g., admin panel + mobile	One system, multiple entry points
Region Management	China administrative division data, province/city/district three levels	Address picker, logistics regions

Infrastructure (17 Items)

These are the underlying capabilities that support business operations:

Capability	Problem Solved	Technical Implementation
Code Generator	One-click CRUD frontend/backend code generation, eliminating repetitive work	Template engine, supports master-child tables, tree tables, uni-app
System API	Online API documentation based on Swagger	Swagger3 + Knife4j
Database Documentation	Auto-generate database table structure docs	Screw
Form Builder	Visual drag-and-drop form design	Low-code form designer
Configuration Management	Dynamic parameter configuration, no restart needed	System parameters + Configuration Center
File Service	Unified file upload/download, multi-cloud storage switching	S3 protocol: MinIO/Alibaba OSS/Tencent COS/Qiniu
WebSocket	Real-time bidirectional communication	Standalone/Cluster dual mode
API Logs	Record API request and response details	Interceptor + async write
MySQL Monitoring	Database connection pool and slow query monitoring	Druid
Redis Monitoring	Redis memory, hit rate, connection monitoring	Built-in monitoring panel
Java Monitoring	JVM memory, threads, GC monitoring	Spring Boot Actuator
Distributed Tracing	Distributed request trace tracking	SkyWalking integration
Log Center	Centralized multi-service log viewing	Log file management
Service Assurance	Distributed locks, idempotency, rate limiting, deduplication	Redisson + custom annotations
Unit Testing	Ensure code quality	JUnit5 + 1121+ test cases

Business Subsystem Overview

Subsystem	Table Count	One-Sentence Description
BPM Workflow	-	Approval process engine, DingTalk-like designer
Pay Payment Center	-	Unified payment/refund/transfer, abstracting channel differences
Report Dashboards	-	Drag-and-drop dashboard design, three reporting engines
Member Center	-	Membership system, VIP levels, points check-in
MP Official Accounts	-	Multi-account management, follower messages, auto-reply
Mall E-Commerce	70+	Complete B2C e-commerce system
CRM Customer Management	20+	Lead → Opportunity → Contract → Collection full process
ERP Purchase-Sales-Inventory	30+	Procurement/sales/inventory/finance integrated
Sale Finance	-	ERP sub-module, receipts/payments/settlements
WMS Warehouse Management	16	General warehouse management
MES Manufacturing Execution	133	Workshop-level manufacturing management
AI Large Model	-	Chat/drawing/knowledge base/workflow
IoT Internet of Things	-	Device management/thing model/rule engine
IM Instant Messaging	16	Private chat/group chat/channels/audio-video

Suitable Users

Java Developers: Have Spring Boot foundation, want to rapidly deliver enterprise-level projects
Small & Medium Teams: Need a foundation covering multiple business scenarios, reducing redundant development
Enterprise IT Departments: Internal digitalization, need mature modules like approval flows, purchase-sales-inventory, CRM
SaaS Providers: Need multi-tenant capabilities and modular architecture to serve multiple customers

Report Dashboards & Data Visualization

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

The Report module enables non-technical users to create professional data dashboards. Without writing any frontend code, by dragging and dropping components and configuring data sources, you can generate visual reports and dashboard pages. Suitable for management dashboards, data monitoring, project reporting, and similar scenarios.

In one sentence: Create data dashboards like making a PowerPoint presentation.

Problems Solved

Pain Point	How Report Solves It
Management wants to see data, developers have to write pages each time	Drag-and-drop design, business users can do it themselves
Data display requirements change frequently	Modify dashboard configuration, no deployment needed
Need professional visualization effects	Built-in dozens of chart components and templates
Different scenarios need different reporting engines	Three engines provided, choose as needed

User Roles

graph LR subgraph Roles DESIGNER["Dashboard Designer
Drag-and-drop dashboard configuration
Set up data sources
Publish dashboards"] VIEWER["Viewer (Management/Clients)
View dashboards
Interactively filter data"] end

Three Reporting Engines

graph TB subgraph GoView["Go-View (Recommended)"] G1["Open-source & free"] G2["Vue3 tech stack"] G3["Pure frontend, standalone deployment"] G4["Rich built-in chart components"] end subgraph Jimu["JimuReport"] J1["Not open-source"] J2["Embedded backend"] J3["Supports complex reports"] J4["Chinese-style reports"] end subgraph AJ["AJ-Report"] A1["Open-source"] A2["Under development"] A3["Fully backend-driven"] end

Feature	Go-View	JimuReport	AJ-Report
Open-source	✅	❌	✅
Learning Curve	⭐ Low	⭐⭐ Medium	⭐⭐ Medium
Chart Richness	⭐⭐⭐⭐⭐	⭐⭐⭐⭐	⭐⭐⭐
Complex Reports	⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Recommended Scenario	General dashboards	Chinese-style complex reports	Backend-driven scenarios

Dashboard Design Process

flowchart LR A["New Dashboard
Choose template or blank"] --> B["Drag Components
Charts/Text/Images/Borders"] B --> C["Configure Data Sources
API / Static Data"] C --> D["Adjust Styles
Layout/Colors/Animations"] D --> E["Preview
Real-time view"] E --> F{Satisfied?} F -->|Yes| G["Publish Dashboard
Generate access link"] F -->|No| B

Built-in Chart Components (Partial)

Line Chart / Bar Chart / Pie Chart / Radar Chart
Data Table / Scrolling Table
Number Flipper
Map (China / Province / City)
Gauge
Word Cloud
Timeline
Border and Decoration Components

Typical Application Scenarios

Scenario	Dashboard Content	Viewers
Sales Dashboard	Today’s sales, order volume, conversion rate, regional ranking	Sales Director, Management
Production Monitoring	Production line status, output, defect rate, equipment OEE	Production Manager, Plant Manager
Operations Dashboard	User growth, activity, retention, revenue trends	Operations Team
Project Reporting	Project progress, milestones, risks, resource usage	Project Stakeholders

AI Large Model

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

The AI module is a one-stop AI capability integration platform, connecting to mainstream large models both domestically and internationally, providing 8 major AI capabilities including chat, drawing, knowledge base (RAG), tool calling, workflow, writing, mind mapping, and music creation. Whether you want to add an AI assistant to your system or build an AI-native application, ready-to-use capabilities are all here.

In one sentence: Make your system “able to chat, draw, write articles, and sing.”

Problems Solved

Pain Point	How the AI Module Solves It
Integrating large models requires individual API integration	Unified integration of mainstream domestic and international models, one-time integration
Internal enterprise knowledge cannot be utilized by AI	RAG knowledge base lets AI understand your documents
Single AI capability (only chatting)	8 major capability modules covering various scenarios
Need to orchestrate AI workflows	Integrated with Dify/FastGPT/Coze workflow platforms
Complex switching between domestic and international models	Unified API layer, switch models without changing code

User Roles

graph LR subgraph Roles AI_ADMIN["AI Administrator
Configure model access
Manage knowledge bases
Set permissions"] AI_USER["AI User
Chat conversations
Drawing creation
Knowledge base Q&A
Writing/Mind mapping"] AI_DEV["Developer
Integrate AI capabilities via API
Create custom workflows"] end

8 Major Functional Modules

graph TB AI_CORE["AI Large Model Platform"] AI_CORE --> CHAT["💬 AI Chat
Multi-model conversation
Context memory
Internet search
Thinking reasoning mode"] AI_CORE --> IMAGE["🎨 AI Drawing
Text-to-image
Supports Stable Diffusion
Midjourney"] AI_CORE --> RAG["📚 AI Knowledge Base
RAG retrieval-augmented generation
Upload documents for Q&A"] AI_CORE --> TOOL["🔧 AI Tool Calling
Function Calling
MCP Protocol"] AI_CORE --> WORKFLOW["🔄 AI Workflow
Integrates Dify/FastGPT/Coze
Visual orchestration"] AI_CORE --> WRITE["✍️ AI Writing
Articles/Reports/Emails
Multi-scenario templates"] AI_CORE --> MINDMAP["🧠 AI Mind Mapping
Auto-generate mind maps"] AI_CORE --> MUSIC["🎵 AI Music
Suno AI music creation"]

Supported Models

Domestic Models

Model	Provider	Features
Tongyi Qianwen	Alibaba Cloud	Strong comprehensive capability
DeepSeek	DeepSeek	High cost-effectiveness, strong reasoning
Doubao	ByteDance	Multimodal capability
Hunyuan	Tencent	Good ecosystem integration
Wenxin Yiyan	Baidu	Strong Chinese comprehension
GLM	Zhipu AI	Open-source friendly
Spark	iFlytek	Outstanding voice capability
Moonshot	Moonshot AI	Long context
MiniMax	MiniMax	Multimodal
BaiChuan	Baichuan Intelligence	Chinese optimized
SiliconFlow	SiliconFlow	Multi-model aggregation

International Models

Model	Provider
GPT	OpenAI
Claude	Anthropic
Llama	Meta
Gemini	Google

Core Capability Details

AI Chat

User: Help me analyze this quarter's sales data
 ↓
AI: Based on the data, Q3 sales increased 15% year-over-year, including...
 ↓ (Supports Thinking reasoning mode)
Displays complete reasoning process + conclusions

Supports internet search, enabling AI to access real-time information.

AI Knowledge Base (RAG)

flowchart LR DOC["Upload Documents
PDF/Word/Web Pages"] --> PARSE["Document Parsing
Segmentation/Vectorization"] PARSE --> STORE["Vector Storage"] QUERY["User Question"] --> SEARCH["Retrieve Relevant Passages"] STORE --> SEARCH SEARCH --> LLM["Large Model
Answer with context"] LLM --> ANSWER["Accurate Answer"]

AI Workflow

Integrates Dify, FastGPT, Coze, and other platforms, enabling visual orchestration of complex AI workflows, such as:

Intelligent Customer Service: User question → Intent recognition → Knowledge base retrieval → Escalation decision
Content Generation: Keywords → Outline → Body → Image generation → Publishing

CRM Customer Relationship Management

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

CRM is the sales team’s “command center.” From a single lead, to converting into a customer, creating an opportunity, signing a contract, and receiving payment — the entire sales funnel is visualized here. Combined with the public pool mechanism, it prevents customer resources from being “hoarded” by individual salespeople.

In one sentence: Help your sales team say goodbye to managing customers in Excel, and make every deal traceable.

Problems Solved

Pain Point	How CRM Solves It
Customer info scattered in salespeople’s personal WeChat/Excel	Unified customer database, no data loss during handover
Sales collision, multiple people following the same customer	Customer lock mechanism + public pool rules
No visibility into what salespeople do daily	Follow-up records, visit records fully logged
Unclear which part of the sales funnel has issues	Lead→Customer→Opportunity→Contract conversion rate visualization
Chaotic payment collection management	Contract → Payment Plan → Payment Record full chain

User Roles

graph LR subgraph Roles SALES["Salesperson
Follow up on leads and customers
Create opportunities and contracts
Record follow-ups and payments"] MANAGER["Sales Manager
Assign leads and customers
Approve contracts
View team data"] ADMIN4["Administrator
Configure public pool rules
Manage product catalog
Data statistics and analysis"] end

Complete Sales Process

Core Table Structure (ER Diagram)

erDiagram CRM_CLUE ||--o| CRM_CUSTOMER : "Converted to" CRM_CUSTOMER ||--o{ CRM_CONTACT : "Has" CRM_CUSTOMER ||--o{ CRM_BUSINESS : "Creates" CRM_BUSINESS ||--o{ CRM_CONTRACT : "Advances to" CRM_CONTRACT ||--o{ CRM_RECEIVABLE : "Payment" CRM_CONTRACT ||--o{ CRM_RECEIVABLE_PLAN : "Payment Plan" CRM_CLUE { bigint id PK varchar name "Lead Name" varchar mobile "Phone Number" tinyint status "Status" bigint owner_user_id FK "Owner" } CRM_CUSTOMER { bigint id PK varchar name "Customer Name" tinyint level "Customer Level" bigint owner_user_id FK "Owner" } CRM_CONTACT { bigint id PK bigint customer_id FK varchar name "Contact Name" varchar mobile "Phone Number" } CRM_BUSINESS { bigint id PK bigint customer_id FK varchar name "Opportunity Name" decimal total_price "Estimated Amount" tinyint status "Stage" } CRM_CONTRACT { bigint id PK bigint business_id FK varchar no "Contract Number" decimal total_price "Contract Amount" tinyint status "Status" } CRM_RECEIVABLE { bigint id PK bigint contract_id FK decimal price "Payment Amount" datetime time "Payment Time" }

Public Pool Mechanism

Rule	Description
Auto-Release	If no follow-up for N days, customer automatically falls into public pool
Advance Reminder	Remind salesperson to follow up before deadline
Lock Protection	Closed-deal customers permanently locked, will not fall into public pool
Customer Limit	Each salesperson has a maximum customer count limit to prevent hoarding
Scheduled Task	Background scheduled scan and execution of public pool release logic

Data Permissions

CRM uses an owner mechanism for data isolation:

Each customer/lead/opportunity/contract has an owner_user_id field
Salespeople can only see their own data
Sales managers can see team data
Administrators can see all data
Supports transfer operation: transfer customers to other salespeople

Feature List

Module	Features
Lead Management	Lead entry, assignment, conversion, invalid marking
Customer Management	Customer info, contacts, follow-up records, locking
Public Pool Customers	Public pool, claiming, release rules
Opportunity Management	Opportunity stages, estimated amount, win/loss
Contract Management	Contract creation, approval, changes
Payment Management	Payment plans, payment records, receivables statistics
Product Management	Product catalog, pricing
Data Statistics	Funnel analysis, performance statistics

Member Center

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

The Member module provides an independent member user system, completely isolated from backend admin users (system_users). It serves as the user foundation for the e-commerce system, responsible for member registration, login, level progression, points operations, and the full lifecycle management of C-end users.

Key Distinction: Admins log into the backend using system_users (system users), while C-end users register and log in using member_user (member users) — two completely independent systems.

Problems Solved

Pain Point	How Member Solves It
C-end users need independent registration/login	Independent member user table, not mixed with admin users
Need membership levels and benefits system	VIP levels + growth value mechanism
Need to increase user engagement and retention	Points check-in, points mall
WeChat ecosystem users need one-click login	Official account login, mini program login, mini program subscription messages

User Roles

graph LR subgraph BackendRoles ADMIN3["Operations Staff
Manage member information
Configure VIP levels
Manage points rules
Set member tags and groups"] end subgraph FrontendRoles MEMBER2["Regular Member
Register/Login/Profile"] VIP["VIP Member
Enjoy level benefits
Earn and use points"] end

Membership System Architecture

graph TB subgraph AccountSystem LOGIN["Login Methods
Phone/Email/WeChat"] REGISTER["Registration
Phone/WeChat authorization"] end subgraph LevelSystem LEVEL["VIP Levels
Regular → Silver → Gold → Diamond"] GROWTH["Growth Value
Earned through purchases/check-ins/tasks"] LEVEL --> GROWTH end subgraph PointsSystem POINTS_GET["Points Earning
Check-in/Purchases/Campaigns"] POINTS_USE["Points Usage
Deduction/Redemption"] POINTS_GET --> POINTS_USE end subgraph OperationsSystem TAG["Member Tags
Profile labeling"] GROUP["Member Groups
Targeted operations"] end LOGIN --> MemberUserTable REGISTER --> MemberUserTable MemberUserTable --> LevelSystem MemberUserTable --> PointsSystem MemberUserTable --> OperationsSystem

WeChat Ecosystem Integration

graph TB MEMBER3["Member Module"] subgraph WeChatCapabilities MP_LOGIN["Official Account Login
WeChat H5 authorization"] MINI_LOGIN["Mini Program Login
One-click phone number access"] MINI_QR["Mini Program QR Code
Parameterized QR code"] MINI_MSG["Mini Program Subscription Messages
Order/Logistics/Campaign notifications"] end MEMBER3 --> MP_LOGIN MEMBER3 --> MINI_LOGIN MEMBER3 --> MINI_QR MEMBER3 --> MINI_MSG

Relationship with Mall

graph LR MEMBER4["Member Center
Provides: Member info/Level/Points"] --> MALL2["Mall E-Commerce
Consumption: Use member identity to order
Earning: Orders earn points and growth value"] MALL2 --> MEMBER4

The mall depends on the member module for user identity, while the mall’s consumption behavior feeds back points and growth value to the member system.

Core Feature List

Feature	Description
Member Management	Member list, details, status management
Member Tags	Custom tags, user profile labeling
Member Levels	VIP level configuration, growth value rules, level upgrades/downgrades
Member Groups	Group by conditions, support targeted push
Points Check-in	Check-in rule configuration, consecutive check-in rewards
Points Records	Points details, flow tracing

MP WeChat Official Accounts

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

The MP module is a “multi-account management center” for WeChat Official Accounts. If you operate multiple official accounts, you don’t need to log into the WeChat Official Account Platform and switch between them — here you can centrally manage followers, messages, menus, materials, and auto-replies for all official accounts.

In one sentence: One admin panel manages all official accounts, doubling operational efficiency.

Problems Solved

Pain Point	How MP Solves It
Switching between multiple official accounts is cumbersome	One admin panel manages multiple official accounts
Follower information is scattered	Unified follower list, tag management
Auto-reply rule configuration is complex	Visual configuration of follow replies, message replies, keyword replies
Menu configuration experience is poor	Visual menu editor, real-time preview
Cannot integrate with business systems	Follower data connected with member module

User Roles

graph LR subgraph Roles OP["Official Account Operator
Manage followers and messages
Configure auto-replies
Edit menus
Manage materials
View data statistics"] FAN["Followers
Follow official account
Send messages
Trigger auto-replies"] end

Functional Architecture

graph TB subgraph Core["10 Major Functional Modules"] ACCOUNT["Account Management
Bind multiple official accounts"] STATS["Data Statistics
Follower growth/Message statistics"] FANS["Follower Management
Follower list/Tags/Sync"] MSG["Message Management
Receive/Reply to messages"] AUTO["Auto-Reply
Follow/Message/Keyword"] TEMPLATE["Template Messages
Business notification push"] TAG2["Tag Management
Follower grouping"] MENU["Menu Management
Visual configuration"] MATERIAL["Material Management
Articles/Images/Audio"] DRAFT["Article Draft Box"] end subgraph WeChatAPI["WeChat Official Account API"] WX_API["Message Receive/Send
Menu Push
Material Upload
User Info Retrieval"] end Core --> WeChatAPI

Auto-Reply Rules

flowchart LR EVENT["User Action"] --> TYPE{Reply Type} TYPE -->|Follow Account| FOLLOW["Follow Reply
Welcome message + Guidance"] TYPE -->|Send Message| KEYWORD{Match Keyword?} KEYWORD -->|Exact Match| EXACT["Keyword Reply"] KEYWORD -->|Fuzzy Match| LIKE["Fuzzy Match Reply"] KEYWORD -->|No Match| DEFAULT["Default Message Reply"]

Integration with Business Systems

Official account followers can be synced as member users, and the mall can push order status to users via template messages, forming a complete WeChat ecosystem closed loop.

Core Feature List

Feature	Description
Account Management	Bind multiple official accounts, switch management
Data Statistics	Follower growth trends, message interaction statistics
Follower Management	Follower list, details, tags, blocklist
Message Management	Receive follower messages, manual reply
Auto-Reply	Follow reply, default reply, keyword reply
Template Messages	Push template messages to followers
Tag Management	Follower grouping tags
Menu Management	Visual bottom menu configuration
Material Management	Articles, images, voice, video material library
Article Draft Box	Article message draft editing

Mall E-Commerce System

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

Mall is the platform’s most complex business module (70+ tables), providing the full e-commerce chain from product management and order transactions to marketing campaigns and distribution commissions. One system comes with both an admin panel (Vue3+Element Plus) and a mobile app (uni-app), ready to use out of the box.

In one sentence: If you need to build a B2C e-commerce store, 90% of the functionality is already implemented here.

Problems Solved

Pain Point	How Mall Solves It
Building a store from scratch takes too long	70+ tables + complete frontend/backend, go live in weeks
Multiple marketing tactics are expensive to develop	Built-in coupons/flash sales/group buying/bargaining/distribution
Need both admin panel and user-facing frontend	Admin panel + uni-app mobile app provided together
Payment and membership need extra integration	Built-in integration with Payment Center and Member Center

User Roles

graph LR subgraph BackendRoles MALL_ADMIN["Mall Admin
Manage products/orders/marketing"] MALL_OP["Operations Staff
Configure campaigns/review reviews"] end subgraph FrontendRoles BUYER["Buyer
Browse products/Place orders/Pay
Participate in marketing campaigns"] DISTRIBUTOR["Distributor
Promote products
Earn commissions"] end

System Architecture

graph TB subgraph AdminPanel ADMIN_PANEL["Vue3 + Element Plus Admin Panel
Products/Orders/Marketing/Data"] end subgraph MobileApp UNI_APP["uni-app Mobile App
H5 + App + Mini Program
Storefront customization (3 templates)"] end subgraph ProductCenter CATEGORY["Product Categories"] ATTR["Product Attributes"] SPU["SPU Products"] SKU["SKU Variants"] REVIEW["Product Reviews"] end subgraph OrderCenter CART["Shopping Cart"] ORDER["Transaction Orders"] AFTER_SALE["After-Sales Management"] EXPRESS["Express Delivery"] PICKUP["Self Pickup Verification"] end subgraph MarketingCenter COUPON["Coupons"] SECKILL["Flash Sales"] BARGAIN["Bargaining"] GROUPON["Group Buying"] DISCOUNT["Limited-Time Discounts"] CONTENT["Content Marketing"] COMMISSION["Distribution Commissions"] end subgraph Dependencies PAY2["Payment Center"] MEMBER6["Member Center"] MP3["Official Accounts"] end AdminPanel --> ProductCenter AdminPanel --> OrderCenter AdminPanel --> MarketingCenter MobileApp --> ProductCenter MobileApp --> OrderCenter MobileApp --> MarketingCenter OrderCenter --> PAY2 OrderCenter --> MEMBER6 MarketingCenter --> MEMBER6

Core Business Flow

User Order Process

sequenceDiagram participant U2 as User participant APP as Mobile/PC participant MALL4 as Mall participant PAY3 as Payment Center participant WMS2 as Warehouse/WMS U2->>APP: Browse products, add to cart U2->>APP: Confirm order, select address APP->>MALL4: Create order (Pending Payment) MALL4->>PAY3: Initiate payment PAY3-->>APP: Payment page U2->>PAY3: Complete payment PAY3->>MALL4: Callback: Payment successful MALL4->>MALL4: Order status → Pending Shipment MALL4->>WMS2: Notify shipment WMS2->>MALL4: Enter tracking number MALL4->>APP: Push shipment notification U2->>APP: Confirm receipt MALL4->>MALL4: Order complete, award points

Marketing Campaign Matrix

Campaign Type	Mechanics	Suitable Scenarios
Coupons	Threshold discounts/percentage discounts/vouchers, can target specific products/categories	Daily promotions
Flash Sales	Limited time & quantity, ultra-low price rush	Traffic generation, inventory clearance
Group Buying	Multi-person group purchase for discount price	Social viral growth
Bargaining	Share with friends to bargain down the price	New user acquisition
Limited-Time Discounts	Discount during specified time period	Holiday promotions
Content Marketing	Articles/videos product seeding	Content commerce
Distribution Commissions	Promotion commissions, multi-level distribution	Social commerce

Storefront Customization

The mobile app supports 3 storefront customization templates, allowing drag-and-drop component layout of the homepage:

Carousel / Navigation icons / Product recommendations
Coupon popups / Countdown timers
Search bar / Announcement bar

Dependencies

Mall E-Commerce
 ├── Payment Center (Pay) —— Order payment
 ├── Member Center (Member) —— User identity/points
 └── Official Accounts (MP) —— WeChat H5 store

ERP Enterprise Resource Planning

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

ERP is the enterprise’s “purchase-sales-inventory hub” — managing the complete flow of physical goods and funds from supplier procurement, warehouse inventory to customer sales. 30+ tables cover five core areas: procurement, sales, inventory, products, and finance, suitable for daily operations management of trading and manufacturing enterprises.

In one sentence: Manage your goods and money, making every transaction traceable.

Problems Solved

Pain Point	How ERP Solves It
Inventory quantities rely on manual counting, often mismatched	Every inbound/outbound transaction auto-updates inventory, real-time and accurate
Procurement and sales processes are opaque	Document approval workflow + status tracking
Unclear how much profit is made	Procurement cost vs. sales revenue, auto-calculated
Multi-warehouse transfers are chaotic	Stock transfer operations are recorded, inventory locations are clear
Financial receivables and payables are hard to manage	Settlement accounts + payment/receipt records

User Roles

graph LR subgraph Roles PURCHASER["Purchaser
Manage suppliers
Create purchase orders
Handle purchase inbound and returns"] SALES2["Salesperson
Manage customers
Create sales orders
Handle sales outbound and returns"] WAREHOUSE["Warehouse Keeper
Confirm inbound/outbound
Manage inventory
Execute stocktaking"] FINANCE["Finance
Manage settlement accounts
Handle payments/receipts
Review documents"] MANAGER2["Manager
Approve documents
View reports"] end

Five Core Modules

graph TB subgraph Procurement["Procurement Management"] P1["Supplier Management"] P2["Purchase Orders"] P3["Purchase Inbound"] P4["Purchase Returns"] end subgraph Sales["Sales Management"] S1["Customer Management"] S2["Sales Orders"] S3["Sales Outbound"] S4["Sales Returns"] end subgraph Inventory["Inventory Management"] I1["Inventory Query"] I2["Inventory Flow"] I3["Stock Transfer"] I4["Stocktaking"] end subgraph Products["Product Management"] PR1["Product Categories"] PR2["Product Information"] PR3["Product Units"] end subgraph Finance["Financial Management"] F1["Settlement Accounts"] F2["Purchase Payments"] F3["Sales Receipts"] end PI["Purchase Inbound"] -->|Inventory Increase| Inventory PR["Purchase Returns"] -->|Inventory Decrease| Inventory SO["Sales Outbound"] -->|Inventory Decrease| Inventory SR["Sales Returns"] -->|Inventory Increase| Inventory PO["Purchase Orders"] -->|Payment| Finance SO["Sales Orders"] -->|Receipt| Finance

Procurement Process

sequenceDiagram participant P as Purchaser participant ERP3 as ERP participant S as Supplier participant WH as Warehouse P->>ERP3: Select supplier, create purchase order ERP3->>ERP3: Order status: Pending Approval Note over ERP3: Can integrate BPM workflow approval ERP3->>ERP3: Approved P->>S: Notify supplier to ship S->>WH: Goods delivered WH->>ERP3: Create purchase inbound order ERP3->>ERP3: Inbound approved ERP3->>ERP3: Inventory increased Note over ERP3: If return needed P->>ERP3: Create purchase return order ERP3->>ERP3: Return approved → Inventory decreased

Sales Process

sequenceDiagram participant C as Customer participant S2 as Salesperson participant ERP4 as ERP participant WH2 as Warehouse C->>S2: Place purchase demand S2->>ERP4: Create sales order ERP4->>ERP4: Order approved S2->>WH2: Notify warehouse to prepare goods WH2->>ERP4: Create sales outbound order ERP4->>ERP4: Outbound approved ERP4->>ERP4: Inventory decreased WH2->>C: Ship goods Note over ERP4: If return needed S2->>ERP4: Create sales return order ERP4->>ERP4: Return approved → Inventory increased

Core Table Structure

erDiagram ERP_PRODUCT ||--o{ ERP_PURCHASE_ORDER_ITEM : "Procurement" ERP_PRODUCT ||--o{ ERP_SALE_ORDER_ITEM : "Sales" ERP_PRODUCT ||--o{ ERP_STOCK : "Inventory" ERP_PURCHASE_ORDER ||--o{ ERP_PURCHASE_ORDER_ITEM : "Contains" ERP_PURCHASE_ORDER ||--o{ ERP_PURCHASE_IN : "Inbound" ERP_SALE_ORDER ||--o{ ERP_SALE_ORDER_ITEM : "Contains" ERP_SALE_ORDER ||--o{ ERP_SALE_OUT : "Outbound" ERP_STOCK { bigint id PK bigint product_id FK "Product" bigint warehouse_id FK "Warehouse" int stock "Inventory Qty" } ERP_PURCHASE_ORDER { bigint id PK varchar no "Document No." bigint supplier_id FK "Supplier" tinyint status "Status" decimal total_price "Total Amount" } ERP_SALE_ORDER { bigint id PK varchar no "Document No." bigint customer_id FK "Customer" tinyint status "Status" decimal total_price "Total Amount" }

Document Number Rules

Format: {prefix}{yyyyMMdd}{6-digit auto-increment}
Example: CGD20240625000001 (Purchase Order)
 XSD20240625000001 (Sales Order)

Approval Mechanism

All inbound/outbound documents have an approval status (ErpAuditStatus):

Status	Description
Not Approved	Draft status, editable
Approved	Approved, triggers inventory change

Key Rule: Only approved documents affect inventory; rejected documents produce no inventory changes.

Dependencies

ERP Purchase-Sales-Inventory
 └── BPM Workflow (Optional) —— Approval process

WMS Warehouse Management System

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

WMS is an independent general warehouse management system (16 tables), distinct from the manufacturing-deeply-integrated warehouse module in MES. WMS is positioned as “general warehouse management,” suitable for pure warehousing scenarios. If you need deep manufacturing integration (such as line-side inventory, production picking), use the warehouse module in MES.

In one sentence: Manage the warehouse’s “in, out, transfer, count” — always know where every item is.

Problems Solved

Pain Point	How WMS Solves It
Don’t know how much inventory is in the warehouse	Real-time inventory query, inventory flow tracing
Inbound/outbound records rely on paper documents	Electronic documents, traceable status flow
Unclear item locations	Multi-warehouse, location management
Stocktaking is time-consuming and labor-intensive	Systematic stocktaking process
Inventory data is inaccurate	Every operation auto-updates inventory

User Roles

graph LR subgraph Roles WH_ADMIN["Warehouse Admin
Manage warehouses/locations
Configure product info
Handle inbound/outbound/transfer/stocktaking
View inventory"] end

Core Business Processes

graph TB subgraph InboundProcess IN1["Create Inbound Order"] --> IN2["Draft Status"] IN2 --> IN3["Confirm Complete"] IN3 --> IN4["Inventory Increased"] IN2 --> IN5["Voided"] end subgraph OutboundProcess OUT1["Create Outbound Order"] --> OUT2["Draft Status"] OUT2 --> OUT3["Confirm Complete"] OUT3 --> OUT4["Inventory Decreased"] OUT2 --> OUT5["Voided"] end subgraph TransferProcess MV1["Create Transfer Order"] --> MV2["Confirm Complete"] MV2 --> MV3["Source Warehouse Inventory Decreased
Target Warehouse Inventory Increased"] end subgraph StocktakingProcess CK1["Create Stocktaking Order"] --> CK2["Enter Actual Count"] CK2 --> CK3["Confirm Complete"] CK3 --> CK4["Surplus: Inventory Increased
Shortage: Inventory Decreased"] end

Core Table Structure

erDiagram WMS_WAREHOUSE ||--o{ WMS_STOCK : "Inventory" WMS_PRODUCT ||--o{ WMS_STOCK : "Inventory" WMS_WAREHOUSE { bigint id PK varchar name "Warehouse Name" varchar code "Warehouse Code" tinyint status "Status" } WMS_PRODUCT { bigint id PK varchar name "Product Name" varchar no "Product Code" varchar unit "Unit" } WMS_STOCK { bigint id PK bigint warehouse_id FK "Warehouse" bigint product_id FK "Product" int stock "Inventory Qty" } WMS_STOCK_RECORD { bigint id PK bigint warehouse_id FK bigint product_id FK int count "Change Qty" tinyint type "In/Out Type" varchar business_no "Related Document No." }

Document Number Rules

Format: {prefix}{MMdd}{4-digit random}
Example: RK06250001 (Inbound Order)
 CK06250001 (Outbound Order)
 YK06250001 (Transfer Order)
 PK06250001 (Stocktaking Order)

Two-Phase Status Flow

All documents follow a Draft → Completed/Voided two-phase pattern:

Status	Description
Draft	Editable, does not trigger inventory changes
Completed	Confirmed complete, triggers inventory transaction
Voided	Document voided, does not trigger inventory changes

Key Rule: Only “Completed” status actually affects inventory quantities.

Difference from MES Warehouse

Dimension	WMS	MES Warehouse Module
Positioning	General warehouse management	Manufacturing deep integration
Table Count	16 tables	62 tables
Use Case	Standalone warehousing, logistics centers	Manufacturing plants, production workshops
Special Features	Basic inbound/outbound/stocktaking	Line-side inventory, production picking, outsourcing management
Requires MES	❌ Standalone	✅ Part of MES

MES Manufacturing Execution System

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

MES is the largest business module on the entire platform (133 tables), designed for workshop-level management needs of manufacturing enterprises. It’s not just “purchase-sales-inventory,” but dives deep into production work orders, process routes, scheduling, work reporting, quality inspection, and equipment maintenance — a complete manufacturing execution system.

In one sentence: If your factory needs to manage “how to schedule work orders, how to execute processes, how to inspect quality, how to maintain equipment,” MES is the answer.

Problems Solved

Pain Point	How MES Solves It
Production progress is opaque	Work order → Scheduling → Work reporting full-chain tracking
Quality inspection relies on paper records	IQC/IPQC/OQC/RQC digitized
Equipment failures affect delivery deadlines	Equipment ledger + inspection plans for preventive maintenance
Material management is chaotic	Line-side inventory + production picking/return management
Outsourced processing is hard to manage	Independent outsourced inbound/outbound management
Worker scheduling is complex	Shift scheduling module

User Roles

graph LR subgraph Roles PLANNER["Planner
Create production work orders
Develop scheduling plans"] WORKER["Operator
View work order tasks
Report work records
Pick/return materials"] QC["Quality Inspector
IQC incoming inspection
IPQC in-process inspection
OQC outgoing inspection"] MAINTENANCE["Equipment Maintainer
Manage equipment ledger
Execute inspection plans"] SUPERVISOR["Workshop Supervisor
View production progress
Andon exception handling"] end

Seven Module Panorama

graph TB subgraph MD["Master Data md (17 tables)"] MD1["Materials/Products"] MD2["Customer/Supplier"] MD3["Workshop Management"] MD4["Coding Rules"] end subgraph PRO["Production Management pro (17 tables)"] PRO1["Process Routes"] PRO2["Production Work Orders"] PRO3["Scheduling Orders"] PRO4["Work Reports"] PRO5["Andon System"] end subgraph WM["Warehouse Management wm (62 tables)"] WM1["Location Setup"] WM2["Inventory Management"] WM3["Purchase Inbound"] WM4["Finished Goods Inbound"] WM5["Sales Outbound"] WM6["Picking & Returns"] WM7["Stock Transfer"] WM8["Stocktaking"] WM9["Miscellaneous In/Out"] WM10["Outsourcing Management"] end subgraph QC2["Quality Management qc (16 tables)"] QC1["IQC Incoming Inspection"] QC2_IN["IPQC In-Process Inspection"] QC3["OQC Outgoing Inspection"] QC4["RQC Return Inspection"] end subgraph DV["Equipment Management dv (12 tables)"] DV1["Equipment Ledger"] DV2["Inspection Plans"] DV3["Inspection Records"] end subgraph TM["Tool Management tm (2 tables)"] TM1["Tool Ledger"] TM2["Tool Checkout"] end subgraph CAL["Shift Scheduling cal (7 tables)"] CAL1["Shift Definition"] CAL2["Scheduling Plans"] end MD --> PRO MD --> WM PRO --> WM PRO --> QC2

Production Execution Process

sequenceDiagram participant PLAN as Planner participant MES2 as MES participant LINE as Production Line participant QC3 as Quality Inspector participant WH3 as Warehouse PLAN->>MES2: Create production work order PLAN->>MES2: Develop scheduling plan MES2->>LINE: Work order dispatched to production line LINE->>WH3: Material picking request WH3->>MES2: Confirm material issuance LINE->>MES2: Process work report QC3->>MES2: IPQC in-process inspection LINE->>MES2: Completion work report QC3->>MES2: OQC outgoing inspection LINE->>WH3: Finished goods inbound

Quality Inspection System

graph LR subgraph IQC["IQC Incoming Inspection"] I1["Supplier Incoming Materials"] I2["Inspect → Pass/Fail"] I3["Fail → Return/Concession"] end subgraph IPQC["IPQC In-Process Inspection"] P1["Sample inspection during production"] P2["Key process inspection"] P3["Exception handling"] end subgraph OQC["OQC Outgoing Inspection"] O1["Inspection before finished goods shipment"] O2["Pass → Release"] end subgraph RQC["RQC Return Inspection"] R1["Customer return inspection"] R2["Determine responsibility attribution"] end IQC --> IPQC --> OQC RQC -.-> IQC

Virtual Line-Side Inventory (WIP)

There is a special concept in the MES warehouse module — virtual line-side inventory (WIP_VIRTUAL_WAREHOUSE), used to track work-in-process materials on the shop floor:

Materials issued from warehouse to production line → Line-side inventory increases
Production line consumes materials → Line-side inventory decreases
Finished goods completed → Line-side inventory decreases, finished goods inventory increases

This keeps the quantity and location of WIP materials on the shop floor always clear.

Relationship with Other Modules

Relationship	Description
MES vs WMS	WMS is general warehouse management; MES’s warehouse module is deeply integrated with manufacturing (line-side inventory, picking, outsourcing)
MES vs ERP	ERP manages “purchase-sales-inventory,” MES manages “production execution,” complementary
MES vs IoT	IoT can be used for equipment data collection, MES for production management
MES vs BPM	Can integrate BPM for quality inspection exception approvals, etc.

Sales & Financial Management

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

This is the financial sub-module of the ERP system, implemented by the finance package of yudao-module-erp. It does not exist independently but is tightly integrated into ERP’s procurement and sales processes, responsible for recording and managing the flow of funds.

In one sentence: Procurement requires payment, sales require collection, returns require refunds — the financial module handles all these “money” matters.

Problems Solved

Pain Point	How Financial Module Solves It
Don’t know which supplier owes how much	Settlement account balances are clearly visible
Payments can’t be linked to specific purchase orders	Payment orders linked to purchase inbound orders
Collections disconnected from sales orders	Receipt orders linked to sales outbound orders
Refund process is chaotic	Return orders automatically trigger refund process

User Roles

graph LR subgraph Roles FINANCE2["Finance Staff
Manage settlement accounts
Process payments/receipts
Process refunds
Reconcile accounts"] end

Core ER Diagram

erDiagram ERP_ACCOUNT ||--o{ ERP_FINANCE_PAYMENT : "Payment" ERP_ACCOUNT ||--o{ ERP_FINANCE_RECEIPT : "Receipt" ERP_PURCHASE_IN ||--o{ ERP_FINANCE_PAYMENT : "Purchase Inbound → Payment" ERP_PURCHASE_RETURN ||--o{ ERP_FINANCE_PAYMENT : "Purchase Return → Refund" ERP_SALE_OUT ||--o{ ERP_FINANCE_RECEIPT : "Sales Outbound → Receipt" ERP_SALE_RETURN ||--o{ ERP_FINANCE_RECEIPT : "Sales Return → Refund" ERP_ACCOUNT { bigint id PK varchar name "Account Name" decimal balance "Current Balance" tinyint status "Status" } ERP_FINANCE_PAYMENT { bigint id PK varchar no "Payment No." bigint account_id FK "Settlement Account" bigint in_id FK "Purchase Inbound Order" decimal price "Payment Amount" datetime time "Payment Time" } ERP_FINANCE_RECEIPT { bigint id PK varchar no "Receipt No." bigint account_id FK "Settlement Account" bigint out_id FK "Sales Outbound Order" decimal price "Receipt Amount" datetime time "Receipt Time" }

Business Scenarios

Scenario 1: Purchase Payment

sequenceDiagram participant P2 as Purchaser participant F2 as Finance participant ERP5 as ERP participant ACC as Settlement Account P2->>ERP5: Complete purchase inbound F2->>ERP5: View purchase inbound orders pending payment F2->>ERP5: Select settlement account, create payment order ERP5->>ACC: Deduct account balance ERP5->>ERP5: Record payment transaction

Scenario 2: Sales Receipt

sequenceDiagram participant S3 as Salesperson participant F3 as Finance participant ERP6 as ERP participant ACC2 as Settlement Account S3->>ERP6: Complete sales outbound F3->>ERP6: View sales outbound orders pending receipt F3->>ERP6: Select settlement account, create receipt order ERP6->>ACC2: Increase account balance ERP6->>ERP6: Record receipt transaction

Settlement Accounts

Settlement accounts represent the fund account relationship between the company and suppliers/customers. Every payment and receipt affects the corresponding account balance.

Attribute	Description
Account Name	e.g., “XX Supplier Settlement Account”
Current Balance	Real-time updates, payments deduct, receipts add
Status	Enabled/Disabled

IoT Internet of Things

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

The IoT module is a device management platform similar to Alibaba Cloud IoT Platform. It can connect massive devices, define device capabilities through thing models, process device data using a rule engine, and achieve device data collection, remote control, and scenario linkage.

In one sentence: If your hardware devices need cloud-based management, this provides the complete chain from device registration to data flow.

Problems Solved

Pain Point	How IoT Solves It
Diverse device access protocols	Supports MQTT/HTTP/CoAP/TCP/UDP/WebSocket/Modbus etc.
Non-uniform device data formats	Thing model standardizes device capability definitions
Don’t know how to process device data	Rule engine → data routing/scenario linkage/alerts
Difficult device firmware upgrades	OTA remote upgrades
Need to integrate with third-party IoT platforms	Built-in EMQX integration, customizable protocols

User Roles

graph LR subgraph Roles IOT_ADMIN["IoT Admin
Define products
Manage devices
Configure thing models
Set up rule engine"] IOT_DEV["Device Developer
Device-side development
Protocol integration
OTA upgrades"] IOT_OP["Operations Staff
Monitor device status
Handle alerts
Data analysis"] end

Platform Architecture

graph TB subgraph DeviceLayer["Device Layer"] D1["Sensors"] D2["Gateways"] D3["Controllers"] D4["Smart Devices"] end subgraph AccessLayer["Access Layer (Multi-Protocol)"] P1["MQTT"] P2["HTTP"] P3["CoAP"] P4["TCP/UDP"] P5["WebSocket"] P6["Modbus"] end subgraph PlatformLayer["IoT Platform"] PRODUCT["Product Management
Define device types"] DEVICE["Device Management
Registration/Authentication/Status"] MODEL["Thing Model
Properties/Services/Events"] OTA["OTA Upgrade
Firmware remote updates"] end subgraph ProcessingLayer["Data Processing Layer"] RULE["Rule Engine
Data rules/Scenario linkage/Alerts"] TD["TDengine
Time-series data storage"] end DeviceLayer --> AccessLayer AccessLayer --> PlatformLayer PlatformLayer --> ProcessingLayer

Thing Model Design

The thing model is the core concept of IoT, describing in a standardized way “what attributes a device has, what it can do, and what it reports”:

graph TB subgraph ThingModel["Thing Model = Digital Description of Device"] ATTR["Property
Static characteristics of device
Example: Temperature, Humidity, Switch State"] SERVICE["Service
Actions the device can execute
Example: Unlock, Restart, Calibrate"] EVENT["Event
Information actively reported by device
Example: Alerts, Faults, Completion Notifications"] end

Rule Engine

flowchart LR DATA["Device Data"] --> ENGINE["Rule Engine"] ENGINE -->|Data Rules| ROUTE1["Data Routing
Store to TDengine
Forward to HTTP/Kafka"] ENGINE -->|Scenario Linkage| ROUTE2["Scenario Linkage
Temp > 30°C → Auto-turn on fan"] ENGINE -->|Alert Config| ROUTE3["Alerts
Device offline > 5 min → Send notification"]

Device Lifecycle

flowchart LR CREATE["Create Product
Define thing model"] --> REG["Register Device
Get authentication info"] REG --> ONLINE["Device Online
Establish connection"] ONLINE --> WORK["Normal Operation
Report data/Receive commands"] WORK --> OTA2["OTA Upgrade"] OTA2 --> WORK WORK --> OFFLINE["Device Offline"] OFFLINE --> ONLINE

Supported Protocols

Protocol	Use Case	Features
MQTT	Mainstream IoT protocol	Lightweight, pub-sub, QoS
HTTP	Simple devices, web apps	High versatility
CoAP	Low-power devices	HTTP-like, UDP
TCP	Custom protocols	Flexible, efficient
UDP	High-frequency data reporting	Low latency
WebSocket	Real-time bidirectional communication	Browser-friendly
Modbus	Industrial devices	Industrial control standard
EMQX	High-performance MQTT Broker	Million-level connections
Custom Protocol	Special devices	Extension development

Technical Dependencies

TDengine: Time-series database for storing massive time-series data reported by devices (requires separate setup)
EMQX: High-performance MQTT Broker (optional, for large-scale device access)

IM Instant Messaging

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

The IM module provides built-in instant messaging capabilities for your platform — no need to integrate third-party IM SDKs (such as Huanxin, RongCloud), directly implement private chat, group chat, channel broadcasting, and audio-video calls within your system. Particularly suitable for scenarios requiring “in-platform communication,” such as e-commerce customer service, internal enterprise communication, community private messaging, etc.

In one sentence: Let your users chat within your platform, with data and experience fully under your control.

Problems Solved

Pain Point	How IM Solves It
Third-party IM SDK costs are high	Self-built IM, zero additional cost
User data stored with third parties	Chat data in your own database
Need to integrate with business systems	User system, friend relationships linked with business
Audio-video call capability	Integrated with LiveKit, supports WebRTC calls

User Roles

graph LR subgraph Roles IM_USER["Regular User
Private chat/group chat
Send text/images/files/voice
Audio-video calls"] IM_ADMIN["IM Admin
Manage groups
Configure channels
Manage sensitive words
View message records"] end

Functional Architecture

graph TB subgraph Core["Core Features"] MSG2["Message Center
Private/Group chat
Text/Image/File/Voice/Video"] FRIEND["Friend Relationships
Add/Delete/Blocklist"] GROUP["Group Management
Create/Join/Leave/Mute"] CHANNEL["Channel Broadcasting
Announcements/Notifications"] CALL["Audio-Video Calls
Based on LiveKit
WebRTC"] end subgraph Auxiliary EMOJI["Emoji Management"] SENSITIVE["Sensitive Word Filtering"] end subgraph Communication["Communication Layer"] WS["WebSocket Real-time Communication
local / redis / rocketmq
/ kafka / rabbitmq"] end Core --> Communication Auxiliary --> Core

Core ER Diagram

erDiagram IM_USER ||--o{ IM_MESSAGE : "Send" IM_USER ||--o{ IM_FRIEND : "Friend Relations" IM_USER ||--o{ IM_GROUP_MEMBER : "Group Members" IM_GROUP ||--o{ IM_GROUP_MEMBER : "Contains" IM_GROUP ||--o{ IM_MESSAGE : "Group Messages" IM_CHANNEL ||--o{ IM_CHANNEL_MESSAGE : "Channel Messages" IM_CHANNEL ||--o{ IM_CHANNEL_MEMBER : "Channel Members" IM_MESSAGE { bigint id PK bigint from_user_id FK "Sender" bigint to_user_id FK "Receiver" bigint group_id FK "Group" tinyint type "Message Type" text content "Message Content" datetime create_time "Send Time" } IM_GROUP { bigint id PK varchar name "Group Name" bigint owner_user_id FK "Group Owner" tinyint status "Status" } IM_CHANNEL { bigint id PK varchar name "Channel Name" tinyint type "Channel Type" }

Database Table Groups

Group	Table Count	Description
Message Center	2 tables	Message records, message conversations
Friend Relations	2 tables	Friends, friend requests
Group Management	3 tables	Groups, group members, group announcements
Channel Broadcasting	3 tables	Channels, channel members, channel messages
Audio-Video Calls	2 tables	Call records, call participants
Others	4 tables	Emojis, sensitive words, etc.

WebSocket Communication Modes

graph TB subgraph SendMode["Message Send Modes (Switchable)"] LOCAL["local
Standalone Mode
For development/debugging"] REDIS3["redis
Redis Broadcast
Small clusters"] ROCKET2["rocketmq
RocketMQ
High throughput"] KAFKA2["kafka
Kafka
Large scale"] RABBIT2["rabbitmq
RabbitMQ
Enterprise-grade"] end

Application Scenarios

Scenario	Usage
E-commerce Customer Service	Buyer ↔ Merchant customer service private chat
Enterprise Internal Communication	Employee group chat, department channels
Community Private Messaging	User-to-user private chat
Online Education	Student ↔ Teacher, course group chat + audio-video
Medical Consultation	Patient ↔ Doctor private chat + audio-video consultation

Vue3 Admin Panel

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

Vue3 Admin Panel is RuoYi’s primary frontend solution and the frontend project with the most complete business features. If you’re unsure which frontend to choose, pick this one — pages for all 14 subsystems are first implemented here.

Tech Stack: Vue3 + TypeScript + Vite + Element Plus + Pinia

Suitable Users

User Profile	Why Choose This
Teams pursuing stability	All features are first implemented here, most thoroughly tested
Element Plus ecosystem users	Mature component library, complete documentation, active community
Need the most complete business features	All 14 subsystems have corresponding pages
Secondary development scenarios	Clear code structure, highly modular

Project Architecture

graph TB subgraph Entry MAIN["main.ts
Application Entry"] end subgraph CoreLayer["Core Layer"] ROUTER["router/
Route Configuration"] STORE["store/
Pinia State Management"] UTILS["utils/
Utility Functions"] end subgraph RequestLayer["Request Layer"] AXIOS["utils/request.ts
axios Wrapper
baseURL / timeout / Interceptors"] API["api/
APIs Organized by Module"] MOCK["mock/
Mock Data"] end subgraph ViewLayer["View Layer (Organized by Subsystem)"] SYS_V["views/system/
System Management"] BPM_V["views/bpm/
Workflow"] CRM_V["views/crm/
Customer Management"] ERP_V["views/erp/
Purchase-Sales-Inventory"] MALL_V["views/mall/
E-Commerce"] end subgraph ComponentLayer COMPS["components/
Shared Components"] DIRS["directives/
Custom Directives"] PLUGINS["plugins/
Plugins"] end MAIN --> ROUTER MAIN --> STORE ROUTER --> ViewLayer ViewLayer --> API API --> AXIOS AXIOS --> UTILS

Key Design

axios Request Wrapper

baseURL: /api
timeout: 30000ms
Interceptors:
 - Request interceptor: Auto-attach Token
 - Response interceptor: Unified error handling, Token expiration redirect to login

Page File Organization

Each business page typically contains:

views/erp/purchase/order/
 ├── index.vue # List page
 ├── form.vue # Form dialog
 └── const.ts # Constants

Permission Control

Menus and buttons are controlled via permission identifiers:

// Button permission example
<el-button v-hasPermi="['erp:purchase-order:create']">Add</el-button>

// Menus returned by backend, frontend dynamically renders based on role

Comparison with Other Frontends

Dimension	Vue3 Admin Panel	Vben5	Vue2
Positioning	Primary, most complete features	Next-gen, more advanced architecture	Classic, Vue2 compatible
UI Library	Element Plus	Ant Design / Element Plus	Element UI
Business Features	✅ Full coverage	🚧 Gradual migration	✅ Full coverage
Developer Experience	⭐⭐⭐⭐	⭐⭐⭐⭐⭐	⭐⭐⭐
Use Case	First choice for new projects	For cutting-edge tech stack	Vue2 legacy projects

Quick Start

# 1. Enter frontend directory
cd yudao-ui-admin-vue3

# 2. Install dependencies
pnpm install

# 3. Start dev server
pnpm run dev

# 4. Access
http://localhost:80

Vben5 Admin Panel

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

Vben5 is RuoYi’s next-generation admin panel, based on Vben Admin 5.x (Monorepo architecture), with more advanced architectural design. It supports both Ant Design Vue and Element Plus UI component libraries — you can freely choose based on your team’s preferences.

Tech Stack: Vue3 + TypeScript + Vite + Vben5 + Ant Design Vue / Element Plus

Suitable Users

User Profile	Why Choose This
Teams pursuing latest architecture	Monorepo + more advanced state management + stronger type constraints
Ant Design ecosystem users	Supports Ant Design Vue, more international UI style
Large project teams	Vben component system (Vxe Table / Vben Form / Vben Modal) better suited for complex forms and tables
Willing to accept feature migration status	Some business modules still being migrated from Vue3 version

Project Architecture

graph TB subgraph Monorepo["Monorepo Structure"] APPS["apps/
Application Entries"] PKGS["packages/
Shared Packages"] INTERNAL["internal/
Internal Tools"] end subgraph UI["Dual UI Library Support"] ANT["Ant Design Vue
More international style"] EP["Element Plus
More localized style"] end subgraph COMP["Vben Component System"] TABLE["Vben Vxe Table
High-Performance Table"] FORM["Vben Form
Declarative Forms"] MODAL["Vben Modal
Dialog Management"] DRAWER["Vben Drawer
Drawer Component"] end subgraph PAGES["Page Structure (Three Files Per Page)"] INDEX["index.vue
Page Entry"] FORM_V["form.vue
Form Definition"] DATA["data.ts
Data Logic"] end APPS --> UI APPS --> COMP APPS --> PAGES

Core Advantages

1. Monorepo Architecture

All packages managed in one repository, unified dependency versions, easier code reuse. Shared utility functions, type definitions, and components are placed under packages/.

2. Dual UI Library Switching

// Can choose Ant Design Vue
import { Button, Table, Form } from 'ant-design-vue';

// Or choose Element Plus
import { ElButton, ElTable, ElForm } from 'element-plus';

The same business logic can adapt to two UI styles, which is especially valuable for projects that need to be delivered to different clients.

3. Declarative Component System

Vben’s component system dramatically improves development efficiency for complex forms and tables:

<!-- Vben Vxe Table: Declarative Column Definition -->
<vxe-grid v-bind="gridOptions">
 <!-- Built-in pagination, sorting, filtering, export -->
</vxe-grid>

<!-- Vben Form: Declarative Form -->
<vben-form :schema="formSchema" />

Feature Migration Progress

Module	Status	Notes
System Management	✅ Completed	Users/Roles/Menus/Departments etc.
Infrastructure	✅ Completed	Code Generation/Files/Config etc.
BPM Workflow	✅ Completed (v2.6.1)	Ant Design version
CRM Customer Management	✅ Completed (v2.6.1)	Ant Design version
Pay Payment Center	✅ Completed (v2.6.1)	Ant Design version
Member Center	✅ Completed (v2.6.1)	Ant Design version
AI Large Model	✅ Completed (v2.6.1)	Ant Design version
ERP Purchase-Sales-Inventory	🚧 In Progress	-
Mall E-Commerce	🚧 In Progress	-

Quick Start

# 1. Enter directory
cd yudao-ui-admin-vben5

# 2. Install dependencies
pnpm install

# 3. Start dev server
pnpm run dev

# 4. Access
http://localhost:{port}

SaaS Multi-Tenancy

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

SaaS Multi-Tenancy allows you to serve multiple enterprise clients with a single codebase, where each client (tenant) can only see their own data, completely isolated from each other. Whether building a vertical SaaS product or managing multiple subsidiaries within an enterprise, this is an indispensable capability.

Two approaches: Column-based isolation (lightweight, suitable for small-to-medium scale) and database isolation (physical isolation, suitable for large-scale SaaS).

Suitable Users

Scenario	Recommended Approach	Reason
SaaS Startup Phase	Column-based isolation	Simple operations, one database handles everything
Large SaaS Platform	Database isolation	Physical isolation, high security, independent backups
Enterprise Multi-Company	Column-based isolation	Limited number of companies, logical isolation is sufficient
Finance/Healthcare Compliance	Database isolation	Data must be physically isolated

Two Approaches Comparison

graph TB subgraph COLUMN["Approach 1: Column-Based Isolation (COLUMN Mode)"] direction TB C1["All tenants share
same database, same tables"] C2["Each table adds
tenant_id column"] C3["SQL Interceptor
auto-appends WHERE tenant_id = ?"] C4["Pros: Simple operations, high resource utilization
Cons: Logical isolation, moderate security"] C1 --> C2 --> C3 --> C4 end subgraph DATASOURCE["Approach 2: Database Isolation (DATASOURCE Mode)"] direction TB D1["Master DB: Shared tables
Users/Menus/Config/Tenant info"] D2["Tenant DB A: Business tables"] D3["Tenant DB B: Business tables"] D4["Tenant DB C: Business tables"] D5["Pros: Physical isolation, high security, independent backups
Cons: Complex operations, lower resource utilization"] D1 --> D2 D1 --> D3 D1 --> D4 D2 & D3 & D4 --> D5 end

Detailed Comparison

Dimension	Column-Based (COLUMN)	Database Isolation (DATASOURCE)
Isolation Level	Logical isolation	Physical isolation
Security	Medium (relies on SQL interceptor)	High (database-level isolation)
Resource Utilization	High (shared connection pool)	Low (independent connections per tenant)
Operations Complexity	Low (single DB operations)	High (multi-DB operations)
Scalability	Limited by single DB performance	Horizontally scalable
Data Backup	Need to filter by tenant_id	Independent backup per tenant
Applicable Scale	Hundreds of tenants	Thousands/Tens of thousands of tenants
Technical Implementation	MyBatis Plus interceptor	dynamic-datasource

Column-Based Isolation Implementation

sequenceDiagram participant U as User (Tenant A) participant APP as Application Layer participant INTERCEPTOR as SQL Interceptor participant DB as Shared Database U->>APP: Query customer list APP->>INTERCEPTOR: SELECT * FROM crm_customer INTERCEPTOR->>INTERCEPTOR: Auto-append tenant_id = 'A' INTERCEPTOR->>DB: SELECT * FROM crm_customer
WHERE tenant_id = 'A' DB-->>APP: Returns only Tenant A's data APP-->>U: Display customer list

Core Mechanism: Through MyBatis Plus’s multi-tenant plugin, automatically adds tenant_id condition before executing any SQL, completely transparent to business code.

Database Isolation Implementation

Based on dynamic-datasource dynamic data sources, when a request comes in, it switches to the corresponding data source based on the current tenant ID:

spring:
 datasource:
 dynamic:
 primary: master  # Master DB (shared tables)
 datasource:
 master: # Master DB config
 url: jdbc:mysql://localhost:3306/ruoyi_master
 tenant_1: # Tenant 1's independent database
 url: jdbc:mysql://localhost:3306/ruoyi_tenant_1
 tenant_2: # Tenant 2's independent database
 url: jdbc:mysql://localhost:3306/ruoyi_tenant_2

Tenant Package Management

graph LR PACKAGE1["Basic Package
System Management + Basic Features"] PACKAGE2["Professional Package
Basic + CRM + ERP"] PACKAGE3["Enterprise Package
All Features"] TenantA["Tenant A"] --> PACKAGE1 TenantB["Tenant B"] --> PACKAGE2 TenantC["Tenant C"] --> PACKAGE3

Each tenant can be bound to a package, which defines the menus and features visible to that tenant. Supports automatic disabling upon package expiration.

Code Generation Advanced

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

The code generator is RuoYi’s “nuclear weapon” for development efficiency. Regular single-table CRUD can no longer satisfy complex business scenarios. Here we introduce three advanced generation modes, covering the most common complex page patterns in enterprise development.

With these capabilities, a complex business page containing master-child tables and approval flows goes from “days of coding” to “minutes of configuration.”

Suitable Users

Scenario	Recommended Mode	Effect
Order + Line Items	Master-Child Standard Mode	Same dialog, master-child tables edited together
Work Order + Processes	Master-Child Embedded Mode	Expand child table directly in list
Purchase Order + Details	Master-Child ERP Mode	Independent master and child lists, independent forms
Department Tree/Category Tree	Tree Table Mode	Auto-generate tree table
Mobile Pages	uni-app Mode	Generate pages compatible with H5/Mini Programs

Three Master-Child Table Generation Modes

graph TB subgraph StandardMode["Mode 1: Standard Mode"] S1["Master Table List Page"] S2["Click Add → Dialog"] S3["Dialog: Master Form + Child Table
Edit in same dialog"] S1 --> S2 --> S3 end subgraph EmbeddedMode["Mode 2: Embedded Mode"] I1["Master Table List Page"] I2["Expand Row → Embedded Child Table
Child table shown directly below master row"] I1 --> I2 end subgraph ERPMode["Mode 3: ERP Mode"] E1["Master Table Independent List"] E2["Child Table Independent List
(Linked by master table ID)"] E3["Master Table Independent Form"] E4["Child Table Independent Form"] E1 --> E2 E3 --> E4 end

Mode Applicable Scenarios

Mode	Use Case	User Experience	Representative Business
Standard Mode	Small master-child data volume, master+child need to be filled together	⭐⭐⭐⭐ Smooth operation	Surveys+Questions, Config+Config Items
Embedded Mode	Need to quickly view child data without navigating away	⭐⭐⭐⭐⭐ High info density	Work Orders+Processes, Tasks+Subtasks
ERP Mode	Master and child each have independent business logic, large data volume	⭐⭐⭐ High flexibility	Purchase Orders+Details, Sales Orders+Details

Tree Table Code Generation

graph LR DEPT["Department Table
id / parent_id / name"] GEN["Code Generator
Recognizes parent_id field"] OUT["Generate Tree Table Page
el-tree + Drag & Drop Sorting"] DEPT --> GEN --> OUT

Supports unlimited levels, auto-generates expand/collapse, drag-and-drop sorting, add child node, and other features.

uni-app Code Generation

Generate complete page code for mobile, supporting:

List pages (pull-to-refresh, load more)
Form pages
Detail pages
API request encapsulation

Frontend Version Support

Generation Target	Vue3 Admin	Vben5	Vue2	uni-app
Single Table CRUD	✅	✅	✅	✅
Master-Child Standard	✅	✅	✅	❌
Master-Child Embedded	✅	✅	✅	❌
Master-Child ERP	✅	✅	✅	❌
Tree Table	✅	✅	✅	❌

Usage Process

Create table structure in the database
Import tables in the “Code Generation” menu
Configure generation options (module name, business name, class name, generation mode)
Preview and generate code
Copy code to the project, configure menu to use

BPM Workflow

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

BPM Workflow is the enterprise’s “approval hub” — leave requests, reimbursements, procurement, contracts, seal usage… almost any scenario requiring “multi-level approval” can be modeled and processed here. Based on the Flowable engine, it provides DingTalk/Feishu-style and BPMN dual designers, allowing non-technical personnel to design processes as well.

In one sentence: Say goodbye to WeChat approvals, email approvals, and paper approvals — turn approval processes into structured, traceable systems.

Problems Solved

Pain Point	How BPM Solves It
Approval processes rely on verbal/WeChat communication, no records	All approvals leave traces, every step is traceable
Approval rules rely on human memory, prone to omissions	Process templates solidify rules, auto-route to correct approvers
Cross-department approval communication costs are high	Auto-routing, no manual notifications needed
Overdue approvals with no follow-up	Auto-reminders for overdue items, supports auto-approval/skip
Organizational changes cause approver changes	Approvers dynamically calculated by role/department, not hardcoded to specific people

User Roles

graph LR subgraph Roles ADMIN["Process Administrator
Design process templates
Deploy and publish processes"] APPLICANT["Initiator
Submit applications
View approval progress
Cancel applications"] APPROVER["Approver
Approve/Reject/Transfer/Add-sign
View pending/completed tasks"] COPYER["CC Recipient
Receive approval result notifications
No action required"] end

Feature Collaboration Flow

sequenceDiagram participant A as Initiator participant F as Process Engine participant P1 as Approver 1 (Dept Manager) participant P2 as Approver 2 (Finance Manager) participant B as Business System (e.g. ERP) A->>F: Initiate Process (e.g. Purchase Request) F->>B: Link Business Data (Purchase Order ID) F->>P1: Push Pending Task P1->>F: Approve F->>P2: Push Pending Task P2->>F: Approve F->>B: Callback: Process Complete, Update Business Status F->>A: Notification: Application Approved Note over F: If any approver rejects
process returns to initiator

Dual Designer Comparison

graph TB subgraph SIMPLE["SIMPLE Designer (DingTalk/Feishu Style)"] S1["Drag-and-drop operation"] S2["Suitable for simple approval chains"] S3["Low learning curve"] S4["Usable by non-technical staff"] end subgraph BPMN["BPMN Designer"] B1["Standard BPMN 2.0"] B2["Supports complex branches/parallel flows"] B3["Requires some learning"] B4["For technical staff"] end SIMPLE -.->|Complex scenarios can upgrade to| BPMN

Feature	SIMPLE Designer	BPMN Designer
Learning Curve	⭐ Very Low	⭐⭐⭐ Medium
Target Users	Business staff, HR, Admin	Developers, Process Experts
Supported Nodes	Approval, CC, Conditional Branch	All BPMN 2.0 Nodes
Parallel Branch	❌	✅
Inclusive Branch	❌	✅
Sub-process	❌	✅

Full Approval Operations

Process Control Capabilities

Control Type	Description	Typical Scenario
Conditional Branch	Route to different approval paths based on form data	Amount < 5000 skips CEO approval
Parallel Branch	Multiple people approve simultaneously, proceed only when all approve	Multi-department parallel countersign
Inclusive Branch	Multiple people approve simultaneously, proceed when any approves	Or-sign scenario
Trigger Node	Auto-execute service tasks	Auto-create ERP document after approval
Delay Node	Wait specified time before continuing	Remind 7 days before contract expiration
Timeout Approval	Auto-process on timeout	Auto-approve/reject if not processed within 48 hours
Auto Reminder	Scheduled reminder for pending tasks	Push pending task summary every morning at 9

Integration with Business Systems

graph TB BPM["BPM Process Engine"] subgraph Integration Scenarios ERP_APPROVAL["ERP Purchase Approval
Purchase Order → BPM Approval → Auto Inbound"] CRM_APPROVAL["CRM Contract Approval
Contract Draft → BPM Approval → Contract Effective"] OA_APPROVAL["OA General Approval
Leave/Reimbursement/Seal Usage/Out of Office"] end BPM --> ERP_APPROVAL BPM --> CRM_APPROVAL BPM --> OA_APPROVAL

Integration Method: Business modules initiate processes, query approval status, and handle approval callbacks through APIs provided by BPM, without needing to concern themselves with Flowable’s underlying details.

Message Queue

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

Message queue is the “central nervous system” for asynchronous communication between subsystems. When ERP outbound needs to notify WMS to update inventory, when mall payment success needs to award points to members — all these cross-module asynchronous collaborations are completed through the message queue.

Design Philosophy: Business code only depends on the yudao-spring-boot-starter-mq abstract interface; switching the underlying implementation only requires changing one line of configuration.

Suitable Users

User Profile	Recommended Solution
Development/Debugging Phase	Spring Event (default, zero dependencies)
Small & Medium Projects	Redis Stream (persistent, supports consumer groups)
Enterprise Projects	RabbitMQ (stable & reliable, mature operations)
High-Throughput Scenarios	RocketMQ (Alibaba ecosystem, distributed transactions)
Big Data Scenarios	Kafka (logs, event tracking, data pipelines)

Architecture Design

graph TB subgraph BusinessLayer["Business Code Layer (depends only on abstraction)"] P["Producer
MessageProducer.send()"] C["Consumer
MessageConsumer.onMessage()"] end subgraph AbstractionLayer["Abstraction Layer yudao-spring-boot-starter-mq"] API["Unified API
Message / MessageProducer / MessageConsumer"] end subgraph ImplementationLayer["Implementation Layer (Choose One of Five)"] SE["yudao-spring-boot-starter-mq-spring-event
Spring Event (Default)"] REDIS["yudao-spring-boot-starter-mq-redis
Redis Stream"] RABBIT["yudao-spring-boot-starter-mq-rabbitmq
RabbitMQ"] ROCKET["yudao-spring-boot-starter-mq-rocketmq
RocketMQ"] KAFKA["yudao-spring-boot-starter-mq-kafka
Kafka"] end P --> API C --> API API --> SE API --> REDIS API --> RABBIT API --> ROCKET API --> KAFKA

Five Implementation Comparison

Implementation	Persistence	Consumption Mode	Use Case	Switch Config
Spring Event	❌ In-memory	Broadcast	Development/Debugging	Default
Redis Stream	✅	Cluster/Broadcast	Small & Medium projects	`yudao.mq.type=redis`
RabbitMQ	✅	Multiple modes	Enterprise projects	`yudao.mq.type=rabbitmq`
RocketMQ	✅	Cluster/Broadcast/Ordered	High throughput, transactional messages	`yudao.mq.type=rocketmq`
Kafka	✅	Partition-based	Big data, logs	`yudao.mq.type=kafka`

Usage Examples

Define Message

// 1. Define message class, implement Message interface
@Data
public class OrderPaidMessage implements Message {
 private Long orderId;
 private Long userId;
 private Integer amount;
}

Send Message

@Resource
private MessageProducer messageProducer;

public void payOrder(Long orderId) {
 // Business processing...

 // Send message
 OrderPaidMessage message = new OrderPaidMessage();
 message.setOrderId(orderId);
 message.setUserId(getCurrentUserId());
 message.setAmount(order.getAmount());
 messageProducer.send(message);
}

Consume Message

@Component
public class OrderPaidConsumer implements MessageConsumer<OrderPaidMessage> {

 @Override
 public void onMessage(OrderPaidMessage message) {
 // Award points
 memberService.addPoints(message.getUserId(), message.getAmount());

 // Update inventory
 stockService.decreaseStock(message.getOrderId());
 }
}

Typical Message Flow Between Subsystems

sequenceDiagram participant MALL as Mall Module participant MQ as Message Queue participant WMS as Warehouse Module participant MEMBER as Member Module MALL->>MALL: User payment successful MALL->>MQ: Send "Order Paid" message MQ->>WMS: Consume message → Deduct inventory MQ->>MEMBER: Consume message → Award points Note over WMS,MEMBER: Two consumers execute independently, no interference

Switching Method

Just modify the configuration file:

# Switch from Spring Event to Redis Stream
yudao:
 mq:
 type: redis  # Change to redis / rabbitmq / rocketmq / kafka

No business code changes needed.

Pay Payment Center

Mon, 01 Jan 0001 00:00:00 +0000

Core Positioning

The Pay Payment Center is the platform’s “unified checkout counter.” The mall sells goods and needs to collect payments, ERP procurement needs to make payments, member top-ups need to collect payments — all these payment and collection scenarios are handled uniformly through the Payment Center, without business modules needing to care whether the underlying payment method is WeChat Pay or Alipay.

In one sentence: Integrate with the Payment Center once, and all business modules can collect and make payments.

Problems Solved

Pain Point	How Payment Center Solves It
Each business separately integrates WeChat/Alipay	Unified integration once, all businesses reuse
Payment channel switching requires changing business code	Channel changes are transparent to business
Payment callback handling is scattered	Unified callback → dispatch to each business module
Payment records are nowhere to be found	Payment Center records all transactions, unified reconciliation

User Roles

graph LR subgraph Roles DEV["Developer
Integrate payment APIs
Handle payment callbacks"] ADMIN2["Operations/Finance
View payment records
Process refunds
Reconciliation"] ENDUSER["End User
Initiate payments
View payment results"] end

Architecture Design

graph TB subgraph BusinessLayer["Business Modules (Payment Callers)"] MALL["Mall
Order Payment"] ERP2["ERP
Purchase Payment"] OTHER["Other Modules
Top-up/Transfer"] end subgraph PaymentCenter["Payment Center yudao-module-pay"] API_LAYER["API Layer
PayOrderApi / PayRefundApi"] CHANNEL["Channel Adapter Layer
PayClient Unified Client"] CALLBACK["Callback Handling Layer
Unified Callback → Dispatch to Business"] end subgraph ChannelLayer["Payment Channels"] WXPAY["WeChat Pay
Official Account/Mini Program/QR Code"] ALIPAY["Alipay
PC/Wap/Transfer"] MOCK["Mock Payment
For development/debugging"] end BusinessLayer --> API_LAYER API_LAYER --> CHANNEL CHANNEL --> ChannelLayer ChannelLayer --> CALLBACK CALLBACK --> BusinessLayer

Payment Application Design

graph TB subgraph AppIsolation APP1["Payment App: Mall Orders
Callback URL: /mall/order/callback
Order Prefix: MALL-"] APP2["Payment App: ERP Procurement
Callback URL: /erp/purchase/callback
Order Prefix: ERP-"] APP3["Payment App: Member Top-up
Callback URL: /member/recharge/callback
Order Prefix: MBR-"] end

Each business module corresponds to a “payment application” with independent callback URL and order number prefix, ensuring payment callbacks are accurately routed to the correct business processing logic.

Full Payment Flow

sequenceDiagram participant U as User participant BIZ as Business System (Mall) participant PAY as Payment Center participant CH as Payment Channel (WeChat/Alipay) U->>BIZ: Submit order, click pay BIZ->>PAY: Create payment order PayOrderApi PAY->>CH: Initiate payment request CH-->>U: Display payment page U->>CH: Complete payment (scan/password) CH-->>PAY: Async callback: Payment successful PAY->>PAY: Update payment order status PAY->>BIZ: Callback notification: Order paid BIZ->>BIZ: Update order status BIZ-->>U: Display payment success

Supported Payment Methods

Channel	Payment Method	Use Case
WeChat Pay	Official Account Payment	WeChat Official Account H5 store
WeChat Pay	Mini Program Payment	WeChat Mini Program store
WeChat Pay	Transfer	Commission withdrawal, refunds
Alipay	PC Payment	PC-side store
Alipay	Wap Payment	Mobile H5 store
Alipay	Transfer	Commission withdrawal, refunds
Mock Payment	Mock	Development/debugging, no real account needed

Dependencies

Mall E-Commerce → Pay Payment Center ← ERP Purchase-Sales-Inventory
 ↑
 System Management Module (Permissions)

Both Mall and ERP depend on the Payment Center, which depends on the System Management module for permissions and configuration management.

Changelog

Mon, 01 Jan 0001 00:00:00 +0000

Version Evolution

RuoYi-Vue-Pro started from v2.0.0 and has been continuously iterating to date, with a total codebase of approximately 260,000 lines (160,000 lines of source code, 60,000 lines of comments, 1,121+ unit tests).

v2.6.1 (2025-07-19) Key Updates

Large-Scale Vben5 + Ant Design Migration:

Migration Module	Status
BPM Workflow	✅ Completed
CRM Customer Management	✅ Completed
Pay Payment Center	✅ Completed
Member Center	✅ Completed
AI Large Model	✅ Completed
Vben5 + Element Plus Code Generation Examples	✅ Added

Monthly Update Records

Time	Major Updates
2026-05	System optimization and bug fixes
2026-04	Feature iteration
2026-03	Feature iteration
2026-02	Feature iteration
2026-01	Feature iteration
2025-12	Feature iteration
2025-11	Feature iteration
2025-10	Feature iteration
2025-09	Feature iteration
2025-08	Feature iteration
2025-07	v2.6.1: Large-Scale Vben5 + Ant Design Migration

Technical Metrics

Metric	Value
Total Lines of Code	259,995
Source Code Lines	161,332
Comment Lines	59,755
Unit Tests	1,121+
Business Subsystems	14
Total Database Tables	300+
Supported Frontend Versions	4 (Vue3 / Vben5 / Vue2 / uni-app)