RubyClerks

This is what is in the box

 

Products products products

The Product is what a company is all about. You buy or produce it, then you sell it and that is what you make your money from.
RubyClerks model of the Product is simple but not overly so. A product has a name, description, picture and price for display. A weight for shipping and a tax rate because you have to show the tax by law (and it keeps changing).
A barcode, usually ean13 is what identifies a product uniquely and can be used for scanning. A supplier code may be used for ordering it.
Products may be grouped into Product Groups for displaying, and reporting.
Products may have key-value attributes, again mostly for displaying, and reporting.
A Product line may be created to group similar products (Product items) to be displayed as one.

Orders - you sell

RubyClerks is very flexible in how you create orders, which are at core just a list of items. An item refers to a product at a certain time. You can think of an item as a physical entity. It copies the price and tax attributes so they never change later.
The states of an order reflect the lifecycle it goes through. When you or a customer has finished creating the order it is ordered.
Next it may be shipped or paid, there is no restriction on which of those comes first.
An order is completed, when it has been paid and shipped. Finally an order may be canceled by you or the customer any time after it has been received

RubyClerks does not have integrated payment, so how you receive or return money is your business (see modules).
But it does track inventory, and stock is reduced when an order is shipped and added when a shipped order is canceled. As physical shipping is optional, so is customer address information.

 

 

Purchases - you buy

RubyClerks assumes that you buy your products from suppliers, and each product is supplied by one supplier. So this information may be stored in the product and used to automatically generated purchases when stock is low.
The states of a purchase are simpler: it is created immediately upon creation and unlike an order may be edited later. Until it is received, at which point the items in it will be added to your stock.
This is the normal way for businesses to receive goods and thus RubyClerks keeps track of the stock this way.

Configuration


For simplicity RubyClerks treats some parts of the system as configuration (not models), these are mainly:
The default tax rates that you are subject too. Tax rates are taken to be a percentage of the product price (vat or european style) and may change per product.
Your payment methods. These are backed by code, only simple cash is built in.
The list of shipping methods you offer. Their names, rates and the code they are backed by. RubyClerks provides Postal service style shipping, by weight.
Unlike other systems RubyClerks does not store Configuration in the database, but in a configuration file. That is assumed to be under revision control and this system allows for much easier testing and evolution.

 

 

And a little bit about what it's not

RubyClerks, like all software, is made for a particular purpose. Defining this purpose seems to count as opinionated nowadays, but it is really just drawing boundaries. Unlike other systems that may say they're not for everyone but then grow to accommodate almost everything anyone has ever thought of, RubyCerks intends to stay small. If it doesn't serve our business, it is unlikely to make it in.
And even if, we pursue the microkernel idea: if you can leave it out, or do it in a module, do. Since ruby is extremely flexible . . .
A little list of things that are not intended
split shipments This is one for the big boys, just create two orders.
split payments another big league feature.
searching and caching are not necessary in the admin side and up to you on the store
us tax may god (or spree) help them. If an extension needs small changes for this i may actually bend a little
reporting is important, and is an extension
multiple storages i may consider this after someone has demonstrated it in an extension
multiple stores is it's own project
themes we have css for that. Though view extensions will be accepted
configuration in db not practical and wasteful (all those db queries)
product matrixes while popular in apparel are a view issue
refunds are so rare for a small business that handling them by hand is ok