Best approach for adding shipping charge to sales transactions?

Wondering what is considered the best/better way or how are people handling adding a shipping/postage fee to sales transactions in ERPNext?

As far as I can gather, it can be added as a line item or added in the Sales Taxes and Charges section beneath the item table.

If added as a line item, this allows GST to be included in the rate, which we want in our case. However, even though it is configured as a ‘Service’ item, it will then display in any related packing and delivery note documents, which we’d rather not have.

If added in the Sales Taxes and Charges section instead, it won’t show in the packing and delivery note documents, but then we can’t seem to configure it so that tax is included in the rate entered, which means the GST calculation for the total amount of the order including the shipping charge is not correct.

Have you tried playing with the Tax/Charge type? If I’m understanding your goals correctly, you should be able to do what you want with the “On Previous Row Total” type.

  • Set the shipiping charges to “Actual”
  • Set the tax to “On Previous Row Total”

The tax should then include the shipping charges in its calculations.

(As always, double check the accounting entries being made to make sure they match your intentions.)

2 Likes

Thank you for your response, much appreciated.

The problem there and what I am struggling with is that the tax is being added to the previous total. Our prices are tax inclusive (including the shipping) so we need it to be included in the rate. To use your example, rather than the tax amount of 110 being added to 1100 to make the order total 1200, we’d need the order total to remain as 1100 and for the tax to be included in that.

Hence why perhaps entering it as a line item is better for this but then, as I said above, we have the issue of it appearing in the item list on delivery documents!?

Ah, I see.

There’s a setting in the Taxes and Charges child doctype to specify that a tax is included in the printed rate (see below)…

…but that calculates against the net total (not net total plus other taxes and charges). I think that’s the correct design, because otherwise the accounting would get pretty weird.

If you need to collect GST on shipping and also consider the GST to be included in the listed rate, it makes sense to treat shipping as an invoiced service rather than an additional charge. It should be possible to include only some items and not others on pick-lists and delivery notes, but I’m not familiar offhand.

Alternately, if you want to keep shipping classified as a charge, you could always break GST into two parts (one for the actual invoiced items and one for the shipping).

Thanks again peterg for your responses and help with this. I think that adding it as a line item is probably going to be the easier / more straightforward way.

If anyone out there does know how to / whether it’s possible to not include service items on pick-lists and delivery notes, please let me know!

I just tested, and in my installation at least non-stock items don’t show up on the pick-lists I generate. Are your service items still listed as “Has Stock” in the doc definition by any chance?

For delivery notes, I think the issue is a bit more complicated. Conceptually, I find it incongruent to have items that appear on sales orders but not on delivery notes. The idea that orders, invoices, delivery notes, etc. all match is fundamental to how I understand those documents to work.

If you really want to do it that way, though, it should be possible to write a relatively trivial server script that would mark all items classified as “Services” as delivered when the sales order is submitted. I think that would ensure they don’t show up on delivery notes.

Thanks again peterg for this discussion.

To give some context, we are looking at moving to ERPNext from other software, and I understand that that might require adjusting some of our processes to fit in with how ERPNext works, however I’m trying to wrap my head around how this will practically work for us. Currently when we add postage/shipping as a ‘service’ line item, it then doesn’t show up on the packing and delivery documents because, well, it’s not a ‘physical’ product that we ship out. But then of course it does still get invoiced.

From what I can gather in my testing so far with ERPNext, if you add shipping as a ‘service’ line item you still need to ‘deliver’ it in order to complete the Sales Order. In cases where you are part-fulfilling an order until it it is completed, you then have the situation where that shipping line, which is one amount for the entire order, has to be just randomly ‘delivered’ with one of the deliveries. As I said, I’m trying to think about this from the perspective of processes and best flow we would have to adopt. We could use the pick list to create a ‘slip’ that goes into the parcels for the customer and, as you rightly point out, the shipping line would not be included on any of those. However, if we only did that and forwent the delivery step, then in the system we’d see a Sales Order with ‘% picked’ but not the ‘%delivered’. (Unless perhaps we just manually close the order after all items are delivered?)

If the shipping were to be added in the Sales Taxes and Charges table (I get the feeling this is intended as the ‘right’ place to add it in ERPNext?) then we don’t have the above issues but then we have the GST not included / calculated correctly issue as described above. We could workaround it as you have suggested by adding the shipping charge ex-GST and then adding the third line but this just seems a bit convoluted and cumbersome, especially when you are trying to think through the simplest way for users entering orders into the system, and then you also end up with the overall GST amount listed in two parts on the invoices, which for us would be a bit strange for customers.

I guess at this stage, it’s fair to say I’m a bit confused about it :slight_smile: It would be good if the Sales Taxes and Charges section could better handle tax-inclusive pricing.

I understand your preference for treating shipping as a charge rather than a service. I’m a bit confused, though, about how you would want to a charge to adjust both sales items and other charges simultaneously. I can’t picture what the accounting for that would look like. Can you provide a debit/credit table showing how such an invoice should be booked?

Hi, have there been any ideas or solutions regarding the subject thread?

Hello,

I have still been trying to work out the better way for us to approach this.

At this point, for our use case, I’m thinking we will:

Add shipping as a line item in the item table, rather than as a sales tax/charge. (It’s just going to be easier because of the GST complication with the sales tax/charge, ie not being able to have GST-inclusive amounts, resulting in having to make two entries to make sure the GST works out correctly = messier for system users, as well as messier for the customer invoice layout.)

Use a picklist as the ‘packing slip’ (ie. that is what gets printed out and goes into customer parcels, which won’t include any shipping line from the sales order, if the shipping item has been set up as a service item).

Create and use the delivery notes only for internal tracking of what has been sent out. The shipping line item will appear when creating the delivery notes, and I guess there will have to be an internal process as to how to manage that so that an order is marked as completely delivered when all items have been fulfilled/sent. (In our case, we would ‘deliver’ the shipping item when creating the delivery note if all items from the order are being fulfilled/delivered at once, or if an order is being partially fulfilled and there will be future shipments, we may remove the shipping line item until such time as the last shipment and the full order is complete.*)

*I guess there could be an argument here as to whether this is more or less messy that stuffing around with the sales/tax charges to get the GST correct, but I personally found it to be very unwieldy, and I am trying to think this through from the perspective of ease of use for entering in sales orders which for us mostly have a postage fee, of varying amounts, added.

For us, it would be better if the system inately allowed for either GST-inclusive prices for ‘Actual’ type in the sales tax/charges or service items to not be included on delivery notes … but alas, this is not the case.

One way to deal with the multiple lines for GST is to create a custom print format and calculate the total tax via Jinja logic. This is my approach.

In NY we have to include sales tax on shipping but when shipping out of state we may not charge tax at all.

Hello again!

I’m still not fully understanding what’s cumbersome/not working here, and I suspect it’s because I’m not following how the accounting is supposed to work. Tax and charge entries on invoices are mapped 1-to-1 to rows in the general ledger, but like @volkswagner is saying you can display it however you want in the print formats you send to your crew or clients.

If you want to treat shipping like a sales item but not have it show up in delivery notes, you could accomplish that with a very trivial one-line server script. If you want to treat it as a charge, what needs to happen depends a lot on how the accounting works, but there are straightforward solutions here too.

ERPNext is data-first in its design philosophy. If I were in your shoes, I’d be thinking about how these transactions should be represented first. Then, after that’s clear, there are plenty of different ways to streamline UI entry and display.

Service items should not be maintained in stock, so there will not be a requirement to deliver. As different items can have different accounts and tax templates assigned, there should not be any issues with the accounting entries whatsoever. It is easier if all items, including the service charge items, have the same rate of tax applied be it included or not.
Looks like a user not testing enough, not reading enough error than an ERPNext feature gap.

I don’t think that’s correct. Non-stock items listed in an invoice do show up in delivery notes, and the sales invoice will not be considered fully delivered if these are outstanding.

True that. Items show up on invoices and delivery notes.
Not sure though if non stock item delivery is required to deliver. Must check. Anyway, they are different items of income so they need to be included in documents.

Hello

My post above was mostly intended as my answer to shujath’s question:

I guess I was attempting to answer this from my/our business’ perspective, rather than to re-ignite the topic :slight_smile: But now that we’re here …

I suppose, conversely, I’m not fully understanding what the accounting has to do with it, and I suspect it may be because we are looking at this through a different lens. For me, whether the shipping amount that we are charging the customer is recorded as income via adding it as a line item or via the Sales Tax and Charges section is neither here nor there. (Am I missing something?) More important is that the GST calculation be correct. In our part of the world, it is commonplace for prices to be GST-inclusive (with the GST amount included displayed on an invoice for the entire transaction in the sub-totals section).

I’m looking at this moreso from the view of operational processes and best/better approach using the in-built functionality of the software without resorting to coding and customisation. Any attempt my me/us to implement ERPNext for our business is completely a DIY proposition. I am a business owner, not a developer, and we are a very small business with no development or coding capabilities at our fingertips (nor inclined to jump to hiring any at this stage) … so I am looking at how we can best work within the confines of what the software inherently does and with its native flow.

If we add the shipping amount we charge the customer as a service line item, it would be simpler in the sense that everything can be added with GST-inclusive pricing, and the GST is correctly worked out and easily added to an invoice print format without too much fuss … and then we just have to deal with the pesky fact that this line item has to be ‘delivered’ somewhere along the fulfillment and delivery stages for the order to be marked as closed.

(Rather than a user having to work out the ex-GST price for the shipping to add in the sales charges and tax section, having another line just for tax to be added to the shipping, and not straightforwardly being able to include the GST amount on the invoice print format etc etc)

This is what, I think, should happen (or at least be an option) but unfortunately it is not the case.

Okay, that’s fine. :slight_smile:

Yes, I think so, hence my post, which was intended as much to help others as to help you. You should do whatever works for you, of course! :beers:

Why don’t you extend your transactions via a new Accounting Dimension based on the Sales Transaction Doctype of choice?

Thank you peterg and everyone else on these forums that post and respond to questions raised. I, for one, have learnt a lot from your contributions, and really appreciate it.