Enterprise management office platform system based on cloud ERP management

Abstract

The invention relates to the technical field of enterprise management office, in particular to an enterprise management office platform system based on cloud ERP management, and the system comprises a business event tracing module which is used for analyzing multiple business events, obtaining a JSON format data stream from a business system interface, and extracting a book warehousing event, an order generation event and a client signing event. According to the invention, various specific operations in enterprise operation, such as book storage, are converted into an immutable atomized service event stream containing complete context information, and a multi-party subscription and processing mechanism is established. Therefore, the direct causal relationship between the business operation and the financial influence is constructed, and the atomicity of the cross-system operation such as inventory deduction and account receivable voucher generation is ensured, that is, all operations are successful or rollback together; the problems of data inconsistency and delay caused by batch processing or interface calling failure of a traditional enterprise resource planning system are solved, and real-time industry and financial integration is achieved.

Description

Technical Field

[0001] This invention relates to the field of enterprise management and office technology, and in particular to an enterprise management and office platform system based on cloud ERP management. Background Technology

[0002] Enterprise management and office technology refers to a set of technologies that utilize computer science, network communication, and data processing to support, automate, and optimize the daily operations and management activities of enterprises or organizations. It is used to integrate and manage financial, supply chain, operations, reporting, manufacturing, and human resources activities.

[0003] Current enterprise management office technologies typically employ a modular design, with each module, such as finance, inventory, and sales, having its own independent database. Data synchronization between these modules relies on scheduled batch processing tasks or point-to-point interface calls. If a synchronization task is interrupted during execution, or a network interface call fails, inconsistencies in data status between different systems will occur. Furthermore, distributors, warehouses, and production units at various levels often rely solely on orders from their direct downstream customers for demand forecasting and replenishment decisions. This hierarchical transmission and processing of information leads to the distortion and amplification of demand signals. A small fluctuation in demand in an end market may escalate into a massive order fluctuation by the time it reaches the upstream supplier, triggering a bullwhip effect. Therefore, improvements are needed. Summary of the Invention

[0004] The purpose of this invention is to address the shortcomings of existing technologies by proposing an enterprise management office platform system based on cloud ERP management.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: A cloud ERP-based enterprise management office platform system includes: The business event tracing module is used to parse multiple business events, obtain JSON format data streams from business system interfaces, extract book entry events, order generation events, and customer receipt events, combine the extracted fields with timestamps and operator identification, generate globally unique serial numbers by combining timestamps with distributed node identifiers, append the globally unique serial numbers to the combined data, serialize the data structure into a byte stream, push it to the target topic message queue, and establish an atomic business event stream. The business status aggregation module is used to create a financial consumer group and an inventory consumer group based on the atomic business event flow. These groups listen to customer receipt events and delivery events, respectively. The financial consumer group calls the preset debit and credit account mapping rules, fills the entry amount field according to the event amount, and generates a structured accounts receivable financial voucher. The inventory consumer group performs a subtraction operation on the inventory value of the inventory network node according to the number of delivery events, replays all events sequentially from the previous snapshot point, accumulates and calculates the current inventory quantity and account balance, and establishes an aggregated business status snapshot.

[0006] Preferably, the system further includes: The supply chain demand smoothing module is used to periodically push the sales records of the downstream distributor's POS system to the central database through the API gateway based on the aggregated business status snapshot, link it to the upstream printing plant node and the group's main warehouse node, set a time decay factor, assign the highest weight to the most recent period's sales data, and decrease the weight of the previous period's data according to an exponential law, and sum the weighted sales data of all historical periods to generate a smoothed demand forecast signal. The inventory collaborative replenishment module is used to extract the standard deviation of the smoothed demand forecast signal as the demand volatility input, convert the preset service level requirements into a safety factor, and combine the unit inventory holding cost and single transportation cost values ​​into the formula for solution. It dynamically calculates the minimum and maximum inventory points for each node in the inventory network. When the node's inventory is lower than the minimum inventory point, the current inventory is subtracted from the maximum inventory point value to obtain the replenishment quantity. The module combines the target warehouse and supplier information to generate a replenishment order and establish a collaborative replenishment scheduling instruction.

[0007] Preferably, the business event tracing module includes: The event data parsing submodule, based on multiple business events, traverses the JSON tree through key-value pair matching to locate and extract the corresponding node data for book entry events, order generation events, and customer receipt events, generating a set of fields including event type, document number, and amount to obtain structured business data; The event information enhancement submodule, based on the structured business data, concatenates the extracted fields with the timestamp obtained from the system clock and the operator identity identifier extracted from the user session, uses the timestamp value and the preset distributed node identifier to perform bit operations to generate a globally unique sequence number, and adds the globally unique sequence number as a new field to establish a complete event message body; The event message publishing submodule converts the complete event message body into a binary byte array, and then sends the byte array as the message payload to the preset target topic partition of the message queue through a network socket to establish an atomic business event flow.

[0008] Preferably, the service status aggregation module includes: The multi-source event subscription submodule, based on the atomic business event flow, sets up a financial consumer group and an inventory consumer group and assigns different consumer IDs, so that the financial consumer group subscribes to the customer receipt event topic and the inventory consumer group subscribes to the shipment event topic, and distributes the received messages to the corresponding processing logic to obtain the classified business instructions; The business status change submodule, based on the classified business instructions, when receiving a customer receipt instruction, queries the preset debit and credit account mapping table, fills the accounting entry template with the event amount, and when receiving a delivery instruction, performs a subtraction operation on the inventory value field of the corresponding node in the inventory network to obtain discrete status change records. The State Replay Snapshot Submodule loads the latest snapshot point data from persistent storage based on the discrete state change records, sequentially reads all discrete state change records after the snapshot point, adds the numerical changes in the records to the snapshot data, generates the current inventory and account balance, and establishes an aggregated business state snapshot.

[0009] Preferably, the supply chain demand smoothing module includes: The downstream sales acquisition submodule, based on the aggregated business status snapshot, calls the API gateway interface to periodically push the sales records of the downstream distributor's POS system to the central database. It then matches the upstream printing plant node and the group's central warehouse node through the document association fields to generate a time-series data table including time, location, and sales volume, and obtains the associated sales dataset. The demand time-weighted submodule, based on the associated sales dataset, sets a time decay factor, multiplies the most recent period sales data by the time decay factor, multiplies the square of the time decay factor by the next most recent period sales data, and so on, until all historical data are traversed to obtain a weighted historical demand sequence.

[0010] Preferably, the supply chain demand smoothing module further includes: The demand signal aggregation submodule, based on the weighted historical demand sequence, sums all values ​​in the weighted historical demand sequence to obtain the aggregated value, and uses the aggregated value as the basic forecast value for the next period to generate a smoothed demand forecast signal.

[0011] Preferably, the inventory collaborative replenishment module includes: The replenishment parameter calculation submodule calculates the standard deviation of the smoothed demand forecast signal time series as the demand volatility input based on the smoothed demand forecast signal, queries the standard normal distribution table, converts the preset service level requirement into the corresponding Z score as the safety factor, and obtains the dynamic safety stock factor. The inventory threshold decision submodule, based on the dynamic safety stock factor, substitutes the dynamic safety stock factor, unit inventory holding cost, single transportation cost, and lead time into the periodic inventory calculation formula to solve for the minimum and maximum inventory points for each node in the inventory network, and obtains the node replenishment strategy threshold.

[0012] Preferably, the inventory collaborative replenishment module further includes: The replenishment instruction generation submodule periodically detects the current inventory level of a node based on the node replenishment strategy threshold. When the node inventory level is lower than the minimum inventory level, the current inventory level is subtracted from the maximum inventory level to obtain the replenishment quantity. The module combines the target warehouse and supplier information to generate structured replenishment order data and establishes a collaborative replenishment scheduling instruction.

[0013] Compared with the prior art, the advantages and positive effects of the present invention are as follows: In this invention, by transforming specific operations in enterprise operations, such as book warehousing, into atomic business event flows containing complete contextual information and immutable, and establishing a multi-party subscription and processing mechanism, a direct causal relationship between business operations and financial impacts is constructed. This ensures the atomicity of cross-system operations such as inventory deduction and accounts receivable voucher generation—that is, either all succeed or all are rolled back—eliminating data inconsistency and delays caused by batch processing or interface call failures in traditional enterprise resource planning systems. This achieves real-time business-finance integration, and the complete event log provides irrefutable audit traceability evidence for all system state changes. Building upon this foundation, the system further utilizes the real sales records of downstream distributors and weights and sums historical data by setting a time decay factor to generate a smooth demand forecast signal that closely reflects the actual market situation. This signal is transmitted to the upstream of the supply chain, suppressing the phenomenon of demand fluctuations amplified step by step due to information distortion, i.e., the bullwhip effect. Finally, based on this smoothed signal and combined with demand volatility, service level, and cost data, the minimum and maximum inventory points of each inventory node are dynamically solved, driving automated collaborative replenishment. This transforms the inventory management of the entire supply chain from a passive, isolated forecast-based model to a proactive, globally optimized model, reducing the risk of inventory backlog and stockouts. Attached Figure Description

[0014] Figure 1 This is a system flowchart of the present invention. Detailed Implementation

[0015] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention.

[0016] Please see Figure 1 This invention provides a technical solution: an enterprise management office platform system based on cloud ERP management, comprising: The business event tracing module is used to parse multiple business events, obtain JSON format data streams from business system interfaces, extract book entry events, order generation events, and customer receipt events, combine the extracted fields with timestamps and operator identification, generate globally unique serial numbers by combining timestamps with distributed node identifiers, append the globally unique serial numbers to the combined data, serialize the data structure into a byte stream, push it to the target topic message queue, and establish an atomic business event stream. The business status aggregation module is used to create financial consumer groups and inventory consumer groups based on atomic business event flows. These groups listen to customer receipt events and delivery events, respectively. The financial consumer group calls the preset debit and credit account mapping rules, fills the entry amount field according to the event amount, and generates structured accounts receivable financial vouchers. The inventory consumer group performs subtraction on the inventory value of the inventory network node according to the number of delivery events, replays all events sequentially from the previous snapshot point, accumulates and calculates the current inventory quantity and account balance, and establishes an aggregated business status snapshot. The supply chain demand smoothing module is used to periodically push sales records from downstream distributors' POS systems to the central database via API gateway based on aggregated business status snapshots, linking them to upstream printing plant nodes and group central warehouse nodes. It sets a time decay factor, assigns the highest weight to the most recent period's sales data, and decreases the weight of previous period's data exponentially. It sums up the weighted sales data of all historical periods to generate a smoothed demand forecast signal. The inventory collaborative replenishment module is used to extract the standard deviation of smoothed demand forecast signals as the input for demand volatility, convert preset service level requirements into a safety factor, and combine the unit inventory holding cost and single transportation cost values ​​into the formula for solution. It dynamically calculates the minimum and maximum inventory points for each node in the inventory network. When the node's inventory is lower than the minimum inventory point, the current inventory is subtracted from the maximum inventory point value to obtain the replenishment quantity. The module combines the target warehouse and supplier information to generate a replenishment order and establish a collaborative replenishment scheduling instruction.

[0017] The business event tracing module includes: The event data parsing submodule, based on multiple business events, traverses the JSON tree through key-value pair matching to locate and extract the corresponding node data for book entry events, order generation events, and customer receipt events, generating a set of fields including event type, document number, and amount to obtain structured business data; The event information enhancement submodule, based on structured business data, concatenates the extracted fields with the timestamp obtained from the system clock and the operator identity identifier extracted from the user session. It uses the timestamp value and the preset distributed node identifier to perform bit operations to generate a globally unique sequence number, and adds the globally unique sequence number as a new field to establish a complete event message body. The event message publishing submodule converts the complete event message body into a binary byte array, and then sends the byte array as the message payload to the preset target topic partition of the message queue through a network socket to establish an atomic business event flow.

[0018] Specifically, based on multiple business events, an event pattern mapping rule base is first configured. This rule base is stored in the form of database tables, containing fields such as event identifier, target field name, and JSON path expression. For example, for the book entry event, the rule might be: {Event identifier: "BOOK_INBOUND", Target field: {"Document number": " When a JSON data stream is received, the top-level eventType field is parsed first to identify the event type. Then, the corresponding parsing rule set is loaded from the rule base. The depth-first traversal algorithm is used to navigate the JSON tree along the JSON path expression defined in the rule. For example, for the path "$.body.items[0].totalAmount", the parser will first locate the "body" key of the root node, then access the "items" array in its value, then access the first element of the array, and finally extract the value corresponding to the "totalAmount" key. During the extraction process, the data type of the extracted value is validated to ensure that the amount field is a floating-point number and greater than zero, and the document number field conforms to the predefined string format (for example, starting with 'RK' followed by 10 digits). All the key-value pairs that are successfully extracted and validated, namely event type, document number and amount, are combined into a standardized internal data object to obtain structured business data.

[0019] Based on structured business data, the system first retrieves the current Unix timestamp (millisecond level) from the server's operating system kernel calls. Then, it extracts the operator's unique identifier, such as an employee ID, from the user session context or authentication token (e.g., the payload of a JWT) carrying the current business operation. These two extracted fields—the timestamp and the operator identifier—are merged with the event type, document number, and amount fields from the structured business data to form an expanded dataset. Next, to generate a globally unique sequence number, a mechanism similar to the snowflake algorithm is used. This sequence number is a 64-bit long integer, defined as follows: the first bit is the sign bit, fixed at 0; the next 41 bits are used to store the timestamp difference, i.e., the current timestamp minus a fixed epoch timestamp (e.g., 2023-01-01 at project startup). The first 10 bits (00:00:00.000) are used to store the distributed node identifier, which is obtained from a central configuration service (such as Zookeeper or Etcd) when the system starts, ensuring that each service instance has a unique ID between 0 and 1023. The last 12 bits are a sequence number within a millisecond, generated by an atomic counter that increments within the current millisecond. If the count exceeds 4095 within a millisecond, the program will wait until the next millisecond. The three parts are combined through bitwise operations, specifically calculated as: Globally Unique Sequence Number = (Timestamp Difference << 22) | (Distributed Node Identifier << 12) | Sequence Number within Milliseconds. The calculated globally unique sequence number is added as a new field named eventGlobalId to the extended data set to establish the complete event message body.

[0020] Based on the complete event message body, Google Protocol Buffers is first used as the serialization framework. The structured complete event message body object is compiled into a binary byte array according to a predefined .proto file. This .proto file describes the name, data type, and order of each field in the message body, such as `string event_type = 1; string document_id = 2; double amount = 3; int64 timestamp = 4;`. The serialization operation converts the object into a highly compressed and well-defined byte stream. Subsequently, a producer client targeting the message queue (such as Apache Kafka) is initialized, establishing a persistent TCP connection with the Kafka cluster broker via a network socket. The serialized binary byte array is used as the message payload, and the document number field from the complete event message body is specified as the message key. During sending, the Kafka producer uses this key to calculate a hash value using its internal Partitioner (e.g., the Murmur2 hash algorithm by default), and then modulo the hash value with the number of partitions in the target topic, i.e., `partition_index = hash(key) %`. The key-based partitioning strategy determines which specific partition a message will be sent to. This strategy ensures that all events related to the same document enter the same partition in sequence. Finally, the producer sends the message with the payload and target partition information through the established network socket, thus establishing an atomic business event stream.

[0021] The business status aggregation module includes: The multi-source event subscription submodule, based on atomic business event flow, sets up a financial consumer group and an inventory consumer group and assigns different consumer IDs. The financial consumer group subscribes to the customer receipt event topic, and the inventory consumer group subscribes to the shipment event topic. The received messages are distributed to the corresponding processing logic to obtain classified business instructions. The business status change submodule, based on classified business instructions, queries the preset debit and credit account mapping table when it receives a customer receipt instruction, and fills the accounting entry template with the event amount. When it receives a delivery instruction, it performs a subtraction operation on the inventory value field of the corresponding node in the inventory network to obtain discrete status change records. The State Replay Snapshot submodule loads the latest snapshot data from persistent storage based on discrete state change records, sequentially reads all discrete state change records after the snapshot point, adds the numerical changes in the records to the snapshot data, generates the current inventory and account balance, and establishes an aggregated business state snapshot.

[0022] Specifically, based on atomic business event streams, two independent Kafka consumer instances are initialized in the application, and different consumer group IDs (group.id) are configured for them. For example, the finance consumer group ID is set to finance-group, and the inventory consumer group ID is set to inventory-group. Both consumer groups subscribe to the same topic called business-events, thus being able to receive all types of business events. Each consumer instance implements message filtering in its internal processing logic. When the finance consumer group instance pulls a batch of messages from the business-events topic, it deserializes the messages one by one and checks the event type field in the content of each message. Only when the value of the event type field is equal to the customer receipt event is the complete content of the message passed to the subsequent financial processing function. For all other types of events, the offset is directly committed and ignored. Similarly, the inventory consumer group instance performs a similar operation, but its filtering condition is that the event type field must be equal to the shipping event. Through this method of logical filtering at the consumer end, the mixed event streams are accurately distributed to their respective corresponding business processing flows, thereby obtaining classified business instructions.

[0023] Based on categorized business instructions, when the financial processing logic receives a customer acceptance instruction, it uses the transaction type (e.g., "sales payment") in the instruction as a query condition to access a pre-configured debit / credit account mapping table in a relational database. This table has the structure {transaction type, summary template, debit account code, credit account code}. For example, a record might be {'sales payment', 'received payment for order number %s', '1122' (accounts receivable), '6001' (main business revenue)}. After finding a matching account code, the program instantiates an accounting entry template object. This object contains fields such as voucher number, date, summary, account code, debit amount, and credit amount. Then, it uses the event amount from the instruction to populate the debit and credit amount fields, generating two entry records (one debit and one credit). When the inventory processing logic receives a shipping instruction, it parses the warehouse ID, product SKU, and shipping quantity from the instruction. Then, it performs an atomic update operation on the inventory level table in the inventory database. The SQL statement for this operation is UPDATE stock_levels. The statement `SET quantity = quantity - [shipment quantity] WHERE warehouse_id = [warehouse ID] AND sku = [product SKU] AND quantity >= [shipment quantity]` adds an inventory check to the WHERE clause to prevent negative inventory values. These generated accounting entries or database update confirmation records constitute discrete state change records.

[0024] To achieve fast state querying based on discrete state change records, the system employs a strategy combining snapshots and event replay. This process is triggered by a scheduled task, for example, every 6 hours or when the number of new records in the event log exceeds a preset threshold. This threshold is set based on system load and recovery time objective (RTO), for example, 10,000 events. The threshold is set based on the fact that replaying 10,000 events on typical hardware takes approximately 5 seconds, which is an acceptable query latency. When the current state needs to be calculated, the system first queries the latest snapshot metadata from persistent storage (such as Redis or a distributed file system) to obtain the location of the snapshot data and the offset of the last event corresponding to that snapshot. Then, it loads the snapshot data (e.g., containing all account IDs and their balances). The system loads a hash table and inventory values ​​for all warehouse nodes and product SKU combinations into memory. Then, an event consumer is created, with its starting consumption position set to the position after the snapshot record offset. It sequentially reads all discrete state change records from that point to the end of the log from the event log and replays these events in memory. That is, based on the type and value of each record, it performs accumulation or subtraction operations on the snapshot data in memory. For example, for a customer receipt record, its amount is added to the balance of the corresponding accounts receivable account. After processing all subsequent events, the data in memory is the accurate current inventory and account balance. Finally, this calculated latest state, together with the latest offset of the current event log, is serialized as a new snapshot version and written to persistent storage, thereby establishing an aggregated business state snapshot.

[0025] The supply chain demand smoothing module includes: The downstream sales acquisition submodule, based on aggregated business status snapshots, calls the API gateway interface to periodically push sales records from downstream distributors' POS systems to the central database. It then matches the upstream printing plant node and the group's central warehouse node through document association fields, generating a time-series data table including time, location, and sales volume, and obtaining the associated sales dataset. The demand time-weighted submodule, based on the associated sales dataset, sets a time decay factor, multiplies the most recent period sales data by the time decay factor, multiplies the square of the time decay factor by the next most recent period sales data, and so on, until all historical data are traversed to obtain a weighted historical demand sequence. The demand signal aggregation submodule sums all values ​​in the weighted historical demand sequence to obtain the aggregated value, and uses the aggregated value as the base forecast value for the next period to generate a smoothed demand forecast signal.

[0026] Specifically, based on the aggregated business status snapshot, a scheduled task is configured using the cron expression 0 1* * * to automatically trigger the data collection process at 1:00 AM daily. This process sends an HTTP POST request to a pre-defined API gateway security endpoint to call the downstream distributor's POS system interface. The request header must contain a pre-shared API key (e.g., X-API-KEY: a1b2c3d4-e5f6-4a7b-8c9d-0e1f2a3b4c5d) for authentication and authorization. The distributor system returns a JSON array, where each object represents a sales record, containing fields such as transactionId, storeId, productId, quantity, and saleTimestamp. After receiving the data, each sales record is processed, and a product-source mapping table pre-built and maintained in the central database is queried through the productId field. The table structure is {productID, source type, ...}. The source node ID is used to generate a standardized record. For example, a record might be named {'ISBN-978-7-5327-8724-4', 'Printing Plant', 'YC001'}. The source node ID is then combined with the saleTimestamp (time), storeId (location), and quantity (sales volume) fields from the original record to form a standardized record. This record is then inserted into a fact table named fact_sales in the central database. The table structure is {sale_id, timestamp, location_id, sales_volume, source_node_id}. All data successfully inserted into this table within a specified time period are combined to generate a time-series data table including time, location, and sales volume, thus obtaining the associated sales dataset.

[0027] Based on the related sales dataset, an independent analysis sequence is first established for each upstream node (printing plant node or group central warehouse node) and each book product (SKU) combination, and a time decay factor is set. This factor, ranging from (0, 1), is used to adjust the weighting of historical data on future predictions. Its specific value is determined through backtesting of historical data, with the goal of minimizing the root mean square error (RMSE). For example, by testing... A series of values ​​from 0.6 to 0.95, with a step size of 0.05, show that when... At that time, the predicted RMSE was lowest over the past 12 periods, so 0.8 was selected as the time decay factor for this product. Then, past data was extracted from the related sales dataset. One cycle (e.g., Sales data for a week are denoted as a sequence. ,in This is the sales data for the most recent period. This is the sales data from the next most recent period, and so on. A time-decay weight is applied to each data point in the sequence, calculated as follows: A historical cycle ( From 1 to Weighted sales data Equal to its actual sales data Multiply by the time decay factor of The power of, i.e. For example, if the sales volume for the most recent three weeks is 100, 120, and 90 respectively, then its corresponding weighted value is , , All The weighted sales data calculated from each historical period are arranged in chronological order to obtain the weighted historical demand sequence.

[0028] Based on the weighted historical demand sequence, all values ​​in the sequence are summed to generate the predicted value for the next period. This process does not perform normalization; the weighted influence strengths are directly linearly superimposed. The calculation formula is as follows: ; in, This is for the next cycle (the 1st) The smoothed demand forecast signal calculated weekly. It is the first step calculated in the previous steps. Weighted sales data for each period, It is a pre-set time decay factor. It is the first The original sales data for each period, It is used to calculate the total number of historical periods, and the summation symbol indicates the summation from the most recent period ( ) keep accumulating until the furthest period ( For example, if we only consider the most recent three periods, the weighted historical demand sequence is {80, 76.8, 46.08}, then the aggregated value is... The calculated aggregated value, 202.88, is set as the base forecast value for the product in the next cycle at this node. This single value is the final smoothed demand forecast signal.

[0029] The inventory collaborative replenishment module includes: The replenishment parameter calculation submodule calculates the standard deviation of the smoothed demand forecast signal time series as the input of demand volatility, queries the standard normal distribution table, converts the preset service level requirements into the corresponding Z score as the safety factor, and obtains the dynamic safety stock factor. The inventory threshold decision submodule, based on the dynamic safety stock factor, substitutes the dynamic safety stock factor, unit inventory holding cost, single transportation cost and lead time into the cycle count inventory calculation formula to solve for the minimum and maximum inventory points for each node in the inventory network, and obtains the node replenishment strategy threshold. The replenishment instruction generation submodule periodically checks the current inventory level of a node based on the node replenishment strategy threshold. When the node inventory level is lower than the minimum inventory level, the current inventory level is subtracted from the maximum inventory level to obtain the replenishment quantity. The module combines the target warehouse and supplier information to generate structured replenishment order data and establishes collaborative replenishment scheduling instructions.

[0030] Specifically, based on the smoothed demand forecast signal, the standard deviation of the corresponding time series (i.e., the raw sales data of the past N periods, not the weighted data) is first calculated. This standard deviation quantifies the degree of fluctuation in historical sales demand around its average value and serves as a core input to demand volatility. Then, based on the inventory service level requirements set by the company's management (e.g., meeting 95% of customer orders), this percentage value is converted into a Z-score in a standard normal distribution. This conversion is accomplished by querying the inverse function table of the cumulative distribution function (CDF) of the standard normal distribution preloaded into system memory, or by solving the inverse function of the CDF using numerical calculation methods (such as Newton's method). For example, for a 95% service level, the Z-score obtained from the query is approximately 1.645. This Z-score is used as the safety factor, which indicates how many standard deviations above the average demand the safety stock needs to be set at in order to achieve the target service level. This Z-score is the final dynamic safety stock factor.

[0031] Based on the dynamic safety stock factor, and combined with the unit inventory holding cost (e.g., 0.5 yuan per item per week), single transportation cost (e.g., 200 yuan per order), and the average lead time promised by the supplier (e.g., 2 weeks) obtained from product master data and supplier master data, the key threshold for the replenishment strategy is dynamically calculated for each node in the inventory network (specifically for each book SKU in each warehouse). The formula for calculating the minimum inventory point is: Minimum Inventory Point = (Average Demand within Lead Time) + (Safety Stock), where the average demand within the lead time equals the weekly average demand multiplied by the number of weeks in the lead time, and the safety stock equals the dynamic safety stock factor (Z score) obtained in the previous steps multiplied by the standard deviation of demand fluctuation within the lead time. The standard deviation of demand fluctuation within the lead time is obtained by multiplying the weekly demand standard deviation by the square root of the lead time length. The formula for calculating the maximum inventory point is: Maximum Inventory Point = Minimum Inventory Point + (Average demand within the review period), where the review period is a preset inventory check interval (e.g., 4 weeks). For example, if the weekly average demand is 100, the weekly demand standard deviation is 20, the lead time is 2 weeks, the review period is 4 weeks, and the safety factor Z is 1.645, then the minimum inventory point is... Items, maximum inventory point is This process involves performing this set of calculations on each node to obtain the node replenishment strategy threshold.

[0032] Based on the node replenishment strategy threshold, a scheduled task is deployed. This task executes frequently (e.g., every 15 minutes), traversing all nodes in the inventory network, querying the current physical inventory of each node in real time, and comparing this value with the node's pre-calculated minimum inventory point. A condition is set: if the current inventory is less than the minimum inventory point, replenishment logic is triggered. The replenishment quantity is calculated by subtracting the current inventory from the node's maximum inventory point, i.e., replenishment quantity = maximum inventory point - current inventory. For example, if a node's current inventory is 240 units, its minimum inventory point is 247 units, and its maximum inventory point is 647 units, then replenishment is triggered, and the replenishment quantity is 647 - 240 = 407 items. Subsequently, based on the product's preset main supplier information (including supplier ID, contact information, purchase price, etc.) and the target warehouse information for this inventory node (warehouse address, consignee, etc.), a structured replenishment order data object is automatically generated. This object is represented in JSON format and contains key fields such as orderId, supplierId, productId, quantity, destinationWarehouseId, etc. Finally, this JSON object is pushed to the order processing system or sent directly to the supplier to establish a collaborative replenishment scheduling instruction.

Claims

1. A cloud ERP-based enterprise management office platform system, characterized in that, The system includes: The business event tracing module is used to parse multiple business events, obtain JSON format data streams from business system interfaces, extract book entry events, order generation events, and customer receipt events, combine the extracted fields with timestamps and operator identification, generate globally unique serial numbers by combining timestamps with distributed node identifiers, append the globally unique serial numbers to the combined data, serialize the data structure into a byte stream, push it to the target topic message queue, and establish an atomic business event stream. The business status aggregation module is used to create a financial consumer group and an inventory consumer group based on the atomic business event flow. These groups listen to customer receipt events and delivery events, respectively. The financial consumer group calls the preset debit and credit account mapping rules, fills the entry amount field according to the event amount, and generates a structured accounts receivable financial voucher. The inventory consumer group performs a subtraction operation on the inventory value of the inventory network node according to the number of delivery events, replays all events sequentially from the previous snapshot point, accumulates and calculates the current inventory quantity and account balance, and establishes an aggregated business status snapshot.

2. The enterprise management office platform system based on cloud ERP management according to claim 1, characterized in that, The system also includes: The supply chain demand smoothing module is used to periodically push the sales records of the downstream distributor's POS system to the central database through the API gateway based on the aggregated business status snapshot, link it to the upstream printing plant node and the group's main warehouse node, set a time decay factor, assign the highest weight to the most recent period's sales data, and decrease the weight of the previous period's data according to an exponential law, and sum the weighted sales data of all historical periods to generate a smoothed demand forecast signal. The inventory collaborative replenishment module is used to extract the standard deviation of the smoothed demand forecast signal as the demand volatility input, convert the preset service level requirements into a safety factor, and combine the unit inventory holding cost and single transportation cost values ​​into the formula for solution. It dynamically calculates the minimum and maximum inventory points for each node in the inventory network. When the node's inventory is lower than the minimum inventory point, the current inventory is subtracted from the maximum inventory point value to obtain the replenishment quantity. The module combines the target warehouse and supplier information to generate a replenishment order and establish a collaborative replenishment scheduling instruction.

3. The enterprise management office platform system based on cloud ERP management according to claim 1, characterized in that, The business event tracing module includes: The event data parsing submodule, based on multiple business events, traverses the JSON tree through key-value pair matching to locate and extract the corresponding node data for book entry events, order generation events, and customer receipt events, generating a set of fields including event type, document number, and amount to obtain structured business data; The event information enhancement submodule, based on the structured business data, concatenates the extracted fields with the timestamp obtained from the system clock and the operator identity identifier extracted from the user session, uses the timestamp value and the preset distributed node identifier to perform bit operations to generate a globally unique sequence number, and adds the globally unique sequence number as a new field to establish a complete event message body; The event message publishing submodule converts the complete event message body into a binary byte array, and then sends the byte array as the message payload to the preset target topic partition of the message queue through a network socket to establish an atomic business event flow.

4. The enterprise management office platform system based on cloud ERP management according to claim 1, characterized in that, The business status aggregation module includes: The multi-source event subscription submodule, based on the atomic business event flow, sets up a financial consumer group and an inventory consumer group and assigns different consumer IDs, so that the financial consumer group subscribes to the customer receipt event topic and the inventory consumer group subscribes to the shipment event topic, and distributes the received messages to the corresponding processing logic to obtain the classified business instructions; The business status change submodule, based on the classified business instructions, when receiving a customer receipt instruction, queries the preset debit and credit account mapping table, fills the accounting entry template with the event amount, and when receiving a delivery instruction, performs a subtraction operation on the inventory value field of the corresponding node in the inventory network to obtain discrete status change records. The State Replay Snapshot Submodule loads the latest snapshot point data from persistent storage based on the discrete state change records, sequentially reads all discrete state change records after the snapshot point, adds the numerical changes in the records to the snapshot data, generates the current inventory and account balance, and establishes an aggregated business state snapshot.

5. The enterprise management office platform system based on cloud ERP management according to claim 2, characterized in that, The supply chain demand smoothing module includes: The downstream sales acquisition submodule, based on the aggregated business status snapshot, calls the API gateway interface to periodically push the sales records of the downstream distributor's POS system to the central database. It then matches the upstream printing plant node and the group's central warehouse node through the document association fields to generate a time-series data table including time, location, and sales volume, and obtains the associated sales dataset. The demand time-weighted submodule, based on the associated sales dataset, sets a time decay factor, multiplies the most recent period sales data by the time decay factor, multiplies the square of the time decay factor by the next most recent period sales data, and so on, until all historical data are traversed to obtain a weighted historical demand sequence.

6. The enterprise management office platform system based on cloud ERP management according to claim 5, characterized in that, The supply chain demand smoothing module also includes: The demand signal aggregation submodule, based on the weighted historical demand sequence, sums all values ​​in the weighted historical demand sequence to obtain the aggregated value, and uses the aggregated value as the basic forecast value for the next period to generate a smoothed demand forecast signal.

7. The enterprise management office platform system based on cloud ERP management according to claim 2, characterized in that, The inventory collaborative replenishment module includes: The replenishment parameter calculation submodule calculates the standard deviation of the smoothed demand forecast signal time series as the demand volatility input based on the smoothed demand forecast signal, queries the standard normal distribution table, converts the preset service level requirement into the corresponding Z score as the safety factor, and obtains the dynamic safety stock factor. The inventory threshold decision submodule, based on the dynamic safety stock factor, substitutes the dynamic safety stock factor, unit inventory holding cost, single transportation cost, and lead time into the periodic inventory calculation formula to solve for the minimum and maximum inventory points for each node in the inventory network, and obtains the node replenishment strategy threshold.

8. The enterprise management office platform system based on cloud ERP management according to claim 7, characterized in that, The inventory collaborative replenishment module also includes: The replenishment instruction generation submodule periodically detects the current inventory level of a node based on the node replenishment strategy threshold. When the node inventory level is lower than the minimum inventory level, the current inventory level is subtracted from the maximum inventory level to obtain the replenishment quantity. The module combines the target warehouse and supplier information to generate structured replenishment order data and establishes a collaborative replenishment scheduling instruction.

Images