Analysis Mode-Inventory System Design Example

Design and cutting of inventory transaction in a medium-sized ERP System

Warehouse design:

The detailed specification of this section in BPML can be used for reference. This design example does not conform
Asset warehouse: parameters related to cost calculation
Supplier inventory or supplier ID: considerations similar to consignment Management Model
These additional fields are only used to indicate other logic-related settings based on the warehouse.

Transaction:

Inventory Period: Set the period for the completion of monthly and periodic inventory carry-over operations (corresponding to the effective period mentioned by Martin in the accounting model)
Inventory period code: uniquely identifies the inventory period, such as 200801, 200803, and so on
Period type
Period number: In this example, the period number starts from 1 for each year.
Period status: corresponding to business operations such as opening, closing, and closing accounts during the inventory period
General Ledger period: cost-related settings, during which the cost during the inventory period is included
Status during the cost period and status during the system period: the same setting is used during the inventory period, cost period, and period, and different status fields are used for representation.
Note: You can set values more flexibly. For example, when the period type is Cycle, you can use two fields, "interval" + "interval unit, for example, every 3 weeks, every month, every quarter, etc.
Transaction Source Type: The materials are transferred from the source database to the target database during the database migration operation. The source type of the purchased and received warehouse is the purchase order, receiving order, and so on.
Transaction type: Warehouse dump, warehouse receiving and warehouse receiving, workshop ticket dispatching, sales warehouse picking and other transaction types
Inventory transaction: Inventory transaction master table
Transaction No.: The transaction ID is automatically generated and provided to the user (so the transaction ID is not used) to uniquely mark the transaction. For example, TR2008030001 and TR2008030002
Transaction time and submission time: the concept of transaction occurrence time and effective time mentioned by Martin
Transaction source Ticket No.: for example, the source type is the specific receipt Ticket No.
Conversion Rate: for example, gas and liquid materials may have loss, volatility, consumption rate, and so on during dumping and other operations.
Transaction details: Specific Material Transaction status in an inventory transaction
Source warehouse, source warehouse, target warehouse, and target warehouse: they may be empty for different transaction types.
Source Ticket No., source ID, and Source Project No.: for example, when the source type is purchased and received into the warehouse, these fields store the receiving Ticket No., receiving ticket ID, and receiving ticket detail Project No.
Reserved quantity: for example, a certain amount of product inventory is reserved to be frozen when a warehouse picking order is opened to ensure that the warehouse picking and delivery are completed (that is, the transaction is switched to the finished status, and the interval may be relatively long) at least this number of products exist (of course not necessarily designed in this way)
Transaction Unit Price, transaction currency, and transaction cost: settings related to cost calculation (intentional Redundancy Design)

This is a simple and practical design method. Inventory transactions and transaction details are the core tables. The business model during the inventory period is basically the general operation standard of the industry. The transaction source type and transaction type are used to track transactions, they can design more complex and flexible rule settings for transactions. For transaction types, SAP uses the mobile type to solve the problem. The basic effect is similar to this, but the rule settings are more complex, it is more flexible to use
Some minor aspects:
1. Two solutions: a.) The number in the transaction details can be negative. For example, a positive number is used for warehouse receiving and a negative number is used for warehouse picking. B.) the number of transaction details is all expressed in positive numbers. The logic of output and warehouse receiving (I .e., positive and negative relationship) is included in the transaction type. Solution a should be more flexible, because solution B implicitly binds this logic; solution a will also result in consistent summary calculation algorithms for transactions (I .e., unified addition calculation ), SQL summary reports are also flexible (for example, the SUM function is simple), but more rule settings can be made to explicitly express this logic.
2. the transaction principle in finance is basically the same as here, but there is a significant difference: financial transactions must be configured through subjects to strictly ensure the balance of accounts, and inventory transactions are not necessary, you only need to strictly record the movement of the asset to indicate that it does not appear or disappear for no reason. For cost calculation, it is similar to finance
3. in this example, the main data is factory-based data. This is not flexible enough. Do not be misled. We should follow the BPML and B2MML specifications for more flexible design. This is also true for others, such as cost and general ledger settings
4. theoretically, the current inventory value and other data should be calculated based on the transaction dynamics. However, in most cases, redundant tables are designed to improve performance, or the Application Server caches the data in the memory, the following describes an important design.

Inventory profit and loss:

Profit and Loss during inventory period: Profit and loss are measured in the inventory period.
Profit and Loss details during inventory: Detailed list of profit and loss, which can also be expressed by positive and negative relationships of quantity in the warehouse receiving and picking type
This design can be used to quickly obtain the current inventory balance and the balance during each historical inventory period. In addition, the usage can also be ambiguous from the perspective of Design. .) it can be used as a redundant design for the current inventory of any day during each inventory period, so there is no need for profit and loss details during the inventory period, because it basically corresponds to the transaction details, in addition, the data must be updated synchronously when a transaction occurs. B .) it can be used as a profit and loss record for each inventory check. In this way, the profit and loss details are required and have no relationship with each inventory transaction. The information expressed is only the balance amount of the previous period and the initial amount of the current period, therefore, the current inventory of any day during the period still needs to be processed by another redundant table or Application Server cache.

Note:
1. although the table structure in the above example is simple, it can also design a variable business operation flow to adapt to different job environments. This is due to this business problem, data Models, object models, and conceptual models differ greatly. data models cannot reflect the status of conceptual models.
For example, to work with QC, SAP can configure the warehouse as GR freeze inventory, non-restricted use inventory and quality inspection inventory. For materials that require quality control, the purchased materials are first moved to the GR freeze database by moving type 103, indicating that these materials are not available because quality control has not been completed; after the QC passes, move type 105 to dump the materials from the GR freeze database to the non-restricted stock, so that they can be used. For inspection-free materials, use mobile 101 to directly ship the goods to the unrestricted inventory. This business process design can also be implemented with slight adjustments to the example design. Inventory transactions and transaction details are a type of abstract object with a relatively high level. How to use them to implement specific business processes is flexible and changeable
2. Other SAP mobile types
104 is used to offset 103; 106 is used to offset 105, and so on. This is similar to Martin's reverse offset and differential offset modes in the analysis mode. The user determines whether to reverse offset or differential offset is used.
124 supplier return, 125 is used to offset 124, 122 (123), 161 (162) and so on are all types of return
From the design of SAP, the mobile type is also a relatively high abstract concept, which can be flexibly used to solve various problems in the conceptual model.