Module 4
Business Processes
a. Sales and Collection Process
The sales and collection process constitutes a fundamental aspect of any business
operation, encompassing a myriad of interconnected activities aimed at facilitating the
exchange of goods and services with customers while ensuring timely and accurate
collection of payments. This multifaceted process not only involves the core functions of
selling products and services but also extends to ancillary tasks such as customer record
management, billing, payment processing, and accounts receivable management.
At its core, the sales and collection process revolves around the seamless
execution of transactions between the organization and its customers. From initiating
sales orders and invoicing customers to processing payments and reconciling accounts,
each step in the process plays a crucial role in driving revenue generation and
maintaining financial stability.
Central to the sales and collection process is the management of customer
relationships and transactions. Organizations must maintain accurate and up-to-date
customer records to facilitate smooth interactions and provide personalized services. This
includes capturing essential customer information such as contact details, purchasing
history, credit terms, and payment preferences.
Billing and invoicing are integral components of the sales and collection process,
ensuring that customers are accurately charged for the products or services they receive.
This involves generating invoices in a timely manner, applying appropriate pricing and
discounts, and addressing any discrepancies or disputes that may arise.
Equally important is the management of accounts receivable, which involves
tracking outstanding balances owed by customers and implementing strategies to
expedite payment collections. This may include sending reminders, extending credit
terms, or negotiating payment plans to accommodate customers' financial circumstances.
Furthermore, the sales and collection process has significant implications for
financial reporting and performance analysis. Accounting transactions generated through
sales activities impact key financial metrics such as revenue, accounts receivable, and
cash flow. Additionally, for companies that sell merchandise, the process affects cost of
goods sold and inventory valuation, necessitating careful monitoring and control to
optimize profitability and inventory turnover.
In essence, the sales and collection process serves as a vital link between the
organization and its customers, driving revenue generation, fostering customer
satisfaction, and ensuring financial stability. By effectively managing this process and
leveraging technological advancements such as customer relationship management
(CRM) systems and automated billing platforms, organizations can streamline operations,
mitigate risks, and capitalize on growth opportunities in today's dynamic business
environment.
The inclusion of sales tax in transactions adds another layer of complexity to the
sales and collection process. Depending on the jurisdiction and the nature of the goods or
services sold, businesses may be required to collect and remit sales tax to the appropriate
authorities. This entails accurately calculating and applying the relevant tax rates to
transactions, maintaining compliance with tax laws and regulations, and ensuring proper
documentation and reporting of tax liabilities.
In addition to the cash and credit sales described, businesses must also account for
sales tax liabilities incurred during transactions. Sales tax collected from customers
represents a liability that the business must remit to the relevant tax authorities within
specified timeframes. Failure to accurately account for and remit sales tax can result in
penalties, fines, and legal repercussions for the organization.
The distinction between cash sales and credit sales further underscores the
importance of effective accounts receivable management. While cash sales immediately
increase cash reserves, credit sales result in the creation of accounts receivable,
representing amounts owed to the business by customers. Managing accounts receivable
involves monitoring payment terms, following up on overdue invoices, and implementing
collection strategies to minimize delinquencies and optimize cash flow.
Moreover, the sale of goods triggers corresponding accounting entries to
recognize cost of goods sold (COGS) expenses and reduce inventory levels. COGS
represents the direct costs associated with producing or acquiring the goods sold,
including materials, labor, and overhead expenses. By accurately matching revenues with
the costs incurred to generate them, businesses can assess profitability and make
informed decisions regarding pricing, product mix, and inventory management.
When customers subsequently pay for goods or services sold on credit,
accounting entries are made to increase cash reserves and reduce accounts receivable
balances. This process, known as cash application or cash reconciliation, ensures that
payments are properly recorded and reflected in the organization's financial statements.
In summary, the sales and collection process involves a series of interrelated
activities, including sales transactions, accounts receivable management, sales tax
compliance, and inventory accounting. By effectively managing these processes and
adhering to best practices in financial management and regulatory compliance, businesses
can optimize cash flow, mitigate risks, and maintain financial health in an increasingly
complex and competitive business environment
b. Sunset Graphics Example
Over two decades ago, Mr. Virgil Bartolomucci, affectionately known as Mr. B,
embarked on a journey to establish what would eventually become a thriving graphic
design and printing business. Through his vision, dedication, and hard work, the company
has evolved into a cornerstone of the industry, offering a diverse range of products and
services that cater to various needs and preferences.
From its humble beginnings, the company has flourished into a multifaceted
enterprise, specializing in the design and sale of an extensive array of signage and
banners, vehicle and boat lettering, vinyl graphics, corporate promotional items, silk-
screened t-shirts, embroidered gear, and more. With a commitment to quality
craftsmanship, innovation, and customer satisfaction, Mr. B's company has earned a
reputation for excellence within the industry and beyond.
As the business landscape continues to evolve, Mr. B recognized the need to
adapt and embrace new opportunities, including the expansion of the business onto the
internet. This strategic decision not only reflects Mr. B's forward-thinking approach but
also underscores his dedication to meeting the evolving needs and expectations of
customers in an increasingly digital world.
However, before embarking on this new of growth and expansion, Mr. B
understood the importance of conducting a comprehensive review of the company's
business processes. This review aimed to enhance documentation, streamline operations,
foster consistency in customer service, and strengthen internal controls, particularly in
light of the automation that would accompany the online expansion.
With a focus on continuous improvement and operational excellence, Mr. B and
his team embarked on a thorough examination of existing processes, identifying areas for
optimization, standardization, and enhancement. Through collaborative efforts and a
commitment to excellence, they developed robust documentation outlining standardized
procedures and best practices across various departments and functions.
Moreover, recognizing the critical importance of effective internal controls in
safeguarding assets, mitigating risks, and ensuring compliance, Mr. B and his team
implemented a comprehensive framework of internal controls tailored to the company's
evolving needs and operating environment. This framework encompasses policies,
procedures, and technological solutions designed to promote accountability,
transparency, and integrity throughout the organization.
Furthermore, as the company embraces automation and digitalization, Mr. B
remains steadfast in his commitment to maintaining the highest standards of quality,
reliability, and customer satisfaction. Leveraging technology as an enabler of efficiency
and innovation, he seeks to empower his team to deliver exceptional value and service to
customers, both online and offline.
In essence, Mr. B's dedication to continuous improvement, innovation, and
customer-centricity serves as the driving force behind the company's success and
resilience in an ever-changing business landscape. As they embark on this new of growth
and expansion onto the internet, Mr. B and his team are poised to capitalize on new
opportunities, uphold their legacy of excellence, and redefine the standards of the
industry for years to come.
In the annals of Sunset's operational history, the process of delivering tailored
products and services to its esteemed clientele has been a testament to its commitment to
customization, quality, and customer satisfaction. Over the years, this bespoke approach
to business has not only defined Sunset's identity but also fostered enduring relationships
built on trust and reliability.
At the heart of Sunset's modus operandi lies a meticulous process, honed through
years of experience and customer feedback, wherein every interaction is marked by a
personalized touch. It all begins with a dialogue – whether initiated by Virgil
Bartolomucci himself or another dedicated member of the Sunset team – wherein the
unique needs and preferences of the customer are carefully discerned and documented.
With a keen eye for detail and a commitment to excellence, Sunset crafts a
tailored quote that serves as a blueprint for the products and services to be provided. This
quote, meticulously prepared and articulated, not only outlines the specifications and
features of the desired products but also reflects the ethos of Sunset – a commitment to
exceeding expectations and delivering unparalleled value.
Upon acceptance of the quote by the discerning customer, the wheels of Sunset's
operations are set in motion. Leveraging its extensive network of suppliers and partners,
Sunset procures any necessary materials or components not readily available in its
inventory. This strategic sourcing ensures that each project is executed with precision and
efficiency, while maintaining the highest standards of quality and craftsmanship.
As the ordered materials and components arrive, Sunset's skilled artisans and
craftsmen embark on the process of customization and assembly. Whether it be screen
printing vibrant graphics, meticulously embroidering intricate designs, or assembling
components with precision, every step is executed with unwavering attention to detail
and a commitment to perfection.
With the customized products ready for delivery, Sunset orchestrates the final
stage of the process – ensuring seamless delivery and installation, if required, at the
customer's site. This hands-on approach not only underscores Sunset's dedication to
delivering turnkey solutions but also affirms its role as a trusted partner in bringing
visions to life.
Upon completion of the job, Sunset issues a comprehensive invoice detailing the
products and services rendered. Depending on the agreed-upon terms, customers are
afforded the flexibility to settle their accounts either immediately or within a mutually
agreed-upon timeframe, typically within 30 days. This flexibility reflects Sunset's ethos
of fostering long-term relationships built on trust, transparency, and mutual respect.
In essence, Sunset's approach to delivering customized products and services is
not merely a transactional exchange but a collaborative journey marked by innovation,
creativity, and unwavering dedication to customer satisfaction. As Sunset charts its
course into the future, it remains steadfast in its commitment to pushing the boundaries of
excellence and redefining the standards of the industry one bespoke creation at a time.
As Sunset embarks on the journey of expanding its business into the realm of e-
commerce, the horizon brims with new possibilities and opportunities. Under the astute
leadership of Virgil Bartolomucci, Sunset is poised to usher in a new era of convenience,
accessibility, and innovation for its valued customers. The decision to offer select
products for sale via its website represents not only a strategic pivot but also a bold step
forward into the digital landscape.
With the advent of online ordering, the traditional boundaries of time and space
begin to blur, offering customers unprecedented convenience and flexibility in their
purchasing journey. From the comfort of their homes or offices, customers can peruse
Sunset's diverse array of products, meticulously curated to meet their discerning tastes
and preferences. Through an intuitive and user-friendly interface, the Sunset website
serves as a gateway to a world of possibilities, where every click brings them closer to
their desired purchase.
The online ordering process unfolds seamlessly, guided by Sunset's commitment
to simplicity and efficiency. Customers navigate through an extensive catalog of
products, each accompanied by detailed descriptions, high-resolution images, and, in
some cases, interactive features that allow for customization or personalization. Armed
with the information they need, customers proceed to select their desired products and
add them to their virtual shopping carts.
At the checkout stage, Sunset's integration of secure payment gateways ensures a
hassle-free transaction experience. Customers can confidently complete their purchases
using their preferred payment method, whether it be credit card, debit card, or alternative
payment options. With robust encryption protocols in place, Sunset prioritizes the
security and privacy of its customers' financial information, instilling trust and
confidence in every transaction.
Behind the scenes, Sunset's dedicated team of employees springs into action,
orchestrating the fulfillment process with precision and care. Leveraging state-of-the-art
technology and streamlined workflows, employees efficiently prepare the ordered
products for shipment, adhering to stringent quality control standards every step of the
way. While the application of graphics may be minimal for online orders, Sunset's
unwavering commitment to craftsmanship and attention to detail remain unwavering,
ensuring that every product meets the highest standards of excellence.
As the products are packaged and prepared for dispatch, Sunset's logistics
network comes into play, seamlessly orchestrating the movement of goods from
warehouse to doorstep. With a keen focus on speed, reliability, and cost-effectiveness,
Sunset ensures that customers receive their orders promptly and intact, regardless of their
location.
Upon receiving their eagerly awaited packages, customers are greeted with a
tangible manifestation of Sunset's dedication to exceeding expectations. Whether it be a
meticulously crafted sign, a vibrant banner, or a custom-printed t-shirt, each product
serves as a testament to Sunset's unwavering commitment to quality, creativity, and
customer satisfaction.
In the ever-evolving landscape of commerce, Sunset's foray into e-commerce
represents not only a strategic imperative but also a reaffirmation of its core values and
principles. As the company charts its course into the digital frontier, it remains guided by
Virgil Bartolomucci's vision of innovation, excellence, and customer-centricity, ensuring
that Sunset continues to shine brightly in the hearts and minds of its customers for years
to come.
c. Sunset Graphics Activity Models
After talking with Virgil about their sales and collection process, our first task
was to draw a simple activity model using BPMN. Sunset starts the process when the
customer requests a quote. Then, a series of tasks takes place in sequence until the
customer pays for the products and services and the process ends. Sunset records sales
when the products and services are delivered to the customer. Most customers place
orders after getting a quote, but some elect to visit other companies to get competing
quotes.
Business process analysis is an iterative process. After thinking about the basic
model, Virgil remarked that a lot of their business involved interaction with customers,
and the basic model doesn’t really show that interaction. We agreed, but we said that
BPMN also allows pools that show different participants in a process. Message flows
(shown by dashed arrows) between pools describe the interaction between participants.
Message flows are labeled to show the content of the information exchanged between
pools. To illustrate, we prepared that shows the customer’s activities in one pool and
Sunset’s activities in the other pool. We explained that each pool needs a start and end
event, and the sequence flow (shown by the solid arrows) within a pool continues from
the start event to the end event without a break. This type of activity model is called a
collaboration model in BPMN, and the interaction between participants is called
choreography.
Virgil agreed that this model shows the interactions more clearly, but he really did
not care about the customers’ activities. He was just concerned about the choreography of
interactions between the pools and the orchestration of Sunset’s activities (the sequence
of activities within one pool is called an orchestration). We understood and changed the
model. We could also hide Sunset’s activities and just show the choreography between
participants, but Virgil liked this model.
The next step is to model potential exceptions to the typical process flow. For
example, Virgil said that sometimes Sunset’s suppliers don’t have the products that
Sunset needs to complete the job. Sunset then notifies the customer and cancels the job.
We weren’t ready to model details of the purchasing process, yet, so we can use a
collapsed subprocess while also allowing for the exception. A collapsed subprocess
contains a series of steps that are hidden from view. Later, we will define the purchasing
process in detail. Because this was getting more complicated, we temporarily dropped the
pools and revised the basic sales model.
We show the exception that occurs when the product is not available as an
intermediate error event attached to the boundary of the subprocess. When the exception
occurs, the customer is notified and the process ends. Under normal conditions, the
process continues as before.
Virgil loved it. He said that is exactly what happens at times. Then, he asked
about the invoice customer and review payment tasks. He said they don’t always get paid
immediately and sometimes have to send another invoice. Because he was starting to
understand BPMN, he asked if we could also use a boundary event to show that the
payment was not received on time. We applauded him for how well he understood the
tools. Yes, we can use an intermediate timer boundary event to show the exception.
Virgil says that he waits 2 weeks after the payment due date to send a new invoice.
Virgil was satisfied that this represents his sales process when he has face-to-face
contact with his customers. Now, he wondered what the internet sales process would look
like. After discussing his plans, we thought the process would look like a standard web
sales process. Customers select items and they are moved to the customer’s cart. The
customer elects to check out and enters the order and shipping information as well as the
credit card payment information. When the credit card payment is confirmed by the credit
card processor, Sunset employees prepare the products, apply some limited graphics if
ordered, and ship the products to the customer. We used an intermediate error boundary
event to show the option that the customer’s credit card is not confirmed. At this point,
we did not include interactions with the credit card processor, but those could be shown
as message flows to another pool.
Virgil said that this did seem simpler. Plus, the internet sales would allow him to
reach more customers. He was curious, though, about the “Process Credit Card Payment”
task. Does this model mean that the customer only gets one attempt to enter acceptable
credit card information? We admitted that the model wasn’t clear. We explained that we
can use a looping task, so the customer enters credit card information until confirmed or
until the customer exceeds a reasonable number of tries. However, when the credit card
information is not confirmed after a reasonable number of attempts, the intermediate
error event is triggered and the process is canceled.
d. Business Rules and Sunset Graphics Sales and Collection Process Control
Next, we wanted to talk about controls over the sales and collection process since
Virgil planned to employ more automated operations. We can implement controls by
developing business rules for the process. We explained to Virgil that a business rule is a
compact statement that constrains some aspect of business activity. Business rules help
ensure that processes and the information systems supporting those processes operate in a
consistent and effective manner to achieve organizational objectives.
Virgil remarked that business rules seemed similar to internal controls. He quickly
pulled out his laptop and went to the COSO website, www.coso.org.1 He paraphrased its
definition, “Internal control is broadly defined as a process designed to provide
reasonable assurance regarding the effectiveness and efficiency of operations, reliability
of financial reporting, and compliance with applicable laws and regulations.” We
explained that business rules are not processes; they are constraints on the process.
However, you could think of business rules as control activities. COSO describes control
activities as including approvals, authorizations, verifications, reconciliations, reviews of
operating performance, security of assets, segregation of duties, and other activities
designed to address risks to achievement of the entity’s objectives. After thinking about
it, Virgil agreed. He understood that business rules implement specific control activities
for a business process. He just wasn’t sure how to do it.
We explained that business rules are developed by identifying three elements:
event, condition, and action. The first step is to identify important business events. Then,
we need to know your conditions that would affect your intention or objective for each
event. Finally, we determine the appropriate actions to take based on the conditions. For
example, we’ve already listed important business events in the activity models, so let’s
examine Sunset’s sales and collection and develop some possible business rules.
Virgil was now involved, so we started with the first step in the process: provide
quote. We asked what his intention was for this step. He replied that his goal was to
provide quotes accurately and promptly because the quote was extremely important in
winning the customer’s business. We then asked about the constraints that should be
applied to the activity because a Sunset employee would prepare the quotes in the future.
Virgil responded that the employee should provide the quote to the customer within 1 day
of the customer’s request. He added that they wanted to control approvals so a manager
approved large value quotes. That way, he could be sure that Sunset would not be
overextended by taking on a large job that it could not accomplish on time.
Next, we asked about the accounting information system controls over the
process. We explained that access controls limit who can use and change records in the
system. This helps implement appropriate segregation of duties. Virgil said that the
employees who provide quotes should not also manage the inventory and set prices, so
they should not have access that would allow them to modify product and price
information. Finally, we said we need application controls to ensure data integrity and an
audit trail. For example, we need to control the assignment of quote numbers to make
sure all of them are accounted for. Plus, we need to establish appropriate ranges or limits
for each value that Sunset’s partners can add or change in the system.
With Virgil’s input, we were able to develop an initial set of business rules for the
sales and collection process. He articulated Sunset’s intentions for every step in the
process, and then we set business rules to segregate duties and limit employee authority
appropriately.
There is an old adage: “garbage-in, garbage-out.” Application controls are
designed primarily to avoid “garbage-in” from data entry errors. Application controls
serve to ensure that data match the original source and correct values as closely as
possible. Application controls often limit the new information that any single user can
add to the system, requiring the use of validated master data. For example, when
scheduling a payment to a vendor, the user should not generally be able to add a new
vendor number. Instead, the user should be required to select from a list of validated
vendors. Similarly, most users should not be able to enter new employee numbers. Such
controls would not limit all potential errors, but they would control entry of valid vendors
or employees.
e. Sunset Graphics Structure Models
We proceeded to examine Sunset Graphics’ information requirements by
preparing UML class diagrams that describe their sales and collection process. As
described, the primary purpose of a UML model of the sales and collection process is to
create a blueprint for the development of a relational database to support the collection,
aggregation, and communication of process information. To develop UML class
diagrams, we follow the REA framework (resources, events, and agents) as a proven
approach to describing business processes in a way that meets both accounting and broad
management information requirements. Appendix A to this provides more information
on the REA framework and a generic sales process UML class model using that
framework.
Virgil outlined Sunset’s process for preparing quotes for customers. A Sunset
employee works with the customer to document how Sunset will meet the customer’s
requirements. The Sunset employee prepares the quote, and the customer can accept the
quote. The quote specifies the prices and quantities of Sunset’s products and services to
be delivered. So, our preliminary model shows Sunset’s resources (Products), the Quote
event, and the two agents (Sunset Employee and Customer) that participate in the event.
the Sunset Employee to Quote event association, the Customer to Quote event
association, and the Quote events to Products resource association. The multiplicities for
association number 1 indicates that each Sunset Employee may participate in a minimum
of zero Quotes and a maximum of many Quotes, but each Quote involves only one
Sunset Employee.2 Similarly, for association number 2, each Customer may participate
in zero to many Quotes and each Quote is prepared for only one Customer. For
association number 3 each Quote specifies prices and quantities for at least one product
(minimum of one and maximum of many). Each product may be listed on many quotes
(but some products may not yet be listed on quotes). Associations 1 and 2 represent one-
to-many relationships between classes. Association number 3 represents a many-to-many
relationship. As we discuss later, the nature of these relationships determines how the
associations are implemented in the relational database.
Next, Virgil described how Sunset’s quotes typically result in one or more orders
from the customer. Of course, the same customer is involved in both the quote and the
order, but a different Sunset employee could take the order. Sunset does not always
prepare quotes prior to taking an order because some of its products do not need to be
customized. When the customer places the order, Sunset has a formal commitment from
the customer that will result in a sale when Sunset completes the delivery. Sunset does
not deliver products and services until the order is complete, so there is a one-to-one
relationship between orders and subsequent sales.
We highlight association 4 because it links the Customer’s order to the previous
quote. Other associations with Order are similar to associations with Quote. The
multiplicities for association 4 indicate that each Quote is related to a minimum of zero
Orders, which may happen if the Customer does not place an order but also indicates that
orders follow quotes in time (i.e., there can be delay between the quote and the customer
order). Each Quote may be related to more than one Order if the Customer places partial
orders, such as when the customer needs certain products and services immediately but
others can wait. Orders are related to a minimum of zero Quotes and a maximum of one
Quote.
Some customers pay Sunset as soon as it delivers the products and services.
However, Virgil said that Sunset’s business and government customers are usually
offered credit terms. Occasionally, the customers may send one check for several orders.
A Sunset partner records the cash receipt from the customer. All cash receipts are
deposited in Sunset’s primary bank account daily.
As with Orders and Quotes, a Sunset employee and customer both participate in
the Cash Receipt event and the multiplicities for these associations are like the earlier
associations between agents and events. We highlighted the association between Orders
and Cash Receipts events (number 5) and the association between the Cash Receipts
event and the Cash resource (number 6). For association number 5 the multiplicities
indicate that each Cash Receipt is linked with a minimum of one Order and a maximum
of many Orders (one customer payment for multiple orders), and each Order is linked to a
minimum of zero (not paid yet) and a maximum of one (paid in full) Cash Receipt. Thus,
the delivered Orders for which there are no Cash Receipts define Sunset’s accounts
receivable. For association number 6 the multiplicities indicate that each Cash Receipt is
deposited into one account (Cash resource) and each account could have many Cash
Receipts. The minimum of 0 next to Cash Receipts indicates that a Cash account does not
have to be associated with any cash receipts. The minimum of 1 next to Cash indicates
that every cash receipt must be associated with at least one cash account.
Virgil now agreed that the model generally represents their sales and collection
process, but he wondered how to include product categories and order status information
that Sunset uses for management. For example, they categorize their products into t-shirts
and gear for silk screening and embroidery, lettering material for vehicles and boats, sign
and banner material, customer artwork, and printing materials (card stock and stationery
items). Additionally, they have a number of different categories for their promotional
products. They also track the status of their orders (e.g., waiting for supply, pending
graphic application, ready for delivery, and delivered).
Companies often apply guidelines, constraints, and descriptive information to
their resources, events, and agents to help manage the business process. Additionally,
companies need to summarize the economic activity to support management’s
information requirements. Generically, these other classes can be called type images.
Association number 7 highlights the two association between the underlying class and its
type image. The multiplicities for both associations reflect that each category/status can
apply to many instances of the underlying class. For example, each Product Category
comprises many Products. Once implemented in a relational database, these type images
allow process information to be summarized by category.
Type images could also support control activities by designating responsibilities.
For example, a Sunset Employee could be assigned inventory management responsibility
for one or more Product Categories, as shown by association number 5. The multiplicities
for association number 8 indicate that one Sunset Partner is assigned to each Product
Category, but some Sunset Partners could be assigned to manage multiple Product
Categories.
Virgil B had no more questions about the UML class diagrams of Sunset’s sales
and collection process, but he did wonder how the model would be implemented in the
relational database. He knew that relational databases implement links between tables
through foreign keys.4 “How do you know where to put the foreign keys?” he asked.
We said that once you understand the multiplicities, it is pretty easy to determine
where to put the foreign keys. Let’s use some of the associations that we’ve already
discussed as examples. We’ve included some sample attributes for the classes. The <>
notation indicates the primary keys; the <> notation indicates the foreign keys. Thus,
Cust_num (customer number) is the primary key for the Customer table, and Order_num
(order number) is the primary key for the Order table. The multiplicities indicate that
each Customer can be linked with multiple Orders, but each Order only involves one
Customer. Foreign keys are primary keys of linked tables, so either the Cust_num is a
foreign key in the Orders table or the Order_num is the foreign key in the Customer table.
Remember that properly designed relational tables cannot have multivalued fields. Thus,
the Order_num cannot be a foreign key in the Customer table because each Customer can
participate in multiple Orders.
Next, we have to determine what to do with the many-to-many relationships, as
shown between Order and Products. In this case, we need to turn the many-tomany
relationship into two one-to-many relationships that can be easily implemented in a
relational database. To do that, we define the Order Items class and model a composition
association between Orders and Order Items. Note that the primary key of Order Items is
the combination of Order_num and Prod_num (called concatenated key or composite
key): Order_num in Order Items links to Order_num in Orders and Prod_num in Order
Items links to Prod_num in Products. The Order Items table will include quantity ordered
and price attributes because those attributes depend on both the Order and the Product
ordered.5 Although we could have modeled Order Items on the original UML class
diagram, identifying the many-to-many relationship serves the same purpose because, in
either case, the Order Items table would have to be defined when the model is
implemented.
f. Sunset Graphics Relational Database
Virgil was now interested in seeing how the structure model would be
implemented in a relational database for Sunset. For this example, we use Microsoft
Access, but the process would be similar for any database-driven system. We encourage
students to use the following description to implement a relational database to support
information requirements for the sales and collection process.
During the model development process, we reviewed Sunset’s existing documents
to determine specific data requirements for each class/table. We then followed the
guidance in the previous section to determine allocation of foreign keys. This resulted in
a list of tables, attributes, data types, field sizes and primary and foreign keys.
g. Purchases and Payment Process
The purchases and payments process includes business activities related to buying
inventory from suppliers, maintaining supplier records, and making payments to suppliers
for trade accounts payable while taking appropriate purchase discounts. The purchases
and payments process generates accounting transactions to record purchases, accounts
payable, and cash disbursements. The process also affects inventory values as purchases
are added to inventory.
We will apply the tools introduced to a comprehensive example of the purchases
and payments process. We first describe the process activities using BPMN, and then we
define the typical information structure using UML class diagrams. Finally, we use the
UML class diagrams to build a database to collect and report relevant process
information. We also describe business rules that establish potential process controls.
h. Sunset Graphics Example
The company designs and sells signs and banners, lettering and vinyl graphics for
vehicles and boats, corporate promotional items, and silk-screened t-shirts and
embroidered gear, among other products. Recently, Virgil decided that it was time to
review his business processes to develop better documentation, improve processes, and
establish consistency in customer service. He also wanted to be sure that effective
internal controls were in place. This comprehensive example assumes that we are
business analysts who are helping Virgil accomplish these goals.
i. Sunset Graphics Activity Models
After talking with Virgil about Sunset’s purchases and payments process, our first
task was to draw a simple business process model using BPMN. Then, a series of tasks
takes place in sequence until Sunset pays for the items and the process ends. Sunset
records purchases and updates inventory when it receives the items.
After reviewing models for the sales and collection process, Virgil was starting to
understand these models. He remarked that he liked the collaboration model better
because it shows the interactions with the external parties that Sunset relies on. So, he
asked if we could prepare a collaboration model of the purchases and payments process.
Of course, we said we could. In this case, the pools would show suppliers and Sunset,
with message flows (shown by dashed arrows) between pools describing the interaction
between participants. In fact, if you are primarily interested in the interactions, you don’t
need to model the orchestration within either pool.
Virgil thought that this model offered a good overview of his typical purchase and
payment process. It showed the choreography of interactions between the pools.
However, he reminded us that as Sunset grows another employee would perform most of
Sunset’s buying and bill paying in the future. Because he was delegating those jobs, he
thought that he should separate the buying duties from the payment duties for better
internal control. He wondered if we could prepare a model that shows the process while
highlighting different jobs within Sunset. We reminded him about lanes in BPMN that
allow us to model those different jobs. Virgil said that was exactly what was needed.
Showing the different jobs would provide better process documentation and highlight the
segregation of duties.
Virgil also noted that sometimes Sunset does not get acceptable items from the
supplier. Sometimes, the entire shipment is unacceptable, but mostly, there are a few
items in the shipment that do not meet specifications. So, Sunset can refuse the entire
shipment or return the unacceptable items to the supplier. He asked if we could include
that in the model. We combined the “Request Prices & Availability” and “Place Purchase
Order” activities in the original model with a collapsed subprocess because we want to
expand on those activities later. We also added another step to assess the items after
receiving them from the supplier. Then, we included a gateway to branch into two
possible courses of action. IfMthe items are not acceptable, Sunset returns them to the
supplier and the process ends. If the items are acceptable, they are placed in inventory; 30
days later (depending on credit terms), Sunset sends a payment to the supplier. The slash
across the sequence flow indicates the default path. Because there are two possible paths
that do not reconnect, we include two end events.
Because we added some new notation, we explained what the new symbols mean.
The gateway is modeled with the diamond. In this case, the gateway branches into two
exclusive paths. We noted that with BPMN 2.0, gateways don’t represent activities, so
we needed to include the assessment activity, “Assess Items,” before the gateway. We
also included an intermediate timer event (the intermediate event symbol with clock
hands) to represent the time delay, Wait 30 days, before payment. Timer events represent
a delay in the flow of a process. They can indicate a delay to (1) a specific date, such as
December 31; (2) a relative time, such as 30 days; or (3) a relative repetitive date, such as
next Friday at 5:00 p.m. As always, the sequence flow must be continuous from the start
event to an end event. Remember that sequence flows do not extend outside a pool.
Message flows connect pools. Because we elected to make the Supplier pool opaque, we
connected the message flows to the edge of the pool. Otherwise, they would connect to
an activity or event in the Supplier pool.
Virgil then reminded us that Sunset started using its business credit card for
making routine purchases. So, the buyer makes the payment when the order is placed.
The rest of the process is similar. Sunset receives and assesses items, sends back any
unacceptable items for refund, and places the good items in inventory. We modified the
purchases activity. Now Sunset makes both the order and payment at the same time at the
beginning of the process. We no longer need a separate payment activity at the end of the
process. We also changed the “Send Back” activity to a collapsed subprocess since
Sunset must follow up to ensure a refund to their credit card account. Virgil thought this
looked correct, although he noted that this diagram clearly shows potential internal
control issues, such as lack of segregation of duties. The same person is placing the order
and making the payment. We replied that he was correct, but the receipt and storage of
the items are assigned to another function. That should mitigate the risk. He may also
want to consider an internal audit process that verifies all orders are received and all
charges to the Sunset credit card areMvalid.
j. Business Rules and Sunset Grapchics Purchases a Payments Process Controls
Next, we wanted to talk about planning controls over the purchases and payments
process to give Virgil more confidence in the integrity of the process when they stepped
back from the day-to-day operations. As with the sales and collection process, we want to
define controls by developing business rules for the process. First, we need to identify
important business events and define Sunset’s intention or objective for each event. Then,
we determine the appropriate actions to take based on the conditions. For example, we’ve
already listed important business events in the business process models, so let’s examine
Sunset’s purchases and payments process and develop some possible business rules.
Again, Virgil summarized objectives for the steps in the process. Of course, the
overall goal was to purchase needed items from reliable suppliers at the best possible
prices to meet required delivery schedules. Sunset also wants these suppliers to be paid
on time, taking prompt payment discounts where appropriate, so they could maintain
positive, long-term relationships. Because Virgil planned to delegate responsibility for
this function, he wanted to be sure that effective controls were applied.
We outlined some standard controls over the purchases and payments process,
suggesting segregation of ordering, receiving, and payment duties. We reiterated that
access controls limit which of their partners can view and change records in the system
and help implement appropriate segregation of duties. We also need application controls
to ensure data integrity and an audit trail. For example, we need to control the assignment
of purchase order and receiving report numbers to make sure all of them are accounted
for. Plus, we need to establish appropriate ranges or limits for each value that Sunset’s
employees can add or change in the system.
With Virgil’s direction, we developed an initial set of business rules for the
purchases and payments process. He articulated intentions for every step in the process,
and then we set business rules to segregate duties and limit partner authority
appropriately. We noted that we would need to set application controls for almost every
attribute updated during data entry.
k. Sunset Graphics Structure Models
Virgil seemed pleased with the business process models so far. However, he was
also interested in planning Sunset’s new database. He’d already set up the sales and
collection tables in Access, and he was waiting for the purchases and payments model so
he could set up these tables, too. We proceeded to examine Sunset Graphics’ purchases
and payments information requirements. As described in, the primary purpose of our
UML class diagram of the purchases and payments process is to create a blueprint for the
development of a relational database to support the collection, aggregation, and
communication of process information. As in, we follow the REA framework (resources,
events, and agents) as a proven approach to describing business processes in a way that
meets both accounting and broad management information requirements. See Appendix
A to this for a description of the generic REA framework for purchases and payments.
Next, we prepared a UML class model for Sunset’s purchases and payments
process based on what Virgil described. A Sunset Employee (agent) selects the Supplier
(agent) and issues a Purchase Order (event) as indicated by the number. The Purchase
Order specifies the prices and quantities of Products (resource) ordered. The Supplier
(agent) sends and a Sunset Employee (agent) receives (Receipts event) the products
(resource) as indicated. The receipt triggers the recognition of the purchase and the
corresponding account payable in the accounting records. Then, when the payment is
due, a Sunset Employee (agent) pays (cash disbursement event) the Supplier (agent) from
a Cash account (resource) as The payment reduces accounts payable.
We showed Virgil the basic model, and he noticed that this model looked very
similar to the sales and collection process model. Although the events were different, the
resources and the Sunset Partner agent were the same. We said that this was a typical
purchases and payments process. We always start with this basic diagram when we model
the purchases and payments process, and then we modify it to reflect the unique
information structure of a particular company. The Purchase Orders event represents
Sunset’s commitment to purchase products and pay the supplier, although commitments
do not affect the financial statements. The Receipts event does affect the financial
statements because it records the purchase for those items received and accepted and
records the increases to accounts payable. The Cash Disbursement event also affects
financial statements because it records decreases to cash and decreases to accounts
payable.
Virgil said that he thought he understood multiplicities pretty well from our sales
and collection process models, but he wanted to review a couple of them to make sure.
For example, the multiplicities for the association between Purchase Orders and Products
specify a many-to-many relationship. Each purchase order requests a minimum of one
and a maximum of many products, and each product might not yet have been ordered and
could be ordered many times.3 We said that was correct but asked Virgil to explain the
multiplicities for the Purchase Orders to Receipts association. He thought about it for a
minute because he was not sure why a Purchase Order could be associated with multiple
Receipts or why a Receipt could be related to a minimum of 0 Purchase Orders. We
answered that we thought some Receipts were purchased over-the-counter from suppliers
without first issuing a Purchase Order. Additionally, we thought that some Purchase
Orders could result in partial shipments from the Supplier. Virgil responded that he could
see how the model reflected those assumptions, but our assumptions were not correct. He
said that Sunset always records a Purchase Order, even for over-the-counter purchases,
and does not accept partial shipments.
Because Virgil said that Sunset always records Purchase Orders for a purchase
and never accepts partial shipments, we revised the diagram. Because there is always a
one-to-one relationship between Purchase Orders and Receipts, we can collapse the two
classes into one and simplify the diagram (even though receipts happen after the orders).
The new Purchases (event) class would record purchase orders and include an attribute to
indicate that the products were received. Because a different employee places the
purchase order than receives the shipment, we need to include two associations between
employees and purchase orders. The corresponding purchase orders table would have to
include a field/attribute that reflects the date of receipt and acceptance.
Each Purchase is associated with a minimum of 0 and a maximum of 1 Cash
Disbursement because Sunset usually pays for purchases 30 days after receipt and pays in
full. Each Cash Disbursement is associated with a minimum of 0 and a maximum of
many Purchases because Sunset writes checks for other purposes and combines payments
for multiple purchases from the same supplier when possible.
We added the type image for Product Categories that we also identified in the
sales and collection process. Virgil then said that they also categorize their suppliers, so
he suggested that we add a type image for Supplier Categories. He was really starting to
understand UML class diagrams. We also added the association between Sunset Partners
and Product Categories to reflect the assignment association that we identified in the
sales and collection process.
Virgil agreed that reflected his purchases and payments process. He also correctly
noted that this model would also accommodate the credit card purchases where Sunset
made payments when the order was placed. He was anxious to get started on defining the
database. He recognized the composition association between Purchases and Purchase
Items reflected by the many-to-many relationship between Purchases and Products. He
said he understood how to post the foreign keys.
l. Conversion Process
The conversion process is inherently more complicated than the sales and
collections and purchases and payments processes described in the previous two,
primarily because of increased recordkeeping requirements and variations in the
sophistication of the process itself among companies. Many types of businesses employ
conversion processes, including bakeries, wineries, breweries, restaurants, car repair
shops, construction companies, equipment manufacturers, automobile manufacturers, and
so on.1 The conversion process includes business activities related to maintaining
inventories of raw material and finished goods, producing finished goods from raw
material, tracking direct labor and direct equipment costs, and applying overhead.
The conversion process generates accounting transactions to record the transfer of
raw material to work-in-process and work-in-process inventory to finished goods. In
addition to the cost of raw materials, the conversion process must also account for direct
labor and other direct costs incurred in determining the cost of goods manufactured. The
allocation of overhead and indirect costs to work-in-process is typically based on direct
labor, although overhead could be allocated based on a number of cost drivers in an
activitybased costing system. More specifically, conversion costs are typically accounted
for at standard, where the standard is based on management estimates, and then the costs
are updated to reflect actual costs incurred continue to apply the tools introduced in a
comprehensive example of the conversion process. We first describe the process
activities using BPMN, and then we define the typical information structure using UML
class diagrams. Finally, we use the UML class diagrams to build a database to collect and
report relevant process information. We also describe business rules that establish
potential process controls.
m. Sunset Graphics Example
Virgil B owns and operates Sunset Graphics. The company designs and sells signs
and banners, lettering and vinyl graphics for vehicles and boats, corporate promotional
items, and silk-screened t-shirts and embroidered gear, among other products. Recently,
Virgil decided to expand the business. To plan the expansion carefully, he wanted to
review Sunset’s business processes to develop better documentation, improve processes,
and establish consistency in customer service. He also wanted to be sure that effective
internal controls were in place since he could not always directly supervise their
employees after the expansion.
Until recently, Sunset didn’t track its conversion costs. If labor was involved in
preparing products for a customer’s order, Sunset simply billed the customer a flat rate
for the service. The company didn’t assign any labor or overhead costs to its products.
However, that changed when it signed a major contract to provide a variety of signs and
banners to state agencies. The terms of the contract required that Sunset include direct
labor, direct equipment costs, and overhead in the cost of its products. Virgil planned to
open a dedicated location to service the state contract. He wondered if job costing could
provide better information about the real costs of their products. If it did, he might change
his accounting process at more locations.
Virgil explained the conversion process. Demand for products under the state
contract fluctuated but often required short delivery times, so he decided to keep a safety
stock of those products (finished goods inventory) on hand. When inventory levels
dropped below certain levels, he then authorized production to replenish the inventory.
To reduce delays, he also decided to maintain a raw materials inventory, although he
wanted to keep those inventory levels as low as possible. It required some planning, but
he created bills of material that identified the raw material required for each product and
estimated the required inventory levels to keep production smooth and meet demand.
n. Sunset Grapchics Activity Models
After gathering information about Sunset’s conversion process, our first task was
to draw a simple activity model using BPMN. Sunset’s conversion process is typical of
most simple manufacturing companies. Then, the production authorization starts
production activities, including the issue of materials (R/M) and the use of direct labor.
Work continues until the required quantity of the finished good item is prepared. At that
point, production is complete and the finished goods inventory is updated.
Virgil remarked that a collaboration model would not make much sense here. All
the work is within Sunset. We agreed, but we said that lanes with a pool could show the
different functions within Sunset to help clarify responsibilities. Virgil then added that
sometimes they performed the work in a series of batches to make the process more
manageable. Often, it takes several batches to complete production. Each batch involves
some setup activity, then raw materials are issued, work is performed, and when
complete, we start the next batch. When all the batches are done, we transfer the products
to finished goods inventory.
We said that it would be pretty easy to add those refinements to the model, but we
wondered if there was anything else to consider. Virgil then added that they always
inspect the work before it is added to the finished goods inventory, and if it doesn’t meet
quality standards, they discard the bad items and produce new items to replace them.
Finally, while Sunset employees place the finished items in inventory, the inventory
manager updates the records.
Virgil was confident that he understood BPMN now and wanted to prepare this
diagram himself. He suggested that the model could use multiple lanes and show the
looping to reflect Sunset’s conversion process. He then sketched. This model showed two
lanes: (1) for the inventory manager and (2) for the Sunset employees who perform the
work. This model shows the inventory manager authorizing production. Then, the
conversion employees set up the batch, issue raw materials, and perform work making
the finished good item. At that point, an employee inspects the work and if the work does
not meet quality standards, the intermediate error event directs the process flow to the
“Discard Errors” activity and the sequence loops back to issue more raw materials. If the
batch is not finished, the gateway also directs the sequence flow back to issue more raw
materials, and the steps are repeated until the batch is done. Then, a second gateway
branches, depending on whether all batches are complete. If not, the sequence flow is
directed back to the “Set up Batch” activity and the steps repeat until all batches are done.
Conversion employees complete production by placing the finished items in inventory,
and the inventory manager updates the inventory records.
We congratulated Virgil on his understanding of activity modeling. We said that
his model would work, but we added some minor refinements. Each activity should only
have one incoming and one outgoing sequence flow under normal circumstances. So, we
added merging gateways for the batch and production looping flows. Then, only one
activity has two incoming sequence flows, but the second flow is only in the case of
rework for errors. It would be better though if we could also avoid that situation.
After further discussion, we decided that we could simplify the presentation by
using a looping collapsed subprocess to represent the batch activities. We didn’t need to
link the “Discard Errors” activity back to “Issue R/M” because the batch needs to
complete a designated number of good products. We just don’t count the errors. The steps
in the subprocess are then shown separately. In this case, the original model was not that
complicated, so either diagram is understandable. When certain parts of any process are
complex, it can often improve understanding of the overall process if the complex parts
are modeled separately. Then, one diagram shows the overall flow at a higher level, and
the separate expanded subprocess shows additional detail. It is possible to include another
collapsed subprocess in the expanded subprocess; thus, the models can have multiple
levels of detail.
Virgil agreed that both models accurately describe their process. He also
understood the value of the looping subprocess to simplify the main diagram and allow
separate modeling of the production batches. We noted that for internal control, we
probably should have identified a third lane to show the separate “Inspect Work”
function. The same employees that perform the work should not inspect the work. Virgil
acknowledged that we were probably right, but we could leave that change for another
day.
o. Business Rules and Sunset Grapchics Conversion Process Controls
Again, we asked Virgil about controls over the conversion process. As with the
other processes, we intended to define controls by developing business rules for the
process. First, we needed to identify important business events and define Sunset’s
intention or objective for each event. Then, we determined the appropriate actions to take
based on the conditions. For example, we’ve already listed important business events in
the activity models, so let’s examine Sunset’s conversion to develop some possible
business rules.
Virgil summarized his objectives for the steps in the process. Of course, the
overall goal was to ensure finished products were available to meet expected demand. We
outlined some standard controls over the conversion process, suggesting segregation of
authorizing, issuing, conversion and inspection duties. We reiterated that access controls
limit which of their employees can view and change records in the system and help
implement appropriate segregation of duties. We also need application controls to ensure
data integrity and an audit trail. For example, we need to control the assignment of
production authorization and material issue numbers to make sure all of them are
accounted for. Plus, we need to establish appropriate ranges or limits for each value that
your partners can add or change in the system.
With Virgil’s direction, we developed an initial set of business rules for the
conversion process. He articulated intentions (goals) for every step in the process, and
then we set business rules to segregate duties and limit partner authority appropriately.
We noted that we would need to set application controls for almost every attribute
updated during data entry.
p. Sunset Graphics Structure Models
Now, Virgil looked forward to adding the conversion process features to Sunset’s
new database. This would mean that his database could handle his entire supply chain
encompassing purchasing, making, and selling his products. We proceeded to examine
Sunset Graphics’ conversion information requirements. The primary purpose of our UML
class diagram of the conversion process is to create a blueprint for the development and
operation of a relational database to support the collection, aggregation, and
communication of process information. We follow the REA framework (resources,
events, and agents) as a proven approach to describing business processes in a way that
meets both accounting and broad management information requirements. See Appendix
A to this for a generic REA model of the conversion process.
Based on what Virgil and Linda told us about their conversion process, we
thought it was very close to a generic conversion process. As indicated by numbers 1 and
2, an employee (agent) with supervisory responsibility authorizes production (event) of
one or more finished goods items (resources). Next, numbers 3 and 4 denote that an
employee (agent) issues (event) the raw material (resource) into work-in-process
inventory based on the bills of material for the finished goods items. Finally, number 5
shows that production employees perform work to make sure the finished goods items
and their direct labor are recorded (labor operations event).
We explained that the association between finished goods and labor operations
indicates the planned labor. The bill of materials association between finished goods and
raw material indicates the planned material content of each finished goods item. The two
duality associations link the raw material issue and labor operations events to the
production authorization. Thus, the data structure captures information about both
planned and actual conversion activity.
Virgil said that he understood most of the diagram, but where is the work-in-
process inventory resource? We explained that we don’t need to model a separate work-
inprocess inventory because we can calculate that value at any time. For example, the raw
material issue event records the value of items issued into work-in-process. The labor
operations event records the value of direct labor added to work-in-process. The labor
plan association establishes standard overhead allocation rates. Until the job is complete,
the accumulated material, labor, and overhead costs increase work-in-process inventory.
When the job is complete, the initial production authorization event is updated and the
cost of goods manufactured increase the finished goods inventory value.
Virgil thought Sunset’s bill of materials should be more than an association,
although he agreed that the company’s conversion process resembled the generic model.
For Sunset, the bill of materials contains more than a simple link between Sunset’s
material (raw materials) and its final products (finished goods). He also said that they
really had no defined labor plan. Sunset just recorded direct labor incurred and used a
simple overhead allocation scheme.
We replied that it was easy to modify the generic process diagram to reflect
Sunset’s information requirements for the conversion process. We could “promote” the
bill of materials association to a type image class because there was more detail involved.
Also, the bill of materials association is typically a many-to-many relationship between
raw materials and finished goods because each raw material item could be used for
multiple finished goods items and vice versa. We would likely create a table to
implement that association anyway. We could also remove the labor plan association
between the finished goods resource and the labor operations event. We developed the
class diagram shown in reflecting those modifications, including multiplicities, and also
keeping the association between Sunset Partners and Product Categories from the sales
and collection process.
Virgil thought that the revised class diagram accurately reflected his information
requirements. However, he had some hypothetical questions about modeling the
conversion process to make sure he understood it perfectly. For example, he asked how
we would modify the model if Sunset used equipment in the conversion process and
wanted to record direct equipment costs. We replied that we would simply add an
equipment resource to capture information about the equipment, and then we would add
an equipment operations event to record the costs of the use of the equipment. An event
records costs applied to work-in-process and a resource captures permanent information
about the things available for use in the process. We added that type images can specify
the plan for resource use, and then the plan could be compared to the actual usage
recorded in the events.
