Estimating the real value of source code
Thursday, October 13, 2011 12:16:11 PM (GMT Daylight Time, UTC+01:00)
If you run a software development company of virtually any size, you've no doubt been asked/bullied at some point for the source code; sometimes it's even stipulated as a requirement of the contract.
At The Site Doctor we don't tend to quibble over the source code (especially not for standard websites at least) and that's mainly because we know that the value of what we do isn't in the files of code themselves; instead the value is in our knowledge of you, your product, your requirements and our past experiences in our respective areas of expertise.
Putting to one side for a moment the knowledge gap (this can be filled over time/with enough resources), depending on your future plans, getting access to the source may not be the holy grail you think it is. If you are actively developing your project on an on-going basis (you should be), consideration will need to be given to how you ensure your copy is up to date. We have systems to handle this (called source control) but you have to question whether the additional time required to learn and manage the various processes are of real benefit to you.
There are a few instances however where having access to the source code is definitely worth it. Have you for example got a contingency plan in place for if your supplier was to no longer exist? What would you do and how would you cope if the development company was no longer around? In these instances, having a copy of the source -or more importantly knowing how you can get access to the up-to-date copy is very important.
How can I quantify the worth of the source code to me?
As with many scenarios like this, there's not really a "one solution fits all" answer however after a little internal discussion we came up with the following:
| Value of Source | Considerations |
| High | - Was the system completely bespoke?
- Is it integral to your day-to-day operation?
- Is it your only source of income?
|
| Medium | - Although integral to your business, you have a copy of the software in a usable form and it doesn't change regularly.
- The system offers "standard" functionality which can be replicated with relative ease should it be required e.g. e-commerce functionality.
|
| Low | - The system is something generic, does not need to be changed
- You have control over the aspects that you need e.g. it's a website with a content management system
|
Is it worth getting the source code as a client?
Yes; but I would consider the message it's giving to your developers. If you ask for it at the beginning of the contract then there shouldn't be a problem but bringing it up after delivery might leave the developers wondering what your motive is (even if it is totally innocent).
Should I give the source code to my client?
Yes; unless you've clearly stipulated otherwise to the client from the start for some reason e.g. to reduce project costs. You should always write your code in a way that is readable to others anyway and knowing that you might at anytime be offering up the source code will encourage you to keep it that little bit leaner.
How do you handle source code with your clients?
To handle a scenario in which The Site Doctor no longer exists (whether it's because we've gone into administration or we're all hit by a meteor), we use Crisis Cover; an online information storage system that securely stores all the information our clients would need if we were no longer around. Crisis Cover then checks that we're still around and if not, distributes the information to the designated contacts.
If you've not already got some form of contingency plan in place I urge you to set something up now whether it's a service like Crisis Cover, Excel or paper!
In closing I would definitely promote the attitude we have at The Site Doctor in that it's better to build long-term partnerships but you should still have some disaster contingency plan in place.
uCommerce is now free and why it’s great news
Friday, June 17, 2011 12:38:15 PM (GMT Daylight Time, UTC+01:00)
Those of you who were lucky enough to make it to CodeGarden 11 (or have been following the #CG11 hash tag) will no doubt already know that uCommerce Starter Edition is now free.
Why this is good news
For quite some time we've been lacking a good all-round e-commerce solution with CMS ability (regardless of platform). Many of us have written hacks, combined multiple solutions together to form a behemoth -usually involving multiple logins etc or attempted to write our own solution which (either down to time or budget limitations), is never quite re-usable. Ultimately, there's been no all encompassing solution that was affordable but more importantly, able cater for small stores as easily as it could enterprise level solutions.
Umbraco has been working hard over the past couple of years to make the CMS as robust as possible and is now powering sites like www.asp.net, http://msdn.microsoft.com and a fair few other enterprise solutions. Being a proven concept is great because it means your investment is minimal -you only need to learn one solution which is mature enough to cater the majority of scenarios and now adding e-commerce to it's arsenal means it covers all bases.
Which uCommerce version do you need?
One question that I heard a lot around CodeGarden was "yes it's free but what have they removed from it?". Usually when someone is giving away something for free, it's not quite what you need/want. Thankfully that doesn't appear to be the case with the free edition of uCommerce.
Depending on your requirements, you'll more than likely find that the starter edition more than covers your needs (it's what powers most of our solutions). I find the thing that usually confuses people is the use of "Catalog". In uCommerce, a catalog is a group of categories and most e-commerce sites only need one catalog.
You may need multiple catalogs in the following scenarios:
- The Umbraco instance runs multiple websites, each website needs to have it's own product catalog, shipping rules etc (basically it's own store)
- You want to have different category/product structures for different countries
How do they compare?
This is so hot off the press that they've not yet had a chance to update the comparisons so I may need to update this table but here's a quick look at the comparisons and I also currently don't know the prices
| Starter (FREE) Edition | Professional | Enterprise |
| Unlimited Categories |  |  |  |
| Unlimited Products |  |  |  |
| Product Relations (What Customers Also Bought) |  |  |  |
| Multiple Shipping Methods |  |  |  |
| Multilingual | |  |  |
| Marketing Foundation (built in marketing, promotion codes etc) | |  |  |
| Review System | |  |  |
| Multiple Catalogs | |  |  |
| Multiple servers supported out of the box | | |  |
| Multiple Catalogs with user level security | | |  |
What can you do with it?
uCommerce is able to handle pretty much any e-commerce scenario you're able to throw at it. We've reviewed all the e-commerce sites we've worked on over the years (either developed entirely or partly by us) and we have found very few scenarios that uCommerce isn't able to accommodate.
The really nice thing about uCommerce is if there's something missing you can simply write it yourself and plug into one of their many pipelines using .Net controls, XSLT, Ruby or Python (if you really wanted to!).
What does it mean for the competition?
There are a couple of other e-commerce solutions for Umbraco already namely Commerce4Umbraco (free and open source -based on dash commerce) and TeaCommerce. They've both got their strengths and weaknesses and that's for a different post but making uCommerce free will stir things up a little but in a very good way. It now means that regardless of your budget or requirements, you have a great choice of options.
I don't think this will kill off the other projects (and I hope it doesn't) because although uCommerce is most likely what we'll use every time, the other providers have got their uses in different scenarios and competition is healthy. If you're more confident in Umbraco itself then you'll probably "get" TeaCommerce quicker than uCommerce as they are structured slightly differently.
What does it mean for the community?
This is massively good news for those who already use Umbraco as it means that you can let your customers sell online from the same interface that they're already using, but I think this has wider implications for the industry as a whole.
As I mentioned earlier, Umbraco have been working hard on making the CMS a very robust offering. Being able to plug in an e-commerce solution now means you can offer your customers an end-to-end solution which easily rivals the enterprise (paid) solutions currently available. What's better for your customers is that it's all from one login whether it's content, e-commerce, blogging, Job listings etc.
I think that offerings like Magneto will be very interested to check out what they're doing. For those of you who think it's finally knocking out DotNetNuke as an offering, I'm afraid Umbraco did that in V3. 
Why am I shouting about it?
Ultimately it now means that there really is now no reason to not choose Umbraco -regardless of what platform you usually develop on (which is great because it means the community will grow).
Not a .Net developer? Don't worry, although it helps with customisation, it shouldn't stop you. The great thing with Umbraco and uCommerce is that you don't need to know any .Net to get running. The entire thing can be wired up through the web backend but if you don't believe me, get in touch and we'll go through it.
Disclaimer: I have been blogging and using uCommerce since it's first release and I am a proud wearer of their official t-shirt at CodeGarden but I still try and look at these things from an unbiased view point as if a better solution for our clients is presented to us then we'd consider it. Either way, I think this is a good move and if you want help with uCommerce, just get in touch.
Output the currency symbol in uCommerce
Wednesday, March 09, 2011 5:06:12 PM (GMT Standard Time, UTC+00:00)
One thing that's always bugged me about uCommerce is the way the prices are displayed (using the not so inviting ISO codes), this is a simple switch statement to output the (prettier) HTML symbol instead.
<xsl:choose>
<xsl:when test="@currency = 'GBP'">
<xsl:text disable-output-escaping="yes">&pound;</xsl:text>
</xsl:when>
<xsl:when test="@currency = 'EUR'">
<xsl:text disable-output-escaping="yes">&euro;</xsl:text>
</xsl:when>
<xsl:when test="@currency = 'YEN'">
<xsl:text disable-output-escaping="yes">&yen;</xsl:text>
</xsl:when>
<xsl:otherwise>
<xsl:text disable-output-escaping="yes">$</xsl:text>
</xsl:otherwise>
</xsl:choose>
Recurring payment provider options for a UK start-up
Friday, February 25, 2011 3:42:23 PM (GMT Standard Time, UTC+00:00)
As many of you will know, we're currently in the process of launching a new online service -Crisis Cover which is a digital safe for your business' digital assets. A week before the launch we ran into a slight hiccup in regards our payment gateway. The problem is simple:
The trouble with this: to trade for a year, we need some way of taking payments for the service; so we had to start looking into alternative payment gateways.
Our requirements
- Low processing fees as the lowest plan is only £4.99
- UK based payment gateway
- Offer (or didn't require) a merchant account number
- Billable in GBP
- Handles the recurring element of the payments (so we didn't need to write a custom handler)
- Trusted brand
- Allows on-site payments (though this wasn't too much of a priority)
The payment gateways we looked into were:
Skip Our findings and jump to our conclusion.
Our findings
PayPal
For
- Quick setup
- Known and trusted brand
- Wide market penetration
- Simple integration
- Fully managed service
- No merchant account number required
Against
- High monthly charge for a business account with montly recurring payments
- Perceived as a B2C service rather than a B2B service
- Constantly tries to upsell it's payment system to the customer (although the Website Payment Pro onsite option should work around that)
- A large number of mix-and-match services it's hard to identify which one you need
Verdict
Although PayPal's offering is very appealing, it is still perceived very much as B2C service which is the main reason we decided against it. In addition to this, their monthly charge for the service we need and processing fees make it a potentially unviable solution to launch with.
For recurring payments, you will need Website Payments Pro with their monthly subscription upgrade which is currently an additional £20pcm (it's buried deep but you can learn more on this page -click the "Reporting & Back Office" tab).
Google Checkout
For
- No setup charge or monthly fee
- Quick setup
- Known and trusted brand
- Simple integration
- No merchant account number required
Against
- Offsite payment (thought they suggest you can do onsite too)
- Recurring payments are in beta
- General "feel" of the checkout experience is clunky
- Not clear how to checkout if you don't have a Google Account
Verdict
Google's offering is certainly very appealing however the lack of non-beta subscription services meant that we didn't explore it further.
SagePay
For
- No setup charge
- Simple billing model
- Known and trusted brand
- Simple integration
- No merchant account number required
Against
- No recurring payment facility
- Potentially slow setup
Verdict
SagePay's offering is a good solution that we have integrated with many times. Their API makes taking payments onsite quick and simple however there is currently no recurring payment system built in so we initially discounted them*.
* See conclusion
Zuora
For
- Complete solution (apparently)
Against
- Overly flashy website that doesn't tell you how much it costs
- Appears to be predominantly US based
Verdict
Although it may seem petty, if you can't find out even the most basic information on the company website it makes me think that they're massively overpriced or not ready to take clients. So sadly, Zuora were ignored due to the lack of useful information.
Recurly
For
- Handles recurring payments
- Quick setup
- Simple integration
- Fully managed service
- Invisible to the customer
Against
- Not a payment gateway
- Another additional monthly cost
Verdict
We've come across Recurly before and we initially discounted it as we didn't understand what it was/did. On revisiting their service in more detail however we realised what it does -and it's actually pretty good/helpful.
Recurly is not a payment gateway. Now I've got that out of the way, I should explain what it is. Recurly is a system that integrates with third party payment gateways e.g. SagePay and enables you to use these third party payment gateways to take recurring payments without requiring Continuous Authority with the acquiring bank.
This is massively important because Continuous Authority is usually what a start-up gets rejected on. Continuous Authority is basically a contract between the acquiring bank (the one "taking" the money) and the customer's bank which allows the acquiring bank to charge the customer (in theory) whenever -and however much- they like. This is obviously seen as a trust issue -especially when the company is a new entity with no trading history.
So Recurly opens up a whole new potential avenue of payment providers (within their group of partners of course!) which is when we took another look at SagePay.
AlertPay
For
- No setup charge or monthly fee
- Handles recurring payments
- Active development community
Against
- Appears to be a similar concept to PayPal (encourages the user to have an AlertPay account)
- Lots of very small small print (check their prices page and "Some industries may be subject to a fee of 3.90 % + £0.59 GBP or equivalent for receiving funds from e-wallet and 6.40 % + £0.39 GBP for receiving funds by credit card")
Verdict
The offering from AlertPay looks good however because it encourages users to sign up for one of their accounts and they've not got enough market penetration yet to be a known/trusted brand which is a key factor in our decision.
CheddarGetter
For
- Handles recurring payments
- Quick setup
- Simple integration
- Fully managed service
- Invisible to the customer
Against
- Requires a Merchant Account
- Very costly
- Not a payment gateway
Verdict
CheddarGetter is very similar to Recurly, just more costly. It's also not clear if your Merchant Account requires Continuous Authority.
Spreedly
For
- Handles recurring payments
- Quick setup
- Simple integration
- Fully managed service
- Invisible to the customer
Against
Verdict
Spreedly is very similar to Recurly as well. We would need to compare them side by side sperately but although the website was clean and clear, the price reasonable (for 200 customers it would be $10pcm cheaper than Recurly). The lack of "pretty" information without signing up put us off. We read through the gumph however we were still left feeling it wasn't quite up to the same standard as Recurly.
Chargify
For
- Handles recurring payments
- Quick setup
- Simple integration
- Fully managed service
- Invisible to the customer
Against
- Monthly charge
- Requires a merchant account
Verdict
We came across Chargify very early on and again is very similar to Recurly, they've recently changed their pricing structure which has made it completely unfeasible to even consider them.
Authorize.Net
For
- Handles recurring payments
- Quick setup
- Simple integration
- Fully managed service
Against
- Primarily US based
- $99.00 setup fee
- Monthly fee of $30
Verdict
Authorize.Net offer the entire solution for what is a relatively low monthly fee however as they're mainly a US based company, this raises complications for us as a UK based company.
Xylyx
For
- Quick setup
- Simple integration
- Low processing charges
- No setup fee
- Based in the UK
Against
- Doesn't yet handle recurring payments
- Backed by www.moneybookers.com so encourages the user to sign up for an acount
Verdict
We immediately signed up to Xylyx having spoken to Robert Atkin who overviewed their offering to us in some detail. It's a very good service all in all however the one thing that let it down for us was the fact that they don't yet have recurring billing built in (though it's due to launch this month).
If we were looking for a standard payment gateway (or when they've rolled out their repeat payments) we'd look at Xylyx again. Despite a somewhat bland website, Robert was very helpful.
The Conclusion
After carefully reviewing the options available to us, if you're looking to setup a service in the UK with recurring payments and minimal fuss I recommend the following order of options:
- Recurly with SagePay
- Spreadly with SagePay
- Recurly with Authorise.Net
- Spreadly with Authorise.Net
- Recurly with PayPal Website Pro
- PayPal Website Pro with recurring billing
Retrieve the customer’s last address when logging into uCommerce
Tuesday, October 26, 2010 11:31:55 AM (GMT Daylight Time, UTC+01:00)
Probably one of the most common features of an ecommerce systems is to "retrieve my details" when logging in -after all that's why you create an account with the seller isn't it?
Out of the box, uCommerce has XSLT to retrieve the customer's last x addresses but one thing it didn't do was automatically re-assign the customer's details when logging in using the built in Umbraco membership code so we need to work around it ourselves -don't worry, it's not too hard (all the code is below for you).
Background
All customer addresses are stored in the uCommerce_Address table automatically, there should be one unique address per customer however if you're on an earlier release you may find you have several copies of the same address for each customer -this is a bug that's been sorted in v1.0.5.0 so upgrade if you can.
Now you'd be forgiven for thinking that you can just select the address from the uCommerce_Address table and then assign the id to the BillingAddressId property of your purchase order however if you do that, you'll find you get the error:
The UPDATE statement conflicted with the FOREIGN KEY constraint "FK_uCommerce_PurchaseOrder_uCommerce_OrderAddress".
The conflict occurred in database "CommsReadyCMS", table "dbo.uCommerce_OrderAddress", column 'OrderAddressId'.
The statement has been terminated.
You'll get this because there is also a second table involved -uCommerce_OrderAddress. uCommerce_OrderAddress stores the actual address used throughout the order process incase the customer changes an address in the future, the order will always have the correct address.
The Solution
Working around this isn't actually too difficult as mentioned before. The easiest solution is to create a new User Control in Visual Studio (I'll call mine login.ascx) and hook into the LoggedIn event. Once logged in, get the Umbraco member and from that, get the customer's billing address.
There's one caveat that I found with uCommerce and that's the way it gets the address. At the moment, there is a function on customer "GetAddress", this is great however if you check out the code it calls, it actually gets the customer's first address from the database -rather than the last address used. I don't think this is a bug as in most cases the first address you enter is your main address. I'll blog separately about managing a default address within the members section.
The code below however retrieves the most recently added address from the database
Login.ascx
<asp:literal runat="server" ID="litLoggedIn" />
<asp:literal runat="server" ID="litLoggedOut" />
<asp:Login runat="server" id="lgnForm" CssClass="checkout-details"
DisplayRememberMe="false" TitleText="" OnLoggedIn="lgnForm_LoggedIn"
UserNameLabelText="Email Address" />
Login.ascx.cs
protected void lgnForm_LoggedIn(object sender, EventArgs e)
{
//If the user has a basket, wire up the shipping address with their last order details
var basket = SiteContext.Current.OrderContext.GetBasket(true);
if (basket != null)
{
//Get the customers current order
var po = basket.PurchaseOrder;
//Look for a shipping address
var add = po.GetBillingAddress();
//We only need to assign the address if there isn't already one assigned to this order
if (add == null)
{
//Get the customer who's just logged in
var mem = Membership.GetUser(lgnForm.UserName);
//To be safe check that we have a member
if (mem != null)
{
//Find the customer
var customer = Customer.ForUmbracoMember(Convert.ToInt32(mem.ProviderUserKey));
if (customer != null)
{
//Get the customer's most recent address
var previousAddress = customer.Addresses.ToList().LastOrDefault(a => a.AddressName == "Billing");
//If you want to get the customer's first address just uncomment this line
//var previousAddress = customer.GetAddress("Billing");
//Populate the billing address with the address)
if (previousAddress != null)
{
OrderAddress address = new OrderAddress
{
FirstName = previousAddress.FirstName,
LastName = previousAddress.LastName,
EmailAddress = previousAddress.EmailAddress,
PhoneNumber = previousAddress.PhoneNumber,
MobilePhoneNumber = previousAddress.MobilePhoneNumber,
CompanyName = previousAddress.CompanyName,
Line1 = previousAddress.Line1,
Line2 = previousAddress.Line2,
PostalCode = previousAddress.PostalCode,
City = previousAddress.City,
State = previousAddress.State,
Attention = previousAddress.Attention,
CountryId = previousAddress.CountryId,
AddressName = "Billing",
OrderId = new int?(po.OrderId)
};
//Store the address in the database
address.Save();
//Assign the address to the purchase order
po.BillingAddressId = new int?(address.OrderAddressId);
//Save the purchase order (shopping cart)
po.Save();
}
}
}
}
}
}
Delete all UCommerce baskets older than x days
Monday, October 04, 2010 10:14:31 AM (GMT Daylight Time, UTC+01:00)
After my last UCommerce post on how to delete test orders and baskets from UCommerce, Søren suggested I extended the delete all baskets code to take into account when it was created. As my last code was relating to deleting test orders/baskets (and so would want to get rid of them all), I decided to post this one separately.
Delete all baskets older than x days
To use this, all you need to do is change the @addedBefore parameter to whatever date/time you want (or just adjust the –7 which represents seven days in the past.
--Delete all carts purchaseorders and associated data within x days
DECLARE @addedBefore smalldatetime
--By default the script deletes everything older than 7 days
SET @addedBefore = DATEADD(dd, -7, GETDATE())
BEGIN TRAN
UPDATE uCommerce_PurchaseOrder SET BillingAddressId = NULL WHERE OrderNumber IS NULL AND CreatedDate <= @addedBefore
DELETE a FROM uCommerce_Shipment a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL AND b.CreatedDate <= @addedBefore
DELETE a FROM uCommerce_OrderAddress a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL AND b.CreatedDate <= @addedBefore
DELETE a FROM uCommerce_OrderProperty a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL AND b.CreatedDate <= @addedBefore
DELETE a FROM uCommerce_OrderLine a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL AND b.CreatedDate <= @addedBefore
DELETE a FROM uCommerce_Payment a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL AND b.CreatedDate <= @addedBefore
DELETE a FROM uCommerce_OrderStatusAudit a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL AND b.CreatedDate <= @addedBefore
DELETE FROM uCommerce_PurchaseOrder WHERE OrderNumber IS NULL AND CreatedDate <= @addedBefore
--Uncomment this
--COMMIT TRAN
--And comment out this
ROLLBACK TRAN
Deleting test orders and baskets from uCommerce
Friday, October 01, 2010 12:53:43 PM (GMT Daylight Time, UTC+01:00)
Although Søren has posted a helpful post on how to delete entire purchase orders from the database here, we needed something a little less “all or nothing” so put the below together.
Delete a specific order id
--Delete purchaseorders and associated data based on order id
DECLARE @OrderNumber nvarchar(50)
SET @OrderNumber = 'TEST-40'
BEGIN TRAN
UPDATE a SET ShipmentId = NULL FROM uCommerce_OrderLine a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE OrderNumber IS NULL
UPDATE uCommerce_PurchaseOrder SET BillingAddressId = NULL WHERE OrderNumber = @OrderNumber
DELETE a FROM uCommerce_Shipment a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber = @OrderNumber
DELETE a FROM uCommerce_OrderAddress a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber = @OrderNumber
DELETE a FROM uCommerce_OrderProperty a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber = @OrderNumber
DELETE a FROM uCommerce_OrderLine a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber = @OrderNumber
DELETE a FROM uCommerce_Payment a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber = @OrderNumber
DELETE a FROM uCommerce_OrderStatusAudit a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber = @OrderNumber
DELETE FROM uCommerce_PurchaseOrder WHERE OrderNumber = @OrderNumber
--TODO: Expand this so it checks for other orders
--DELETE a FROM uCommerce_Address a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber = @OrderNumber
--DELETE a FROM uCommerce_Customer a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber = @OrderNumber
--Uncomment this
--COMMIT TRAN
--And comment out this
ROLLBACK TRAN
Delete all baskets
--Delete all carts purchaseorders and associated data
BEGIN TRAN
UPDATE a SET ShipmentId = NULL FROM uCommerce_OrderLine a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE OrderNumber IS NULL
UPDATE uCommerce_PurchaseOrder SET BillingAddressId = NULL WHERE OrderNumber IS NULL
DELETE a FROM uCommerce_Shipment a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL
DELETE a FROM uCommerce_OrderAddress a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL
DELETE a FROM uCommerce_OrderProperty a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL
DELETE a FROM uCommerce_OrderLine a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL
DELETE a FROM uCommerce_Payment a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL
DELETE a FROM uCommerce_OrderStatusAudit a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.OrderNumber IS NULL
DELETE FROM uCommerce_PurchaseOrder WHERE OrderNumber IS NULL
--TODO: Expand this so it checks for other orders
--DELETE a FROM uCommerce_Address a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.NULL = @NULL
--DELETE a FROM uCommerce_Customer a INNER JOIN uCommerce_PurchaseOrder b ON a.OrderId = b.OrderId WHERE b.NULL = @NULL
--Uncomment this
--COMMIT TRAN
--And comment out this
ROLLBACK TRAN
Update: At the request of Søren, I’ve altered the delete all baskets post so it allows you to delete all baskets older than a given date, see: Delete all UCommerce baskets older than x days
Getting started with uCommerce
Tuesday, August 17, 2010 5:49:45 PM (GMT Daylight Time, UTC+01:00)
I thought seeing as uCommerce is now an actual product I would start to overview an install/configuration of uCommerce assuming no prior knowledge of uCommerce. Firstly, let me start of by saying that once you've got your head around uCommerce and some of it's complexities, you'll find it a fantastic product that makes creating a new ecommerce website as easy as setting up a standard Umbraco website. It is still missing a few features, but you can easily work around these with a bit of custom XSLT/C#.
Ok, back to setting up your first uCommerce website. I've grouped these into what I feel are logical sections but if I've missed something, please let me know.
1. Install the uCommerce Package
If you've not already done so, go to the uCommerce Download page and download the uCommerce package (at time of writing, I'm using 1.0.4.2) and then download the uCommerce Store package (currently 1.0.1.2).
Install the uCommerce package as you do any other package in Umbraco. Once installed you'll be able to install the store package.
Assuming all your permissions on your Umbraco install are correct, refresh your browser and you should have a new section "Commerce". If they're not right, you'll be told to add a few web.config settings.
2. Wire up the catalog
This is the step that I didn’t “do” when we first got started and it turns out it’s one of the most important steps as it joins the uCommerce catalog to the front end.
- Go to your Umbraco "Content" section
- Right click on the page you would like to be the store's "home" page (in the example store, this would be "Shop")
- Click "Manage hostnames" (see figure below)
- Enter your hostname (the domain name the site runs on) in the "Domain" box and then choose the default language for the website
- Click "Add new Domain" and then "Close this window"
- Click the "Commerce" section button (in the bottom left)
- Click the little arrow to the left of "Product Catalog"
- Left click the relevant catalog (if you've installed the store package this will be "uCommerce")
- Select your new domain from the "Host name" drop down list
- Click the save disk button in the top left
3. Setup Your Product Definitions
A “Product Definition” is uCommerce’s concept of document types, it allows you to add additional information to the product. If you’re using the uCommerce starter store, you’ll get a couple of product definitions out of the box –software and support. At the moment, you can't add additional properties through the uCommerce back end (i.e. if you wanted to add additional information such as Meta Keywords/Descriptions etc -I'll cover how we got around this in a later post) but there are a number of default the category/product properties (I've put their XML reference in brackets where relevant):
uCommerce Category Properties
- Image (@image)
- Display Name (@displayName)
- Description (@description)
The default XML looks like this:
<category parentCategoryId="" parentCategoryName="" index="0" id="67" name="Software" displayName="Software" displayOnSite="True" description="" image="" />
uCommerce Product Properties
- SKU (@sku)
- Internal name
- Display on web site (@displayOnSite)
- Allow ordering (@allowOrdering)
- Thumbnail (@thumbnailImage)
- Primary image (@primaryImage)
- Display name (@displayName)
- Short description (@shortDescription)
- Long description (@longDescription)
The default XML looks like this (the variants are not standard but are there because they're setup as part of the store package):
<product index="0" sku="100-000-001" displayName="uCommerce 1.0 RTM" shortDescription="uCommerce is a full featured e-commerce platform with content management features powered by Umbraco. Everything you need to build a killer e-commerce solution for your clients!" longDescription="uCommerce is fully integrated with the content management system Umbraco, which provides not only the frontend renderendering enabling you to create beautifully designed stores, but also the back office capabilities where you configure and cuztomize the store to your liking.

uCommerce_ foundations provide the basis for an e-commerce solution. Each foundation addresses a specific need for providing a full e-commerce solution to your clients. foundations in the box include a Catalog Foundation, a Transactions Foundation, and an Analytics Foundation.

Each of the foundations within uCommerce_ are fully configurable right in Umbraco. No need to switch between a multitude of tools to manage your stores. It's all available as you would expect in one convenient location." thumbnailImage="1097" primaryImage="1097" allowOrdering="True" isVariant="False" displayOnSite="True" hasVariants="True" price="3495.0000" currency="EUR">
<variants>
<product index="0" sku="100-000-001" displayName="Developer Edition" shortDescription="" longDescription="" thumbnailImage="0" primaryImage="0" allowOrdering="False" isVariant="True" displayOnSite="False" hasVariants="False" variantSku="001" price="0.0000" currency="EUR" Downloadable="on" License="Dev" />
<product index="1" sku="100-000-001" displayName="30 Days Evaluation" shortDescription="" longDescription="" thumbnailImage="0" primaryImage="0" allowOrdering="False" isVariant="True" displayOnSite="False" hasVariants="False" variantSku="002" price="3495.0000" currency="EUR" Downloadable="on" License="Eval" />
<product index="2" sku="100-000-001" displayName="Go-Live" shortDescription="" longDescription="" thumbnailImage="0" primaryImage="0" allowOrdering="False" isVariant="True" displayOnSite="False" hasVariants="False" variantSku="003" price="3495.0000" currency="EUR" Downloadable="on" License="Live" />
</variants>
</product>
Adding additional product properties is simple.
- Click the "Commerce" section button
- Navigate to: Settings --> Catalog --> Product Definitions
- Choose the product definition you would like to edit (or create a new one in the same way that you would with Umbraco document types)
- Right click the product definition you need to add extra properties to and click "Create"
- Type in a name for your new property i.e. Size
- Choose the Data Type for the property (if you need something that's not listed see "Creating your own Data Type" below):
- ShortText -A textbox
- LongText -A text area
- Number -Beleive it or not, a numeric value
- Boolean -A checkbox
- Image -A media selector
- Click the "Create" button
- You can now choose a few additional options for the new property including how it should be shown to the user and whether it's Multilingual.
- Name -the text used as the label in the uCommerce product editor (it's also the name of the attribute on the XML that will contain it's value)
- Data Type -the type of control to render in the uCommerce product editor
- Multilingual -whether the control should be shown on the "Common" tab of the uCommerce product editor or the language specific tab
- Display On Web Site -A flag that's sent out in the XML so you can decide whether or not to show it on the website
- Variant Property -Whether this should appear as a table column heading under the "Variants" tab (I'll go into variants more in a later post)
Note: Do not set Multilingual and Variant property to both true as at the moment, it won't be shown in the uCommerce product editor -you've been warned!
- Render in Editor -Whether the control should be shown in the uCommerce product editor screen or hidden from the administrator (i.e. for data you want to use internally only and should be editable)
- Finally you'll need to enter in a Display Name for the various languages. This is what's shown to the user if you dynamically pull through the various properties on the product details page.
4. Creating Your Own Data Type
Now, you may be thinking that using that set of data types is a little limiting for something like "Size" or "Colour" and you might want to display something a little more flexible to the user -such as a drop down list. This is easy enough:
- Right click the "Data Types" node
- Enter a name i.e. "Size"
- Choose the definition for the Data Type (for size we will use "Enum")
- Save and Refresh the "Data Types" node
- Right click your new Data Type and click Create
- Enter your Option's value i.e. "Small"
- Repeat 5-6 until all your options are set i.e. add "Medium" and "Large"
Note: At the moment, the enum values cannot be re-ordered through the UI so make sure you add them in the order you want them in the editor!
5. Load Your Catalog
Once you've finished creating your various product types, it's time to create your catalog. Creating categories and products within uCommerce is as simple as creating pages in Umbraco. Using the same right click menu concept you can create nested categories as deep as your catalog requires. You can add products and categories at any level by choosing either the "Category" or "Product" radio button and choosing your product type.
6. You're Done!
Assuming you've followed the steps above, you should now have a (fairly basic) store setup. Go to your site's homepage and click the "uCommerce" menu item and voila, your categories and products should be listed.
Not getting the categories you were expecting? Perform the helpful xsl “copy-of” trick within either the "RootCategories[XSLT].xslt" file or "Category[XSLT].xslt" file:
<pre><xsl:copy-of select="$categories" /></pre>
and then have a look at the output:
<errors><error>No product catalog group found supporting the current URL.</error></errors>
If you're getting the above error, currently (and this may be a misunderstanding/changed later) you have to have the catalog and catalogue group names the same –in the example site, they’re both “uCommerce”.
As I think the concept store offered with Software/Support isn't particularly real-world, I'm going to work on creating a basic store that you can use to better understand uCommerce and it's intricacies.
Check back soon as I'll be posting an overview of the checkout process, the various XSLT files and integrating payment gateways into uCommerce (initially SagePay, PayPoint, WorldPay and PayPal).