We need to record every business event that generates data which can be useful to manage the enterprise. Thus, each event is assigned a specific number and all its details are recorded, often in a named business document. For example, for customer return event, we need to assign a customer$\_$return$\_$number, and record date, time, delivery note against which the items are returned $($which will link to customer info and sales$\_$order as well$).$ item$($s$)$ returned, quantity returned, accepted to restock, quantity scrapped $($e$.$g$,$ expired or damaged items$),$ quantity to be returned to the vendor $($e$.$g$.,$ defective material$).$ We will create a customer$\_$return$\_$note to store and access this information as needed. The same applies to other events as well. Further, it plays an important part in providing a foundation for the ERD. Ultimately, both activity decomposition and ERD have to match and work together. And we verify that in the CRUD matrix.

Going forward, you can limit the scope as follows. This also provides you the right tips to get the job done. Be sure to view the Warehouse$>$Receiving decomposition I placed in this module as well.

Sales: Limit to Sales Order Management, Pick$-$Slip Scheduling, Customer Data Management, Product and Catalog Data Management, Territory and Sales Force $($Data$)$ Management.

Exclude sales promotion, clearance sales.

Purchasing: Limit to Annual Planning $($under it Current Year Sales Totals, Forecast for the Next Year, estimate year$-$end stock$),$ ABC analysis, Manage Inventory Policy, Net requirement for the next year$)$; Purchase Order Management $($sending inquiry to vendors, getting bids, negotiating, creating purchase orders$),$ Vendor $($data$)$ Management, Inventory Management $($review levels and update Inventory Policy Table$).$

Warehouse: Receiving, storage and picking, packing, delivery, customer return

Exclude walk in sales. Physical Inventory Verification $($optional with zero points$)$ Summary of problem definition, identify scope. Assume that from this point onward the scope is limited to purchasing, warehousing, and sales.

Context Diagram $-$ showing the interactions of the proposed system with other actors$/$systems and any associated data exchange.

Critical success factors and processing requirements for each area

List of events for each major area. Clearly identify all external, internal, and temporal events. For each event list event$-$name, trigger, activity that handles it$,$ and any remarks.

List of objects identified for the system

Detailed functional and process decomposition for each area listing aggregate activities, and clearly identifying M $($manual$)$; O$,$ E $($online$,$ elementary$)$; B$,$ E $($batch$,$ elementary$)$; O$,$ NE $($online$,$ nonelementary$)$; and B$,$ NE $($batch$,$ nonelementary$)$ activities. As you know elementary activities are those $($programs$)$ that write, delete, or update data in the database. If an activity just reads data it is nonelementary. On the other side, a batch activity processes a large number of records, such as making a monthly report or inventory list, while an online activity performs a single business transaction and may access a few related records.