Supplier Catalogs in eProcurement Systems: Domain and Business Models
Alexandr Orlenko | August 4th, 2023
We already discussed the importance of bringing product catalogs into the eProcurement area and discussed how it could be implemented. Today I would like to discuss domain and business models to highlight the pros and cons of implementing the data structure.
Without a doubt, a domain model stands as the fundamental pillar when constructing a system. Drawing from my experience, I have encountered various models and worked on them from different perspectives, both as a user (seller/buyer) and as a maintainer (developer). Now, let me share my insights and propose a universal approach that I believe will become mainstream.
Domain Models — The Foundation of a System
A domain model is the backbone of any system. It is a structured visual representation of interrelated concepts or real-world objects that includes the vocabulary, key concepts, behaviors, and relationships of all entities. Using a domain model streamlines the design, development, and support processes, saving significant time and ensuring that all team members are on the same page.
Product Data Types
I am used to separating each product into the following parts: content, price, inventory, and shipping cost.
It is based on different needs for updates regularly. For example, content is more or less stable and doesn’t require frequent updates in comparison with inventory that may be updated hundreds or even thousands of times per day based on how active sellers sell. So it doesn’t make any sense for the system to update the whole product if just the stock quantity has been changed. But unfortunately, some sellers can provide their updates only as a whole catalog all the time and it applies as an additional requirement on the import process to sort out unchanged data. And it becomes even more important to differentiate product data types in the domain model.
Content
Product content comprises the visual elements of a product or service, such as title, description, images, standard attributes (brand, manufacturer, country of origin), and customizable attributes for more detailed descriptions.
It involves categorizing the product using standard taxonomy systems like UNSPSC (United Nations Standard Products and Services Code), HS (Harmonized Commodity Description and Coding System), eClass (a global and ISO/IEC compliant system), etc.
It is a configuration. Some products are complex and represent group of products such as bundles (several products are grouped together and sold as a single unit for one price), variations (a single product with specific values for all variation attributes: size, color, material, etc.), and linked (accessories, up-sell, cross-sell, etc.) products. They can include eForms (digital forms that can be used to collect information from buyers before adding a service/product to a cart).
Price
The pricing aspect offers diverse options: unit price, list price, and more, with considerations like base quantity, unit, minimum order, and lot size.
It can also incorporate tiered or volume pricing, providing discounts based on the quantity purchased, enhancing the buying experience and encouraging customer loyalty.
Inventory
Inventory entails essential details about product availability. It includes stock status, quantities in the seller’s warehouse, and items restricted for buyers or agreed upon by contract. Additionally, it provides information on expected restock dates for out-of-stock items and whether the product is on backorder. This comprehensive inventory management system ensures a smooth shopping experience for customers and effective stock control for sellers.
Shipping Cost
Shipping Cost encompasses crucial information about available shipping methods, estimated delivery times, and associated costs for each option. Depending on the chosen quantity, shipping costs may vary. This comprehensive system ensures transparency and allows customers to make informed decisions while facilitating efficient shipping and delivery processes for sellers.
Additional Terms for The Domain Model
I suggest to use additional descriptive terms in the model, such as “offer item” and “offer” to enhance clarity and facilitate effective communication within the domain.
Offer Item
In a business model where a product can be offered multiple times to the same or different buyers, it is practical to consolidate the variable aspects of each product into a single unit. This includes elements like price, inventory, and shipping costs. Since sellers may have distinct contracts with various buyers, providing better terms or special discounts, we can refer to this entity as an “Offer Item.”
Offer
Offer is a collection of such Offer Items. It can also be called a Contract, but my experience is that a contract is just a special case of an offer with strongly defined conditions and dates, and it can’t be changed in the middle once it’s approved by both sides.
We need such an aggregation to manage the common properties of this group of items in one place. We are talking about the buyer for whom we create it, the start and end dates when it is active, the state it is in now, and the target market when a seller needs to define a country or list of countries where products can be sold.
Count of Copies for a Seller Product Catalog
From my point of view it is very important to define how many copies of a Seller product catalog we have in the system and why. It has to be reasonable and shouldn’t slow down the development of the system.
One Copy per Connection
I think the most common case is when a seller is connected to only one buyer on a system because that buyer chose the system and invited that seller and other business connections to unify invoice and order processing. That means we don’t have to overcomplicate the structure and terms. Each seller only has one copy of their catalog, especially if they provide it to a buyer from their PIM, and they don’t even need to manage it on the system. In this case, the buyer owns the data and can enrich and use it.
Multiple Copies per Seller
If the seller sees other buyers in this system or is interested and can find new buyers here then they need to manage it and distribute it between different channels (buyers) then we already have (number of buyers * 2) copies of their catalog. Because we have a copy for each buyer from the seller side and each buyer has their own copy to enrich it. And just to imagine how hard it is for the system. Let’s say we have a big seller with 10M products with 10 buyers where they sell.
As a result, we need to store in DB 10M*10*2=200M products. It is really expensive to store and process extra volumes. And if we apply the real picture as the goal of system growth and say that big sellers sell their products for thousands of buyers inside our system, then we realize that this architecture applies some limitations and doesn’t allow us to grow as fast as the market demands.
One Copy per System
In a very special case, the content of each product is presented only once, and sellers who sell that product don’t have to provide the content at all. They use a universal identifier to define which product they want to sell, and provide price, inventory, and shipping costs. Only handmade products or services can still be owned by the seller. For all popular products and catalogs, we have only one copy per system, not per seller. And in this case, the system owns the product content, but not the seller. The system can sell them from its own warehouse. It can also provide a service to securely connect a buyer with another seller when a product is out of stock at the connected seller. Because the system knows all sellers for each product and their inventory and rating history.
One Copy per Seller
The previous case requires less space to store data, but it doesn’t provide the flexibility to build their own view, which seems to be important for enterprise buyers. Because each eProcurement client can have its own vision of how it should be presented to its users. So I prefer the option where a seller owns the data but has only one copy of their product catalog and offers the same content to buyers with specific quote item data that can include specific prices, specific inventory, specific shipping costs and so on.
Considering Seller Opinions
You can say that everything written above is just a view from the system side and the seller side is just ignored. I would say that I take care of a lot of sellers and I am absolutely sure that the most important criterion in building the system is the usability of it for the sellers. I talked a lot with them and found out that almost all of them have their own PIM system to manage product data and they just need a flexible integration point or layer to connect two systems and make this processing fully automatic and stable.
I have heard from some of them that it is clearer for them to work with one product catalog per buyer. They said that it is easy to control different versions. But again, none of them said they needed to share different titles or descriptions or images. It was all about different quantities and different prices all the time.
So it’s not so important to them how the system is designed, but it has to meet their expectations. If they are concerned about security and want to have a point of investigation to be confident in the stability of the system and a high level of transparency, then it can keep the history of changes to provide a clear report of who changed something and when. This is a very useful feature in any case.
Solution
As a result, I have created a domain model diagram that fulfills all the requirements discussed above. This model aims to offer an efficient solution for the eProcurement system, ensuring smooth communication and seamless functionality for buyers and sellers alike.
We can see that we have only one copy of a content per seller and a buyer works with the same copy.
Content*, OfferItem*, Offer* objects mean that they only extend Content, OfferItem, Offer objects respectively owned by the seller. This is necessary for data isolation. Each buyer has its own space to enrich data without affecting the seller’s copy. As a result, the seller sees only his own part, but the buyer sees both.
One product can only be presented once in an offer based on specific conditions in an offer item. Each product can have as many offer items as it needs, because it can be presented in different offers to sell its products on the network to different buyers and marketplaces, or to the same buyer but for different periods of time and/or different prices, stock, shipping costs.
From my point of view, it is very important in today’s reality where every company needs to support multiple systems to fully automate its processes, to simplify the customer experience and to provide a single point to manage all the connections, all the catalog data and distribute it to the sales channels. And this model fully covers that need and provides maximum flexibility as it could be.
If you see some missing pieces or some special requirements that don’t fit into this model, I would love to look at them together and define more about it.I look forward to your reactions and comments!
Take care!
Let’s start building something great together!
Contact us today to discuss your project requirements and hire our dedicated development team. Together, we can revolutionize your eProcurement capabilities and drive your business forward.
