The CART system.

In a earlier post I’ve discussed the Items-Transactions-Contracts principle. Today, I am going to expand my views on this topic with the CART system, which is basically a system that can handle items, transactions and contracts.

CART stands for Catalog, Actions, Rules and Templates. And yes, you might already see how ITC fits into CART. The catalog contains all items in your system. The actions are the transactions of your system. The rules are your contracts. And the templates are all the templates you’ve defined for the items, transactions and contracts.

For those who want to look for a matching database model in this system: don’t! There is no model that can handle it all. These are actually four different class models and classes are more than simple database models. They include code that act upon the data. But if you do want to create a data model, just consider this as a system with four different models that are connected to one another. (Maybe three if the templates are only defined by code and metadata.)

When you create a new system, you first have to set up the catalog. Why? Because the catalog is the inventory of everything that you’re going to handle. Next, you set up the actions so you know what you can do with those items. In general, you can just move them around, create new ones or remove existing items. This is all arranged by the actions system. Once you have defined all actions, you start to combine them into rules. If you want to sell an item to a customer, you’re probably end up with several connected transaction. One that sends the item to the customer, one that receives the payment from the customer and maybe one related to VAT that you have to send to the Tax Office. Thus a single sale actually results in several actions. Once you have defined all catalogs, actions and rules, you’ve probably created the templates too. Because every definition of an item, transaction or contract will end up in your template system.

So, let’s consider a simple example to use this principle upon. Let’s organize a garage sale. Say, you have a goal to reach: $500. You want to reach this by selling all your old stuff thus you announce a garage sale. You create a few flyers and you make some cold lemonade so you have some added expenses that you also have to earn back. And to keep track of it all, you want a system to keep track of all the numbers.

First of all, you already have a basic CART system with simple templates for contracts, transactions and items. An item is just a GUID to identify the item. You won’t need anything more. The transaction is a record with a GUID as identification and three other GUID’s for the sender, receiver and the item itself. Sender and receiver can be null. Last, you will need a contract which will also have a GUID as identifier and a link to the transaction templates that it supports. Which also means that you need a way to store templates in some way, but let’s identify them with a single GUID too, plus a unique name and version number. (The version number is required if you’re going to support it and want to alter the system in the future.)

First of all, you define the persons. One is you, the salesperson. One is the customer. Templates for these are simple and more than the basic item plus a name would not be required. You would also create similar item types for the goal you want to reach and the expenses you have. The goal type could have an extra description to explain the goal in more details. Then you will create the type for the items that you’re going to sell. Call them products and give them a name and a short description. Add a monetary field to the record for the default price. You might give discounts but this would be the price you would ask. And maybe even a picture if this is going to be an online garage sale. Since you’re going to give away lemonade and perhaps snacks too, you might also want to create an item type for these, since these will result in added expenses. These too would have a name and a cost price. This all will be your catalog and all these definitions are stored in your templates system. (Which could have any form. A Database model, class definitions, whatever.)

Next, you will fill them with records. Add yourself as salesperson. If your wife and kids are also helping, add them too as sales persons. However, adding more than one salesperson might need an additional shop item, with transactions between shop ans salesperson to move products. Add a single customer record, unless you have a few customers who are special or when you want to keep track of your customers. In that latter case, you would have to add customer records when you sell an item to a new customer.

Add all the things you want to sell to the products. When you’re selling lemonade, make sure you also add “Glass of lemonade” as product! Finally, add the expenses that you’re likely are going to have. Bags of chips or peanuts, bottles of lemonades or whatever else you use to make lemonade, glasses, if you use real glasses to serve your customers because even if they return the glasses, some might break. Or paper cups if you don’t use glasses. Anything that you think is important to keep track of.

Next, the actions with all possible transactions. And suddenly you will realize that I haven’t added “money” as item. Yeah, that’s right. I forgot, so add a new type to the items for money. Simply the ID and the name “Money”. Then add a money record for the currency of your choice. Add multiple records if you want to support multiple currencies, although that would make trading a bit more difficult, since it means that you will have to convert the base prices of the items to the different currencies.

So, let’s define a few transactions. First of all you can have one where the salesperson sends a product to the customer. The customer would then have to send money back to you. The product transaction is simple: salesperson, product, customer. The money transaction is a bit more complex, since it has a customer, money and salesperson field, but also an amount field to specify the exact amount that is paid.

If you want to allow refunds, you would also need transactions for the reverse order. These would be different transaction types. (Then again, you could also delete existing transaction records but then you’ll lose a historic overview.

Next, you will need money transactions to send money from the salesperson to the goal and to send money from the salesperson to the expenses. But expenses and goal have a limit to the amounts they can receive so whatever remains would be profit. Which reminds me, I’ve forgotten to add “Profit” as an item type. Add it, with one profit record.

Did you notice that I did not add an amount field to the goal and the expenses? That’s because we’re going to set these values by transactions! To set up our goal, we need a transaction with the goal as sender, since we want to reduce its amount. When the goal reaches zero, its solved. (Same for expenses.) And it’s a money transaction so the item we’re sending would be money and we need an additional amount field. The target is void, null. We could define an extra item that we’re using to specify the exact destinations that the money is used for, but for our sales system, it’s just not important enough. Remember: we don’t have to include the whole world in our application!

The expenses are a bit similar, although here the sender is a specific expense. And the amount would default to the amount specified by the expense itself. (Unless we got a discount when we buy a new bottle of lemonade, of course.) And again, these amounts are sent to the void, unless you want to keep track of where you’ve bought the stuff.

So now we have transactions for customers making purchases, customers asking for refunds and for maintaining the expenses and keeping track of reaching our goal. And already we see the rules in this all! One rule is for making purchases. A customer buys something so we have two transactions. A product moves to the customer and money to the salesperson. However, we need more transactions, since the money is used to reach our goal! So the purchase rule would need a transaction to send money to the expenses first, because we first need to pay the expenses before we have money available for our goal. Once the expenses reaches zero, we can add money to our goal. When our goal reaches zero, we add money to our profit.

When we allow refunds, we’ll need a refund rule, which would basically do the reverse of a purchase. But refunds will need us to move money away from our profit, goal or even expenses. So when we do a refund, we first lower our profit, making sure we never get a profit below zero. When we have no profits, we will add the refund as an extra expense. Don’t subtract it from our goal but just remember that we can only reach our goal when our goal and our expenses have reached zero. So, basically if we have to do a lot of refunds, we have a lot of expenses, even though we have reached out goal.

And we need a rule for our expenses, which basically means we’re going to the supermarket to buy snacks and lemonade to serve. Since we don’t really care about the supermarket, we’ll just receive lemonade and snacks from the void while sending money to the void. (Actually, we could have replaced our customers by the void too, but it’s better to use customers so we know which transactions are actually sales and refunds, and which ones are just expenses.

So now we have a bunch of contract and transaction templates:

Purchase contract:

  • Salesperson gives the product to customer.
  • Customer gives money to salesperson.
  • Salesperson adds money to expenses.
  • Salesperson adds money to goal.
  • Salesperson adds money to profit.

Refund contract:

  • Customer gives the product to salesperson.
  • Salesperson gives money to customer.
  • Salesperson removes money from profit.
  • Salesperson removes money from expenses.

Expense contract:

  • Salesperson removes expense item. 

Shopping contract:

  • Salesperson removes money from expenses.
  • Salesperson adds Expense items.

Balance contract:

  • Profit moves money to expenses.
  • Profit moves money to goal.
  • Goal moves money to expenses.

Setup contract:

  • Remove money from goal.
  • Remove money from expenses.
  • Add salesperson.
  • Add shop if multiple sales persons are added.
  • Add customer.
  • Add products to salesperson. (Or shop.)
  • Add expense items.

When you use multiple sales persons, you might consider adding transactions to send products from the shop to the salesperson, and back again for the refunds. You can also choose to have products sent directly from the shop to the customer, with the money being paid to the salesperson. You might want to keep track of how much each salesperson makes, otherwise it’s no use to have multiple sales persons. Your salesperson would be the shop. The products transactions between shop and sales persons would be to keep track of who sold which item…

This all defines our CART system for a simple garage sale. We have a bunch of items in our catalog, a bunch of possible actions and six contracts. All of them defined as templates and the contracts will need some code to check for the actual status of our goal, our expenses and even keeping track of our expense items, because when we run out of lemonade, we might need to buy more.

The next step would be to design some data models for the four different systems, to connect them and to finally create a nice user interface for the application. But that’s a nice challenge for my readers. Just keep in mind that you’re supposed to keep things simple.

Before you start selling, you would need to set up the shop, which would need the setup contract to be used.

And at the end of the sale, what you would like to do is to check if your expenses are zero. If they’re below zero, you will need to balance the three accounts. (Expenses, goal and profit.) This requires the balance contract that I’ve added to the list. Basically, your expenses must reach zero, else the whole thing has been a huge loss. Next, your goal needs to be zero, else you haven’t reached your goal. Finally, whatever is in your profit will be your profit of the garage sale, which you might use to celebrate a great action.

Next, if you want to build the thing in some client-server style, the contracts would be the web methods that you will need to create. You will also need a method to give you all the items in your system, which you will need in your client. Your client might want to display each and every purchase and refund so you might want to get all these contracts with related transactions. But you’re probably more interested in the current status so it’s more likely that you just want to see the amounts left in your goal, expenses and profits, and perhaps also for each salesperson. Basically, that would just be a method that would sum up all money transactions related to a specific item. You would send the item ID to the server and it would return an amount back.

Software development…

Today, I want to talk about designing software. Basically, I want to explore my principle of items-transactions-contracts (ITC) that I’ve discussed before. But let’s look back on those first.

An item is just that. It’s something that you have to work with. It can be a person, or it can be a currency. Maybe it’s a product or just a description of a product. Whatever it is, it’s something that has data that you need to use. Items can be containers for other items, thus items have children and one parent. Like a box of matches that has two matches. Or a person who is part of a household.

Transactions will handle amounts and describe movements of items. Basically, a transaction is nothing more than a message saying that an x amount of item A is moved from item B to item C. A could be a bike that is moved from the shop to its new owner. Or it’s a crate that’s moved from shore to a boat. Or it’s an amount in Euro’s that’s deposited in your bank account from your employer. Transactions allow you to move around data, but also to create or remove items from your system by moving them from to towards the void. (The null container, meaning either recipient or sender is null.) Transactions are also related to time, since a transaction will happen at a specific moment.

Contracts are used to group transactions together. Most transactions are part of a collection of transactions that are related to one another for a special purpose. For example, your savings account will give interest but to get that interest, you first need to put money in your account, and wait for a while. You do a transaction and your bank will follow-up with transactions. Another example is when you send a package overseas. First you deliver the package to the post office, which will give you a receipt back, confirming your delivery. The post office will then move the package around by truck to the harbor, then by boat to cross the sea to the next harbor where a truck will pick it up again to bring it to the post office nearest to the delivery address. And then a mailman will deliver the package. And in every step the post office will send transactions back to keep track of the package so it won’t get lost.

Each of these are governed by templates. You can have templates describing specific types of items or specific types of transactions. You would generally also use templates for contracts. Most object-oriented developers are already familiar with templates and refer to them as “classes” or “object types”. But if you create dynamic objects, you would have to deal with dynamic templates to describe the layout of the data.

When you look at your design, you should try to see if you can divide your data in these four groups: Items, Transactions, Contracts and templates. You will notice that many systems won’t match this pattern. You will also notice that projects that don’t match this pattern might have some limitations on what you can change about them without doing a lot of re-factoring. So, does this pattern work for real-world solutions? Well, let’s set up a design.

The case: a movie theater wants a completely new system to do its administration. So the first step would be to find the items that you would need. Of course, you’d be dealing with persons, with movies, with merchandise and snacks and soft-drinks and of course with tickets. But you would also have to work with chairs, since people want to sit while watching the movie. And the theater hall where you will play the movie. Maybe you also want to keep track of the equipment. But that latter thing isn’t very important. One more thing that is important is money. Money is a strange item but you still need to keep track of your money…

Well, the persons can be divided into multiple groups. You have employees who you need to pay and who collect tips from visitors. They might also receive commission from the sales of snacks and drinks. You will need a lot of data about your employees.

You would also have visitors, but in general a simple headcount would be enough. You could have special visitors like movie directors or actors who visit your theater so your system might want to keep track of some special visitors. (It would also allow visitors to subscribe to your theater.)

And then the contacts that you’re in business with. You need to buy the movie rights, buy the food and drinks from distributors, maintain the address of your accountant and other important persons and maybe even keep a list of important actors and directors whose movies you want to show. This would be a generic address book, but you might want to link these to specific items in your system through transactions. If you use Microsoft Outlook, these would be in your Outlook Contacts, but your system could link to it and e.g. send an order when your stock runs out of soda.

So, we have a list of item templates already, and it’s already growing fast. The next step would be determining the transaction and contract templates and link them to the item templates. For example, your employees work for you so you have contracts with them. For every specific amount of time they give you, you will give them a specific amount of money. This is their salary. Also, the commission means that for every amount of products that they sell, they will receive a small percentage of the profits on those items. So if they sell a soda for 2 Euro’s, they might receive 4 Euro-cents in commission.

Next the visitors, who also have a contract with you. They buy a ticket which will give them access to a specific hall at a specific time for a specific duration. In the most complex situation, you have a transaction for the payment, one for giving the ticket and one for the visitor to move from the void to a specific chair in your hall. And another move of the visitor from the chair back to the void when the movie is over.

And then you have the transactions with your distributors and suppliers. You need to buy movie rights and maybe you have a specific contract with your distributor which provides you with 12 movies per year for a fixed price. So one money transaction from you to the distributor and 12 transactions from the distributor to you. Your suppliers will also have plenty of transactions. You pay them for a crate full soda drinks, which they deliver. But they will also pay you back for the empty packaging, which would be the crate and the empty bottles.

To put this all in a design, you would at least need three tables. One for items, one for transactions and one for contracts. You would also need a place to keep the templates, but those could be just part of your code. There’s no need to make things more complex if you don’t need the extra flexibility.

The tables should not be simple database tables. You need a more object-oriented database system. In Visual Studio you have such an option by using the entity framework. This framework will allow you to add inheritance to your tables so the Persons table would inherit from the Items table. Thus, a person would still be an item, but an item isn’t a person. By using inheritance you could set up a simple, generic system for all the things I’ve described above and once you’re done, you have a great engine for your administration project. You can easily expand it with more functionality and depending on how you’ve set it up the migration to newer versions would be very simple. The entity framework will give you a powerful data layer and your next step would be to build a business layer and GUI for this project.

When you follow the ITC principle, then any developer should have no problems recognizing the purpose of any data item in the project. You might replace your complete development team with a new team, and the new team would easily see the layout of your datamodel. No complex documentation would be required since the hierarchy of your data tables would give more than enough information already. Just be aware that no one should step away from this principle or else your project becomes more complex again…

I need to blog more often.

The life of an ICT specialist like me is always busy, busy, busy. Even on my day off, I still have a lot to do. This morning, for example, I went to the dentist to have two fillings replaced. I still had two old amalgam fillings and these have been replaced by two nice, white ones. The rest of the day was reserved to take a long walk with my dogs but they’re not in real shape today. I think it’s too warm for them now so maybe another time. I still have a few other things to do too…

For example, I am working on two personal projects. One is related to me keeping score of my glucose levels. Yeah, I have diabetes but still don’t need insulin injections. I want to keep it that way so I need to keep an eye on my glucose levels. More moving, better eating will improve my health. But the bookkeeping requires a simple project which allows me to enter the results and it should generate reports and charts for informational purposes. And not just for me, but for generic usage. Right now, I’m still thinking about what the project should do exactly. Thinking about the complexity of it all. It should be able to keep track of multiple users and maybe it should also be usable by physicians to add patient accounts so they can keep track of their patients. Maybe it needs a Smartphone module, an Android module or even an iPad module so patients can use simple mobile devices. And perhaps an import/export module so patients can export their data in some format to have it imported in some other application. And of course a reporting module that preferably supports Word and PDF. And I have plenty of other ideas too. As I said, I’m busy.

And then the other project. That’s more a self-education project. I like to generate CGI artwork but after several years of creating art, I ended up with a large collection of homemade images. Combine this with my own photo’s from my digital camera’s and it’s just a lot of images. I need a better way to organize them, adding tags and publish them in some way. I already use Flickr for some of the more interesting images but I want to publish all of them. So I have an idea of a simple system that will store the images with additional tags, keywords, license information, some extracted EXIF information, a rating value, sign if it’s NSFW or not and much, much more. And I want two versions of this tool. One should be a browser app which would show up on any device and the other should be a Silverlight app which would mostly be supported on windows platforms, but which would give a much nicer user interface, thus a better user experience. And yes, this too keeps me very busy…

Of course, don’t forget that I still create CGI artwork. This too eats up a lot of time. But worse of all, it requires my computer to do the most work, churning numbers to render some data into a digital image. It’s a process that might take 5 minutes or 60 hours, depending on the complexity of the image…