Delivery charges in TAS

Is there anyone else who has experienced this problem with the way delivery charges are dealt with in TAS? We run a business-to-consumer website selling about 900 different products where some products are sold from stock, some shipped direct from the supplier. Stock is only ordered on the supplier by offical purchase order through prog 7.1.1., received into stock by prog 7.2.2., and invoice received prog 7.2.3. Fantastic for cutting down repetitous typing, but it means the associated delivery charge has to be allocated a product code to be included on the purchase order, and TAS will only allow nominal distribution of this to a STOCK and therefore ASSET code. Alternative is to enter the associated purchase invoice via prog 3.2.1 when it arrives, which means typing a lot of it out again duplicating effort (also angsting whether GMV accrual account is the correct nominal or not). Similarly, we import sales orders from the back of the website using the excellent Infoplex TAS Link, but these orders import into prog 6.1.1, where yet again the delivery charge for each order has to be assigned a product code to be included on the sales order, meaning same nominal path into a totally incorrect stock/asset nominal. It's not possible to import these sales orders into prog 2.2.1, because that doesn't update the stock. We cannot be the only company running a website who want to import data into TAS where every purchase and sale has an associated delivery charge, but where we need the facility to account for those charges within each purchase order or sales order without having to split it out as an expense in other different programmes within TAS. If anyone from TAS is reading this - is it possible to add the feature of delivery charge to these programmes so it can be accounted for correctly please, and is there anyone else reading who has already encountered or solved this problem?

Comments
mramsay's picture

Delivery charges in TAS

mramsay | | Permalink

We use a Nominal Ledger "Delivery Charge Control A/C" to handle this, e.g. 1650 or 2120. It does not terribly matter whether it is an asset or liability type. When you set up the product record for your Delivery Charge (you might have several, one for each supplier or by distance etc), make sure it is a Non-Stock and Service type and, in the 'Stock A/c' field use the Delivery Charge Control A/C. Use the required product code on both SO's and PO's. When a SO is posted, this account will be automatically credited by the CoS value and when a PO is received/invoiced the account is automatically debited. In an ideal world, if you have got your unit cost price(s) correct, the account balance should be 0.00 at the end of each period. However, there will be inevitable discrepancies caused by various factors, such as timing differences (e.g. late invoices) or cost pricing errors. For this reason, you would normally reconcile the account periodically and journal out the difference to, for example, the CoS account.

Glad to hear you like TASLink for automating the integration of your website with TAS!

Mark

Idea exchange

David Richards | | Permalink

Jackie, why don't you post your suggestion to our Idea Exchange? You can access it on www.tassoftware.co.uk/idea or on the suggestions tab of our newly launched Facebook page . That way it'll give others the opportunity to comment and expand on your idea.

 

Delivery charges in TAS

Jackie Smethurst | | Permalink

Hello Mark,

Thank you for the fulsome reply, much appreciated. And yes, we really are happy with the TASLink, can't think how we managed without it!

I hope your suggestion works given your ideal world scenario (where the unit cost price(s) are right) is a major obstacle. At the moment we use 1 product code for all deliveries, it is set to 0.00 cost price for the following reasoning:-

-The website must present 1 delivery charge to the customer for the total order. There is already a very complicated shipping matrix calculator behind the scenes of the website to cope with weight, (multiple items in one order tripping into different weight/price bands for Royal Mail for example), versus fixed cost (£25.00 to deliver a fridge-freezer for example), versus location (mainland UK, offshore islands, other EU countries), versus value (the insurance element for example).
- Delivery charges currently range from £1.95 Royal Mail to UK address to £130.00 large item to EU address.
- Customers may buy more than 1 product in an order, and customers may be based anywhere in Europe.
- All this presents many variables of delivery charge.
- Applied to just one example sale of a product, there is 1 product code for a lawnmower delivery charge to mainland UK = £7.95, fine because TAS only allows 1 value for cost so we could enter the cost which is also £7.95. However, this product could also be shipped anywhere across Europe, so value for same delivery product code would be higher for the sales order component, but TAS only holds one cost value of £7.95 which is now incorrect. So we could introduce 20 product delivery codes for this one item to be shipped across the region. What if the customer orders something else to be shipped at the same time? The charge to the customer and cost to us do not necessarily increase by the fixed amount of each item separately, there is usually some saving by shipping the 2 or more items together. So again for this same product you could have multiple part-cost values if shipped as part of a larger order, depending on the size and value of the other items in the order (and you'd have to apportion the cost between the other items in the order too).  There are 900 products on the website ranging from small wind-up rechargable radio to large side-by-side American fridges, it is unwieldy to predict all the possible combinations of goods customers may order including this lawnmower, I'm sure you're getting the picture though about the sheer number of product codes needed to accommodate all variables of delivery charges & costs for each item & permutation (even if we could rationalise them into bands of charges).

The ideal that this control account balance will be 0.00 at the end of each period will never happen either, in general we are charged far more than we can pass on to the customer. To take another example, delivering one brand of log store on a pallet to any location in the UK is £7.95. It is only possible to pass on £7.95 because that is what the customer will bear - it actually costs us anywhere from £37 to £55 depending on location.  Similarly with fridge-freezers, cookers, induction hobs, washing machines, large items of garden equipment like the petrol-engined blower-vacuums to pick up fallen leaves, heavy log-splitters etc. etc.. The small things that go out by post are predictable, if it costs us £3.95 or £7.95 then we charge £3.95 or £7.95, but the vast majority of the larger items cost us a LOT more than we can pass on in charges to the customer, so it's not a straightforward customer pays £25.00, it costs us £25.00, more like customer pays £25.00, costs us £50.00. The net result is the a/c will most likely show negative if that matters, but we should technically break even on delivery charges because we cover the difference in margin so it's accounted for within income. Delivery isn't something we make a profit on.

In summary, the cost variables are just too numerous so we currently use 1 product code for all deliveries charged to customer, 1 product code for all delivery costs from supplier. It is neither practicable to allocate a product code with cost for each supply-side delivery, nor to manually change the actual cost of that delivery before entering each order. If your proposed delivery charge control a/c solution can allow for the fact that unit cost price on sale is 0.00 even though it isn't, and that all associated purchase-related delivery costs but not all sales-related delivery charges are in the one control a/c, and if the accounts can therefore accurately reflect the income & expense impact on the company, then we'll happily adopt it and say thanks. If not, is there a simpler and more flexible solution without getting TAS changed to allow delivery charges as an integral part of a sales or purchase order but without forcing it into the tramlined, product-code route of data entry?

Dull subject I'm afraid; many thanks for looking at it anyway!

Jackie

mramsay's picture

Delivery charges in TAS

mramsay | | Permalink

With so many variables in calculating the cost price of delivery it sounds as though you need to automate the calculation. We have one customer who imports high volumes of orders from Amazon to TAS with similar issues: weight, insurance and whether to deliver direct from supplier or from warehouse, whilst having only one or two delivery charge selling prices on Amazon. Here, we automated the calculation of the cost prices based on these factors. If your website system can calculate these cost prices for you it should be a simple matter, via TASLink, to pass them automatically into the delivery charge cost price on the SO.

Either way, the concept of using a NL control account still holds.

Our approach

daleblackman | | Permalink

Hi guys - interesting thread

We have approached this problem by having two products:

CARRIAGE - This is a non-stock item, subject to VAT, has zero cost price (and no stock levels). The sale nominal is a custom one - Carriage Income (code 3220-100, an income, credit account), the cost nominal is another custom one - Carriage Cost (code 4100-100, an expense, debit, cost of sales account).

ZCARRIAGE - Identical to the one above.

When we sell an item we add the CARRIAGE product and enter the appropriate price - based on weight, destination, service etc.

When we buy stock from a supplier we use ZCARRIAGE and enter their carriage cost price. When their invoice arrives the cost is automatically assigned to 4100-100. If we are unsure of the cost until the invoice arrives then we don't enter a cost on the PO, but enter the carriage separately as below.

When our carriers invoice us for carriage we enter their invoice via 221 and assign the costs to 4100-100.

What all this achieves is a nice neat display on our P&L of carriage income (e.g. invoiced out) in the income section, and carriage costs on our cost of sales.

We use two separate products so that the product CARRIAGE never inherits a cost price - which ZCARRIAGE does (in the last cost field). It doesnt matter that ZCARRIAGE does because we never sell any.

Hope this helps.

BTW - what web cart are you using to integrate with the infoplex solution?

Delivery charges in TAS

Jackie Smethurst | | Permalink

Hello Mark and Dale,

Only just read your replies, both very helpful suggestions. We have a bespoke website with checkout Dale - your suggestion appears to be an expansion on Mark's original reply to this post, we'd already decided that was a good solution and your reply has cemented that view. Thank you both very much for sharing your thoughts and experience, much appreciated.

Kind regards, Jackie

Add comment
Log in or register to post comments
Group: TAS Books discussion group
A place for the TAS Books community to share ideas and tips