Using Java, Color, and UML to Design Sales-Related Applications
- Product-Sale Management
- Cash-Sale Management
- Customer-Account Management
For more information on Java development, visit our Java Reference Guide or sign up for our Java Newsletter.
Example is the school of mankind, And they will learn at no other.
— Edmund Burke
This chapter presents three compound components:
- Product-sale management, for businesses that collect payments by issuing invoices to customers and (eventually) getting paid
- Cash-sale management, for businesses that collect payment at the time of a sale
- Customer-account management
3.1 PRODUCT-SALE MANAGEMENT
What. For flexibility, we treat a product as a material resource with some added responsibilities. In this way, we can take any material resource and turn it into a product (this happens in some industries).
A product can be a product in the traditional sense, a service, or a combination of both.
Product-sale management supports the selling of products (goods, services, or combination of both)—on an invoicing basis, rather than on a "cash and carry" basis (as in cash-sales management).
Scope. Product-sale management starts with sales and ends with invoicing.
Steps. First, define product types and products. Second, make a sale to a customer. Third, ship products. Fourth, invoice the customer. Fifth, record the delivery of products; track and resolve delivery-problem reports. Sixth, make agreements and assessments.
Links. Deduct quantity from inventory (link with material-resource management; it interacts with inventory management). Post invoice totals (accounting management).
Mirror images. In product-sales management, we move things out of the business on an invoicing basis (from us to a customer). In material-resource management, we move things into the business on an invoicing basis (from a supplier to us).
Components. The components within product-sale management are (Figure 3-1):
- Product
- Sale to customer
- Shipment to customer
- Delivery to customer
- Invoice to customer
- Product agreement
- Product assessment
Figure 3-1 Product-sale management components.
Moment-intervals. The main moment-intervals for product-sale management are (Figure 3-2):
- Product price
- Sale to customer
- Shipment to customer
- Delivery to customer
- Delivery-problem report
- Invoice to customer
- Discount agreement
- Commission agreement
- Cost and overhead allocation
- Marketing study
- Sales forecast
- Geographic-region assignment
Figure 3-2 Summary in pink.
Interactions. The components work together to get things done. An example of inter-component interaction, "calculate direct commissions for a sales rep," is shown in Figure 3-3. A sender asks yellow sales rep to calculate its commissions, the ones coming from its own sales (called "direct" commissions). A sales-rep object asks each of its pink sales to build a list of product-sale details. Next, a sales-rep object asks each of its pink commission objects to calculate direct commissions. A commission object then matches its product descriptions and quantities with the sales details, looking for a valid match, then computes the commission for the sales of that product. Some commission objects might not be linked to a product description, in which case that commission applies across all of the product-sale details. At the end, the sales rep returns its results to the sender.
Figure 3-3 Calculate direct commissions for a sales rep.
Expansion. One could expand this compound component by adding components to support pre-sales activities, including customer and prospect rankings, test marketing activities and results, and feature tracking for future products. One could also expand it with post-sale activities including service.
3.1.1 Product
Figure 3-4 Product component.
Product. A green product is something that a business sells, is individually identifiable (it has a serial number), and is something that must be individually tracked. If a product were not individually identifiable, you would not need a green thing; instead, you could use a quantity of a blue catalog-entry-like description. Even if something were individually identifiable, if all you needed to track were quantities rather than each numbered unit itself, then again a quantity of a blue catalog-entry-like description would be sufficient. If you need to track more than just quantity, e.g., specific serialized items, then you need to manage a collection of these items. The green product could have a collection of serial numbers, or a blue catalog-entry-like description could have a collection of green serialized products.
A green product has required links to a green material resource and a blue product description. A blue product description has a required link to a blue material-resource description.
For example, consider a specific Ford F-100 truck, identifiable by its serial number, called a vehicle identification number. A green product linked to a green material-resource represents it.
Now consider a standard catalog-entry that applies to any Ford F-100 on a dealer's lot: the manufacturer is Ford, the model name is F-100, the vehicle type is truck, and so on. A blue product linked to a blue product description represents it.
A green product links to some yellow product-being-sold roles.
Product description. This is a catalog-entry-like description of a kind of material resource. A blue material-resource description is the main description; it links to a number of other supporting blue context-specific supplemental descriptions that one can add as needed. Notice that the blue tax category links to its applicable green geographic regions.
Other components use certain quantities of a product description. For example, if someone requests 20 Ford F-100 trucks, then a component might include a request detail with a quantity of 20, linked to a blue product description that applies to each Ford F-100.
Product price. A pink product price sets a price for a quantity and price unit of measure, applicable for an interval of time. It links to blue product description(s) or to green products. It also links to the yellow pricer responsible for setting that price.
You have some modeling choices when it comes to price. You can model it as an attribute in the green product (for example, the price for that red Ferrari, that one right there!) or a blue description (for example, the price of a Snickers bar of a particular size). However, if you want to track that price in the past (for trend analysis), in the present (to make sales), and in the future (planning for forthcoming price changes), then yes, you need a pink moment-interval for product price.
Product catalog. A green catalog is a collection of blue product descriptions. If the catalog were a catalog of one-of-a-kind collectibles, it would link to green product(s) too. In addition, if a catalog were to have catalog-specific prices, then a catalog would link to its pink prices, with those prices linking to its product descriptions.
Methods. Key methods include: calculate price for a detail object (with quantity and unit of measure), list catalog entries with catalog-specific prices, and verify availability of a quantity.
Interactions. The "calculate price for a detail object (with quantity and unit of measure)" sequence is shown in Figure 3-5. A sender asks a blue product description to calculate its price, given a detail object, one with values for both quantity and unit of measure. The product description asks each of its pink product price(s) to calculate its price for a detail—and goes with whatever is the best price. (In a retail system, the "best price" might be the lowest price. In an insurance system, it might be the highest price. Insurance-application developers know what we mean! A business always looks different when standing on the other side of the counter.) A product price checks that it's valid for the date, gets the price, gets the quantity, gets the price unit of measure, asks the detail object for its price, asks the detail object for its unit of measure, does the math, and returns its result. At the end, the product description returns the price to the sender.
Figure 3-5 Calculate price for a detail object (with its quantity and unit of measure).
Another interesting interaction sequence is "list catalog entries with catalog-specific prices," shown in Figure 3-6. A sender asks a green product catalog to list its catalog entries with catalog-specific prices. The product catalog asks each of its pink product prices for its corresponding blue product descriptions. Then it interacts with both the product price and the product descriptions, adding to its list of catalog entries with prices. At the end, the product catalog returns the list to the sender.
Figure 3-6 List catalog entries with catalog-specific prices.
3.1.2 Sale to Customer
Figure 3-7 Sale-to-customer component.
Sale to customer. A pink sale-to-customer links to two yellow roles: sales rep and customer. It links to a green (ship-to) address and a green terms-and-conditions object. It also links to pink sale-to-customer detail(s).
Sale-to-customer detail. A pink sale-to-customer detail specifies quantity, negotiated price, and status. It links to a blue product description. Or it might link to yellow product-being-sold roles, which in turn link to green products (in the product component). It might link to a green (ship-to) address.
Before and after. For sale to customer, the subsequent pink moment-interval is shipment to customer.
Methods. Key methods include: make sale to customer, calculate the total of a sale, calculate quantity of a product description sold over an interval, and compare sale with deliveries.
Interactions. The "calculate quantity sold" sequence is shown in Figure 3-8. A sender asks a blue product description to calculate the quantity sold, passing along an applicable interval as an argument. The product description asks each of its pink sale details for its quantity within that interval. Each sale detail then asks its pink sale for its date, checks to make sure it's within the interval, then returns its amount (if within the interval) or zero (otherwise) to the product description. Ultimately, the product description returns its result to the sender.
Figure 3-8 Calculate quantity sold.
3.1.3 Shipment to Customer
Figure 3-9 Shipment-to-customer component.
Shipment to customer. A pink shipment to customer links to a yellow customer (a derivable link, via sale); it links to a yellow shipper too. It also links to pink shipment detail(s).
Shipment detail. A pink shipment detail specifies a quantity shipped. A shipment detail links to a blue product description (derivable, by traversing links back to sale detail); or it might link to some number of yellow product-being-sold roles, each of which links to a green product (in the product component).
Before and after. For shipment to customer, the preceding pink moment-interval is sale to customer. The subsequent pink moment-interval is delivery to customer.
Methods. Key methods include: make shipment to customer, verify if credit is still acceptable, calculate shipment weight, assess deviation from sales, and compare shipment with deliveries.
Interactions. The "calculate shipment weight" sequence is shown in Figure 3-10. A sender asks a pink shipment to calculate its weight. A shipment then asks each pink shipment detail to calculate its weight. Each shipment detail asks its corresponding pink sale detail for its connecting blue product-description. Finally, it asks the product description for its weight, multiplies weight by the shipment-detail quantity, and returns the total weight for the shipment detail. Shipment adds up the results and returns the total to the sender.
Figure 3-10 Calculate shipment weight.
3.1.4 Delivery to Customer
Delivery to customer. A pink delivery-to-customer links to a yellow customer (a derivable link, via shipment and sale). It links to some yellow product-being-sold roles, each of which links to a green product (in the product component). It also links to pink delivery detail(s).
Delivery detail. A pink delivery detail specifies quantities received and quantity returned. A delivery detail links to a blue product description (derivable, by traversing links back to sale detail); or it might link to some number of yellow product-being-sold roles, each of which links to a green product (in the product component).
Delivery problem-report. A delivery may result in some number of pink problem-reports. Each problem-report tracks when it's opened and closed, along with other relevant information.
Figure 3-11 Delivery-to-customer component.
Before and after. For delivery-to-customer, the preceding pink moment-interval is shipment-to-customer.
Methods. Key methods include: log delivery to customer, assess timeliness of this delivery, and calculate the average problem report open-to-close duration for a customer.
Interactions. The "calculate average open-to-close problem-report duration" sequence is shown in Figure 3-12. A sender asks a yellow customer to calculate its open-to-close problem-report duration. It asks each of its pink delivery(ies) to calculate its own problem-report open-to-close duration. Each delivery asks each of its pink delivery-problem reports to calculate its own open-to-close duration. A customer totals the duration, asks each delivery for its quantity of problem reports, performs the math, and returns the result to the sender.
Figure 3-12 Calculate average open-to-close problem-report duration.
3.1.5 Invoice to Customer
Invoice to customer. A pink invoice to customer links to a yellow customer. It also links to pink invoice detail(s).
Invoice detail. A pink invoice detail tracks the quantity, price, and unit of measure. An invoice detail links to a blue product description (derivable, by traversing links back to sale detail); or it might link to some number of yellow product-being-sold roles, each of which links to a green product (in the product component).
Figure 3-13 Invoice-to-customer component.
Before and after. For invoice to customer, the preceding pink moment-interval is shipment. The subsequent pink moment-interval is accounting posting.
Methods. Key methods include: make invoice to customer, calculate the total of an invoice, and make an adjustment invoice.
Interactions. The "make an adjustment invoice" sequence is shown in Figure 3-14. A sender asks a pink invoice to make an adjustment invoice. The pink invoice does so in two steps: First, it asks the invoice class for a new invoice object. Then it gets its own values and sets the new invoice object accordingly.
Figure 3-14 Make an adjustment invoice.
3.1.6 Product Agreement
Discount agreement. A pink discount agreement links to a yellow customer. It also links to pink discount-agreement detail(s).
Discount-agreement detail. A pink discount-agreement detail specifies a discount, applicable to sales of products described by certain blue product-agreement descriptions (if linked) or to sales of any products (otherwise).
Commission agreement. A pink commission agreement links to a yellow sales rep. It links to a green "node linked within a commission agreement." It also links to pink commission detail(s).
Figure 3-15 Product-agreement component.
Commission-agreement detail. A pink commission-agreement detail specifies a commission, applicable to sales of products described by certain blue product-agreement descriptions (if linked) or to sales of any products (otherwise).
Commission network. Commission agreements define who gets a commission from a sale. When a sales rep makes a sale, he earns a commission. Others in a commission network, for example, the sales rep's managers, rippling upwards several levels, each enjoy commission from that sale. A green commission network links to the root node for a given network. A green "node linked within a commission network" might link to a commission agreement, making it a so-called "agreement node," the node from which indirect commission will be calculated. A green "node linked within a commission network" might also link to a yellow commission-network participant, indicating the assignment of a party to a particular node within a commission network (note that this assignment could change, without affecting the shape of the commission network).
Methods. Key methods include: make discount agreement, make commission agreement, and list commission percentages for which eligible.
Interactions. The "calculate direct commissions" sequence is shown in FIgure 3-16. A sender asks a yellow sales-rep object to calculate its direct commissions. For each of its sales, the sales-rep object asks for a list of pink product-sale details. Then it sends the product-sale details to its pink commission agreement(s). Each commission agreement sends each product-sale detail to its pink commission-agreement details, which in turn calculate whatever commission is due (for the product description or product being sold role) linked to that sale detail. Eventually, the sales-rep object tallies up the commissions and returns the result to the sender.
Figure 3-16 List commission percentages for which eligible.
3.1.7 Product Assessment
Cost-and-overhead allocation. A pink cost-and-overhead allocation links to a yellow accountant. It also links to blue product description(s).
Marketing study. A pink marketing study links to a yellow marketer. It also links to pink marketing-study detail(s), tracking specifics within a study. A pink marketing-study detail tracks part of a marketing study, optionally linked to blue product description(s).
Sales forecast. A pink sales forecast links to a yellow marketer. It might link to some number of green geographic regions. It also links to pink sales-forecast detail(s), tracking specifics within a forecast. A pink sales-forecast detail tracks part of a sales forecast, optionally linked to blue product description(s).
Figure 3-17 Product-assessment component.
Geographic-region assignment. A pink geographic-region assignment links to a yellow sales unit, which in turn links to a green organizational unit (in the party component). It might link to some number of geographic regions.
Methods. Key methods include: make cost and overhead allocation, make a marketing study, make a sales forecast, and make a geographic-region assignment, and calculate total overhead allocations.
Interactions. The "calculate total overhead allocation" sequence is shown in Figure 3-18. A sender asks a blue product description to calculate its total overhead allocation. It asks each of its pink cost-and-overhead allocations to determine its applicable overhead allocation. If it is currently applicable, an allocation returns its overhead number; otherwise, it simply returns zero. The product description adds up the results and returns the total to the sender.
Figure 3-18 Calculate total overhead allocation.