Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

Not sure whether this is the right place to ask this question, but here goes..

Currently I have requirement to add support for consignment transaction in our inventory module. I have a very limited understanding of what consignment means in inventory, i.e.

Customer get stocks/products from Seller without actually buying them, the product just resides in the Customer's inventory and it's still owned by the Seller. Only when the Customer actually buy the stocks then only will the ownership of the stock is transferred.

The issue is i can't imagine how the data will be presented to both the Customer and the Seller. What i know is that i would need to deduct the stock from the Seller's inventory when the Customer raise a request to get the stock through consignment, but what about the 'ownership' of the stocks/products? Does that mean i would need to create another column in my table to state that for each inventory it is owned by who?

Anywhere i can get information on how i should work out an inventory module like this?

Thanks.

share|improve this question
    
This sounds like the kind of domain knowledge that you should seek to get from the domain experts in your organisation. We're programmers, not quartermasters. –  AakashM Nov 20 '12 at 15:19
    
It is a kind of domain knowledge, unfortunately in my current organisation there are no experts in this area, hence my need to look for answers from the net.. –  ipohfly Nov 22 '12 at 8:04
    
OK, but you have customers? Or potential customers at least? You need someone who knows what the system should do, whatever kind of system you're building - otherwise how would you know when you've got it right?! –  AakashM Nov 22 '12 at 9:10
    
@AakashM You're right, however with my clients, most of them don't know what they need in terms of stock control, basically they just tell us that they want the 'industry practice' version and when things are not working as per they expected they will just blame us. I'm trying to get someone with the domain knowledge to work with us, hope there'll be good news.. –  ipohfly Dec 4 '12 at 8:04
add comment

2 Answers

Fist, I must implore you not to build this system from scratch. It is a much more complex project than it seems. Please consider using an open source eCommerce platform, order management system, and product catalog. Check out the Apache Open for Business Project. There are many others - most want you to pay them consulting fees.

Many order management software packages often model this using the concepts of supply and demand. You have some high level entities, such as Product (for example, FancyBrand Men's V-neck undershirts), Item (for example, FancyBrand Men's undershirt in size Medium and color white), Supplier (the company who sells the item to the retailer), Vendor (the company who actually makes the item, who is not necessarily the same as the Supplier). A Retailer could buy Product Foo, which is produced by Vendor Fooz, from Supplier Bar today and then from Supplier Baz tomorrow. Or Foo could by supplied by both Bar and Baz at the same time (hint: don't use 1 column for the Supplier-Product relationship).

When Supplier Bar sends/allocates N more Foo Items to the Retailer, Retailer should increase its Supply of Item Foo by N. You can also attach a "type" to the Supply that you add.

When a Customer begins the process of purchasing M Foo Items, you typically increase the demand against Foo by M. After the transaction is complete (credit card has been validated, fraud check has completed, etc.) Retailer decrements both Supply and Demand by M.

I would also avoid thinking about the Supplier's inventory level for Foo. The Retailer knows nothing about the Supplier's inventory. The Retailer only knows how many Foo items are in the Retailer's inventory, and of those, how many came from Supplier Bar or Supplier Baz. Even if the Retailer hasn't paid the Supplier for the item, and even if the Supplier never sends the items to the Retailer (maybe because the Supplier ships directly to the customer after the Retailer handles the transaction), if the Retailer can sell those items to its customers, then those items are part of the Retailer's Supply.

There are 2 ways a Supplier might want to be paid: on each transaction, or periodically. If the Supplier wants to be paid every X days for whatever items the Retailer has sold. So you need to be able to answer the question: "How many Foo items from Supplier Baz did I sell in the last X days?" If the Supplier wants to be paid on each transaction, you still need to know which Foo Item in each transaction was sent/allocated from Supplier Baz.

Again - don't build this all by yourself!

But if you insist, I've seen consignment modeled 2 different ways and both worked fine. One way is to model all the consigned inventory as a separate distribution center. For example, if you have 45 physical stores and 5 warehouses, you'd have 50 distribution centers. You can treat all consigned goods as being held in a separate distribution center. This works particularly well if your suppliers don't actually send you the product, and the product is in fact shipped to the consumer from the supplier.

The other way I've seen this done is to use a type attribute on your Supply. Some example types could be "good condition", "slightly damaged", "safety", or in your case, "purchased" vs. "consigned." Therefore you could have rows like the following in your Supply entity:

id  sku         quantity  type
--  ----------  --------  ---------
1   foo-item1   10        consigned
2   foo-item2   5         purchased
3   fooz-item1  20        consigned

Note that the sku must uniquely identify an item and if you have multiple suppliers for that item, then you need to be able to navigate from the sku back to the supplier.

And you can also find a reasonable open source data model for invoices and oders.

share|improve this answer
    
Thanks for the info. Actually i'd used OfBiz myself before, but currently my organization is using C# and they have their own modules which are very tailor-made for a specific industry, and I need to integrate the inventory module with them, so i think it will difficult to find an open source inventory system for this? –  ipohfly Nov 22 '12 at 8:05
    
You're right - it will be tough to integrate OfBiz with a C# app. Given that your employer is using C#, maybe they enjoy buying things from Microsoft? I'm sure Microsoft would be happy to sell them some enterprise retail software (microsoft.com/enterprise/industries/retail-hospitality/…). –  rzrelyea Nov 23 '12 at 19:13
add comment

The model is similar to an e-commerce cart. You can add products to the cart, but until you pay, the seller is still the owner of those products.

If I understand well the context, the difference with a cart resides in the fact that the same product can be in one and one only cart. Once the customer adds a product to the inventory, the product is still owned by the seller, but is marked as unavailable, so that the seller doesn't end up explaining to its buyers why they cannot get their product while they added it to the inventory.

As for the ownership, the seller owns the product until payment. Once payed, the buyer becomes the owner.

share|improve this answer
    
Thanks. My problem is that I'm not sure how to present the 'stock placed in customer's warehouse but still own by admin' relationship to the system users, like whether i should have a report to show all those consigned stocks? –  ipohfly Nov 22 '12 at 8:07
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.