In proper accounting practices, you don't reverse or void any invoice -- you add transactions on top of it instead: payments, chargebacks, and other adjustments.  You basically have to include all activities that occur to that invoice, otherwise you can't tell how much you owe or are owed.  This is almost like real accounting.  The potential complexity of this setup may be why Richard hasn't made another course on this.

If you run a business, you probably know all this already.  There is no way to make this simple, because real life occurrences which decide how your database need to be set up and which you have no control over are rarely simple.  Suppose you owe a customer $100 refund due to defective items you sold him.  But what if he owes you $200 unpaid invoices from past orders?  He should pay you instead.  What if he pays you only $50, but then places another $100 order, then returns $80 of the goods due to defects, then, then...  You get the picture.  Things can get complicated fast.  You need something like an accounting system to keep track of things.  Or you keep track of them all in your head, which is an impossibility if you have hundreds or thousands of customers.  What's more, that are dating factors involved.  Some invoices may be due 3 months from now, 3 weeks from now, right now, or 2 weeks past due, 2 months past due...etc.  How much does a particular owe you at any particular point in time?  if you don't know that, how do you know what refund to give him, if any?  You need a system to do that.

Richard's invoicing lesson is only about creating that invoice.  But once you have other activities attached to that invoice, it becomes an entirely different project.

Yeah, essentially, but I would do to keep in the framework of how the databases built is to create a second order that's basically a reversal of the first one. You never want to delete an order, so let's say you've got a customer that buys a hard drive for $100 and then a week later wants to return it. You wouldn't change the original order because it's got the order date, the amount paid, probably is credit card information, all that stuff. So you would create another order in the system and somehow mark it as a refund, maybe an IsRefund field. And then for the amount, you'd put a refund line item for -$100, and that would also negate any sales tax and other adjustments. And then you process that and save that in the system. So overall, your accounting would show zero net gain, but you have a history of all those transactions. I have covered this in my Developer lessons, but yeah, I'm going to put together a simple video on how to do this for the TechHelp people too 'cause it's been asked a bunch of times. And yeah, Kevin's right, and proper accounting practices, you never delete anything.