Ordered Date on an order

Ideas & feature requests
1

An order date would be helpful. So we can keep track of when an order was entered.

  • It should be independent of the planned/successful delivery or invoice/due date.
  • While I’m sure there is a created_at date already hidden in the database, this one would auto-fill to today when an order is entered, but should be edit-able if required.

This would be helpful for a raft of situations, but here’s a few:

  • Backorders
  • Pre-orders
  • Measuring Fulfillment Performance

N.B. This might be a wider question about being clearer about the difference between an order and an invoice. While I think perhaps total delineation between these two (generally separate but not mutually exclusive) documents has been omitted in Breww to simplify things for operational (rather than financial) staff. The language in the UI and the help documentation is blurred and it makes it really confusing. Reference to an ‘invoice’ and to a ‘order’ is muddled. I’ll put it in another Feature Request to fix that if anyone else shows any interest.

2

Thanks Simon.

You’re right that there is a “created at” date in the database, and this is also shown on the order/invoice screen, but not in the PDFs. It’s always the date the order was created in Breww, even if the invoice/delivery date changes.

Screenshot 2022-10-21 at 15.50.16
Screenshot 2022-10-21 at 15.50.161300×614 34.2 KB

Is this request to allow this to be manually set to a different date?

At the moment, “orders” become “invoices” when the order’s status is updated to “invoiced”. I must admit that I disagree that the current situation is muddled (unless you try to consider an invoice and an order completely different things). If you let them be two “statuses” of the same basic entity, the current situation is clear, simple to follow and keeps day-to-day operations intuitive to people who are not accountants.

This approach simplifies a great deal of things from a day-to-day usability point of view, but does mean that some edge cases are harder to account for. At the moment, there’s also a single delivery per order, although there has been a request for this to be changed → Partial order dispatch / part delivering orders.

If you need to part-invoice or part-deliver an order, 99% of the time you could instead place multiple orders. Keeping order and invoice numbers consistent prevents a lot of confusion - “Sorry, is that order number 12345 or invoice number 12345?” It’s also rare to have to worry about if the order information differs from the invoice information - such as they ordered 10, but were only invoiced for 8 - and I’d argue so rare that losing this ability is worth it for the other benefits.

The close linking of an invoice to a delivery also reduces complications such as making sure you don’t double-count stock invoiced but not yet delivered (and therefore still included in your stock valuation), and visa-versa.

It’s our opinion that the simpler process here that Breww has adopted is better than the more complex approach of these all being disparate documents with their own numbers (this was a conscious design decision). There are certainly pros and cons with the processes taught in theoretical situations to accountants and what works in the real-world for the people actually taking orders and delivering them.

I’m not saying that we will never split orders and invoices into completely separate documents, but I must admit that at this time this isn’t something we have an appetite for. I feel that splitting these completely would help occasionally and more often create unnecessary work/confusion, and there are other changes that we could work on instead that would be far more beneficial to the typical brewery.

I welcome your comments on this, especially if you do still think orders and invoices should become separate entities in Breww, and thank you for putting this forward :+1:

3

I had missed that created date in the Order/Invoice screen because I was finding the issue when creating the order. So apologies.

So to clarify from a user perspective, I’m asking for that date to be editable when creating the order (and in fact later as well). This is of course different functionally from the database ‘created at’ date. And I would want to see the editable version replace the un-editable version in the front-end.

90% of the time I would expect a user to leave the date as the same as the same date the order was created. But the some use cases for a user-editable version might look like this:

  • Reading an order email sent last Friday, and wanting to keep track of order → delivery performance. This is also good to let the customer know when they ordered.
  • Redoing an order after a mistake. And backdating it to the time the original was created.
  • Planning a future order. Saving as a draft an order you expect to receive from a customer.
4

I completely recognise the problems you identified when making the decision to simplify the order vs invoice experience for the user. It’s one I’ve come across many times, and I agree with the observation that the functionality would be necessary only in the minority of cases. I’m afraid not convinced by the solution though.

I think by removing the strict distinction between the order transaction and the invoice transaction the experience becomes simpler for the majority and impossible for the minority of cases. This optimises a workflow to a point where it is efficient in the majority of cases, but occasional ineffective. Would the same approach work if the Delivery was less well separated from the Order/Invoice?

It’s a wider issue of course. There is a…‘understanding gap’ that’s often present between financial staff and operational staff (that I’ve observed is particularly prevalent in the brewing industry). It’s not an immovable elephant in the room that’s impossible to solve through proper communication between those two broad groups and basic training, but it is often treated that way.

By removing the distinction between the two, I think Breww reinforces that gap in understanding. Rather than solving the issue by omitting functionality present in many other platforms, the better solution would be to minimise the impact on the majority of transactions through carefully designed UX flow, and maximise the effectiveness of the functionality through training and support to give fight against that common gap in understanding.

5

That’s great, I’m sure we can accommodate this :+1:

What is currently impossible in Breww, that you would need to do (and why doesn’t placing multiple orders work)? If we start with this, we can work out the best solution.

What is the “understanding gap” and why is it actually a problem (in the real world, not just in theory to an accountant)?

Please don’t take any of this the wrong way, I’m just keen to make sure we get the best outcome. Thank you.

6

I’m not sure I’m exactly clear on what you’re asking about here, and that’s likely down to my own explanation. I think perhaps I’m describing a broad generalisation better explained with case studies, so this is maybe not the forum. But for example:

There is a difficult situation if an order is cancelled before delivery/invoicing. VAT Requirements state that invoice numbers must be sequential. There is an allowance for multiple different sequences (for example if Shopify is managing a sequence, Breww is managing a sequence, and Xero is managing a sequence, perhaps with different prefixes for clarity). There is also an allowance for invoices to be issued, then later voided (as long as they were issued).

But in a scenario where sequentially numbered orders can be upgraded into invoices with a similar number or not, there are missing invoices in the sequence. Where a platform like Xero is used for VAT Return processing, there are missing invoices in that platform too.

While I’m sure a report of cancelled orders could be exported form Breww, and an explanation of why these invoices are missing could be pulled together during an audit. I think this would be easiest to keep track of if invoices were a separate document with a separate number sequence. (Separate from the order that is.)

7

Yes, I agree, this is probably something best picked up another time/place, but it’s been helpful to get your comments on this :+1:

Please correct me if you think I’m wrong, but my understanding is that there is no requirement for an invoice to be issued and then cancelled, in order to explain a break in the sequence. It’s fine to have a break (with a never issued invoice) as long as you can explain why. Breww helps make sure you can always do this by not letting you delete an order/invoice and thereby guaranteeing you always have the record of what happened to that number (which is what HMRC are getting at).

The below quote is from HMRC’s website:

My previous business to Breww, used the same approach of one-to-one invoice and order numbers (again with them being the same number), which of course resulted in gaps in the sequence (with never-issued invoices) and the invoice numbers being issued “out of turn”. This business has been audited for a number of years now by PWC (as a legal requirement) and this wasn’t ever a concern as we had records of what happened to these “missing invoices”. As with Breww, this was in our management platform only and not in our accounting platform. Based on this, I’m confident that what we’re doing with Breww is perfectly acceptable to HMRC and would pass an audit.

I fully agree with you that Breww could do this differently, but just wanted to clarify that what Breww does now is acceptable to HMRC and there is no legal requirement for this to be changed. Thank you :smile: